Topic starter
06/11/2026 6:56 pm
TL;DR: Static deploy keys remain exposed in runners, secrets stores and logs long after teams forget them, according to Twingate's analysis of CI/CD SSH usage. For practitioners, the issue is not key management hygiene alone but whether the pipeline ever needs a reusable key at all.
Editorial analysis by NHI Mgmt Group, based on content published by Twingate: “Stop Storing SSH Keys in CI/CD Secrets”.
Key questions
Q: Why do stored deploy keys create such a large blast radius?
A: Stored deploy keys create a large blast radius because one credential can often unlock many repositories, hosts or deployment targets until it is revoked.
Q: What is the difference between OIDC federation and SSH key auth?
A: OIDC federation uses a short-lived assertion about the workload to obtain scoped access without storing a reusable private key, while SSH key auth relies on a persistent key pair that proves possession of a private key.
Q: How should security teams eliminate static secrets from CI/CD pipelines?
A: Security teams should move from stored credentials to runtime-issued access wherever possible.
Practitioner guidance
- Audit deploy secrets for static SSH material Search repository secrets, CI variables, and secret managers for SSH_KEY, PRIVATE_KEY, DEPLOY_KEY, and PEM patterns.
- Replace reusable deploy keys with federated identity Move the pipeline to an identity provider flow that issues short-lived credentials for each job.
- Broker SSH sessions through a policy gateway Place a session broker between the runner and target hosts so access is authorised per resource and per run.
Bottom line: Static SSH deploy keys create a durable identity problem inside CI/CD because they can be copied, logged, and reused outside the intended job.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:56 pm
Deploy keys are a supply-chain identity problem, not a server-access convenience. Once a reusable SSH credential sits in CI/CD, the security question changes from who can deploy to who can extract the key from the runner, logs, or workflow state. That means the deploy pipeline has become a secrets repository with execution rights, which is a poor identity boundary for modern delivery. Practitioners should treat pipeline-held SSH keys as standing access with a wider blast radius than the job that uses them.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What signals show that deploy credentials need to be rotated?
A: Deploy credentials need rotation when they appear on disk, in logs or in source control, when ownership is unclear, or when they have no clear rotation record. Other signals include failed inventory checks, shared use across systems, and credentials that have outlived the workload or deployment job they were issued for.
👉 Read our full editorial: CI/CD SSH keys persist long after the pipeline is compromised