Device lifecycle management in 2026 exposes the identity gap

At a glance

What this is: This is a device lifecycle management guide that frames endpoint planning, provisioning, maintenance, and decommissioning as the core controls for keeping diverse device estates secure and usable.

Why it matters: It matters because device lifecycle failures often become identity failures too, especially where device access, user assignments, and retirement controls affect human, NHI, and autonomous programmes together.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Zluri's guide to device lifecycle management for 2026

Context

Device lifecycle management is the discipline of planning, provisioning, maintaining, and retiring devices so they remain secure and usable across their full service life. In identity terms, it is never just an IT asset problem, because device assignment, software access, and retirement decisions shape who or what can reach corporate systems.

The article treats laptops, tablets, smartphones, and IoT devices as parts of one operational estate, which is the right starting point for governance. The gap is that many enterprises still manage device status separately from access status, even though decommissioned hardware, stale user assignments, and unmanaged connected devices can all leave identity residue behind.

For identity teams, the useful question is not whether devices are managed, but whether the lifecycle process is connected to access governance, inventory accuracy, and secure disposal. That is the bridge between endpoint hygiene and NHI or human IAM control design, especially when the same endpoint is used to provision, authenticate, and retire access.

Key questions

Q: What breaks when device lifecycle management is not tied to identity governance?

A: When device lifecycle management is isolated from identity governance, organisations lose the ability to prove who used the device, what access it carried, and whether retirement actually removed trust. That creates residual access risk through cached credentials, retained software permissions, and incomplete offboarding. The control failure is usually not the asset record itself, but the missing link between device state and identity state.

Q: Why do device retirement and identity offboarding need to happen together?

A: They need to happen together because a retired device can still hold data, tokens, or local access paths that remain usable after IT thinks the asset is gone. If identity offboarding happens separately, the organisation may leave behind active trust in a supposedly decommissioned endpoint. That is especially risky when devices are reused, resold, or reconnected to cloud services.

Q: How do organisations know whether device provisioning is actually enforcing least privilege?

A: They know it is working when the device image, installed applications, local privileges, and assigned access match the user’s role and are reviewed as part of governance. If standard builds routinely include software or permissions that exceed role need, provisioning is creating excess entitlement rather than controlling it. The strongest signal is a provisioning record that can be audited end to end.

Q: What should security teams do when IoT devices reach end of life?

A: Security teams should require a formal retirement process that disables access, wipes data, removes credentials, and confirms the device is no longer trusted by the network. IoT devices often persist longer than expected because they sit inside business processes, so end of life has to be treated as an access event as well as an asset event.

Technical breakdown

Device lifecycle management as an identity control surface

Device lifecycle management is more than asset tracking. Every device has a state change, from procurement to provisioning to disposal, and each state change can alter trust, access, and exposure. If inventory is incomplete or user assignment data is stale, teams lose the ability to prove what the device is, who used it, and whether it still belongs in the environment. That is why lifecycle records matter to IAM and security teams, not only IT operations. A device that is retired without clean identity offboarding can still carry authenticated sessions, local tokens, or unmanaged software access paths.

Practical implication: tie device inventory records to identity and access workflows so retirement cannot happen without verified access removal.

Provisioning, access control, and role-based device assignment

Provisioning is the point where device identity and user identity converge. The article correctly notes that roles, software packages, and access levels should be aligned so users receive only what they need. In practice, that means provisioning is an authorisation event, not just imaging or setup. If provisioning is loosely governed, devices become a shortcut around least privilege, because local apps, cached credentials, and preinstalled tools can extend access beyond the intended role. For enterprises with mobile workforces or IoT estates, the same mistake spreads faster because the device may be used outside the corporate perimeter.

Practical implication: enforce role-based provisioning gates and verify that assigned software and access are logged as part of identity governance.

Decommissioning, secure disposal, and residual access

Decommissioning is the final control point, and it is where many lifecycle models fail. A device is not truly retired when it leaves procurement or is reassigned in a spreadsheet. It is retired only when the data is wiped, credentials are removed, accounts are disabled, and the asset is no longer trusted by the organisation. If any of those steps are missing, the device can remain a usable foothold for data recovery, token reuse, or unauthorised reconnection. For IoT devices, the problem is sharper because disposal often outlives active monitoring.

