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.
Why This Matters for Security Teams
Device retirement is not just an asset disposal task, and identity offboarding is not just an account cleanup task. When those processes are separated, the endpoint can retain valid tokens, cached credentials, VPN profiles, certificates, or local trust relationships long after the device is considered retired. That creates a lingering access path that bypasses the normal change control that security teams expect.
This is a classic lifecycle failure: the hardware may leave inventory, but the identity tied to that hardware can still be trusted by cloud apps, SaaS platforms, or internal systems. NHI Management Group has documented how weak lifecycle practices amplify exposure, especially when organisations lack visibility into service accounts and secrets, as reflected in the Ultimate Guide to NHIs. The broader risk posture also aligns with NIST Cybersecurity Framework 2.0, which treats asset management and identity control as linked operational disciplines rather than separate clean-up activities.
In practice, many security teams encounter the exposure only after a decommissioned device is reused, resold, or quietly reconnected to the network.
How It Works in Practice
Effective offboarding treats the device and its identity footprint as one chain of trust. The retirement workflow should begin before the device leaves service: identify every credential, certificate, session token, key store, mobile management enrollment, and local application cache associated with that endpoint. Then revoke or expire the identity artefacts at the same time the hardware is wiped, recovered, or disabled.
Current guidance suggests that security teams should make revocation event-driven, not calendar-driven. If a laptop, kiosk, phone, or embedded device is retired, the identity lifecycle should trigger immediate actions such as certificate revocation, token invalidation, MDM unenrollment, password rotation, and removal from allowlists. For non-human and device-like workloads, the same logic applies to workload identities, which is why lifecycle discipline is central in the NHI Lifecycle Management Guide and in the identity lifecycle controls described in the Ultimate Guide to NHIs.
- Wipe local secrets before custody transfer, resale, or disposal.
- Revoke cloud tokens and certificates at the same change window.
- Disable device enrollment and remote management bindings.
- Confirm downstream app access has been removed, not merely hidden in inventory.
- Audit for duplicate credentials stored outside formal secret management.
Where possible, automation should tie CMDB decommission events to identity and secret revocation workflows so that no single team must remember every dependency. These controls tend to break down in federated environments where device ownership, cloud identity, and application administration sit in different teams because no single workflow owns the full trust chain.
Common Variations and Edge Cases
Tighter offboarding often increases operational overhead, requiring organisations to balance speed of retirement against the risk of leaving behind usable trust. That tradeoff becomes sharper in environments with BYOD, shared tablets, industrial endpoints, field devices, or contractor-managed hardware, where the organisation may not control every local credential store or recovery path.
Best practice is evolving for these edge cases. There is no universal standard for exactly how much proof is required before a device can be considered safely retired, but the safest pattern is to verify both physical custody and identity revocation. For example, a device that is factory-reset but still enrolled in MDM is not truly offboarded. Likewise, a badge reader, kiosk, or IoT device may be physically removed while its certificate still authenticates to a backend service.
This is why lifecycle governance should include exception handling for lost devices, emergency retirements, and partial decommissioning. The security team should also track where device secrets are duplicated, because leaked copies often survive the formal offboarding step. Research from NHI Management Group also shows how common lifecycle weaknesses are in the field, including offboarding gaps described in the Top 10 NHI Issues. In mixed estates, the model fails when ownership is unclear and revocation cannot be confirmed end to end.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers secret rotation and revocation during lifecycle events. |
| NIST CSF 2.0 | PR.AA-5 | Identity lifecycle and access revocation support authenticated asset decommissioning. |
| NIST AI RMF | Lifecycle governance for autonomous systems depends on accountable identity teardown. |
Link asset retirement to access removal so no decommissioned device keeps trusted access.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
