Who is accountable when an unmanaged SSH key causes an incident?

Accountability should sit with the team that owns machine identity governance, not only the system administrator who created the key. If a credential is unmanaged, the incident exposes a lifecycle failure in inventory, review, and revocation controls. In regulated environments, that also becomes an audit and evidence problem.

Why This Matters for Security Teams

An unmanaged ssh key is not just a technical loose end. It is evidence that machine identity governance failed somewhere in the lifecycle: issuance, inventory, ownership, review, rotation, or revocation. Accountability therefore belongs with the function that owns those controls, not only the administrator who originally created the key. That distinction matters because incidents created by unmanaged secrets usually surface after access has already expanded beyond the original intent.

The risk is amplified by the scale of the problem. NHI Management Group notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage in the Ultimate Guide to NHIs — Key Challenges and Risks. When SSH keys sit outside a governed lifecycle, they become permanent footholds for lateral movement, privilege escalation, and audit failure. NIST’s Cybersecurity Framework 2.0 treats identity protection and asset governance as core security outcomes, which is exactly why unmanaged keys are never just an ops inconvenience. In practice, many security teams encounter this only after an incident report forces them to reconstruct ownership from scattered logs and expired tribal knowledge.

How It Works in Practice

Accountability should be assigned to the team that owns the machine identity control plane, usually in partnership with platform engineering, IAM, or security operations. The incident question is not simply “who typed the command that created the key?” It is “who was responsible for ensuring the key had an owner, a purpose, a TTL, and a revocation path?” That operating model aligns with the lifecycle view in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

In mature environments, the response path usually includes:

• Assigning a business owner and technical owner to every SSH key or key pair.
• Maintaining inventory that maps keys to hosts, services, users, and repositories.
• Enforcing rotation, expiry, and revocation through policy rather than manual reminders.
• Logging issuance and use so investigators can distinguish misuse from unmanaged drift.
• Using PAM, secrets managers, or workload identity controls where static SSH access is no longer justified.

This is also where evidence quality becomes part of accountability. If no one can prove when the key was created, why it existed, or who approved its continued use, then governance has failed even if the compromise was detected quickly. Current guidance suggests treating SSH keys as regulated credentials, not informal admin conveniences, because unmanaged keys often bypass normal review gates. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives makes clear that this also becomes an auditability problem when retention, approval, and revocation evidence are missing. These controls tend to break down when keys are created ad hoc in scripts, CI/CD jobs, or emergency access workflows because ownership is never formalised.

Common Variations and Edge Cases

Tighter key governance often increases operational overhead, requiring organisations to balance speed of access against the risk of orphaned credentials. In emergency administration, developers, SREs, and contractors may each believe someone else owns the key, which is where accountability disputes usually start. In those cases, current guidance suggests using time-bound access and explicit approval records so the incident review can trace responsibility without ambiguity.

There is no universal standard for this yet, but the direction of best practice is clear: unmanaged SSH keys should be treated as a control failure, even when the immediate misuse was external. Some environments still permit long-lived keys for legacy systems, air-gapped hosts, or brittle vendor appliances. Those exceptions do not remove accountability; they shift it toward documented compensating controls, stricter review cadence, and stronger containment. NHI Management Group’s research on The 52 NHI breaches Report reinforces that identity incidents often persist because governance does not keep pace with operational reality. When teams cannot answer who owns the key, who approved it, and who can revoke it, the organisation has already lost control of the asset.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access causes a production incident?
• Who is accountable when a compromised non-human identity causes major outage or data loss?
• Who is accountable when a patient portal compromise causes billing or claims disruption?
• Who is accountable when a compromised private key is still trusted?