The SSH key management in 2026 is an inventory problem, a rotation problem, and a trust problem that the security team has been overlooking because the SSH key sits as the most over privileged credential in the production environment, and the SSH key is also the credential that the security team has the least visibility into. The SSH key has been the workhorse of the production access for thirty years, the SSH key sits as the workhorse that the security team has not had the tools to manage properly, and the SSH key is going to be the entry point for the next major incident. This serves as the field guide to actually doing the work.
The SSH key serves as the most over privileged credential in most environments, and the credential is also the least audited. The SSH key counts as the credential that gets shared between the developer and the production system, and the SSH key stands as the credential that the security team has been telling itself amounts to the right answer for the developer access for the last three decades. The SSH key amounts to the right answer for the use case it was designed for (the developer logs in, the developer does the work, the developer logs out), and the SSH key serves as the wrong answer for most of the use cases it is being used for today (the service account, the CI/CD pipeline, the cross region replication, the emergency break glass).
The inventory problem
The inventory problem serves as the problem that the security team does not know what SSH keys exist, the security team does not know where the SSH keys are authorised, and the security team does not know who owns the SSH keys. The inventory problem sits as the most fundamental problem, the inventory problem counts as the most expensive problem to solve, and the inventory problem becomes the problem the security team is most likely to put off because the inventory problem amounts to the most tedious problem to solve.
The right way to solve the inventory problem is to use a tool that can read the authorised_keys files across the fleet, match the public keys to the users, and produce a report the security team can act on. The right tool in 2026 becomes the smallstep, the Teleport, the Boundary, or the open source equivalent. The wrong tool stands as the spreadsheet. The wrong tool becomes the home grown script.
The rotation problem
The rotation problem counts as the problem that the SSH keys do not get rotated regularly, the SSH keys do not get rotated when the owner leaves, and the SSH keys do not get rotated when the use case changes. The rotation problem runs as the most common problem, the rotation problem counts as the most preventable problem, and the rotation problem stands as the problem that the security team is going to have to fix first because the rotation problem amounts to the problem the regulator is going to ask about in the audit.
The right way to solve the rotation problem is to use a short lived certificate instead of a long lived key. The SSH certificate (the one issued by the smallstep CA, the Teleport CA, the internal HashiCorp Vault CA) has a lifetime of minutes to hours, the certificate is automatically rotated, and the certificate is automatically revoked when the owner leaves. The certificate amounts to the right answer for the use case the security team is going to have to defend in the audit, and the certificate counts as the answer the security team should be moving to.
The migration from the long lived key to the short lived certificate counts as the migration that takes the next 18 months for the typical enterprise. The migration is not free, the migration is going to require the engineering team to do the work, and the migration is going to be the work the security team is going to have to fund.
The trust problem
The trust problem runs as the problem that the security team does not know which SSH keys to trust, the security team does not know which SSH keys are compromised, and the security team does not know which SSH keys are being used by the attacker that is in the environment. The trust problem runs as the most dangerous problem, the trust problem serves as the most difficult problem to solve, and the trust problem runs as the problem the security team is going to have to solve before the next major incident.
The right way to solve the trust problem is to use a bastion host (the Teleport, the Boundary, the open source equivalents) that mediates every SSH session, records every SSH command, and provides the security team with the visibility the security team has been missing. The bastion host stands as the right answer for the production access use case, and the bastion host sits as the answer the security team should be deploying for the privileged access.
The bastion host is not free, the bastion host is going to add the latency the engineering team is going to complain about, and the bastion host is going to be the work the security team is going to have to do to make the production access auditable. The bastion host sits as the work, and the work is what the security team is going to have to do to make the SSH access defensible.
What to do this quarter
Pick one production system. Inventory the SSH keys. Document the owners. The inventory of one system counts as the proof of concept for the inventory of the rest, and the proof of concept is what the security team is going to have to do to make the rest of the inventory possible.
Then move the system to the short lived certificate. The first migration runs as the proof of concept for the rest of the migrations, and the first migration is what the security team is going to learn from. The first migration is going to be hard, the first migration is going to take longer than the security team expects, and the first migration is what the security team is going to have to do to make the rest of the migrations possible.
The bottom line
The patterns the post covers have been showing up in production for long enough that the patterns have names, the failures, the mitigations, the gaps. The work the security team and the engineering team and the operations team are quietly doing today sits as the work that decides whether the practice the post names sits as a tool the team uses or a liability the team is paying for.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
