Security teams should treat the authorized_keys file as a privileged control point, not a convenience feature. Restrict who can add keys, limit file permissions so only administrators can modify it, and monitor for unexpected changes. Periodic review matters because a malicious public key can create persistent passwordless access that is easy to overlook once installed.
Why SSH authorized keys become a persistence problem
SSH authorized keys are not just an access convenience, they are an authentication path that can outlast passwords, MFA resets, and even some account recovery actions if they are not governed tightly. Once a public key is placed in authorized_keys, it can provide quiet, passwordless entry until it is removed, rotated, or the account itself is disabled. That makes it a high-value persistence mechanism.
From a security operations perspective, the file is effectively an authorization ledger for SSH access. If attackers, contractors, or overbroad admin workflows can write to it, they can create durable access that may not trigger the same user-facing friction as interactive logins. Good control therefore focuses on who may modify keys, how changes are detected, and how old keys are retired.
Well-run teams treat authorized_keys as part of a broader access lifecycle, not a one-time setup artifact. That means key ownership should be known, changes should be attributable, and stale entries should be removed as soon as access is no longer justified. Ultimate Guide to NHIs covers the same lifecycle discipline for credentialed access, including governance, rotation, offboarding, and visibility.
Controls that reduce persistent unauthorized access
The most important control is to narrow write access to the file itself. Only trusted administrators or approved automation should be able to add or change authorized keys, and the file permissions should prevent ordinary users from editing it. On shared systems, that often means combining strict filesystem permissions with controlled deployment workflows rather than manual ad hoc edits.
Monitoring is the second essential control. Teams should alert on unexpected file changes, especially additions of new keys, changes outside maintenance windows, or edits to privileged accounts. If your environment supports it, keep a central record of approved keys so you can compare the live file against the expected state and spot drift quickly.
Review and removal matter just as much as initial placement. Keys that were added for troubleshooting, vendor support, or short-term administration often become permanent by accident. Periodic recertification should answer a simple question: does this key still need to exist on this host for this account? If not, remove it and verify that login no longer works.
For teams that want a broader identity control reference, OWASP Non-Human Identity Top 10 helps frame key hygiene, overprivilege, and lifecycle management as recurring control issues rather than one-off cleanup tasks. CIS Controls v8 is also useful where teams need a prescriptive account and access management baseline.
Risk and Threat Considerations
Unauthorized SSH keys are attractive because they create low-noise persistence. An attacker who adds a key once may keep access through credential resets, helpdesk activity, or user password changes, especially if the account remains enabled and the file is not monitored. The risk grows sharply when the account has administrative reach, shared use, or access to jump hosts and sensitive infrastructure.
Failure mechanism: the attacker or insider gains write access to authorized_keys, inserts a public key, and then uses SSH private-key authentication to return later without needing the original password or session.
Impact: persistent unauthorized access, difficult-to-detect reentry, privilege abuse, and potential lateral movement across systems that trust the same account or administrative workflow.
Because the persistence mechanism is simple and durable, teams should assume compromise is possible whenever key governance is weak. 52 NHI Breaches Analysis is a useful reminder that credential-based persistence often survives longer than defenders expect, and MITRE ATT&CK Enterprise Matrix provides the adversary technique context for credential access and lateral movement patterns that commonly follow unauthorized access.
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 CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | OWASP Non-Human Identity Top 10 | Authorized SSH keys are identity-bearing access material that must be governed tightly. |
| Recommendation — Apply OWASP NHI guidance to inventory, rotate, and retire SSH keys with clear ownership. | ||
| CIS Controls v8 | 6 — Access Control Management | SSH authorized keys are an access path that must be restricted and reviewed. |
| Recommendation — Enforce least privilege for key management and regularly review authorized SSH access. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Adding or altering authorized keys is a durable account persistence mechanism. |
| Recommendation — Detect unauthorized account changes and alert on new SSH key additions. | ||
| NIST CSF 2.0 | PR.AC — Access Control Management | SSH key governance is part of protecting access to systems and accounts. |
| Recommendation — Constrain SSH key write access and validate authorized access against policy. | ||
Practitioner Guidance
What to verify: confirm who can modify authorized_keys on every SSH-reachable system, and verify that the change path is logged and reviewable. If local administrators can edit the file directly without oversight, treat that as a control gap rather than an implementation detail.
Common mistake: teams often secure the SSH daemon but forget the file governance layer. Locking down SSH itself does not help if a stale or malicious key can still be added silently and left in place for months.
What good looks like: each key has an owner, a reason for existence, a review date, and a removal path. Stale keys are removed quickly, unexpected additions trigger alerting, and validation shows that deleted keys no longer authenticate.
Practitioner takeaway: the real control is not “SSH access exists,” it is whether every key is approved, attributable, monitored, and removable before it becomes a durable backdoor.
Related resources from NHI Mgmt Group
- How should security teams replace static SSH keys with short-lived access controls?
- How should security teams prevent unauthorized access across human and machine identities?
- How should security teams implement device-bound SSH access across large server fleets without relying on shared keys?
- How should security teams manage file transfer workflows when relying on cloud-based SSH access controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
