Accountability sits with the organisation’s lifecycle owners, because offboarding is part of the same identity governance chain as onboarding. The control should be tied to the leaver event, with deprovisioning verified before departure is complete. If that does not happen, access persists longer than the business relationship does.
Why This Matters for Security Teams
Former employee access is not just an HR cleanup issue. It is an identity lifecycle failure that can leave secrets, API keys, service accounts, and delegated permissions active after the business relationship ends. That matters because account ownership, entitlement review, and revocation are supposed to move together. When they do not, the organisation inherits an avoidable exposure window that attackers can exploit through stale credentials and forgotten integrations. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in its Ultimate Guide to NHIs.
The practical risk is broader than a disabled badge or deactivated email inbox. Access often persists in CI/CD pipelines, cloud consoles, vaults, and application-specific tokens that are not covered by basic HR termination workflows. OWASP’s Non-Human Identity Top 10 treats this as an NHI governance problem because stale machine access can outlive the user who created it. In practice, many security teams discover lingering access only after an audit, incident, or post-departure misuse, rather than through intentional offboarding control.
How It Works in Practice
Accountability should sit with the identity and application lifecycle owners, not with the departed employee. The reason is simple: offboarding requires coordinated action across IAM, PAM, secrets management, application owners, and the manager or business owner who approved the access in the first place. A clean process starts when the leaver event is triggered and ends only when deprovisioning is verified, including any inherited access, shared accounts, and non-human credentials.
In a mature process, the workflow typically includes:
- Immediate suspension of direct login access at the identity provider.
- Revocation or rotation of secrets, tokens, certificates, and API keys tied to that person.
- Review of privileged roles, group memberships, and delegated admin rights.
- Removal from CI/CD systems, cloud subscriptions, vaults, and SaaS app permissions.
- Evidence capture showing the access path was actually removed, not merely requested.
That verification step is critical. Current guidance suggests treating offboarding as incomplete until downstream systems confirm revocation, especially where identities are federated or access is provisioned through multiple layers. This is consistent with the lifecycle focus in the Ultimate Guide to NHIs — Key Challenges and Risks, and with NIST’s identity management emphasis on timely credential binding and unbinding in NIST SP 800-63B. If a former employee also created or owned machine identities, the cleanup must include those identities, because human offboarding alone does not retire non-human access.
These controls tend to break down in decentralised environments where application owners can mint their own tokens, cloud permissions are inherited through nested roles, or secrets are embedded in pipelines that no one inventory tracks.
Common Variations and Edge Cases
Tighter offboarding control often increases operational overhead, requiring organisations to balance rapid termination handling against the risk of breaking legitimate dependencies. That tradeoff is real in environments with shared service accounts, contractor rotations, mergers, or legacy systems that cannot support fine-grained revocation.
Best practice is evolving, but there is no universal standard for every edge case. Some teams use just-in-time access and short-lived credentials so the offboarding burden is reduced automatically; others rely on periodic attestations for systems that cannot yet support stronger lifecycle controls. The important distinction is whether access is revocable by design or only removable after manual detective work.
This is where NHIs frequently expose the gap between policy and reality. NHI Mgmt Group’s 52 NHI Breaches Analysis shows how often credential sprawl and stale access turn into incident material. If a former employee still holds access through a vendor integration, a cached token, or a shared admin account, accountability extends to the owner of that control path as well as the approving business function. That is why offboarding should be measured by confirmed revocation, not by the date the departure notice was issued.
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 SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Stale machine access after departure is a core NHI lifecycle weakness. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and revoked when employment ends. |
| NIST SP 800-63 | SP 800-63B | Digital identity lifecycle guidance supports timely credential deactivation and binding removal. |
Use identity proofing and authenticator lifecycle controls to disable access promptly at departure.
Related resources from NHI Mgmt Group
- Who is accountable when former employees still have SaaS access after offboarding?
- Who is accountable when a former employee still has access after leaving?
- Why do former employees still keep access after offboarding in many organisations?
- Who is accountable when former employees still have Microsoft 365 access?
