398 days to 47 reads like a number change. Means nothing to management right? It’s a workflow change. The cert(s) we touch once a year becomes the cert we touch every six weeks, multiplied by the entire inventory just built.
The schedule is fixed, it is public, and it’s not a rumor. The CA/Browser Forum passed Ballot SC-081v3 in April 2025, and it steps the maximum lifetime of a publicly trusted TLS certificate down: from 398 days, 200 days as of March 15, 2026, 100 days as of March 15, 2027, and 47 days as of March 15, 2029 [1]. Each step roughly halves the one before it. Certificates already issued keep their original lifetime, so nothing breaks overnight; the squeeze arrives at renewal, which is where most of your inventory meets the new rules whether it’s ready or not.
The math is the part that reframes it from policy to operations. An organization running a thousand public certificates handles on the order of a thousand renewals a year today. At a 47-day lifetime, those same thousand certificates generate nearly eight thousand renewal events a year, because each one now turns over roughly eight times instead of once [2]. That is the eight-fold figure sitting behind the opening line, and it’s why “we’ll add headcount” isn’t an answer. You don’t staff your way out of an eight-fold increase in a recurring administrative operation that requires a modicum of due diligence. You automate it, or you start having outages.
This isn’t hypothetical. Missed renewals already take down major infrastructures more than we sometimes want to admit:
- Microsoft Teams, February 2020: an expired authentication certificate locked users out of Teams globally for roughly three hours after the company reported that users may be unable to access Microsoft Teams and later confirmed the outage was due to an expired certificate (TechCrunch)
- Ericsson SGSN-MME, December 2018: an expired software certificate in Ericsson’s core network software shut down affected equipment, knocking out mobile data and voice for roughly 32 million O2 customers in the UK and tens of millions of SoftBank customers in Japan (Softpedia)
- Logitech certificate, January 2026: an expired code-signing certificate broke Logitech’s macOS apps system-wide, a fresh reminder that renewal failures aren’t a 2018-2020 relic (MacRumors)
Three different failure modes, one common thread: none of these companies lacked the engineering talent to prevent an expiration date from arriving unnoticed. They lacked the automation, or monitoring, or inventory, or any combination of the three.
The 2027 Cliff
Here is the part the headlines seem to miss: the cliff is 2027, not 2029. The 200-day phase that arrived in 2026 still survives a semi-manual process, because renewing twice a year is annoying but livable. The 100-day phase in March 2027 is where it breaks for most organizations, because quarterly-plus renewal across a production inventory is past the point where people clicking buttons can keep pace.
By the time 47 days lands in 2029, any team that is going to make it has already automated. If 2029 is the coup de grâce, then 2027 is the wound, and “it’s just a flesh wound” is not a migration strategy. Plan for the 2027 date and the 2029 one mostly takes care of itself.
Validity, meanwhile, is only the number everyone watches. The one that actually reshapes your tooling is domain control validation reuse, which steps down on its own track: 398 days, now 200, soon 100, and finally 10 days in the last phase [1]. At a 47-day certificate with a 10-day reuse window, you are re-proving control of each domain something like three dozen times a year. Email-based validation and a human dropping a file on a server are finished at that cadence; they were never meant to run weekly.
Worse, validation is getting more rigorous at the same time as it gets more frequent: the Forum now requires corroborating domain validation from multiple network perspectives, and DNSSEC validation where present is effective alongside the first phase in March 2026 [3]. The operation you now run thirty-odd times a year is also harder to run each time. There is no shortcut hiding in the effort.
The Escape Hatch
There is, however, an escape hatch. In October 2025 the Forum added a new domain control validation method, section 3.2.2.4.22, “DNS TXT Record with Persistent Value,” informally the DNS-PERSIST-01 method [4], with a matching ACME challenge moving through the IETF as dns-persist-01 [5]. The idea is a set-once and reap the benefits over time: we place a single persistent TXT record naming the CA and our account, and the CA reuses it across issuances instead of making us rewrite DNS on every renewal.
Read the fine print, though, because it’s easy to oversell. The persistent record doesn’t exempt you from the 10-day reuse cap; the CA still re-checks the record at each issuance and still may only rely on it for those ten days. What it removes is the per-renewal DNS write, not the re-validation. For shops with strict DNS change-management, for multi-tenant and edge platforms, and for IoT fleets that can’t coordinate real-time DNS updates, it can be the difference between feasible and ITIL change control revolt; it’s a workflow simplification, not a loophole.
Add it up and the conclusion isn’t so subtle. At this cadence automation stops being a nice-to-have and becomes the only way to stay out of an asylum. But “just automate it” quietly assumes one thing that falls apart fast: that a single CA can issue everything you need. And that’s what we discuss next.
References
[1] CA/Browser Forum. Ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods” (passed April 2025). Maximum TLS validity 398 to 200 (15 Mar 2026), 100 (15 Mar 2027), 47 (15 Mar 2029); DCV reuse 398 to 200, 100, then 10 days; Subject Identity Information reuse 825 to 398 days as of 15 Mar 2026.
[2] DigiCert. “TLS Certificate Lifetimes Will Officially Reduce to 47 Days” (2025
[3] CA/Browser Forum. Ballot SC-067v3 (Multi-Perspective Issuance Corroboration) and Ballot SC-085v2 (Require Validation of DNSSEC when present for CAA and DCV lookups)
[4] CA/Browser Forum. Ballot SC-088v3, "DNS TXT Record with Persistent Value DCV Method
[5] IETF draft-ietf-acme-dns-persist, ACME challenge “dns-persist-01” for persistent DNS TXT record validation (working-group draft, rev -01, 2026).