What is the difference between SSH public key authentication and SSH certificate-based authentication?

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.

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?