When unauthorized SSH keys remain in authorized_keys, access control breaks at the point of trust. The server will continue to accept the attacker’s private key as valid, even after normal user activity changes. This can enable repeated logins, lateral movement, and difficult-to-detect persistence across cloud and server environments.
What actually breaks in the access model
Leaving an unauthorized public key in authorized_keys breaks the trust boundary at authentication. SSH no longer distinguishes between a key that should still be trusted and one that should have been revoked, so the server continues to grant access based on stale authorization. That turns key custody into a standing access path instead of a controlled one.
Operationally, the failure is not just “someone can log in.” It means the account’s access state is no longer tied to user intent, employment status, device state, or offboarding. In practice, an attacker who has the matching private key can reconnect whenever the service is reachable, even if passwords are changed and normal user activity has stopped.
The most common adjacent control failures are weak key inventory, poor offboarding, and missing review of stale keys. That is why Ultimate Guide to NHIs and the lifecycle processes for managing NHIs matter here: the same lifecycle discipline that applies to other long-lived access material also applies to ssh key, including discovery, ownership, rotation, and removal.
Why stale SSH keys create persistence and lateral movement risk
An unauthorized key in authorized_keys is a durable access mechanism because it can survive routine account changes. If the key is present on a jump host, admin box, or server with broad reach, the issue expands from a single account compromise into a reliable foothold for reuse, lateral movement, and quiet re-entry after defenders believe access was contained.
This risk is especially serious in cloud and hybrid estates where SSH is used for break-glass access, automation, or privileged administration. A stale key can preserve access across rebuilds, temporary credential resets, and many “normal” remediation steps that do not explicitly remove the public key from the server side.
For readers mapping the issue to broader control failures, the Top 10 NHI Issues and key challenges and risks sections both surface the same pattern: long-lived credentials and incomplete revocation are a persistence problem, not just an administration problem.
Using one relevant stat from NHIMG’s research, 91.6% of secrets remain valid five days after notification, which is a useful reminder that revocation is often slower than defenders assume. SSH keys are only safe when removal is prompt, complete, and verified on every host that accepts them.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | SSH keys are authentication material that directly govern access to systems. |
| PR.AA-03 — Remote Access is Managed | SSH is a remote access path whose trust must be tightly controlled. | |
| PR.PS-02 — Identity Management, Authentication, and Access Control | Stale keys break authentication and access control enforcement. | |
| Recommendation — Inventory and revoke unauthorized SSH keys as part of access governance. Restrict and continuously review SSH-based remote access paths. Apply least-privilege access controls and remove stale authenticators promptly. | ||
| CIS Controls v8 | 5.3 — Disable Dormant Accounts | Unauthorized keys preserve access even when user activity changes or stops. |
| 6.3 — Manage Authentication Factors | SSH keys function as authenticators that must be controlled and rotated. | |
| 6.8 — Untrusted Credentials | An unauthorized key is an untrusted credential embedded in a trust store. | |
| Recommendation — Remove inactive access paths and verify account authorization state regularly. Track, rotate, and revoke SSH keys with the same rigor as other authenticators. Detect and remove untrusted credentials from authorized access stores. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Management | SSH keys are credential material and become a persistence risk when left authorized. |
| NHI-04 — Lifecycle and Offboarding | The issue is fundamentally a failure to deprovision access material on time. | |
| NHI-06 — Privilege and Access Governance | Stale authorized keys preserve access and can enable lateral movement. | |
| Recommendation — Revoke unauthorized SSH keys and manage them through a formal credential lifecycle. Ensure offboarding removes SSH keys from every host and automation path. Review SSH key access scope and remove any privilege that exceeds need. | ||
| MITRE ATT&CK | T1021.004 — Remote Services: SSH | Unauthorized SSH keys are used to maintain remote access and move laterally. |
| Recommendation — Monitor SSH remote access for unauthorized persistence and lateral movement. | ||
Practitioner Guidance
What to verify: Confirm that the public key has been removed from every authorized host, not just from the account owner’s workstation or ticket record. A key is still active if any reachable system accepts it, so validation must include the actual server-side trust store, automation targets, and any copied or templated account state.
Decision rule: If the key can authenticate to any privileged or persistent system, treat it as an active access path and rotate or revoke before assuming the account is safe. If the key was used for automation, assess whether the replacement path is documented and whether the new key material is narrower in scope than the one being retired.
Common mistake: Teams often reset passwords and declare the account remediated while leaving public keys behind. That leaves an alternate authentication path in place, which is why SSH key cleanup must be part of offboarding, incident response, and routine access review rather than an afterthought.
Practitioner takeaway: The control objective is not merely to remove a suspicious key, it is to prove that no untrusted public key remains capable of authenticating anywhere the account can reach.
