You Don't Want Long-Lived Keys

Kelby Ludwig (security engineer at Argemma) argues that long-lived cryptographic keys are liabilities that compound over time, and that the right move is usually to replace them with ephemeral credentials rather than to get better at rotating them. Where rotation is unavoidable, concentrate the work in a focused team rather than distributing the toil across product engineers.

Why long-lived keys compound risk

Three independent pressures push the risk up over time:

• People leave. As employees come and go, the population of humans with possible knowledge of a key only grows. You can't unlearn a key.
• Guessing gets cheaper. If someone is constantly trying, the cumulative probability of a successful guess rises with time.
• Cryptographic wear-out. Symmetric primitives have message limits. Past roughly 2^32 messages with a single AES-GCM key, forgery attacks become realistic. The longer the key lives, the more usage it accrues.

Why rotation is painful

Most engineers can recognise at least one failure mode:

• A leak forces an emergency rotation that wasn't planned.
• A key generated years ago by an ex-employee comes with stale or absent documentation.
• The rotation rollout itself causes an outage because the runbook hasn't been exercised.
• A botched rotation has large blast radius — keys don't gracefully degrade, they just stop working everywhere at once.

Rotation works in principle and fails in practice for the same reason backups do: the muscle isn't exercised.

Ephemeral credentials sidestep most of this

A key that lives for a day or less makes "rotation" the default behaviour rather than a quarterly project. Three concrete substitutions Ludwig calls out:

• SSH access via EC2 Instance Connect. Instead of static keypairs copied into config and forgotten, each session requires a fresh authentication and authorization check that mints a short-lived credential.
• Package publishing via Trusted Publishers. A static PyPI token tends to spread — into a CTO's personal 1Password, then into half-forgotten release pipelines. Trusted Publishers lets a specific GitHub Actions workflow mint temporary credentials per release via OIDC. There is no token to leak. (See open-source-security-astral for Astral's implementation.)
• User authentication via SSO. A user-chosen long-lived password at every app gets replaced with a signed, short-lived assertion from an IdP. Attackers can guess weak passwords; they can't usefully guess a signed XML document. Ludwig acknowledges this still relies on the IdP's signing key being long-lived — that's the point of the next section.

When you can't eliminate the long-lived key

Some keys can't go away — the IdP's signing key, KMS root keys, encryption-at-rest masters. The argument is that reducing the count is still valuable, even if you can't drive it to zero:

• Concentrated effort. Reasoning about the security of one EC2 instance whose only job is calling KMS is much more tractable than reasoning about every engineer's laptop. Fewer long-lived keys means fewer pieces of infrastructure that need full rigor.
• Concentrated rigor. Cryptographic key limits, lifetime math, rotation runbooks — these need to be someone's main job. As a tertiary concern of a feature team, they get forgotten or done wrong. Make one team's job to solve it once for everyone.

For the long-lived keys that remain, Ludwig's checklist:

• Scope. Limit what each key can do. A data encryption key scoped to a single shard of customer data is much less useful to an attacker than a global one.
• Mathematically reasoned lifetime bounds. Pick a maximum lifetime with the same level of confidence as "would take a supercomputer billions of years to guess" — not vibes.
• Quarterly rotation minimum. Treat it as exercising a muscle. Regular rotations keep the tooling and documentation accurate.
• Concentrate the toil. Don't distribute it. A small team that owns this and is incentivised to be rigorous will do it better than every product team trying.

Connections

• ephemeral-credentials — the underlying concept this article makes the case for
• supply-chain-security — long-lived registry tokens are one of the prominent failure modes here
• jwt-for-sessions — adjacent argument about lifetime mismatch (long-lived sessions in a token format meant to be short-lived)
• crqc / post-quantum-cryptography — different angle on the same theme: today's long-lived keys may not survive tomorrow's threat model