Treating Devices as Identities: How to Manage Their Lifecycle

Every access decision now carries 2 identity questions: who is the user, and which device are they using?

A device now plays a direct role in access decisions, helping determine whether a user can reach an application, whether a contractor can view regulated data, whether an admin session should begin, and whether auditors can trace what happened after an incident.

Okta’s recent article on device access security makes this point clearly: device identity is becoming a compliance control, especially for third-party access, sensitive-data access and forensic logging. NIST’s Zero Trust Architecture also treats authentication and authorization for both the subject and the device as separate functions before a session starts.

For our clients, the key question is: can we manage device identities with the same discipline we apply to users?

That starts with lifecycle control.

1. Create a device identity record

A device identity needs a reliable record before it can support access decisions.

At minimum, the record should include:

1. Device ID, serial number and platform
2. Assigned owner or business sponsor
3. Managed or unmanaged status
4. Enrolment source, such as UEM, MDM or EDR
5. Operating system and patch status
6. Encryption status
7. Endpoint protection status
8. Certificate status
9. Last seen date
10. Linked user identities
11. Access exceptions
12. Risk or compliance state

The goal is practical control. Security teams need to know whether the device is known, who is accountable for it, which controls are active, and whether it should reach protected applications.

This is where identity and endpoint teams need a shared data model. IAM may know the user. Omnissa Workspace ONE or another workspace platform may know the device. EDR may know the threat state. ITSM may know the owner and support process. A device identity model connects these records so that access policy can use them.

2. Define enrolment rules

Device lifecycle control starts before the device accesses anything important.

For corporate devices, enrolment should confirm ownership, management status, baseline configuration and certificate deployment. The device should be visible in the endpoint management platform and linked to the correct user or team.

For BYOD and third-party devices, the policy may be different. The organisation may not control the full device, so the minimum standard should be explicit. For example: current OS version, disk encryption, screen lock, supported browser, active endpoint protection and no jailbreak or root status.

The policy should also say which applications are blocked from unmanaged devices. Email may have one standard. Financial systems, privileged tools, customer data platforms and regulated workflows should have stricter rules.

3. Assign ownership and business context

A device identity without an owner creates weak accountability.

Every device should have an accountable owner. For employees, this is usually the assigned user.

For shared workstations, kiosks, service devices and contractor laptops, ownership may sit with a department, project sponsor or external partner manager.

This matters during access reviews and incidents. Security teams need to know who approved the device, who can confirm its use, who receives remediation tasks, and who approves removal when the device is no longer required.

Business context also matters. A laptop used by a payroll administrator does not carry the same access risk as a training-room device. A device used for privileged administration does not carry the same requirements as a standard office endpoint.

Treating devices as identities means joining technical inventory with access context.

4. Apply posture policy before access

A practical device posture policy should define clear states:

1. Known device: the device has a trusted record.
2. Managed device: the device is enrolled and controlled by the organisation or an approved platform.
3. Compliant device: the device meets security requirements, such as encryption, patch level, endpoint protection and screen lock.
4. Risky device: the device has failed a posture check, shows suspicious behaviour, has outdated controls, or has been reported lost.
5. Unknown device: the device has no reliable identity record.

Each state should trigger an access action. Unknown devices may be blocked from sensitive applications. Managed but non-compliant devices may require remediation before access. Risky devices may trigger session revocation or a new authentication challenge. Hardened devices may be required for privileged workflows.

This is where Okta can enforce access policy and where endpoint or workspace platforms can supply device posture. Omnissa’s Workspace ONE guidance for Okta shows practical integration patterns using Workspace ONE Access, Workspace ONE Tunnel, and API or event-based flows with Okta Workflow.

5. Review device access regularly

User access reviews are common in regulated environments. Device access reviews should follow the same discipline.

The review should answer:

1. Which devices accessed sensitive applications?
2. Which devices have exceptions?
3. Which devices are linked to privileged users?
4. Which devices have not checked in recently?
5. Which contractor devices still have access?
6. Which devices have changed owner?
7. Which devices failed posture checks repeatedly?

This gives IAM, endpoint, security operations and compliance teams one view of device-related access risk.

For auditors, this also creates evidence. The organisation can show that device access is reviewed, exceptions are tracked, and non-compliant devices are handled through a defined process.

6. Respond when a device becomes risky

Device identity must support action during an incident.

When a device becomes risky, the response should be defined in advance. The security team may need to revoke active sessions, block access to sensitive applications, require step-up authentication, quarantine the device, start endpoint investigation, open a service desk ticket or wipe corporate data.

The response should depend on the device state and the application risk. A failed posture check on a low-risk app may create a warning. A malware alert on a device with access to privileged systems should trigger stronger action.

The important part is coordination. IAM controls access. Endpoint teams manage the device. SOC teams investigate risk. Service desk teams guide the user. Legal or compliance teams may need evidence. A device identity lifecycle gives these teams the same facts to work from.

7. Retire device identities cleanly

Device offboarding is often where things start to slip.

When a device is replaced, lost, sold, reassigned or returned by a contractor, its identity should be closed properly. That means removing app access, revoking certificates, removing device trust, wiping corporate data when needed, updating inventory and keeping logs for the required retention period.

Retired devices should not remain in access policies as trusted endpoints. Old records create confusion during audits and can leave access paths open after the device has left normal control.

A clean retirement process should be part of every device lifecycle model.

A practical device lifecycle checklist

Security and IAM leaders can start with 10 questions:

1. Do we have a single reliable record for every device that accesses protected applications?
2. Can we link each device to an owner or business sponsor?
3. Do we classify devices by managed, compliant, risky, unknown and retired states?
4. Do access policies use device posture before granting access?
5. Do we apply stricter device rules for sensitive data and privileged workflows?
6. Can we block or revoke access when device posture changes?
7. Do third-party devices have clear onboarding and expiry rules?
8. Do we review device access and exceptions regularly?
9. Can we produce device-level evidence for audits and incidents?
10. Do we retire devices by revoking trust, certificates and access?

Where we add value

Managing the lifecycle of device identities spans IAM, endpoint management, workspace security, compliance, and operations. It requires clear architecture, seamless integration, and strong governance.

Cloudcomputing can support this through Zero Trust assessment, access policy design, Okta implementation, Omnissa Workspace ONE integration, device posture enforcement, audit evidence design and continuous improvement.

The objective to make every device visible, accountable and governed before it becomes part of an access decision.

For CISOs, CTOs and IAM leaders, treating devices as identities gives a practical way to close a common Zero Trust gap. It connects the user, the endpoint, the application and the evidence into one operating model.