Static SSH keys behave like unmanaged non-human identities because they outlive the people and processes that created them. They are hard to inventory, slow to revoke, and easy to copy or reuse. That makes them a governance problem as much as a technical one, especially when cleanup after offboarding is inconsistent.
Why This Matters for Security Teams
Static SSH keys are not just an authentication convenience. They create a durable identity surface that often sits outside normal lifecycle controls, which is exactly why they become an nhi governance issue. Once a key is embedded in scripts, images, jump hosts, or automation pipelines, it can behave like a permanent credential with no natural owner, weak traceability, and no reliable retirement path. That is the opposite of what modern identity governance expects, as described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and NIST Cybersecurity Framework 2.0. The risk is not theoretical: NHI governance depends on being able to inventory, scope, rotate, and revoke identities with confidence. Static SSH keys undermine all four.
This becomes more serious when teams rely on them for machine-to-machine administration, CI/CD access, or third-party support. The credential may be valid long after the original business need has changed, and that creates exposure during offboarding, incident response, and audit. In practice, many security teams encounter stale SSH keys only after an unrelated compromise, rather than through intentional identity cleanup.
How It Works in Practice
The governance problem starts with persistence. A static SSH key usually has no built-in expiry, so its value is tied to whatever systems still trust it, not to any explicit policy. That means revocation depends on finding every copy, every authorized_keys file, every automation job, and every inherited image that may contain it. If one copy survives, the identity survives.
Current guidance suggests treating SSH keys as managed NHI secrets, not as informal admin shortcuts. That means assigning ownership, mapping each key to a workload or operator function, and applying rotation and revocation as standard controls. The NHI lifecycle model in Ultimate Guide to NHIs is useful here because it frames creation, use, monitoring, and decommissioning as separate governance steps. NIST also emphasizes continuous identity and access management in NIST Cybersecurity Framework 2.0, which is the right mental model for long-lived machine credentials.
A practical control set usually includes:
- Inventory every SSH key and tie it to a named workload, owner, or service ticket.
- Replace shared keys with unique keys per system or automation context.
- Rotate keys on a schedule and after any role change, vendor change, or incident.
- Remove keys from golden images, templates, and unattended scripts.
- Prefer short-lived access paths where operationally feasible.
That approach matters because NHI compromise patterns are common enough to be operationally relevant: the State of Non-Human Identity Security reports that 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks. These controls tend to break down in legacy Unix estates and vendor-managed appliances because key sprawl and manual change windows make revocation slow and incomplete.
Common Variations and Edge Cases
Tighter SSH governance often increases operational overhead, so organisations have to balance access speed against cleanup certainty. That tradeoff is real in environments where automation depends on stable trust relationships, such as legacy clusters, embedded devices, or cross-team support channels.
There is no universal standard for this yet, but best practice is evolving toward short-lived credentials and stronger workload identity. For some use cases, SSH certificates or brokered access can reduce standing risk, while for others the better answer is to remove SSH entirely from routine machine access. The exact control depends on the environment and the blast radius of compromise.
One common edge case is emergency access. Teams sometimes keep static keys for break-glass operations, but those keys should be separately governed, heavily monitored, and time-bounded in process even if the platform cannot enforce expiry. Another edge case is shared platform automation, where one key services many jobs. That pattern is efficient, but it creates a hidden NHI concentration risk and should be broken into narrower identities where possible, as noted in Top 10 NHI Issues and the breach patterns discussed in 52 NHI Breaches Analysis. In practice, static SSH keys become hardest to govern when they are baked into infrastructure that no one still wants to own.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Static keys need rotation, which this control directly addresses. |
| NIST CSF 2.0 | PR.AC-1 | SSH keys are access credentials that must be identified and managed. |
| NIST AI RMF | Governance of persistent machine credentials supports accountability and risk management. |
Use AI RMF governance practices to assign ownership, monitor usage, and define revocation rules for machine identities.
