Your SSH Keys Are a Liability. Here's What Replaces Them.
TL;DR: SSH keys don't expire, don't rotate, and don't get revoked when someone leaves. Twingate Privileged Access for SSH brokers sessions through your IdP so there's no key material to leak, orphan, or forget.
Nobody knows how many SSH keys are sitting on their servers.
That's the actual problem. Ask a security team how many keys grant root on production and you'll get an estimate, a nervous laugh, or a promise to get back to you. Meanwhile the CrowdStrike 2025 Global Threat Report found that 79% of attacks in 2024 were malware-free, relying on valid credentials that were already trusted.
An SSH key is a valid credential. It's trusted by every server that holds it. It doesn't set off alarms. And there's a very good chance you have thousands of them you can't account for.
The scale of the problem is worse than most people think
A few numbers worth sitting with:
Studies from Ponemon and Venafi have found that 60–90% of enterprises don't have a complete inventory of their SSH keys.
Large organizations average more than 7,000 orphaned SSH keys with root or privileged access. These are keys tied to former employees, decommissioned services, or forgotten automation.
On average, an SSH key is used to authenticate to more than 10 servers, meaning a single stolen key often opens a lateral path across an entire environment.
None of this is theoretical.
The 2015 breach at a major cloud provider, the 2019 attack on a large enterprise SaaS company, and repeated compromises documented by Mandiant have all involved either stolen keys or keys left behind by people who no longer worked at the company. In most cases, no one noticed for months.
Why SSH keys became a security debt
SSH keys made sense in 2005.
You had a handful of servers, a handful of engineers, and a shared understanding that private keys stayed on laptops.
That's not what happens now:
An engineer joins. They generate a key pair on their laptop. IT (or the engineer themselves) copies the public key into authorized_files on however many bastion hosts, jump boxes, and production servers they need to reach. There's usually no central record of which servers got which key.
Six months later that engineer works on a different team, but the keys stay. Two years later they leave. HR deprovisions their Okta account, their laptop is wiped, and their Slack is deactivated. The public key sitting in ~/.ssh/authorized_keys on 40 servers? Untouched.
SSH keys don't:
Expire on their own
Show up in your IdP's deprovisioning workflow
Get rotated when someone changes roles
Appear in a central inventory unless you built one
Trigger MFA challenges when used
Generate meaningful audit trails tied to a human identity
They also travel. A key copied to a shared bastion, an SCP'd config directory, a laptop backup, a CI runner, a Terraform state file. Each copy is a new attack surface, and the original owner has no idea.
The credential problem is now the attack
The CrowdStrike figure, 79% malware-free, is the number that should change how security teams think about this. Attackers don't need to write exploits anymore. They log in.
The 2024 Snowflake customer breach is a decent illustration. Attackers used valid credentials, harvested from earlier infostealer campaigns, to access customer environments. No zero-day or malware. Just legitimate credentials used by an illegitimate person, invisible to endpoint detection because there was nothing malicious to detect.
SSH keys are exactly this pattern. A key harvested from a compromised laptop, a leaked backup, a misconfigured CI system, or a git repo (it happens more than anyone wants to admit) is a valid credential. The server accepts it. The audit log records a successful login. Nothing looks wrong.
Signature-based detection can't help you here. Behavior-based detection can sometimes catch anomalous session activity, but by then the attacker is already in.
What "replace SSH keys" actually means
The goal shouldn't be to add another layer on top of key management. Vaulting keys, rotating keys, running certificate authorities for short-lived SSH certs, these all reduce risk, but they preserve the underlying model: static credentials that the server trusts.
The shift is to broker SSH sessions through identity, not through key material. In this model:
Users authenticate to their IdP (Okta, Entra ID, Google, whatever you already use)
An access broker verifies identity, device posture, and policy at session time
The broker establishes the SSH session to the target server
Neither the user's device nor the server's
authorized_keysfile holds any long-lived credentialWhen the IdP account is disabled, access stops everywhere on the next authentication attempt
This is what Twingate Privileged Access for SSH does. It sits at Layer 7 as a session-level gateway. Users initiate SSH the way they always have. The Twingate Gateway verifies the request against your IdP and your Twingate policy, then proxies the session to the resource.
There's no key on the user's device to steal, no authorized_keys entry to forget, and the session itself is recorded for audit.
How it works, briefly
The architecture uses four components you'd expect from a Zero Trust Network Access system:
The Client on the user's device intercepts the SSH connection attempt.
The Controller verifies the user's identity against your IdP and checks policy.
The Connector, deployed inside your environment with outbound-only connectivity, receives the authorized session and proxies it to the target server.
The Gateway enforces per-session policy at Layer 7 and records the session.
No inbound ports open on your servers. No SSH keys distributed. No jump box holding the union of everyone's access.
What offboarding should look like
The clearest way to describe the difference is offboarding. Today, in most organizations, it looks like this:
HR disables the Okta account.
IT deprovisions email, Slack, Zoom, GitHub.
Someone tries to find the person's SSH keys. Success is optional.
Six months later, an audit turns up their key still in
authorized_keyson a handful of production hosts. Someone opens a ticket. The ticket sits.
With identity-brokered access, offboarding is:
HR disables the IdP account.
That's it.
The next time anyone attempts to use that identity to reach any resource (SSH, database, internal web app, Kubernetes) the Controller rejects the authorization request. There's no residual credential to clean up because there was never a credential to leave behind.
Common objections, briefly
"What about break-glass access?" Fair. You still need a documented emergency path, typically a small number of hardware-token-protected accounts audited separately. The point isn't that SSH keys are never appropriate, it's that they shouldn't be the default access model for everyone.
"What about automation and CI?" Service accounts and workload identities are their own problem. Short-lived credentials, OIDC federation from your CI system, and workload-specific policies are the right pattern. Twingate handles service accounts as first-class identities with their own policies, which is different from treating a CI system as if it were a human.
"What about audit and compliance?" Session-level recording and centralized logs are usually a compliance upgrade over what most teams have with raw SSH. Auditors generally prefer "here's every session tied to a named identity" to "here's a wtmp log we hope hasn't been tampered with."
"We already use SSH certificates." SSH CAs are a real improvement over static keys. But they still leave you managing a CA, key rotation, and per-user certificate issuance. Brokering through identity removes those operational costs entirely, and the user experience is often better because there's no cert to renew.
The takeaway
If your access model depends on knowing where every SSH key is, you've already lost. Most organizations don't know, and the ones that think they do are usually wrong by an order of magnitude.
Static credentials that the server trusts, distributed to users and never revoked, are the exact shape of the problem behind most modern breaches. The fix isn't better key management. It's making the key unnecessary in the first place — brokering sessions through the identity system you already run and trust.
Closing
For more on how to deploy the Identity Firewall for SSH and configure per-session policies, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Your SSH Keys Are a Liability. Here's What Replaces Them.
TL;DR: SSH keys don't expire, don't rotate, and don't get revoked when someone leaves. Twingate Privileged Access for SSH brokers sessions through your IdP so there's no key material to leak, orphan, or forget.
Nobody knows how many SSH keys are sitting on their servers.
That's the actual problem. Ask a security team how many keys grant root on production and you'll get an estimate, a nervous laugh, or a promise to get back to you. Meanwhile the CrowdStrike 2025 Global Threat Report found that 79% of attacks in 2024 were malware-free, relying on valid credentials that were already trusted.
An SSH key is a valid credential. It's trusted by every server that holds it. It doesn't set off alarms. And there's a very good chance you have thousands of them you can't account for.
The scale of the problem is worse than most people think
A few numbers worth sitting with:
Studies from Ponemon and Venafi have found that 60–90% of enterprises don't have a complete inventory of their SSH keys.
Large organizations average more than 7,000 orphaned SSH keys with root or privileged access. These are keys tied to former employees, decommissioned services, or forgotten automation.
On average, an SSH key is used to authenticate to more than 10 servers, meaning a single stolen key often opens a lateral path across an entire environment.
None of this is theoretical.
The 2015 breach at a major cloud provider, the 2019 attack on a large enterprise SaaS company, and repeated compromises documented by Mandiant have all involved either stolen keys or keys left behind by people who no longer worked at the company. In most cases, no one noticed for months.
Why SSH keys became a security debt
SSH keys made sense in 2005.
You had a handful of servers, a handful of engineers, and a shared understanding that private keys stayed on laptops.
That's not what happens now:
An engineer joins. They generate a key pair on their laptop. IT (or the engineer themselves) copies the public key into authorized_files on however many bastion hosts, jump boxes, and production servers they need to reach. There's usually no central record of which servers got which key.
Six months later that engineer works on a different team, but the keys stay. Two years later they leave. HR deprovisions their Okta account, their laptop is wiped, and their Slack is deactivated. The public key sitting in ~/.ssh/authorized_keys on 40 servers? Untouched.
SSH keys don't:
Expire on their own
Show up in your IdP's deprovisioning workflow
Get rotated when someone changes roles
Appear in a central inventory unless you built one
Trigger MFA challenges when used
Generate meaningful audit trails tied to a human identity
They also travel. A key copied to a shared bastion, an SCP'd config directory, a laptop backup, a CI runner, a Terraform state file. Each copy is a new attack surface, and the original owner has no idea.
The credential problem is now the attack
The CrowdStrike figure, 79% malware-free, is the number that should change how security teams think about this. Attackers don't need to write exploits anymore. They log in.
The 2024 Snowflake customer breach is a decent illustration. Attackers used valid credentials, harvested from earlier infostealer campaigns, to access customer environments. No zero-day or malware. Just legitimate credentials used by an illegitimate person, invisible to endpoint detection because there was nothing malicious to detect.
SSH keys are exactly this pattern. A key harvested from a compromised laptop, a leaked backup, a misconfigured CI system, or a git repo (it happens more than anyone wants to admit) is a valid credential. The server accepts it. The audit log records a successful login. Nothing looks wrong.
Signature-based detection can't help you here. Behavior-based detection can sometimes catch anomalous session activity, but by then the attacker is already in.
What "replace SSH keys" actually means
The goal shouldn't be to add another layer on top of key management. Vaulting keys, rotating keys, running certificate authorities for short-lived SSH certs, these all reduce risk, but they preserve the underlying model: static credentials that the server trusts.
The shift is to broker SSH sessions through identity, not through key material. In this model:
Users authenticate to their IdP (Okta, Entra ID, Google, whatever you already use)
An access broker verifies identity, device posture, and policy at session time
The broker establishes the SSH session to the target server
Neither the user's device nor the server's
authorized_keysfile holds any long-lived credentialWhen the IdP account is disabled, access stops everywhere on the next authentication attempt
This is what Twingate Privileged Access for SSH does. It sits at Layer 7 as a session-level gateway. Users initiate SSH the way they always have. The Twingate Gateway verifies the request against your IdP and your Twingate policy, then proxies the session to the resource.
There's no key on the user's device to steal, no authorized_keys entry to forget, and the session itself is recorded for audit.
How it works, briefly
The architecture uses four components you'd expect from a Zero Trust Network Access system:
The Client on the user's device intercepts the SSH connection attempt.
The Controller verifies the user's identity against your IdP and checks policy.
The Connector, deployed inside your environment with outbound-only connectivity, receives the authorized session and proxies it to the target server.
The Gateway enforces per-session policy at Layer 7 and records the session.
No inbound ports open on your servers. No SSH keys distributed. No jump box holding the union of everyone's access.
What offboarding should look like
The clearest way to describe the difference is offboarding. Today, in most organizations, it looks like this:
HR disables the Okta account.
IT deprovisions email, Slack, Zoom, GitHub.
Someone tries to find the person's SSH keys. Success is optional.
Six months later, an audit turns up their key still in
authorized_keyson a handful of production hosts. Someone opens a ticket. The ticket sits.
With identity-brokered access, offboarding is:
HR disables the IdP account.
That's it.
The next time anyone attempts to use that identity to reach any resource (SSH, database, internal web app, Kubernetes) the Controller rejects the authorization request. There's no residual credential to clean up because there was never a credential to leave behind.
Common objections, briefly
"What about break-glass access?" Fair. You still need a documented emergency path, typically a small number of hardware-token-protected accounts audited separately. The point isn't that SSH keys are never appropriate, it's that they shouldn't be the default access model for everyone.
"What about automation and CI?" Service accounts and workload identities are their own problem. Short-lived credentials, OIDC federation from your CI system, and workload-specific policies are the right pattern. Twingate handles service accounts as first-class identities with their own policies, which is different from treating a CI system as if it were a human.
"What about audit and compliance?" Session-level recording and centralized logs are usually a compliance upgrade over what most teams have with raw SSH. Auditors generally prefer "here's every session tied to a named identity" to "here's a wtmp log we hope hasn't been tampered with."
"We already use SSH certificates." SSH CAs are a real improvement over static keys. But they still leave you managing a CA, key rotation, and per-user certificate issuance. Brokering through identity removes those operational costs entirely, and the user experience is often better because there's no cert to renew.
The takeaway
If your access model depends on knowing where every SSH key is, you've already lost. Most organizations don't know, and the ones that think they do are usually wrong by an order of magnitude.
Static credentials that the server trusts, distributed to users and never revoked, are the exact shape of the problem behind most modern breaches. The fix isn't better key management. It's making the key unnecessary in the first place — brokering sessions through the identity system you already run and trust.
Closing
For more on how to deploy the Identity Firewall for SSH and configure per-session policies, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Your SSH Keys Are a Liability. Here's What Replaces Them.
TL;DR: SSH keys don't expire, don't rotate, and don't get revoked when someone leaves. Twingate Privileged Access for SSH brokers sessions through your IdP so there's no key material to leak, orphan, or forget.
Nobody knows how many SSH keys are sitting on their servers.
That's the actual problem. Ask a security team how many keys grant root on production and you'll get an estimate, a nervous laugh, or a promise to get back to you. Meanwhile the CrowdStrike 2025 Global Threat Report found that 79% of attacks in 2024 were malware-free, relying on valid credentials that were already trusted.
An SSH key is a valid credential. It's trusted by every server that holds it. It doesn't set off alarms. And there's a very good chance you have thousands of them you can't account for.
The scale of the problem is worse than most people think
A few numbers worth sitting with:
Studies from Ponemon and Venafi have found that 60–90% of enterprises don't have a complete inventory of their SSH keys.
Large organizations average more than 7,000 orphaned SSH keys with root or privileged access. These are keys tied to former employees, decommissioned services, or forgotten automation.
On average, an SSH key is used to authenticate to more than 10 servers, meaning a single stolen key often opens a lateral path across an entire environment.
None of this is theoretical.
The 2015 breach at a major cloud provider, the 2019 attack on a large enterprise SaaS company, and repeated compromises documented by Mandiant have all involved either stolen keys or keys left behind by people who no longer worked at the company. In most cases, no one noticed for months.
Why SSH keys became a security debt
SSH keys made sense in 2005.
You had a handful of servers, a handful of engineers, and a shared understanding that private keys stayed on laptops.
That's not what happens now:
An engineer joins. They generate a key pair on their laptop. IT (or the engineer themselves) copies the public key into authorized_files on however many bastion hosts, jump boxes, and production servers they need to reach. There's usually no central record of which servers got which key.
Six months later that engineer works on a different team, but the keys stay. Two years later they leave. HR deprovisions their Okta account, their laptop is wiped, and their Slack is deactivated. The public key sitting in ~/.ssh/authorized_keys on 40 servers? Untouched.
SSH keys don't:
Expire on their own
Show up in your IdP's deprovisioning workflow
Get rotated when someone changes roles
Appear in a central inventory unless you built one
Trigger MFA challenges when used
Generate meaningful audit trails tied to a human identity
They also travel. A key copied to a shared bastion, an SCP'd config directory, a laptop backup, a CI runner, a Terraform state file. Each copy is a new attack surface, and the original owner has no idea.
The credential problem is now the attack
The CrowdStrike figure, 79% malware-free, is the number that should change how security teams think about this. Attackers don't need to write exploits anymore. They log in.
The 2024 Snowflake customer breach is a decent illustration. Attackers used valid credentials, harvested from earlier infostealer campaigns, to access customer environments. No zero-day or malware. Just legitimate credentials used by an illegitimate person, invisible to endpoint detection because there was nothing malicious to detect.
SSH keys are exactly this pattern. A key harvested from a compromised laptop, a leaked backup, a misconfigured CI system, or a git repo (it happens more than anyone wants to admit) is a valid credential. The server accepts it. The audit log records a successful login. Nothing looks wrong.
Signature-based detection can't help you here. Behavior-based detection can sometimes catch anomalous session activity, but by then the attacker is already in.
What "replace SSH keys" actually means
The goal shouldn't be to add another layer on top of key management. Vaulting keys, rotating keys, running certificate authorities for short-lived SSH certs, these all reduce risk, but they preserve the underlying model: static credentials that the server trusts.
The shift is to broker SSH sessions through identity, not through key material. In this model:
Users authenticate to their IdP (Okta, Entra ID, Google, whatever you already use)
An access broker verifies identity, device posture, and policy at session time
The broker establishes the SSH session to the target server
Neither the user's device nor the server's
authorized_keysfile holds any long-lived credentialWhen the IdP account is disabled, access stops everywhere on the next authentication attempt
This is what Twingate Privileged Access for SSH does. It sits at Layer 7 as a session-level gateway. Users initiate SSH the way they always have. The Twingate Gateway verifies the request against your IdP and your Twingate policy, then proxies the session to the resource.
There's no key on the user's device to steal, no authorized_keys entry to forget, and the session itself is recorded for audit.
How it works, briefly
The architecture uses four components you'd expect from a Zero Trust Network Access system:
The Client on the user's device intercepts the SSH connection attempt.
The Controller verifies the user's identity against your IdP and checks policy.
The Connector, deployed inside your environment with outbound-only connectivity, receives the authorized session and proxies it to the target server.
The Gateway enforces per-session policy at Layer 7 and records the session.
No inbound ports open on your servers. No SSH keys distributed. No jump box holding the union of everyone's access.
What offboarding should look like
The clearest way to describe the difference is offboarding. Today, in most organizations, it looks like this:
HR disables the Okta account.
IT deprovisions email, Slack, Zoom, GitHub.
Someone tries to find the person's SSH keys. Success is optional.
Six months later, an audit turns up their key still in
authorized_keyson a handful of production hosts. Someone opens a ticket. The ticket sits.
With identity-brokered access, offboarding is:
HR disables the IdP account.
That's it.
The next time anyone attempts to use that identity to reach any resource (SSH, database, internal web app, Kubernetes) the Controller rejects the authorization request. There's no residual credential to clean up because there was never a credential to leave behind.
Common objections, briefly
"What about break-glass access?" Fair. You still need a documented emergency path, typically a small number of hardware-token-protected accounts audited separately. The point isn't that SSH keys are never appropriate, it's that they shouldn't be the default access model for everyone.
"What about automation and CI?" Service accounts and workload identities are their own problem. Short-lived credentials, OIDC federation from your CI system, and workload-specific policies are the right pattern. Twingate handles service accounts as first-class identities with their own policies, which is different from treating a CI system as if it were a human.
"What about audit and compliance?" Session-level recording and centralized logs are usually a compliance upgrade over what most teams have with raw SSH. Auditors generally prefer "here's every session tied to a named identity" to "here's a wtmp log we hope hasn't been tampered with."
"We already use SSH certificates." SSH CAs are a real improvement over static keys. But they still leave you managing a CA, key rotation, and per-user certificate issuance. Brokering through identity removes those operational costs entirely, and the user experience is often better because there's no cert to renew.
The takeaway
If your access model depends on knowing where every SSH key is, you've already lost. Most organizations don't know, and the ones that think they do are usually wrong by an order of magnitude.
Static credentials that the server trusts, distributed to users and never revoked, are the exact shape of the problem behind most modern breaches. The fix isn't better key management. It's making the key unnecessary in the first place — brokering sessions through the identity system you already run and trust.
Closing
For more on how to deploy the Identity Firewall for SSH and configure per-session policies, check out the Twingate documentation.
New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions