On-Demand SSH Certificates

What On-Demand SSH Certificates Change

On-demand SSH certificates replace static SSH key trust with a short-lived, signed credential that is issued only when access is needed. That shifts SSH from a durable secret you must inventory and remove later to a time-bound access assertion that can be scoped, expired and revoked through the certificate authority.

The practical change is that access decisions move closer to session time. Instead of relying on a long-lived private key sitting on disk, the issuer can encode who may connect, for how long, and sometimes to which hosts or principals, which reduces the blast radius of stolen material and makes access governance much tighter.

This model is most useful where SSH access must be frequent but still tightly controlled, such as administrators, automation, bastions and workloads that need ephemeral access paths. It is also why many organisations pair it with broader SSH Key and SSH Certificate Management Guide practices rather than treating certificates as a standalone fix.

How SSH Certificates Work in Practice

An SSH certificate is not the same thing as a TLS certificate. It is an OpenSSH-specific signed object that carries identity claims, principals and validity limits, and the SSH server checks it against a trusted certificate authority key or host policy before allowing access.

Because the certificate is short-lived, the issuing authority becomes part of the access control path. That means certificate issuance policy, CA custody and revocation design matter just as much as the client-side signing step. If the CA is weakly governed, the certificate merely turns key sprawl into trust sprawl.

For workloads and automated systems, on-demand certificates also fit the wider pattern of workload identity and ephemeral access. The same trust model appears in certificate-based workload authentication, especially when SSH is one of several ways a system proves who it is at runtime. For that broader pattern, see the Guide to SPIFFE and SPIRE.

Why Short-Lived Certificates Reduce SSH Key Risk

Static SSH keys are attractive to attackers because they are reusable, often copied across hosts and frequently forgotten in authorized_keys files, CI pipelines or developer laptops. On-demand certificates reduce that persistence window by making the credential usable only briefly and by moving trust to the issuer rather than the raw public key alone.

That does not eliminate compromise, but it changes the recovery problem. A stolen private key or signing path may still be abused until it is contained, yet the short lifetime and revocation controls can sharply limit the duration of exposure compared with a durable key that remains valid for months or years.

Compromise scenarios usually become about issuer trust, secret protection and certificate misuse rather than only about theft of a single SSH key. In practice, the main benefit is that you can replace broad, permanent SSH access with narrow, expiring access that is easier to audit, rotate and remove.

Operational Patterns for Issuance, Rotation and Review

On-demand SSH certificates work best when the organisation treats the certificate authority as a controlled security service, not a convenience feature. The issuer should be owned, logged and protected, and the certificate policy should define who can request access, what principals may be embedded, and how revocation is handled when access must end early.

That operational model is stronger when paired with inventory and lifecycle review. Administrators should know where SSH is still accepted, which systems trust the CA, and where long-lived keys still exist as exceptions. The same lifecycle discipline applies to host certificates, user certificates and automation accounts, especially when the aim is to remove orphaned trust paths. The Machine Identity, PKI and Certificate Lifecycle Guide is the right companion for the certificate lifecycle side of that work.

For SSH-specific policy and rollout detail, the SSH Protocol and Certificate Authority Guide explains how principals, CA custody and revocation lists fit together, while the OpenSSH Server Hardening Guide shows how to enforce certificate-based login on the server side.

Risk and Threat Considerations

Short-lived SSH certificates reduce persistence, but they also concentrate trust in the issuing authority and any automation that can mint certificates. If the CA, signing key, or issuance workflow is compromised, an attacker may be able to generate valid access for multiple hosts or principals until the issue is contained.

Failure mechanism: Abuse of the CA trust path, signing key theft, or overbroad issuance policy can turn a strong access-control design into a scalable impersonation channel. The risk is highest where revocation is slow, host trust is broad, or certificates are issued without tight principal and lifetime limits.

Impact: The result can be rapid lateral movement, unauthorized administrative access, and delayed containment across the SSH estate, especially when certificate-based access is assumed to be safer than it really is.

Practitioner Guidance

Why practitioners should care: On-demand SSH certificates are only safer than static keys when the issuance path is governed as carefully as the server trust path. If certificate requests are weakly authenticated, poorly audited, or easy to overissue, the control becomes a high-value abuse point rather than a reduction in key sprawl.

What to watch for: Pay close attention to CA key custody, certificate lifetime, principal scope, revocation handling and exceptions where old authorized_keys entries still bypass the certificate model. If you cannot answer who can mint certificates, for whom, and for how long, the implementation is not yet mature enough for broad trust.

Practitioner takeaway: Treat SSH certificates as an access-governance control, not just a crypto format, and validate them against the same lifecycle discipline you would expect from any other privileged access path.

Related resources from NHI Mgmt Group

• Should organisations use SSH certificates instead of long-lived keys?
• How should security teams govern SSH certificates in Linux environments?
• Why do SSH certificates create blast radius risk for NHI governance?
• Why do SSH certificates create hidden NHI governance risk?