Evaluate identity and access in device management by one test: does the right person, on a managed device, reach exactly the work resources their role needs, and does that access end the moment it should? Otukan answers it by linking each phone and tablet to a user from your directory, installing the certificates and settings that open Wi-Fi, VPN, email and work apps, and reporting device state to your identity provider. When a user changes role, leaves or loses a device, Otukan adjusts or withdraws that access and records it. Android and Apple devices are configured separately.
Fleet scope
Identity on a device depends on who owns it and how it is used. Otukan sets the identity model per device group with you before enrolment, because changing it later means enrolling the device again.
| Device group | Android (Android Enterprise) | iOS and iPadOS (Apple device management) |
|---|---|---|
| Assigned to one employee | Device assigned to a directory user; approved apps through a managed Google Play account or managed Google account | Supervised device assigned to a directory user |
| Personally owned | Work profile tied to the user; only the work side holds credentials | User Enrollment with a Managed Apple Account |
| Shared by several people | Device identity, with sign-in handled inside the work apps | Shared iPad with Managed Apple Accounts, where applicable |
| Dedicated to one task | Device identity with no personal account | Supervised device with Single App Mode, carrying a device identity |
Read the rows as intentions, not equivalents. Each platform decides what a management service may bind to a user and what it may see, and Otukan follows those rules on each side.
What a credential opens
Otukan delivers access as configuration rather than as something the user types: Wi-Fi and VPN profiles with a certificate issued for the device, email and calendar accounts, single sign-on settings for work apps, and the managed apps themselves. A user who never sees a shared password cannot pass it on.
Operating model
Identity has three authorities outside Otukan, and Otukan keeps each in its lane.
| Authority | Decides | Otukan’s part |
|---|---|---|
| Your directory | Who works for you and in which groups | Reads users and groups; never edits them |
| Your identity provider | Who may sign in to which service, and from which device state | Supplies each device’s managed and compliant status |
| Your certificate authority | Which certificates are valid | Requests certificates per device and asks for revocation at exit |
| Otukan device management | Which profiles, accounts and apps a device carries | Maps groups to access and applies changes |
The directory, identity provider and certificate authority remain your systems, operated by your teams or a partner you choose. How the management service works with your existing systems is covered on deployment and integrations. Otukan documents each connection, the role it uses and what it may read or change, so your security team can review it like any other privileged integration. How management reacts to security findings is covered on MDM security integration.
Lifecycle
Access has to be right on day one and still right on the last day. Otukan runs each stage below for the workflow you name, and tests it on a pilot group first.
| Stage | What Otukan does | What you confirm on the pilot |
|---|---|---|
| Provisioning | Assigns the device to its user during enrolment and installs the role’s certificates, accounts and apps | Wi-Fi, VPN, email and work apps work without the user typing a secret |
| Change | Swaps profiles when the user moves to another directory group | Old access disappears as the new access arrives |
| Recovery | Renews certificates before expiry and reissues them after a device reset | Connections continue through renewal and after re-enrolment |
| Offboarding | Withdraws certificates, work accounts and managed apps, and releases the device for reissue | Nothing work-related remains, and the record shows what was removed |
Proving it before rollout
On the pilot, Otukan runs a small set of scripted cases with your identity and security leads watching. A test user joins and receives a new device. The same user then moves to another department, reports the device lost, and finally leaves. After each step you check two things on the device itself and in your own systems: which access works, and which no longer does. The results, with times and screenshots, become the acceptance record for the identity workflow.
Lost and stolen devices follow the offboarding path at speed: credentials are revoked first, then the device is locked or wiped as its mode allows. The remote actions themselves are covered on MDM remote device management. The other capabilities are listed on capabilities.