TL;DR: Teleport argues that SSH remote access is shifting from static keys to short-lived certificates bound to verified identity, with MFA, OIDC-backed authorisation, and per-session issuance reducing standing trust and revocation burden across UNIX environments. The governance question is whether access can be proven and constrained at issuance, because static keys assume trust persists long after the operator, host, or role has changed.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: SSH certificates are displacing static keys for remote access, with identity-bound, short-lived credentials replacing indefinite trust relationships.
Why it matters: It matters because IAM, PAM, and NHI programmes need remote access controls that can verify identity, scope sessions, and remove standing credentials when people or roles change.
👉 Read Teleport's analysis of SSH certificates and identity-based remote access
Context
Static SSH keys create an identity governance problem, not just a login problem. Once a public key is trusted on a host, that trust often persists indefinitely unless someone manually removes it, which means access can outlive the person, project, or contractor relationship that justified it.
SSH certificates change the model by binding access to a verified identity, a short TTL, and explicit session constraints. That moves remote access closer to issue-time authorisation, where the control can prove who is asking, what host is in scope, and how long the trust should last.
Key questions
Q: What breaks when SSH access still relies on shared credentials?
A: Shared credentials break attribution, make revocation slow, and make access reviews less meaningful. If multiple people or processes can use the same key, the organisation cannot prove who created a session, who used it, or whether the access should still exist. The control gap is identity ownership, not encryption.
Q: Why do short-lived certificates reduce risk for remote desktop authentication?
A: Short-lived certificates reduce risk because they narrow the window in which a stolen credential remains useful. If an attacker captures the certificate after it is issued, it expires quickly and is harder to reuse at scale. Certificates also resist brute force attacks and can carry session-specific metadata, which strengthens control and auditability for remote access.
Q: How should security teams phase out static SSH keys in distributed infrastructure?
A: Security teams should replace static SSH keys with certificate based access, backed by a central identity source and strong authentication. That approach reduces long lived credentials, improves revocation, and gives administrators a clearer control point for who can connect. In practice, the first goal is to make access ephemeral, auditable, and tied to approved identity providers or team membership.
Q: When does certificate-based remote access become the right control model?
A: It becomes the right model when remote access must prove identity at issuance time, limit session scope, and support clean offboarding. That is especially true for privileged UNIX access, contractor access, and environments where static credentials create unacceptable standing trust.
Technical breakdown
Why static SSH keys become standing credentials
A static SSH key pair is a reusable authenticator, not a scoped access grant. The private key proves possession, but the host sees only a trusted public key and has no built-in sense of expiry, purpose, or session boundary. That creates an identity sprawl problem: keys get copied, stored insecurely, and left behind in authorized_keys files long after the owner changes. In governance terms, the control is decoupled from the human or operational state it was meant to represent.
Practical implication: treat SSH keys as standing credentials that need lifecycle control, not as harmless transport artefacts.
How SSH certificates add scope and time to remote access
An SSH certificate introduces a certificate authority, a TTL, and constraints that the host can verify at login time. Instead of trusting each user key forever, the host trusts the CA public key and evaluates whether the presented certificate is valid for the requested principals, source or destination scope, and permitted actions such as port forwarding or agent forwarding. That makes remote access much closer to policy enforcement than to simple key possession.
Practical implication: move remote access decisions to issuance time so scope, duration, and role can be enforced before a session starts.
Why identity-provider-backed issuance changes the governance model
Certificate-based access works best when authentication and authorisation happen before the certificate is issued. In the article's example, MFA and OIDC-backed checks feed a just-in-time certificate workflow, which means the access decision is tied to identity proofing and policy rather than to a copied secret. This is the point where remote access stops being about host-level trust and becomes a governed identity workflow with auditability, revocation, and session records.
Practical implication: integrate identity verification with certificate issuance so the credential itself reflects current authority, not historical entitlement.
Threat narrative
Attacker objective: The attacker wants durable remote shell access to trusted UNIX hosts without needing repeated authentication or immediate detection.
- Entry occurs through a stolen password or copied SSH private key that can be reused against hosts that still trust static keys.
- Credential abuse succeeds because the key has no native expiry, so the attacker inherits standing access until someone manually revokes it.
- Impact is persistent remote access to UNIX hosts, with the ability to move through systems that still accept the stale credential.
Breaches seen in the wild
- CI/CD pipeline exploitation case study: Credentials in an exposed .git/config let a researcher edit a Bitbucket pipeline so it planted their SSH key on the server. No victim was named.
- SonicWall SSL VPN account compromises 2025: Attackers used valid credentials to log in to more than 100 SonicWall SSL VPN accounts across 16 environments in October 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Static SSH keys are a standing trust problem disguised as an authentication mechanism. Once a public key is placed on a host, the trust relationship persists until someone actively removes it, which means access governance becomes dependent on perfect cleanup. That is why SSH key sprawl is fundamentally a lifecycle failure, not just a credential-format issue. The practitioner conclusion is that remote access controls need expiry and revocation semantics, not merely stronger key generation.
SSH certificates turn remote access into issuance-time authorisation. The meaningful control boundary moves from host configuration to the decision to mint a short-lived certificate for a specific identity and scope. That means the programme has to govern who can issue, under what conditions, and with what session constraints. The practitioner conclusion is that certificate issuance, not host trust lists, becomes the primary control surface.
Identity-based remote access narrows the gap between PAM and NHI governance. Human operators, contractors, and eventually machine actors all need the same basic assurance: verified identity, scoped authority, and bounded lifetime. What changes is not the governance pattern, but the actor type and the evidence needed at issuance. The practitioner conclusion is to design one lifecycle model that can govern human and non-human remote access without relying on persistent secrets.
Runtime access must be auditable at the session level, not just at the credential level. Short-lived certificates improve the trust model, but the real governance value appears when every issued session carries identity evidence, scope, and replayable logs. That makes access reviews and investigations materially better because the record reflects who was authorised at that moment. The practitioner conclusion is to align audit, revocation, and session recording around certificate issuance events.
Ephemeral credential trust debt: organisations that keep static keys alongside certificate workflows create two parallel trust models, one governed and one unmanaged. That split undermines the very rationale for identity-based access because stale keys continue to provide an unscoped back door. The practitioner conclusion is to remove the legacy trust path, not simply add a new one on top.
What this signals
Identity-based remote access changes the control point. When the credential is time-bound and issued after MFA, the important question is no longer whether a key exists on a host, but whether the current session was authorised under the right identity conditions. That shift matters because it collapses the gap between authentication, authorisation, and revocation.
Remote access governance is converging across humans and machines. The article's most important signal is that the same certificate model used for human operators is now extending to workloads and AI agents. Practitioners should expect remote access policy, session evidence, and lifecycle controls to be designed once and applied across actor types.
Static key cleanup is becoming a governance liability. As long as unmanaged keys coexist with certificate-based workflows, organisations will carry two trust models at once. That creates audit ambiguity and leaves a persistent path that bypasses the tighter certificate lifecycle.
For practitioners
- Audit static SSH key sprawl Inventory authorized_keys files, shared admin accounts, and copied private keys that still grant persistent host access. Classify each by owner, scope, and last verified business need so you can see where standing trust remains in place.
- Adopt short-lived SSH certificates Shift privileged remote access to certificates with explicit TTLs, principal scope, and session constraints. The goal is to make every login depend on current identity and current authority rather than on a reusable key pair.
- Bind issuance to MFA and identity provider checks Require strong authentication and policy evaluation before a certificate is minted. That prevents possession of a copied key from becoming enough to reach a production host.
- Eliminate host-level trust persistence Remove reliance on per-host public key accumulation and replace it with trust in the CA public key. That reduces the cleanup burden when employees move teams, contractors leave, or access needs expire.
- Record and review certificate-backed sessions Keep session logs and playback tied to the certificate that authorised access so investigations can answer who accessed what, when, and under which identity conditions.
Key takeaways
- Static SSH keys are not just older technology, they are standing trust objects that often survive the people and projects they were meant to serve.
- The article shows that certificate-based access becomes materially stronger when it binds identity, scope, and session lifetime at issuance time.
- The control lesson is to replace indefinite host trust with short-lived, auditable access and to remove any legacy key paths that remain outside that model.
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 MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 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-01 — Improper Offboarding | Static keys persist after people and roles change, creating offboarding gaps. |
| NHI-05 — Overprivileged NHI | SSH keys often grant broader host access than the current task requires. | |
| NHI-07 — Long-Lived Secrets | The article centres on replacing non-expiring keys with short-lived certificates. | |
| Recommendation — Retire standing SSH keys when users, contractors, or hosts leave scope. Constrain SSH access to the minimum principals and session capabilities needed. Replace long-lived SSH credentials with short-lived certificates and enforced expiry. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | SSH keys and certificates are authenticators whose lifecycle must be managed. |
| Recommendation — Manage SSH authenticators through issuance, rotation, expiry, and revocation controls. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Remote access decisions depend on scoped entitlements and authorisation checks. |
| Recommendation — Apply entitlement checks before issuing access and log the resulting session authority. | ||
| NIST Zero Trust (SP 800-207) | Section 3.1 — Zero Trust principles | Identity-based remote access replaces implicit host trust with verified access decisions. |
| Recommendation — Enforce verified identity and least-standing-access principles before each SSH session. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen SSH keys enable credential reuse and movement across hosts. |
| Recommendation — Map exposed SSH keys to credential-access and lateral-movement detection coverage. | ||
Key terms
- SSH Certificate: An SSH certificate is a signed credential that lets a server trust an identity without relying on a static key alone. In NHI terms, it is a short-lived machine credential whose security depends on issuance policy, principal validation, and where the trust anchor is accepted.
- Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
- Certificate Authority Services: Certificate Authority Services are the trust services that issue and manage digital certificates for users, applications, and machines. They anchor encrypted communication by proving identity and supporting certificate lifecycle controls such as issuance, renewal, revocation, and validation across enterprise systems.
- 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 article covers the operational detail this post intentionally leaves for the source:
- The step-by-step history of SSH remote access from plaintext protocols to identity-bound certificates
- The practical BLESS architecture, including bastion flow, Lambda-based certificate signing, and host trust setup
- The auth layer pattern that combines OIDC, MFA, RBAC, and just-in-time certificate issuance
- The modern session workflow for identity-based access across servers, databases, Kubernetes clusters, cloud consoles, and web apps
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 2, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org