Authorized keys persistence occurs when an attacker adds their SSH public key to a user or service account’s authorized_keys file. It creates durable remote access that survives password changes and many secret rotations unless the key material is explicitly removed.
Expanded Definition
authorized keys persistence is a post-compromise technique in SSH environments where an attacker plants a public key in an authorized_keys file, or in a related trust path such as a forced-command wrapper or centralized account provisioning pipeline. Unlike password theft, this method is designed to survive routine credential changes because SSH will continue to trust the inserted key until the entry is removed or the account is rebuilt.
In security operations, the term matters because persistence can hide inside normal administration activity. A legitimate-looking key entry may be added to a developer account, a service account, or a break-glass account, especially where access is managed informally. Guidance varies by environment, but the operational principle is consistent: durable SSH access must be treated as an identity control issue, not only an endpoint hardening issue. For a control baseline, see NIST SP 800-53 Rev 5 Security and Privacy Controls, which supports account, access, and audit discipline around privileged access paths. The most common misapplication is assuming a password reset removes access, which occurs when the attacker’s SSH key remains present in authorized_keys or an equivalent trust store.
Examples and Use Cases
Implementing SSH access controls rigorously often introduces operational friction, requiring organisations to balance administrator convenience against the need for rapid key inventory, review, and removal.
- A threat actor adds their key to a Linux admin account’s authorized_keys file after obtaining limited shell access, then returns later through the same SSH path.
- A compromised service account used for automation retains an attacker-controlled key even after the original password is changed, because the account still accepts key-based login.
- An unmanaged jump host contains a stale key left behind by a contractor, creating an access path that is indistinguishable from legitimate administration until it is audited.
- A centralized home-directory provisioning script copies a malicious or over-permissive key into new accounts, turning a setup workflow into a persistence mechanism.
- During incident response, a responder reviews ~/.ssh/authorized_keys, shared account directories, and any forced-command entries to confirm whether SSH trust has been altered. For reference on account and access governance, practitioners often align these checks with NIST SP 800-53 Rev 5 Security and Privacy Controls.
Why It Matters for Security Teams
Authorized keys persistence is important because it gives an attacker quiet, low-friction access that often evades the alert patterns associated with password compromise. If teams only monitor authentication failures or password changes, they can miss the fact that SSH is still accepting a trusted public key. This is especially relevant for privileged Linux estates, automation accounts, and NHI-heavy environments where keys may be reused across systems or embedded in deployment processes.
The identity security angle is significant: SSH keys are credentials, and in many environments they function as non-human identity material for automation, orchestration, and administrative access. That means key lifecycle, ownership, and revocation need the same rigor applied to other privileged credentials. Detection and response should include inventorying authorized_keys files, checking for unexpected key additions, reviewing provisioning systems, and correlating access logs with change records. NIST guidance on account management and auditability, together with identity assurance concepts in NIST SP 800-63 Digital Identity Guidelines, helps frame the issue as trust management rather than simple file hygiene. Organisations typically encounter the operational impact only after an account is re-used successfully despite password resets, at which point authorized keys persistence becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Covers identity and access control governance for persistent SSH trust paths. |
| NIST SP 800-53 Rev 5 | AC-2 | Defines account management expectations relevant to authorized key lifecycle control. |
Inventory SSH trust relationships and remove unapproved key-based access as part of access governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
