SSH certificates and identity-based remote access are replacing static keys

At a glance

What this is: This is a retrospective on the evolution of secure remote access from plaintext protocols to SSH certificates, with the key finding that identity-bound, short-lived certificates are replacing static keys.

Why it matters: It matters to IAM and NHI practitioners because the same lifecycle, authorization, and audit problems that broke SSH key management now reappear in machine and agent access.

By the numbers:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• Only 38% have automated certificate lifecycle management in place.

👉 Read Teleport's analysis of the evolution from plaintext SSH to identity-based access

Context

SSH certificates are a governance pattern, not just a transport control. They replace persistent trust in static keys with time-bound, identity-backed credentials that can be scoped, audited, and revoked. That shift is central to NHI governance because every service account, workload, bot, and AI agent eventually runs into the same question: who, or what, should be trusted for how long?

The article traces that transition from plaintext remote access to certificate-based access and then to broader identity-led access workflows. For IAM teams, the important lesson is that standing credentials create cleanup debt while certificate systems move the decision point to issuance time. That makes lifecycle control, MFA, and session auditability the real control plane, not the key file itself. In practice, this is the same problem space covered in the Ultimate Guide to NHIs and the OWASP Non-Human Identity Top 10.

Key questions

Q: How should security teams replace static SSH keys with short-lived access controls?

A: Security teams should move SSH access behind identity proof, policy checks, and short-lived certificates. That means no direct key sprawl on hosts, no reusable standing credentials, and no access without MFA or approved identity context. The goal is to make every session depend on a fresh issuance decision rather than a permanent trust relationship.

Q: Why do static SSH keys create NHI governance risk?

A: Static SSH keys behave like unmanaged non-human identities because they outlive the people and processes that created them. They are hard to inventory, slow to revoke, and easy to copy or reuse. That makes them a governance problem as much as a technical one, especially when cleanup after offboarding is inconsistent.

Q: What breaks when SSH certificate workflows are only partly automated?

A: Partial automation creates gaps between authentication, authorization, and certificate issuance. If one step is manual or inconsistent, teams can still issue access to the wrong person, the wrong host, or the wrong time window. In practice, that reintroduces the same drift that certificate-based access was meant to remove.

Q: What should teams do when remote access still depends on legacy SSH trust?

A: Teams should tighten revocation, shorten credential life, and centralize access decisions before expanding the model. If a legacy process still relies on distributed keys, the first priority is to reduce standing trust and add auditability. That gives security teams a safer path to certificate-based access without leaving old trust paths open.

Technical breakdown

Why SSH keys create standing trust

SSH keys are static credentials. Once a public key is placed on a host, trust persists until someone removes it, and the host cannot tell whether the key still belongs to a current user, contractor, or forgotten account. That creates long-lived access paths, weak ownership, and poor revocation hygiene. In NHI terms, it is the same failure mode seen with API keys and service account credentials: authentication becomes detached from lifecycle governance. The core architectural problem is not encryption, but persistence. Practical implication: any control that cannot expire, scope, and revoke trust on demand is a standing privilege risk.

Practical implication: Treat static keys as unmanaged standing credentials and move them behind issuance, expiry, and revocation controls.

How SSH certificates change the authentication model

An SSH certificate is signed by a trusted certificate authority and can include a TTL, allowed principals, source and destination constraints, and permitted actions. The remote host no longer needs to track each user key individually. Instead, it trusts the CA public key and validates the certificate at login time. That shifts authorization from distributed host state to centralized issuance policy, which is much easier to govern when identities are dynamic. For IAM and NHI teams, the architectural gain is not just stronger crypto. It is the ability to attach identity, scope, and time to every access decision.

Practical implication: Use certificate issuance as the control point for scope, duration, and host-level trust.

Where BLESS-style workflows fit in modern access architecture

BLESS-style access uses a bastion and certificate authority workflow to authenticate the requester, authorize the target, and issue a short-lived SSH certificate just in time. The important design pattern is sequencing: identity proof, access decision, certificate issuance, then session establishment. That same sequencing now appears in modern privileged access and agentic AI control models, where the system must verify identity before it can grant execution authority. The technical lesson is that access should be assembled at runtime from verified identity and policy, not pre-positioned in a reusable secret. Practical implication: integrate MFA, RBAC or policy, and ephemeral credential issuance into one access path.

Practical implication: Build runtime access flows that verify identity before issuing any credential, token, or certificate.

Threat narrative

Attacker objective: The attacker wants durable remote shell access that survives normal identity changes and cleanup activity.

1. Entry occurs when an attacker steals or reuses a long-lived SSH private key that has no built-in expiration.
2. Escalation follows when that key still maps to a host trust relationship that was never cleaned up after role changes or offboarding.
3. Impact is persistent remote access to UNIX hosts without needing to bypass MFA, because the static key itself remains valid.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SSH certificate governance is now part of NHI governance. The article makes clear that the security problem is no longer just SSH hardening. Once access is represented by signed, short-lived credentials, the same lifecycle questions that govern API keys, tokens, and service accounts apply. Practitioners should stop treating SSH as an isolated infrastructure exception and govern it as a non-human identity pattern.

