Revoke the key from every authorized_keys file, confirm no backups or copies remain in shared locations, and tie that removal to the offboarding workflow. A valid key is still an active credential even if the account owner is gone.
Why stale SSH keys stay risky after a user leaves
When a person leaves, the server-side key does not become harmless on its own. SSH access is controlled by the presence of a valid public key in authorized_keys, so any leftover copy remains an active login path until it is removed everywhere it exists, including home directories, shared jump hosts, backups, and scripts that may redeploy it.
Offboarding has to treat ssh key as credentials, not as documentation. The practical goal is to eliminate every surviving trust path that can still authenticate to production systems, then verify that the removal actually took effect across the environments where the key might have been copied or cached.
A useful way to think about the problem is that a departed user changes ownership, not cryptographic validity. The key can still work even when the human account is closed, which is why removal must be tied to the same lifecycle event that disables other access paths and not left to informal cleanup after the fact.
What “removed everywhere” really means
The first place to check is the obvious one, but it is rarely the only one. Keys can be present in multiple authorized_keys files, deployment artifacts, configuration management templates, bastion host copies, golden images, and backup snapshots. If any one of those locations can still repopulate the key, the credential is effectively still live.
That is why teams should pair direct revocation with a search for copies and a short validation step. A sane offboarding process confirms the key is absent from active servers, then confirms the same key fingerprint is not being reintroduced by automation or left behind in shared storage, version control, or recovery media.
In practice, this is an access governance issue as much as a server hygiene issue. The cleanest implementation is to make SSH key removal part of the offboarding workflow so the control happens at a predictable point, with ownership, timing, and verification assigned before the employee record is retired.
How to keep the control from failing in real environments
The common failure is treating server access as a local admin task instead of a lifecycle control. Teams remove the key from one host, but miss cloned systems, unmanaged servers, or automation that restores the old state during rebuilds. Another frequent miss is forgetting that shared admin accounts can preserve access long after the original user is gone.
A stronger pattern is to reduce the number of places where long-lived SSH keys are allowed to exist at all. Where possible, use centralized access mechanisms, short-lived access, or a managed key process so departure does not depend on finding every static file by hand. That reduces the blast radius when offboarding is delayed or incomplete.
For teams that already rely on keys, the operational discipline is to know which keys are attached to which servers, who owns them, and how they are removed. Without that inventory, revocation becomes guesswork. With it, offboarding becomes a bounded task rather than an incident-prone scavenger hunt.
Risk and Threat Considerations
Residual SSH keys create direct unauthorized-access risk. If the key is still accepted on a server, anyone holding a copy can continue to authenticate, which turns a personnel change into a standing credential exposure until the last copy is removed.
Failure mechanism: The key survives in one or more authorized locations, or is reintroduced by automation, backups, or shared storage, so the server continues to trust a credential that should have been retired.
Impact: An ex-user, contractor, or attacker with access to the copied key can still reach systems, move laterally, or reuse the key as a persistence mechanism even after the human relationship has ended.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys are authenticators that must be revoked and rotated on departure. |
| AC-2 — Account Management | Offboarding must remove access as part of lifecycle termination. | |
| IA-9 — Service Identification and Authentication | Server-side SSH access between systems depends on authenticated non-human access material. | |
| Recommendation — Revoke departed users' SSH authenticators and verify no remaining systems can accept them. Tie SSH key removal to account termination and offboarding workflow completion. Inventory and retire system-to-system SSH trust material with the same rigor as user access. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Key removal depends on maintaining and retiring identities and their authenticators. |
| A.5.18 — Access rights | SSH keys grant access rights that must be removed when no longer needed. | |
| Recommendation — Maintain an identity inventory that drives timely SSH key retirement on offboarding. Remove SSH access rights promptly and confirm they cannot be reissued from backups or copies. | ||
Practitioner Guidance
What to prioritise: Treat the key fingerprint as the unit of removal, not the user record. Revoke it on every server, then verify that deployment tooling, backup sets, and shared admin locations cannot republish it.
What to verify: Confirm the key is absent from active authorized_keys files and that no automation, golden image, or configuration repository can restore it on the next rebuild.
Decision rule: If the key can still authenticate to any production or privileged environment, treat the offboarding as incomplete until the credential is gone and the remaining access path is explained.
Practitioner takeaway: Offboarding is not complete when the employee leaves, it is complete when the last valid SSH trust path has been removed and the removal has been checked against every place that can recreate it.
Related resources from NHI Mgmt Group
- Why do SSH keys become a risk when teams manage many Linux servers?
- Why does password protecting SSH keys still matter even when teams use an SSH agent?
- What should security teams do first when SSH private keys may be exposed or duplicated across servers?
- How should security teams handle SSH key rotation in environments where keys are reused across many servers?