TL;DR: Infrastructure-as-code tools still depend on SSH credentials for host access, and Twingate argues that the common patterns create long-lived credential debt across laptops, CI runners, and shared secrets stores. The real governance shift is to remove runner-held keys entirely so access revocation, audit, and blast-radius control move to identity and session policy.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Infrastructure-as-code workflows still rely on SSH keys for host access, leaving credential debt, rotation burden, and broad blast radius in common Ansible and Terraform setups.
Why it matters: IAM, PAM, and NHI teams need to treat build and provisioning paths as privileged access channels, because the runner often becomes the weakest credential store in the environment.
Context
Infrastructure-as-code describes desired state, but it does not automatically solve how the automation tool authenticates to the target system. When that access path depends on a static SSH key, the identity problem shifts from the host to the runner and the secrets store that carries the key. That creates a lifecycle issue, not just an access issue, because the credential now exists in multiple places that must all be governed.
Ansible and Terraform are especially prone to this pattern because they often reach systems directly rather than only through cloud APIs. In practice, that means the access channel for provisioning, repair, and bootstrap work can become a standing privileged path unless the team deliberately replaces key-based access with a more governable identity model.
Key questions
Q: Why do SSH certificates reduce risk compared with passwords?
A: SSH certificates reduce risk because they remove reusable passwords, narrow access to specific identities, and support time-bound trust. That lowers brute-force exposure and makes revocation more precise. The benefit only holds if the organisation actually enforces expiry and tracks who can issue or renew certificates.
Q: Why do CI runners become a high-risk place for SSH access?
A: CI runners become high-risk because they often hold build secrets, SSH private keys, deploy tokens, and broad network reach for short-lived jobs. If a runner is compromised, an attacker can steal credentials from environment variables, cached files, or logs, then pivot into source control, servers, or release systems. Isolated runners, short-lived credentials, and per-job vault retrieval reduce that exposure.
Q: What is the difference between SSH keys and SSH certificates for governance?
A: SSH keys are reusable credentials that can persist indefinitely unless administrators remove them, while SSH certificates are time-bounded identities signed by a central authority. For governance, certificates make ownership, expiry, and auditability easier to control. That usually makes them a better fit for privileged access and automated workflows.
Q: How should teams remove secrets from infrastructure automation?
A: Remove secrets by replacing embedded credentials with short-lived, centrally issued credentials or identity-based access. Use a vault, OIDC-backed federation, or cloud instance roles so the access model where the runner fetches secrets at runtime, rather than storing SSH keys, passwords, or API tokens in code, variables, or state files. Rotate any residual secrets and block plaintext output in logs.
Technical breakdown
Why IaC SSH access becomes credential sprawl
When Ansible or Terraform connects over SSH, the authentication material has to live somewhere the runner can reach. That usually means a private key on a laptop, a secret injected into CI, or a shared credential stored for repeated use. Each copy is a separate control point, and each one expands the rotation and revocation problem. The technical issue is not SSH itself, but the way automation turns a single credential into many distributed copies across execution environments. Read How to find unused GitHub deploy keys and SSH keys.
Practical implication: Treat every automation runner as a credential-bearing endpoint and remove keys from places you cannot inventory and revoke reliably.
How Vault-signed SSH certificates change the trust model
A certificate-based SSH model replaces a long-lived private key with a short-lived certificate issued on demand by a trusted authority. The target host trusts the CA, not the runner, so access is constrained by certificate lifetime and host scope rather than by a reusable secret. This is a better trust model, but it also introduces a distributed control plane for issuing, backing up, rolling, and monitoring the CA and its signing workflow. See the SSH Protocol and Certificate Authority Guide.
Practical implication: Use certificate issuance when you need SSH but want the access window to shrink from persistent key exposure to session-scoped trust.
Why proxy-based access removes the key from the workflow
A proxy-based access layer changes the SSH pattern by making the connection path identity-aware before it reaches the host. The runner authenticates to the proxy, the proxy enforces policy, and the host receives traffic without requiring the automation tool to carry a private key. The host still authenticates the session at the OS layer, but the runner no longer stores the secret that created the session in the first place.
Practical implication: Shift the credential boundary away from the runner so the automation system no longer acts as a secret distribution point.
Threat narrative
Attacker objective: The attacker or insider gains reusable SSH access to managed hosts through a credential that was meant to support automation, not persistent administration.
- Entry begins when an automation runner or operator workstation holds the SSH credential needed for provisioning or remote execution.
- Credential access occurs through that copied key, which may also exist in CI secrets, controller databases, or other duplicated locations.
- Impact follows when one exposed key unlocks broad host access across the environments that reuse it.
Breaches seen in the wild
- HashiCorp GPG key exposure 2021: Codecov's poisoned Bash Uploader exposed the GPG key HashiCorp used to sign download checksums; HashiCorp rotated it and re-signed its releases.
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SSH credentials used by IaC are a lifecycle problem, not a tooling detail. When the same key is copied into a laptop, a CI runner, and a controller database, ownership, rotation, and revocation stop being single actions and become an estate-wide hunt. That is why provisioning access so often outlives the person or pipeline that first needed it. Practitioners should treat automation credentials as governed identities, not convenience artifacts.
Credential debt is the right name for this pattern. The debt accumulates because each exception to a clean authentication model creates another place where the secret can persist. Unused deploy keys are a symptom of the broader issue: the environment keeps old access paths alive because there is no clean place to withdraw them all at once. The implication is that governance has to focus on where the credential exists, not just on who created it.
Short-lived certificates improve SSH governance, but they do not erase the operational burden of trust distribution. Certificate-based access narrows the blast radius and improves revocation timing, yet it still depends on a CA, host trust configuration, and policy scoping. That means the governance model improves only if the team can run the issuing infrastructure with the same discipline it applies to the hosts.
Proxy-mediated access changes the identity question from secret management to session policy. If the automation runner no longer holds the credential, the key control becomes whether the IdP session, device state, and connection policy are sufficient to authorize the work. That is a stronger place to make the decision because the access path becomes observable and revocable at connection time, not after a secret has already spread.
Read next: How to find unused GitHub deploy keys and SSH keys
What this signals
Credential debt will keep surfacing in automation-heavy environments until teams change where authentication state lives. The runner is too often treated as a harmless execution point, yet it is also where secrets are copied, cached, and forgotten. The governance move is to make access decisions at session time, not by distributing keys into every tool that can open a shell.
Runner-held SSH access is a strong candidate for policy collapse into identity-aware session control. When the provisioning plane can authenticate through an IdP-backed connection layer, the access review changes from tracking a file path to reviewing session policy, device trust, and revocation handling. That is the more durable control boundary for infrastructure automation.
For practitioners
- Replace runner-held SSH keys Move provisioning access away from static private keys stored on laptops, CI runners, or controller databases and into a model that does not duplicate the secret across execution environments.
- Inventory every automation credential copy Map every place Ansible and Terraform can read SSH material, including local files, injected secrets, and orchestration databases, then remove orphaned copies first.
- Adopt short-lived SSH certificates where keys must remain Use CA-issued certificates for workflows that still need SSH so the trust window is minutes, not months, and host access can be revoked without reissuing long-lived keys. See the SSH Protocol and Certificate Authority Guide.
- Move management access behind an identity-aware proxy Route automation traffic through an access layer that authenticates the session before it reaches the host, so the runner no longer acts as a secret store.
Key takeaways
- IaC does not remove SSH governance work when the automation path still depends on private keys.
- The central failure mode is credential duplication across runners, laptops, and controller stores, which expands blast radius and slows revocation.
- Short-lived certificates and identity-aware access layers both improve the model, but the strongest outcome is to stop placing reusable secrets on the runner at all.
Related NHI Mgmt Group resources: SSH Protocol and Certificate Authority Guide · Tailscale credentials · How to find unused GitHub deploy keys and SSH keys · Unix and Linux Privileged Access Guide
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 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Runner-held SSH keys and copied secrets are the leakage pattern at the centre of the article. |
| NHI-07 — Long-Lived Secrets | Static SSH keys create persistent access that survives far beyond a single provisioning session. | |
| Recommendation — Eliminate duplicated SSH secrets across runners and controllers, then revoke any exposed credentials immediately. Replace long-lived SSH keys with short-lived certificates or session-bound access wherever automation requires host access. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The article is fundamentally about lifecycle control over authenticators used by automation tools. |
| Recommendation — Apply authenticator management to automate issuance, rotation, and revocation for machine-used SSH credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Provisioning access needs policy-backed authorization, not ad hoc key distribution across runners. |
| Recommendation — Centralise authorization for automation access and remove standing entitlement from unmanaged SSH keys. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Exposed SSH keys enable credential access and broad movement across managed hosts. |
| Recommendation — Hunt for copied SSH credentials and map their reuse paths to likely lateral movement opportunities. | ||
Key terms
- Terraform Cloud: Terraform Cloud is a managed service for running Terraform workflows and coordinating infrastructure changes. It centralizes state, remote execution, policy checks, and team access controls, which makes it a control point for cloud infrastructure automation and for governing the identities, secrets, and approvals used in infrastructure as code pipelines.
- Ansible Role: An Ansible role is a reusable automation unit that packages tasks, variables, and handlers for a specific job. In this context, the role lets teams add host import and deletion actions to provisioning and deprovisioning playbooks without building custom logic from scratch.
- SSH Key: A cryptographic key pair used to authenticate to servers and services via the Secure Shell (SSH) protocol. SSH keys associated with service accounts and automated pipelines are a common NHI attack vector and frequently found orphaned or unrotated.
- 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.
Deepen your knowledge
NHI governance, machine identity security, and secrets management 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 November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org