Stop treating SSH certificates like a luxury for enterprise teams

Technical Briefing | 11/1/2026

Most of us started with authorized_keys files scattered across hundreds of servers. You manually copy a public key, try to automate it with Ansible, and eventually realize you have no idea who actually has access to what. It is a slow-motion disaster that bites you the moment an engineer leaves the team or a laptop gets stolen.

Why static keys are a liability

Static keys are effectively permanent unless you go out of your way to rotate them, which nobody does. If you rely on them, you aren’t really doing Zero Trust, you are just managing a massive, distributed ACL that you have lost control of. SSH certificates flip this around by making the key short-lived and cryptographically bound to an identity provider.

ssh-keygen -s /etc/ssh/ca_key -I admin-access -V +1h -n root,ubuntu user_key.pub

• Certificates eliminate the need to distribute individual public keys to every single node
• You can embed principals into the certificate to restrict access to specific system users
• Short expiry times act as a built-in revocation mechanism if someone forgets to renew
• The CA public key is the only thing that needs to live on your production servers

Moving past the manual CA dance

You don’t have to build a custom PKI infrastructure from scratch. Projects like Smallstep or HashiCorp Vault can automate the signing flow so your engineers just run a single command to get a key that works for the next eight hours. If you are still ssh-copy-id ing your way into servers, you are just waiting for a breach to tell you that it’s time to upgrade your security posture.

If you are worried about the migration, start by just pointing your testing environment at a CA. Once you see how quickly the old authorized_keys files become obsolete, you will wonder why you spent years wrestling with config management just to manage access lists.