Accountability sits with the organisation’s identity, security, and system owners because access governance is a control responsibility, not just a tooling choice. Leadership should expect clear ownership for provisioning, offboarding, exception handling, and monitoring. If former employees retain access, that indicates a process failure that must be tracked, measured, and remediated.
Why This Matters for Security Teams
When former employees still have access, the failure is rarely just a missed checkbox. It usually reflects broken ownership across identity operations, security review, and system administration, especially where offboarding is fragmented across SaaS apps, cloud consoles, and service accounts. That is why NHI Management Group treats access revocation as a control issue, not a tooling preference, and why the OWASP Non-Human Identity Top 10 is useful here even for human lifecycle failures.
The same pattern appears in NHI governance: access often persists because no one owns the full lifecycle. In the Ultimate Guide to NHIs, NHI Mgmt Group notes that only 20% of organisations have formal offboarding and API key revocation processes, and 91.6% of secrets remain valid five days after notification. That gap matters because stale access is not theoretical; it creates a standing path back into systems after employment ends. In practice, many security teams encounter this only after a former employee has already used retained access, rather than through intentional offboarding design.
How It Works in Practice
Accountability should be assigned by control domain, not by assumption. Identity owners are responsible for joiner-mover-leaver workflows, security owners define minimum control requirements, and system owners must ensure each application, vault, CI/CD pipeline, and cloud tenant actually enforces revocation. The control model should cover human accounts, privileged roles, API keys, tokens, and any delegated access path that can outlive the employee.
Operationally, the best practice is to break the problem into four linked actions:
- Trigger offboarding from a single authoritative HR or workforce event.
- Revoke interactive access, privileged roles, and session tokens immediately.
- Rotate shared secrets, service credentials, and automation tokens that may have been known to the departing employee.
- Verify closure with logging, reconciliation, and exception tracking across all connected systems.
That model aligns with the access governance emphasis in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where organisations need evidence that revocation is not just requested but completed. It also maps to NHI-specific lifecycle discipline in the 52 NHI Breaches Analysis, where stale credentials and weak ownership repeatedly turn into real incidents. Mature programmes measure time to revoke, time to rotate, and the percentage of systems covered by automated offboarding checks. These controls tend to break down when access is spread across shadow IT, unmanaged SaaS tenants, and manually maintained exceptions because no single owner can attest to full coverage.
Common Variations and Edge Cases
Tighter revocation controls often increase operational overhead, requiring organisations to balance speed of offboarding against the risk of breaking active business processes. That tradeoff is especially visible when former employees built automations, managed shared inboxes, or owned production scripts that other teams still depend on.
Current guidance suggests treating these cases as exception-managed, time-bound risks rather than permanent access continuations. If a departing employee’s access is needed to support handover, it should be converted into a documented, short-lived exception with explicit approver, expiry, and post-transition review. The same discipline applies when access is embedded in service accounts or machine credentials, because a human departure may reveal a larger NHI governance gap. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it shows how excessive privileges and poor visibility make cleanup harder than teams expect.
There is no universal standard for this yet, but the practical test is simple: if a system cannot prove revocation within the organisation’s required timeframe, it is not under effective control. That is why accountable owners should be named before a departure occurs, not after an audit or incident exposes the gap.
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-63, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Directly covers identity lifecycle and access authorisation management. |
| NIST SP 800-63 | Supports identity proofing and authenticator lifecycle discipline for account deprovisioning. | |
| NIST AI RMF | GOVERN | Accountability and oversight are core to governance of automated access decisions. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Stale secrets and missed revocation are classic NHI lifecycle failures. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification, not assumed trust after departure. |
Define accountable owners for access governance, exceptions, and monitoring, then track closure metrics.
Related resources from NHI Mgmt Group
- Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?
- Who should be accountable when identity teams expand access governance to unstructured data and SaaS activity insights?
- Why do traditional IAM and SSO controls still leave access gaps in modern environments?
- Who is accountable when access paths outside IAM and SSO create compliance or security gaps?
