Why does SSH key sprawl make offboarding risky?

Why SSH key sprawl turns offboarding into an access persistence problem

SSH key sprawl changes offboarding from a simple account closure task into a hunt across hosts, environments, automation jobs, and shared admin paths. When the same key pair is reused or copied widely, removing one account does not remove the underlying access path, so former staff or contractors can still authenticate if any authorized_keys entry remains in place.

That is why offboarding has to cover both the person and the keys they used. A leaver may no longer have a directory account, but a stale private key can still unlock access to servers, bastions, jump hosts, and legacy scripts unless those trust points are found and removed.

Where hidden SSH keys keep access alive after a leaver exits

The main failure mode is incomplete inventory. SSH keys often accumulate in home directories, shared service accounts, configuration management, CI jobs, cloud-init scripts, and backup or bootstrap images, which makes them easy to miss during a manual review. NHIMG’s SSH Key and SSH Certificate Management Guide is useful here because it treats key sprawl, orphaned keys, and authorized_keys governance as one operational problem.

Offboarding also becomes riskier when teams rely on static keys instead of short-lived access. If a key has been copied into multiple authorized_keys files, removing the user record or disabling one login path does not guarantee the key has disappeared from every server, which leaves a silent backdoor until the last copy is removed.

For teams that have already moved toward certificate-based SSH, the control shifts from chasing many static keys to managing a smaller set of trust anchors and revocation paths. The SSH Protocol and Certificate Authority Guide is relevant because it explains how certificate authorities, revocation lists, and phased rollout reduce the persistence problem created by scattered authorized keys.

What good offboarding looks like when SSH access must be removed everywhere

Effective offboarding starts with discovery, not deletion. You need to identify where the leaver’s public keys were installed, which shared accounts or automation identities can still use them, and whether any privileged path depends on the same material. The Employee Offboarding Security Guide is a good operational reference because it ties leaver handling to session revocation, token removal, and owned non-human access as part of the same process.

The practical sequence is to remove keys from authorized_keys files, rotate any shared credentials that may have been known to the leaver, and confirm that no automation account or bastion path still accepts the old material. If SSH access is managed through a broader privileged access model, the Unix and Linux Privileged Access Guide helps connect key removal to root governance, scoped sudo, and SSH certificate controls.

Offboarding is strongest when it is measurable. If you cannot prove where a key was used, who owns the corresponding account, and when it was last active, you do not have a reliable leaver process. That is especially important for contractor exits, where access may have been granted outside the normal HR workflow.

Risk and Threat Considerations

SSH key sprawl creates durable unauthorized access because the credential object is copied, not centrally enforced. A former employee’s private key can remain valid on one forgotten host, one old automation account, or one overlooked bastion long after HR believes access has ended.

Failure mechanism: One reused key pair is installed in many places, and offboarding removes only the obvious account while stale authorized_keys entries, shared accounts, or automation references continue to accept the old key.

Impact: The leaver process becomes a false negative, because access survives with no password reset prompt, no obvious lockout event, and potentially no immediate alert if the stale key is still trusted by a server.

Practitioner Guidance

What to prioritise: Start with hosts and accounts that can reach production, administrative shells, and automation paths. If the key ever appeared in a privileged context, treat removal and rotation as urgent rather than as a routine cleanup task.

What to verify: Confirm that authorized_keys files, shared service accounts, CI jobs, and bastion trust paths no longer contain the leaver’s keys or any copy derived from them. Also verify that the same key was not reused for other systems before you close the case.

Common mistake: Deleting the user account and assuming SSH access is gone. With key sprawl, the account is often only one of several authentication paths, so the real control is removal of the key material everywhere it was trusted.

Practitioner takeaway: Offboarding is only complete when you can show that every remaining SSH trust path has been found, removed, or replaced, because one stale key is enough to preserve access.

Related resources from NHI Mgmt Group

• Who is accountable when a GitLab SSH key is left active after offboarding?
• How should security teams replace SSH key sprawl with a more scalable trust model?
• What happens when organisations move to the cloud without fixing SSH key sprawl first?
• What do teams get wrong when they try to fix SSH key sprawl too quickly?