Ephemeral credential trust debt is the hidden cost of static access models. Short-lived certificates reduce exposure, but they only work when identity proof, authorization, and issuance are tightly integrated. Where those steps are stitched together manually, the organisation inherits integration debt that becomes operational risk. The control objective is not merely to shorten credential life, but to remove unmanaged trust persistence altogether.

Identity-bound access is replacing host-bound trust. The important shift is that the host no longer needs a durable list of approved keys. It needs a trusted authority and a policy decision at the moment of access. That pattern is the same one emerging in workload identity and agentic AI access models, so remote access teams should expect their SSH governance choices to influence broader NHI architecture decisions.

The market has already moved from custom stitching to policy-led platforms. The article shows an industry transition from bespoke bastion scripts and manual certificate workflows to unified access systems. For practitioners, that means the bar has changed. Teams should re-evaluate whether their access design still depends on custom glue, because custom glue is where audit gaps, revocation delays, and inconsistent policy enforcement usually appear.

Access lifecycle is the real control surface. The decisive question is not whether a session is encrypted. It is whether access can be issued, constrained, observed, and revoked with clear ownership. That is a familiar NHI lesson, and the same discipline will matter as certificate-based models extend beyond human operators into workloads and AI agents.

From our research:

• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For a broader control baseline, see 52 NHI Breaches Analysis for recurring failure patterns in exposed credentials and over-privileged access.

What this signals

Identity-led remote access is becoming the default expectation, and organisations that still rely on durable SSH keys will carry avoidable trust debt. The practical signal for IAM and platform teams is that certificate issuance, not host-side key distribution, is now the cleaner governance boundary. With the Ultimate Guide to NHIs showing that only 5.7% of organisations have full visibility into their service accounts, the same visibility gap will affect machine-like access paths unless teams bring them under a single lifecycle model.

Certificate-based access only improves security when the surrounding control plane is mature. Teams should watch for weak ownership, inconsistent revocation, and access workflows that still rely on manual exception handling. That is where an identity system intended to reduce risk becomes another source of drift, especially as the model extends from humans to workloads and AI agents.

Zero Trust architectures will keep pushing this model outward. As more infrastructure sessions are mediated by identity and short-lived credentials, the boundary between SSH access, workload access, and agent access will keep shrinking. The teams that prepare now will be the ones that can reuse the same governance pattern across all three.

For practitioners

• Implement short-lived SSH certificate issuance Replace static SSH keys with short-lived certificates that expire automatically and are issued only after identity verification and policy checks.
• Tie SSH access to MFA and identity provider controls Require MFA-backed authentication and central identity provider integration before any certificate is minted, so access decisions happen at issuance time.
• Inventory and revoke dormant SSH keys Audit authorized_keys files, map each key to a current owner, and remove keys that no longer have an active business purpose.
• Log certificate issuance and session activity Capture who requested access, which host was targeted, what certificate was issued, and how the session was used for later review.
• Extend the same control model to workloads and agents Apply the same identity, scope, and expiry model to service accounts and AI agents so remote access governance does not stop at human admins.

Key takeaways

• Static SSH keys are a standing privilege problem because they persist after the original trust decision has gone stale.
• Short-lived SSH certificates move access control from distributed host state to identity-backed issuance, which is easier to govern and audit.
• Teams that want safer remote access should treat certificate lifecycle, MFA, and revocation as core NHI controls, not optional extras.

Key terms

• SSH Certificate: An SSH certificate is a signed credential that lets a user authenticate for a limited time under defined conditions. It binds identity, scope, and expiry to remote access, which makes it easier to govern than static keys that persist until manually removed.
• Standing Privilege: Standing privilege is access that remains valid without a fresh approval or issuance step. In remote access, it usually appears as long-lived keys or credentials that keep working after the original business need has ended, creating revocation and audit problems.
• Certificate Authority For Access: A certificate authority for access is the trusted component that signs short-lived credentials after authentication and policy checks. In identity-led remote access, it becomes the control point for who can connect, for how long, and under what constraints.
• Identity-Bound Remote Access: Identity-bound remote access is a model where the login decision depends on a verified identity rather than a reusable secret stored on hosts. It reduces key sprawl, improves auditability, and supports tighter lifecycle control across humans, workloads, and agents.

What's in the full article

Teleport's full post covers the operational detail this post intentionally leaves for the source:

• A step-by-step account of how BLESS used a bastion host and Lambda-based certificate authority to issue SSH certificates.
• The specific OIDC, MFA, and RBAC integration pattern used to authenticate and authorize remote login requests.
• How modern certificate-based access extends the same model to databases, Kubernetes clusters, cloud consoles, and web applications.
• The article's own framing of how the market moved from custom integration to unified access workflows.

👉 Teleport's full post covers the BLESS workflow, certificate issuance model, and modern access patterns.

Deepen your knowledge

SSH certificate governance and short-lived access controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are replacing static keys with identity-bound access, it is a practical place to start.