Ballot SC-081v3 cut the maximum public TLS certificate lifetime to 200 days from 15 March 2026, with 100 days from March 2027 and 47 days from March 2029. A team currently renews its 400 public certificates by quarterly ticket. What does the shorter ceiling buy, and what is the bill?

What is gained

Revocation does not work well enough to rely on. Certificate revocation lists are stale by design, and soft-fail status checking means a client that cannot reach the responder proceeds anyway. In practice the real bound on the damage from a compromised key is the certificate's remaining lifetime, so the ceiling is the control. Going from 398 days to 47 days shrinks that exposure window by roughly eight times.

The second gain is indirect and larger: a 47-day certificate cannot be renewed by a human remembering, so the policy forces out the most common self-inflicted outage in this area, the certificate nobody was tracking.

What is paid

Renewal stops being an administrative task and becomes a production dependency on the critical path. At a 47-day ceiling, renewing at two-thirds of life means roughly every 30 days: for 400 certificates that is around 5000 issuances a year instead of 400. The same ballot cuts domain-validation reuse towards 10 days by 2029, so validation cannot be cached across renewals either.

The new failure modes are all in the pipeline rather than the calendar: the ACME client, write permission on the DNS zone used for validation, certificate-authority rate limits, and distribution to every place that terminates TLS. Anything pinning a certificate or embedding a leaf in a trust store now breaks on a monthly cadence rather than annually.

When the cost becomes visible

At the first renewal that coincides with a DNS provider API incident, and at the first inventory surprise - the certificate on an appliance, in a vendor console, or in a load balancer somebody created by hand four years ago. The estate is discovered by the policy, usually at 03:00.

How to keep the option to reverse

• Inventory before automating. Count certificates, owners and terminating components. Anything not issued through the automated path is the actual risk register.
• Renew at one third of remaining life, so a failed renewal leaves a week of retries rather than hours.
• Alert on the absence of an event. "No successful renewal in N days" catches a silent scheduler, which "certificate expires soon" catches only at the end. This is the alert teams skip and then need.
• Keep a tested manual issuance path, because the fallback you have never exercised is not a fallback.
• Standardise on the validation method you can automate everywhere, typically DNS-based validation against a delegated zone, rather than per-host methods that fail on the one host nobody can reach.

Common weak answers

• "We will ask our CA for longer certificates." Public certificates above the ceiling will not be issued, and browsers enforce it independently.
• "We will run an internal CA." Reasonable for internal traffic and irrelevant for public endpoints, and an internal CA needs the same automation with none of the external deadlines to force it.
• "We will script it in the build pipeline." A quarterly ticket replaced by a job with no alert on non-execution has relocated the outage rather than removed it.