SSH public key authentication relies on long-lived keys that are manually installed on hosts, while SSH certificate-based authentication uses short-lived certificates signed by a trusted certificate authority. The certificate model adds expiration, revocation, and identity information such as principals or roles, which makes access easier to govern and better suited to larger environments.
Why SSH Certificate Authentication Changes the Security Model
SSH public key authentication and SSH certificate-based authentication both prove possession of a private key, but they do not create the same operational risk. Public keys are often long-lived, manually distributed, and difficult to inventory at scale. Certificate-based authentication adds time limits, issuer trust, and identity metadata, which makes access easier to govern across many servers and users. That matters when key sprawl, shared admin accounts, and delayed revocation are the real sources of exposure.
For security teams, the difference is not academic. Long-lived keys behave like static credentials, which are hard to trace once copied, embedded in automation, or left behind after a role change. Certificate-based SSH shifts the control point to a trusted issuer, so access can be granted for a short period and tied to a named principal or role. Current guidance suggests this is a better fit for environments that need repeatable access decisions and stronger offboarding. NHI Management Group notes that only 38% of organisations have automated certificate lifecycle management in place, and that certificate expiry is the leading cause of outages for 45% of organisations, according to the Critical Gaps in Machine Identity Management report.
In practice, many security teams discover the weakness of manually managed ssh key only after a forgotten key still works long after the person or system that used it has changed.
How Certificate-Based SSH Works in Practice
With public key authentication, the server stores an authorised key and accepts logins whenever the matching private key is presented. With certificate-based authentication, the server trusts a certificate authority, then validates a signed certificate that contains the user or workload identity, permitted principals, and an expiry window. The private key still matters, but the certificate adds governance controls that are absent from a plain key.
That change affects how teams issue, scope, and revoke access. A typical operational pattern is:
- generate or register a public key once, but do not place it permanently on every host;
- have a trusted authority sign short-lived SSH certificates for a specific role, host class, or session;
- set short TTLs so access naturally expires if it is not renewed;
- use revocation or CA trust changes to invalidate access centrally when a user leaves or a workload is decommissioned;
- log certificate subject, principal, and validity data so access reviews are meaningful.
This aligns well with broader identity guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls, which emphasises least privilege, access control, and auditability. It also reflects the governance problems described in the Ultimate Guide to NHIs — What are Non-Human Identities, especially where long-lived secrets and poor visibility create hidden access paths.
In practice, certificate-based SSH tends to break down when the CA, host trust configuration, or certificate issuance workflow is not automated, because the intended control becomes another manually managed dependency.
Where Teams Still Get Tripped Up
Tighter SSH governance often increases operational overhead, so organisations have to balance stronger control against certificate issuance latency, CA availability, and integration complexity. That tradeoff is especially visible in legacy fleets, mixed Unix estates, and emergency access workflows.
There is no universal standard for exactly how much SSH certificate use is enough. Some organisations keep certificates for human administrators and retain public keys for simple automation. Others move both human and machine access to signed, short-lived credentials. Best practice is evolving, but the consistent theme is that certificate-based authentication works best when identity is centrally issued and revoked, while public keys still make sense for low-change environments that can tolerate slower lifecycle management.
Edge cases matter. Break-glass accounts may still need carefully controlled static access if the CA is unavailable. Offline systems may not be able to validate against a live trust service. Shared service accounts are especially risky because certificate metadata can be diluted by poor ownership, and a certificate only improves governance if the underlying principal is actually unique. ISO guidance on information security management supports the broader need for controlled lifecycle processes, but the implementation details depend on the environment. For teams already struggling with inventory and revocation, the same patterns that show up in machine identity failures also appear in SSH estates that rely on stale keys and incomplete offboarding.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | SSH keys and certs are NHI credentials that need lifecycle control and revocation. |
| NIST CSF 2.0 | PR.AC-4 | SSH access should be least-privilege, governed, and auditable at request time. |
| NIST AI RMF | If SSH is used by AI agents, identity and trust decisions must be continuously governed. | |
| NIST Zero Trust (SP 800-207) | SC-7 | Certificate-based SSH aligns with continuous verification and reduced implicit trust. |
| OWASP Agentic AI Top 10 | A2 | Autonomous agents using SSH need short-lived identity and constrained execution rights. |
Issue ephemeral SSH credentials to agents and revoke them immediately after task completion.
Related resources from NHI Mgmt Group
- What is the difference between SSH password authentication and public key authentication?
- What is the difference between knowledge-based authentication and inherence-based authentication in MFA?
- What is the difference between certificate-based authentication and FIDO in practice?
- What is the difference between certificate-based authentication and passwordless login based on OTPs or static credentials?
