Your SSH keys are living in the past

Technical Briefing | 7/14/2026

We all love the simplicity of authorized_keys. It worked perfectly for the last two decades. But if you are still managing a central list of static public keys for fifty engineers across three hundred servers, you are sitting on a time bomb. If one laptop gets compromised or an engineer leaves the company, revoking their access without causing a massive operational headache is effectively impossible. It is time to stop pretending that static keys are an identity management strategy.

Why ephemeral certificates are actually sane

The shift toward Zero Trust means identity needs to be proven at the moment of connection, not based on a file that has been sitting on your root filesystem since 2018. SSH certificates allow you to issue a short-lived key that expires in an hour. When it dies, the access is gone. If you want back in, you re-authenticate with your SSO provider. No more stale accounts, no more manual key rotation, and no more panic when someone forgets their YubiKey on the train.

ssh-keygen -s ca_key -I cert_id -V +1h -z 12345 user_key.pub

• Sign keys with a hardware-backed CA rather than keeping the private key on a random build server
• Enforce forced-command restrictions in the certificate to limit what users can run
• Set the validity window to match your standard shift duration so keys naturally expire

Transitioning to a CA-based setup can feel like a heavy lift, especially when your current workflow is just a bunch of scripts pushing keys around. Start by configuring one bastion host to accept a CA-signed key. Once you see the audit logs populate with the certificate serials rather than just ambiguous key fingerprints, the peace of mind will be worth the initial friction. Next time an audit happens, you will actually have proof of who was authorized at any specific second.