When should you use short-lived certificates instead of long-lived ones?

Short-lived certificates — often valid for hours or days instead of a year — make sense wherever the workload issuing them is ephemeral or where the security benefit of frequent rotation outweighs the operational cost of renewing more often.

Typical cases include containers and pods that only live for the duration of a deployment, service-mesh sidecars authenticating internal east-west traffic, and CI/CD build agents that spin up and tear down per job. In all of these, a stolen or leaked certificate has a much smaller window of usefulness to an attacker if it expires in hours rather than a year, and there's no operational team dependent on manually renewing it since the issuance is fully automated (often through Firefly rather than the full TPP path).

Long-lived certificates still make sense for stable, human-facing endpoints — a public website or an API gateway with an external SLA — where renewal automation exists but the workload itself isn't disappearing every few minutes, so the extra rotation frequency of a short-lived cert wouldn't add meaningful security value.