You don't want long-lived keys

Long-lived keys are liabilities that, broadly, compound over time. You can manage this risk in two ways. The first is to reduce the scope of what a given key can do. This is ideal but not always possible. The more general risk reduction is rotating keys, which is often an incredible pain.

Systems built around ephemeral keys (i.e., keys that are valid for roughly 1 day or less) sidestep a lot of this pain as "rotation" is a built-in feature. Replacing long-lived keys with ephemeral keys is one of the best uses of security engineering effort.

Specific examples include replacing long-lived production SSH keys with temporary credentials like EC2 Instance Connect, or using "trusted publishers" in CI/CD pipelines to generate temporary credentials for package releases instead of static PyPI tokens. SSO is another prime example, replacing user-selected passwords with short-lived authentication assertions.

While it's not plausible to get rid of all long-lived keys, reducing their number allows you to concentrate security efforts. It is much easier to harden a focused piece of infrastructure than an arbitrary engineer's laptop.

For the long-lived keys that remain, follow these guidelines:

1. Limit the scope of what a given key can do.
2. Reason through the limits of the maximum lifetime of a given key.
3. Aim to rotate long-lived keys at least quarterly to ensure tooling and documentation stay sharp.

Proper maintenance of long-term keys takes work. Don't distribute that toil to everyone; concentrate that effort into a group incentivized to be rigorous and solve it once for everyone else.