It starts innocently.
A new engineer joins, and getting them SSH access means generating a keypair, getting the public key onto the right hosts and hoping you got all of them. Then someone leaves, and now you're searching across your systems trying to find every place their key landed. Somewhere in between, a key that should have been rotated two years ago is still sitting in an authorized_keys file on a box nobody's logged into since. None of this is hard. It's just endless, and it's become one of the most consistent time sinks on your plate.
SSH key management isn't a project you scoped. It accreted. A rotation cron someone wrote and left behind, authorized_keys files scattered across every host, keys tucked into CI variables, keys sitting in ~/.ssh on laptops you don't control. Every one of those was a reasonable call in the moment. The sum is a homegrown system for issuing, distributing, and tracking credentials, and you're maintaining it for free, in the margins, because it was never actually anyone's job.
That's what makes it a build-vs-buy question, even though nobody framed it that way. It all runs on the honor system: it works until it doesn't, and when it doesn't, it's usually because someone left, or something leaked, or an auditor asked a question nobody could answer quickly.
Strip it down, and you're building custom solutions to four problems that are already solved elsewhere.
Distribution. Getting the right public keys onto the right hosts and keeping that true as the fleet changes. Every new host, every rebuild, every autoscaling event is a chance for the map to drift.
Rotation. Keys that should rotate but don't, because rotating means touching every host they live on.
Revocation. The one that actually keeps people up at night. Someone leaves, or a laptop walks off, and now you're grepping the fleet for a key, hoping the list of hosts you're checking is complete. You will never be fully sure it was.
Sprawl. authorized_keys as an append-only file nobody prunes. Keys with no owner. Keys that outlived the person they belonged to. Access that accumulates because removing it is harder than adding it.
None of these is a hard problem in isolation. They're just constant, and they're exactly the kind of undifferentiated work that eats platform-team time without ever showing up as a feature you shipped.
The cost here shifts from your time to your exposure. Every key you generate and distribute has to live somewhere a person can reach it. It's in ~/.ssh on a laptop. It's in a CI secret. It's pasted into a script, or sitting in an env var, or, on a bad day, committed to a repo by someone in a hurry. That's your exposure, and it's bigger than you think, because you've been counting keys instead of counting the places each key can leak from.
The Verizon Data Breach Investigations Report (DBIR) analyzes tens of thousands of real breaches each year and reports how breaches happen. In the 2026 edition, credential abuse fell to 13% as a standalone initial access vector, down from 22% partly because pretexting was broken out into its own category. That is the number worth holding onto if you are holding an SSH key. Credentials are less often the way in now and more often what the intrusion runs on once it is inside, which is what a standing key is good for.
Credential abuse fell to 13% as a standalone initial access vector, but still appears somewhere in 39% of breaches
A stolen key is rarely just one machine. SSH is how people move between hosts, so a key that opens one box is often a key that opens the next, and the one after that. This is lateral movement, and it's the objective after a cybercriminal gets in: turn one foothold into many, quietly, using credentials that are supposed to be there. A standing SSH key is perfect for it, and it looks exactly like legitimate use, because technically it is. A single stolen key can travel a long way before anyone notices. That's the real danger.
The big question isn't "how do I manage all these keys better?", it's "why is the key somewhere a human can reach it in the first place?"
Flip the model. Instead of distributing keys to people and hoping they keep them safe, the credential is injected into the connection at the resource, pulled just in time and only for the life of that session.
The developer authenticates themselves through your existing identity provider and connects. The Delinea Platform sits between the identity provider and the resource. Secret Server holds the private key, proxies the SSH session and creates that session without revealing the key to the person using it.
Delinea's Privileged Remote Access lets users connect through a browser, with no VPN or local client to install. Your platform or IT team centrally configures and manages the underlying connectivity and access controls. The infrastructure is still in place, but each user no longer has to handle the setup.
The important part is where the key is not. It lives in the vault, rotated on demand or on a schedule, with the key pair updated on every endpoint where it is used. The injection happens at the connection, not on the developer's laptop. You are not asking anyone to hold a secret in order to do their job.
There is a second route worth knowing about because it goes beyond injection. Server PAM takes the per-host key entirely out of the picture. Engineers log in to Windows, Linux and Unix servers as themselves using enterprise directory identities, with privileges elevated just-in-time and MFA enforced at both login and elevation. There is no key to distribute because there is no per-host account to distribute one to.
This is what narrows the path for lateral movement. When every session is authorized at connect time and tied to a real identity, and the credential only exists for the life of that session. There is no standing key sitting on a laptop for anyone to take. Connecting requires being you, right now, not just holding something you took. The standing credential that made a stolen key so useful is no longer part of the flow.
You can't leak a key you never held. That's not a slogan; it's the whole mechanism.
You didn't want to be in the SSH key management business. So stop being in it.
The keygen ritual goes away. The distribution scripts go away. The rotation cron that everyone's afraid to touch goes away. And revocation, the one that used to mean grepping the fleet at 6pm on someone's last day, becomes turning someone off once and being done. Access is tied to identity, so when the identity is gone, the access is gone, everywhere, at the same time.
You also get things you never got around to building: every session tied to a real human, recorded, and available when an auditor or an incident asks who did what, where, and when. Not because you built a logging pipeline, but because it connects this way instead of the old way.
If what you need is the operational details, rotation schedules, SSH certificates, and the controls that surround them, SSH key management best practices cover that ground. This post is about the question that comes before it: whether the key needs to exist anywhere a person can actually reach it.