Practical implication: require proof of data wipe, credential removal, and trust revocation before any device leaves the active estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Device lifecycle management is becoming an identity governance problem, not just an asset management problem. The article shows that planning, provisioning, maintenance, and disposal all affect who or what can still use the device after the IT team thinks it is done. That makes lifecycle records part of the access control evidence chain, especially when endpoints carry cached credentials, local tokens, or app entitlements. Practitioners should treat device lifecycle and identity lifecycle as linked control planes, not adjacent processes.

Device provisioning is where least privilege either holds or leaks. The article’s focus on role-based device setup is the right mechanism, but the deeper point is that device assignment creates an access posture that can either reinforce or undermine IAM policy. If software bundles and permissions are standardised without verifying role need, the device becomes an entitlement container with more power than the user requires. Practitioners should treat provisioning as a governance checkpoint, not a deployment routine.

Secure decommissioning is the named failure mode this topic exposes: residual device trust after retirement. The device may be removed from circulation, but the trust relationship can survive through retained data, unreleased accounts, or unmanaged connected services. That means the control failure is not simply weak disposal hygiene, but incomplete trust revocation at the end of the lifecycle. Practitioners should make retirement evidence mandatory before any asset is considered closed.

IoT device lifecycle governance extends the same problem into a harder operating context. The article notes that IoT devices are heterogeneous, networked, and security-sensitive, which makes them harder to monitor and retire cleanly. Once those devices are tied to business processes, lifecycle mistakes can affect operational continuity as well as access control. Practitioners should assume that every connected device can become a long-lived identity artefact if offboarding is not explicitly governed.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• Another finding from the same research shows that 79% of organisations have experienced secrets leaks, and 77% of those incidents resulted in tangible damage.
• For teams handling device retirement and connected assets, the next step is to align lifecycle evidence with the NHI Lifecycle Management Guide so offboarding, rotation, and disposal are governed together.

What this signals

Device lifecycle discipline will increasingly be measured as an identity control, not an IT housekeeping task. As organisations connect provisioning, maintenance, and disposal to access workflows, the operational question becomes whether every device state change can be translated into a trustworthy identity event. That shift matters because lifecycle gaps are often where stale access survives longest.

The most useful programme signal is whether device retirement actually produces verifiable closure across inventory, credentials, and trust relationships. If those three do not close together, the organisation still has an identity problem even if the asset has been removed from service.

Residual device trust: when an endpoint is retired but its credentials, data, or service relationships remain usable, the organisation has not completed decommissioning. That concept is becoming central as fleets get more diverse and more connected, especially where mobile and IoT endpoints blur the line between hardware management and identity governance.

For practitioners

• Link device records to access records Connect asset inventory, user assignment, and entitlement data so provisioning and retirement are visible in the same governance workflow.
• Make decommissioning a controlled exit gate Require evidence of data wiping, account removal, and trust revocation before a device is marked retired or reassigned.
• Audit IoT devices separately from laptops and phones Classify IoT assets as a distinct lifecycle population because their firmware, connectivity, and retirement risks do not match standard endpoint handling.
• Treat provisioning as an authorisation step Verify that device configuration, installed software, and local access align to role need before the device is handed to a user.

Key takeaways

• Device lifecycle management is an identity-adjacent control surface because provisioning and retirement directly affect trust, access, and residual exposure.
• The biggest operational weakness is not the existence of device records but the failure to connect those records to offboarding, access removal, and secure disposal.
• Practitioners should treat provisioning and decommissioning as governance gates, not operational afterthoughts, if they want lifecycle controls to hold up under audit.

Key terms

• Device Lifecycle Management: The process of tracking a device from acquisition through provisioning, maintenance, and retirement. In identity governance terms, it is the control path that determines whether a device remains trusted, which users it supports, and whether any access or data survives after decommissioning.
• Secure Decommissioning: The controlled retirement of a device so it can no longer expose data, credentials, or access paths. In practice, this means wiping data, removing accounts or tokens, and confirming that the asset is no longer trusted by systems or operators.
• Residual Device Trust: Trust that continues to exist after a device should have been retired. It often appears when credentials, cached sessions, or linked services remain active, leaving the organisation exposed even though the hardware has left normal circulation.

Deepen your knowledge

Device lifecycle management and offboarding are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning endpoint retirement with identity governance, it is worth exploring.

This post draws on content published by Zluri: Lifecycle Management Device Lifecycle Management - A Guide for 2026. Read the original.