SSH Key

Expanded Definition

An SSH key is a cryptographic credential pair used by the SSH protocol to prove identity without typing a password. In NHI security, the private key functions as a secret, while the public key is distributed to servers that must trust it.

SSH keys are often more durable than passwords, which makes them useful for automation but risky when they are embedded in scripts, shared across environments, or left on legacy hosts. Usage in the industry is still evolving around how strictly SSH keys should be governed relative to API tokens and certificates, but the security principle is consistent: keys need ownership, rotation, and revocation. The NIST Cybersecurity Framework 2.0 provides a useful control lens for identity protection and access governance, even when organisations implement SSH differently across platforms.

The most common misapplication is treating SSH keys as one-time setup artifacts, which occurs when teams create them for deployment access and never inventory, rotate, or retire them after the associated service changes.

Examples and Use Cases

Implementing SSH keys rigorously often introduces operational overhead, requiring organisations to weigh automation speed against key lifecycle controls, endpoint hardening, and emergency revocation readiness.

• CI/CD pipelines use SSH keys to pull code, push artifacts, or reach deployment targets without interactive login.
• Privileged administrators use key-based access for bastion hosts, jump servers, and restricted Linux estates where password authentication is disabled.
• Backup jobs, configuration management, and orchestration tools rely on keys to reach remote systems on a schedule.
• Vendors and third parties may receive temporary SSH access for maintenance, creating a governance need to time-box and audit the key lifecycle.
• Teams sometimes store keys in code repositories or shared build agents, a pattern that conflicts with the guidance in the Ultimate Guide to NHIs and weakens traceability across environments.

For implementation reference, SSH handling should align with identity assurance and access policy expectations in the NIST Cybersecurity Framework 2.0, especially where service access is part of the organisation’s broader trust model.

Why It Matters in NHI Security

SSH keys are a high-value NHI control point because they frequently outlive the service accounts, workloads, or vendors that created them. When no owner is assigned, a key can remain valid long after a system is decommissioned, giving attackers a quiet path into production infrastructure. NHI programs routinely find that credential sprawl is the real problem, not the protocol itself.

The Ultimate Guide to NHIs reports that 71% of NHIs are not rotated within recommended time frames, which helps explain why SSH keys become persistent access pathways rather than controlled credentials. That risk compounds when teams store secrets outside dedicated managers or fail to offboard keys when applications change.

SSH key governance also supports zero trust and least privilege. Even a well-formed key is unsafe if it grants blanket access across fleets or survives beyond its intended scope. Organisational maturity is often exposed by whether keys are discoverable, attributable, and revoked on schedule, not by whether SSH itself is enabled.

Organisations typically encounter the impact only after a server compromise, at which point SSH keys become operationally unavoidable to locate, rotate, and retire.

Related resources from NHI Mgmt Group

• What are the key NHI security metrics every CISO should track?