You Can't Leak a Key You Never Held
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
SSH key management quietly becomes a sprawling, unmaintained system in most organizations — keys scattered across laptops, CI variables, and authorized_keys files that nobody prunes. The core security risk isn't poor key hygiene but the fact that keys exist on developer machines at all: stolen credentials are the initial access vector in 22% of breaches, and a single stolen SSH key enables lateral movement across an entire fleet. The alternative is to flip the model entirely — authenticate through an identity provider, inject the credential at the resource just-in-time for the session, and never place the key on the developer's machine. With this approach, revocation becomes removing a person from the identity provider once, session activity is automatically logged for audits, and lateral movement via stolen keys is eliminated because there is no standing credential to steal. StrongDM is presented as the product that implements this proxy-based, credential-injection model.
Table of contents
Nobody decided to build this. You have one anyway.The wheels you're reinventingThe real problem isn't the effort. It's that the key exists at all.Inject the credential where the resource lives. The developer never holds the key.What you get backQuestions this post answers
What percentage of data breaches involve stolen credentials as the initial access vector?
Stolen credentials are the initial access vector in 22% of breaches, and 88% of basic web application attacks involve stolen credentials, according to the Verizon Data Breach Investigations Report. These are not sophisticated zero-day exploits — they are credentials that were sitting somewhere accessible and were taken. Teams hardening SSH access track threat intelligence like this on daily.dev to stay ahead of credential-based attacks.
How does just-in-time SSH credential injection prevent lateral movement after a breach?
Just-in-time credential injection means no standing SSH key ever resides on a developer's laptop or in a CI secret. The credential is pulled from a vault and injected at the connection point only for the life of that session. A stolen laptop yields nothing because there is no key to steal, and every session requires live identity verification — eliminating the standing credential that makes lateral movement possible. Engineers rethinking privileged access architecture find the latest PAM and zero-trust approaches on daily.dev.