How short can a certificate live before your process breaks?

In April, the CA/Browser Forum approved ballot SC-081v3: public TLS certificate lifetimes step down from today's 398 days to 200 in March 2026, 100 in March 2027, and 47 days by March 2029. Browsers and CAs voted for it together. It is happening.

The right reading of the schedule is not "certificates got annoying". It is: manual certificate handling has been given a published end date. At 398 days, a renewal is an annual ritual a calendar reminder can carry. At 47, it is a monthly operation across every endpoint you own, and a process that involves a human copying a file will fail often enough to page you more than it works.

So the question in the title converts to a checkable condition: what would have to be true for 47 days to be a non-event? One answer, in three parts. Issuance is automated everywhere, including the appliances, the load balancers and the vendor boxes that today get certificates by ticket. Deployment is automated everywhere, meaning the certificate reaches the process that serves it without a maintenance window. And expiry is observed independently, because automation that fails silently at monthly cadence produces outages at monthly cadence.

The audit worth doing this quarter is an inventory with one column: for each certificate, does its renewal involve a person? The rows that say yes are your 2027 incident list, published four years early. The vendors on those rows get one email each, now, asking for their automation roadmap; procurement leverage ages badly once everyone is asking.

The schedule's kindness is its dates. March 2026 breaks the annual habit, March 2027 breaks the semi-manual, and each step is a rehearsal for the next. Teams that treat 200 days as the deadline for full automation will find 47 uneventful. Teams that treat each step as survivable will meet 2029 the interesting way. The forum, unusually for this industry, told you exactly when the debt is due.