Accountability usually sits with IT, security, and the business owner of the offboarding process, because they are responsible for removing access and protecting data after employment ends. Organisations need clear ownership for device recovery, remote lock or wipe actions, and access revocation. Without assigned accountability, offboarding failures tend to repeat and become accepted as normal.
Why This Matters for Security Teams
When former employees still have access through unreturned devices, the issue is not only property recovery. It is an access governance failure that can expose data, credentials, and downstream systems long after HR has closed the file. In NHI Management Group research, only 20% of organisations have formal processes for offboarding and revoking API keys, and that same gap often appears in endpoint recovery and account closure.
The security risk is amplified when a device still holds active sessions, cached tokens, local secrets, or synced files. OWASP’s OWASP Non-Human Identity Top 10 and NIST control guidance both point to the same operational reality: identity and device state must be removed together, not as separate tasks. NHI Mgmt Group’s Ultimate Guide to NHIs shows how persistent credentials and weak offboarding create durable exposure that survives the employment relationship.
Accountability becomes clouded when HR, IT, security, and line-of-business owners each assume another team will disable access. In practice, many security teams discover the gap only after a former employee’s device is used to reach company data, rather than through a controlled offboarding process.
How It Works in Practice
Accountability should be assigned to the process owner for offboarding, with IT and security responsible for execution and the business owner responsible for confirming the person, device, and access path are fully removed. That means the workflow must cover more than badge returns. It should include device inventory, endpoint quarantine, remote lock or wipe, session termination, password resets, token revocation, and removal from collaboration and admin tools.
For managed environments, the best practice is to tie identity lifecycle events to endpoint management and access policy enforcement. If a laptop is unreturned, it should not remain a trusted access path to mail, files, VPN, SaaS apps, or privileged admin consoles. NIST SP 800-53 Rev. 5 control families reinforce this operational model through access enforcement, account management, and device protection requirements, while the Ultimate Guide to NHIs — Key Research and Survey Results highlights why lingering credentials are often valid long after discovery. Organisations should also define escalation timing, because delays turn a recoverable device issue into a data retention problem.
- Assign one process owner for offboarding accountability, even if multiple teams execute tasks.
- Trigger access revocation when employment ends, not when the device is finally recovered.
- Use remote wipe, MDM lock, and token/session revocation as parallel actions.
- Verify removal from VPN, email, file sharing, source code, and admin pathways.
- Log evidence of completion so exceptions cannot be normalised.
These controls tend to break down when devices are personally owned, unmanaged, or used offline because the organisation cannot reliably enforce revocation or validate data removal.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of employee exit with proof that access has actually ended. That tradeoff becomes harder when a former employee is remote, the device is off-network, or the organisation allows BYOD with limited endpoint control.
Current guidance suggests a risk-based approach in those cases. If the device cannot be recovered immediately, the organisation should still revoke all active sessions, rotate secrets that may have been cached locally, and remove any trust granted to that endpoint. Where legal or privacy constraints limit remote wipe, the accountability model should shift to documented containment, not informal assumption. This is especially important for privileged users, contractors, and employees who had access to sensitive systems or customer data. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often access problems persist after the original trust decision has expired.
There is no universal standard for this yet, but mature programs treat offboarding as a cross-functional control with a named owner, measurable closure criteria, and explicit exception handling. Without that, the organisation cannot prove whether the device is missing or whether the access problem is still live.
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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) 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-10 | Offboarding failures often leave identities and credentials active. |
| NIST CSF 2.0 | PR.AA-01 | Identity lifecycle control is central to ending access after employment. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management covers removal of access when users leave. |
| NIST Zero Trust (SP 800-207) | 4.1 | Zero Trust requires continuous verification, not trust in endpoints. |
| NIST AI RMF | GOVERN | Accountability and oversight are core to managing access risk. |
Assign explicit ownership for offboarding controls and track exceptions to closure.
