When access is not fully revoked, former staff can still reach production systems, shared accounts, and sensitive data long after termination. That creates exposure to misconfiguration, data deletion, unauthorized changes, and theft of intellectual property. The practical consequence is a longer period of risk, plus a harder incident response because ownership and access records are incomplete.
Why Revocation Fails When Privileged Access Is Left Behind
When technical staff leave, privileged infrastructure access should stop immediately across cloud consoles, virtualization layers, CI/CD, secrets stores, shared break-glass paths, VPNs, and any delegated admin tooling. If it does not, the organisation is not just carrying a paperwork issue; it is leaving an active trust relationship in place after the person who held it no longer has an employment relationship. That creates an avoidable window where legitimate-looking access can be used without obvious anomaly.
The practical problem is that infrastructure access is often distributed across more places than HR, IT, and security teams assume. A single offboarding miss can leave credentials valid in automation, shared admin accounts, or long-lived API tokens that were never tied cleanly to one owner. NHIMG’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful signal for how often lifecycle controls lag behind access reality. In practice, many security teams discover the gap only after the former staff member is already gone and nobody can prove where the access still works.
How Privileged Access Should Be Unwound in Practice
The right model is to treat departure as an access-lifecycle event, not a helpdesk cleanup task. Human directories, privileged access systems, cloud IAM, SSH keys, secrets managers, automation tokens, support portals, and local break-glass credentials all need separate verification because they fail independently. For infrastructure, the most important question is not whether the account was disabled in one system, but whether any path still exists that can reach production or modify sensitive assets.
Current best practice is to revoke in layers. First, remove the departing staff member from authoritative identity sources and privileged roles. Next, invalidate credentials that can still authenticate outside those directories, including static secrets, personal SSH keys, API tokens, and service-console sessions. Then rotate shared credentials and inspect automation for embedded access that may have been assigned informally during operations. That sequencing matters because revoking one control without rotating the others can leave the same privilege reachable through a different path.
Questions about ownership also matter. If an account or secret is shared, the organisation needs a named service owner and a clear record of where that access is used. Without that, offboarding becomes guesswork and recovery slows down. NHI lifecycle controls are especially relevant here because infrastructure access often outlives the employee who created it, and the replacement operator may not even know which credentials exist. The NHI Lifecycle Management Guide is useful because it frames this as inventory, ownership, rotation, and revocation rather than one-time deprovisioning.
- Verify every privileged path, not just the primary login account.
- Rotate shared credentials immediately when ownership is unclear.
- Check automation, scripts, and CI/CD jobs for embedded access.
- Confirm that audit logs still attribute activity to a valid owner.
These controls tend to break down in hybrid environments because infrastructure ownership is split across platforms, local admin rights, and machine-bound secrets that do not disappear when a person leaves.
What Common Edge Cases Make This Worse
Tighter offboarding often increases operational overhead, requiring organisations to balance rapid removal against service continuity. The hardest cases are shared administrative accounts, emergency break-glass credentials, vendor-supported systems, and legacy infrastructure where no one can prove which secret is still active. In those environments, a simple disablement event can interrupt operations, so teams delay revocation and keep expired access alive longer than they should.
There is no universal standard for this yet, but current guidance suggests treating any privileged credential without a confirmed owner, expiry date, or usage record as suspect. That is especially important for infrastructure that can mutate production state, because standing access in those systems has a much larger blast radius than a normal application account. For that reason, the most useful review is often not “who left?” but “which privileged paths still depend on a human memory rather than a controlled lifecycle?”
The highest-risk edge case is when a former staff member had access to both infrastructure and secrets management. In that situation, even a dormant account can still expose rotation gaps, recovery keys, or deployment credentials that were never reissued. NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant here because long-lived secrets are the ones most likely to survive a personnel change.
Risk and Threat Considerations
Leaving privileged infrastructure access in place after staff departure creates a material exposure window even when no attack is visible. The risk class is unauthorised access through forgotten credentials, shared admin paths, stale tokens, or incomplete ownership transfer. That exposure matters because infrastructure privileges often allow configuration changes, data access, service disruption, and credential harvesting.
Failure mechanism: Revocation usually fails when access is distributed across multiple control planes and the organisation only disables one of them. A former staff member, or anyone who later obtains their still-valid credential, can use legitimate authentication paths to act as an authorised operator. If shared accounts, static secrets, or automation tokens are not rotated, the organisation may also lose the ability to distinguish expected activity from misuse.
Impact: The most common consequences are unauthorised production changes, service interruption, data exposure, and delayed incident containment. In the worst case, the missing revocation becomes a persistence path that survives employment termination and forces responders to assume that any affected privileged credential may already be compromised.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | Lifecycle Management — Lifecycle Management | Access revocation and ownership gaps are core non-human identity lifecycle failures. |
| Recommendation — Inventory, revoke, and rotate every privileged machine credential when ownership changes. | ||
| CIS Controls v8 | 5 — Account Management | Leaving staff access active is a classic account lifecycle and offboarding failure. |
| Recommendation — Remove stale privileged accounts and verify deprovisioning across all systems. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Credential Management, Authentication, and Access Control | Revocation failure is an identity and access control breakdown affecting production trust. |
| Recommendation — Enforce immediate credential revocation and access validation after termination. | ||
| NIST Zero Trust (SP 800-207) | 3.1 — Access to Resources | Former staff should not retain implicit access to protected resources after departure. |
| Recommendation — Re-evaluate every resource request and deny access once trust changes. | ||
| MITRE ATT&CK | T1078 — Valid Accounts | Stale privileged credentials can be abused as valid accounts for authorised-looking access. |
| Recommendation — Hunt for continued use of valid accounts after offboarding or role changes. | ||
Practitioner Guidance
What to prioritise: Revoke the paths that can alter production first, not the accounts that are easiest to disable. If a credential can reach infrastructure, treat it as higher priority than a convenience login or non-production tool.
What to verify: Confirm that access has been removed from identity providers, privileged access tools, cloud consoles, secrets stores, and automation. A clean HR exit record is not sufficient evidence unless the technical paths have been checked independently.
Decision rule: If you cannot prove that a privileged credential is unused, rotate it. If you cannot prove who owns a shared account, remove or replace it before the next operational event forces a guess.
What good looks like: Every privileged access path has a named owner, an expiry or review point, and log evidence showing that revocation and rotation completed across all relevant systems.
Practitioner takeaway: The real objective is not merely to disable a departing person; it is to eliminate any surviving authority that can still touch production, especially when that authority is hidden in secrets and automation.
Related resources from NHI Mgmt Group
- What happens when privileged infrastructure access is not tied to stronger device and second-factor controls?
- What happens when an unused SaaS app still has access to patient data?
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
