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

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.

Related resources from NHI Mgmt Group

• Why do shared vaults create risk when organisations rely on standing credentials for privileged access?
• What are the signs that privileged access controls are failing in a distributed IT environment?
• What happens when a privileged account, a local login path, and plaintext credentials exist in the same application?
• What happens when employees use generative AI on broadly shared company files without proper access controls?