Join our Newsletter — 33% off our NHI Course
Home FAQ Architecture & Implementation What happens when an employee leaves but privileged…
Architecture & Implementation

What happens when an employee leaves but privileged access is not removed immediately?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated September 1, 2026 Domain: Architecture & Implementation

If privileged access survives the exit, the former employee may still reach high-value systems, sensitive data, or administrative functions. That can enable deliberate abuse, accidental exposure, or simple account misuse if credentials were shared or reused. The business impact is broader than one account. It can include data loss, sabotage, failed audits, and a weakened trust model across the environment.

Why This Matters for Security Teams

When an employee exits and privileged access is still active, the problem is not just an account that was forgotten. It is a live trust path into systems, data, and administrative functions that should no longer be reachable. That creates immediate exposure to misuse, whether the former employee is malicious, careless, or simply unaware that access still works. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotation, which shows how often exit controls lag behind reality.

This issue also overlaps with the broader non-human identity problem, where privileged credentials often outlive the people who created or used them. The same lifecycle discipline discussed in the Ultimate Guide to NHIs applies here: access must be discovered, validated, and removed across vaults, CI/CD, cloud consoles, and service accounts, not just in the HR system. Security teams also benefit from the control guidance in the OWASP Non-Human Identity Top 10, because stale privilege is often tied to unmanaged identities rather than a single directory record. In practice, many security teams discover the issue only after an audit finding, an unusual login, or a post-exit incident has already forced the review.

How It Works in Practice

Immediate removal should be treated as a coordinated entitlement shutdown, not a single deprovisioning step. The practical sequence is: identify every privileged identity tied to the person, revoke interactive access, invalidate active sessions, rotate any shared secrets, and confirm that downstream systems no longer trust the departed user’s credentials. That includes admin roles, break-glass access, SSH keys, API keys, tokens in secret managers, and any delegated permissions in SaaS tools.

Good offboarding also needs ownership. HR may trigger the event, but identity, security, application, and platform teams must each confirm their own controls. A mature process includes:

  • Immediate disablement of primary directory access and MFA factors
  • Session revocation for cloud, VPN, and privileged access management tools
  • Credential rotation where the employee knew shared secrets or operational passwords
  • Review of service accounts, scripts, and automation jobs the employee maintained
  • Ticket-based evidence that privileged access was removed within the required SLA

The control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls supports this by aligning offboarding with access enforcement, account management, and auditability. Where the person also touched non-human identities, the operational lesson from the 52 NHI Breaches Analysis is clear: the risk persists until the last valid credential and privilege path is closed, not merely until HR marks the employee as terminated. These controls tend to break down in environments with shared admin accounts, unmanaged cloud sprawl, or homegrown scripts that no one has fully inventoried.

Common Variations and Edge Cases

Tighter offboarding often increases operational overhead, requiring organisations to balance speed against the risk of breaking legitimate workflows. The most common exception is when the departed employee owned a shared operational account or an automation pipeline that several teams depend on. In those cases, simple removal can disrupt services, so the better answer is transfer, reissue, and rotate rather than preserve old access as a shortcut. Current guidance suggests that “temporary retention” should be rare, time-bound, and formally approved, but there is no universal standard for exactly how long that window may be.

Another edge case is contractor or seasonal access, where the exit date may be known but the account remains active because the system owner never confirms closure. That is a process failure, not a technical limitation. The same applies to privileged access embedded in scripts, CI/CD variables, or cloud roles that were never tied back to a named owner. The Ultimate Guide to NHIs — Key Challenges and Risks is useful here because it highlights how visibility gaps turn offboarding into guesswork. ISO/IEC 27001:2022 also reinforces the need for lifecycle-controlled access review, even though it does not prescribe a single offboarding workflow. In environments with heavy automation or shared privileged platforms, the real challenge is proving that every dependent credential was revoked without disrupting production.

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.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Stale privileged access often means NHI lifecycle and rotation controls failed.
NIST CSF 2.0PR.AC-4Access control and least privilege are directly implicated when exit revocation lags.
NIST SP 800-63Identity proofing and lifecycle termination matter when prior credentials remain usable.
NIST AI RMFGOVERNGovernance is needed to assign accountability for offboarding and residual access risk.
NIST Zero Trust (SP 800-207)SC-4Zero trust requires continuous trust re-evaluation, which stale access undermines.

Revoke and rotate all human-tied privileged identities at offboarding, then verify no active trust paths remain.

Deepen Your Knowledge

Sign up to our weekly newsletter — get 33% off our NHI Foundation Level Course

    NHIMG Editorial Note
    Reviewed and updated by the NHIMG editorial team on September 1, 2026.
    NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org