When offboarding does not include SSH key revocation, former users may retain access to servers, scripts, and automated workflows long after they leave. That creates hidden backdoor access and makes it harder to prove control over privileged identities. A complete exit process should remove keys, rotate shared credentials, and confirm that trust relationships are broken.
Why Unrevoked SSH Keys Create Persistent Access After Offboarding
ssh key are a form of privileged authentication material, so if they survive employee offboarding they can still open operational systems long after a person’s employment ends. The practical problem is not just “old access”; it is continued trust in an identity path that should have been broken. That makes offboarding a security control, not an HR formality.
In environments where keys are reused across servers, automation, or admin jump paths, a missed revocation can leave access active in places that are rarely reviewed. The risk grows when the key is embedded in scripts or used by shared accounts, because the original human owner may no longer be visible in day-to-day administration.
For teams dealing with key lifecycles and rotation, the underlying issue is the same whether the key is for a person or for a machine workflow: the trust relationship must end cleanly, and the replacement state must be known. NHI Lifecycle Management Guide and Ultimate Guide to NHIs both frame that lifecycle discipline around provisioning, rotation, and offboarding.
Where the Exposure Shows Up in Real Operations
The most immediate exposure is unauthorized server access, but the downstream effect is broader. A leftover key can reach scripts, deployment hosts, bastions, and automation jobs that were never intended to outlive the employee, so the blast radius can extend well beyond a single login session.
Offboarding gaps also create visibility problems. If the key still works, logs may show a valid authentication event even though the user is no longer authorized, which complicates investigation and weakens confidence in access reviews. This is why key removal should be paired with inventorying where the key is trusted, not just deleting a user record.
A useful mental model is to treat SSH keys as part of credential hygiene and not as a narrow endpoint setting. When a key is tied to long-lived access, the same failure mode appears in many places at once, which is why broad lifecycle guidance such as Guide to the Secret Sprawl Challenge is relevant to the operational problem of stale access material.
What Good Offboarding Requires for SSH Keys
Good practice is to revoke the key at the source, remove any copied public key material from authorized_keys stores, and rotate any shared credentials that the departing employee could still reach. If the key was used in automation, that workflow must be reassigned or reissued so the automation does not silently keep authenticating with inherited trust.
Offboarding should also include a check for key reuse. A key that works on one system often works on several, so confirmation needs to cover every trust boundary where the key was accepted, including legacy servers, staging environments, and jump hosts. In many cases, the right control is not only revocation, but also replacing long-lived keys with shorter-lived access paths where feasible.
For teams that struggle with rotation at scale, the control objective is to shorten credential lifetime and reduce dependency on a single static secret. Guide to NHI Rotation Challenges and Ultimate Guide to NHIs, Static vs Dynamic Secrets are useful references for that rotation and lifetime problem. NIST SP 800-57 Key Management also supports the broader principle that cryptographic material should be governed through lifecycle and cryptoperiod discipline.
Risk and Threat Considerations
Unrevoked SSH keys can become hidden persistence for a former employee or anyone who obtains the key later. The same trust path that was legitimate during employment can be abused after separation, which turns an offboarding miss into a durable access-control failure.
Failure mechanism: The organization removes the human account but leaves one or more trusted SSH public keys in place, or fails to rotate shared access that the key can still reach. Because SSH access often bypasses higher-level application controls, the leftover key can keep authenticating until someone explicitly finds and removes it.
Impact: An attacker or disgruntled former user may retain server access, modify scripts or deployments, exfiltrate data, or create new persistence paths. At scale, the result is weak assurance that privileged access has actually ended, which is especially damaging when keys are reused across automation and administrative workflows.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Unrevoked SSH keys are a classic offboarding failure that leaves access alive. |
| NHI-07 — Long-Lived Secrets | SSH keys are long-lived authentication material when not rotated or retired on exit. | |
| NHI-05 — Overprivileged NHI | Leftover keys often retain broad server access beyond the former employee's need. | |
| Recommendation — Revoke SSH keys and verify every trusted host no longer accepts the departed identity. Shorten key lifetime and replace static SSH access with expiring credentials where possible. Reduce the remaining key's privilege footprint before decommissioning the access path. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys are authenticators whose issuance, rotation and revocation must be controlled. |
| IA-2 — Identification and Authentication (Organizational Users) | Employee SSH access is an organizational-user authentication issue with direct offboarding impact. | |
| AC-2 — Account Management | Offboarding depends on timely removal of accounts and related access paths. | |
| Recommendation — Remove or rotate authenticators promptly during offboarding and validate revocation across systems. Tie user deprovisioning to authentication disablement and access termination checks. Disable accounts and associated access paths immediately when employment ends. | ||
| NIST SP 800-57 | Recommendation for Key Management, Part 1: General | SSH keys are cryptographic keys whose lifecycle and replacement should be governed. |
| Recommendation — Apply key lifecycle discipline to rotation, replacement and retirement of SSH keys. | ||
Practitioner Guidance
What to verify: Confirm that offboarding includes a searchable inventory of SSH keys, their host scope, and their owners. If you cannot prove where a key was trusted, you cannot prove it was fully revoked.
Decision rule: If the key can authenticate to any production host, treat it as a privileged access artifact and prioritize removal plus password or credential rotation for any shared dependencies before closing the ticket.
Practitioner takeaway: The important question is not whether the employee is gone, but whether every path that still trusts their key has actually been broken.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 25, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
