Pick a short-lived certificate and you reduce the window of exposure if a private key ever leaks. Pick a long-lived certificate and you reduce the chance that a human forgets to renew it. Both failure modes are real. The team that frames this as "short is more secure, long is more convenient" usually ends up picking wrong. The right framing is which failure mode hurts you more.
Why short-lived is usually the right answer
Let's Encrypt defaults to 90-day certificates with a 60-day option. The short lifetime is the point. If a key is compromised, the damage window is capped at a quarter. Automation gets cheap with ACME, so the cost of "renew more often" drops to a cron job and a webhook.
For most modern infrastructure, this is the right answer. Kubernetes clusters running cert-manager. Virtual machines behind a Traefik or Caddy reverse proxy. Anyone with a CI pipeline that hits the right endpoint on a schedule. In all of those setups the certificate is a renewable artifact in a system, not a manual task.
Where longer lifetimes still earn their keep
The 398-day certificate, which the CA/B Forum caps for traditional commercial CAs like DigiCert, Sectigo, and GlobalSign, and which is itself being reduced to 200 days for new certs issued after March 15, 2026, still makes sense in a few narrow situations.
Extended Validation or Organization Validation certificates where a long-running procurement or finance department is the bottleneck for issuance. Air-gapped or restricted networks where outbound ACME is not possible and manual renewal is the realistic workflow. Legacy appliances and load balancers whose renewal interface is painful and infrequent.
In these cases, a year-long certificate spreads the cost of the next renewal event across twelve months instead of four. The argument is not that long certificates are safer, it is that they are less work in environments where automation is not a real option.
The trap teams fall into
Treating 90-day Let's Encrypt certificates as risky because they are "less stable" than paid annual certs. The reverse is true. A short certificate that the system handles automatically is far more stable than a long certificate that depends on a quarterly calendar reminder. The risk is not the lifetime, it is the human involvement.
What people actually mean when they say "production needs a paid CA"
When teams say "Let's Encrypt is fine for dev or staging but real production needs a paid CA," they usually mean that the certificates from their paid CA did not require any internal change to deploy. That is almost always because their paid CA renewals are still on a manual checklist somewhere. The honest comparison is automated 90-day renewals against manual 398-day renewals. The automated short-lived setup wins on both security and reliability.
Practical rules of thumb
If your ACME client runs unattended and your certificate chain is validated cleanly, go with the shortest lifetime available. If you need OV or EV and the procurement cycle takes longer than the certificate lifetime, talk to your CA about API-driven issuance before assuming you need a long cert. If you genuinely cannot automate, put the renewal on a checklist with calendar reminders well before the expiry, and back it with a monitoring tool that pages you independently of any calendar entry. The shorter lifetime makes the calendar error smaller, but neither lifetime saves you from a missed renewal by itself.
The underlying math
Pick the lifetime that, given your automation, has the smallest realistic chance of producing an expired certificate in production. For most teams in 2026 that is the shortest certificate their setup can comfortably handle.