Certificates Are About to Expire Every 47 Days. Most Teams Can't Rotate Them Manually
October 29, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
A publicly trusted TLS certificate issued today can still last about a year. By March 2029, the maximum will be 47 days. The CA/Browser Forum's Ballot SC-081v3 phases that reduction in over three steps, and it applies to every website, API, and internal service that relies on a public certificate, which means the renewal process your team runs a few times a year is about to become a process it runs every month and a half, for every certificate it owns.
That is not a distant compliance footnote. It is an operations problem with a fixed deadline, and it is already reshaping what "certificate management" means as a job function.
What exactly is changing, and when?
Starting March 15, 2026, the maximum validity for a publicly trusted TLS certificate drops to 200 days. A year later, on March 15, 2027, it drops again to 100 days. The final cut lands on March 15, 2029, when the ceiling falls to 47 days, a schedule set by Ballot SC-081v3, approved unanimously by the CA/Browser Forum in April 2025.
Alongside the shorter lifespans, the ballot also shortens how long domain control validation can be reused before a certificate authority has to re-verify that you actually control a domain. That reuse window compresses on the same schedule, which means the administrative overhead of proving domain ownership gets more frequent too, not just the certificate issuance itself. The CA/Browser Forum sets these Baseline Requirements as the industry body of certificate authorities and browser makers, and its rules on validation, issuance, and revocation already govern how SSL/TLS certificates get trusted across the web.
For a team managing a handful of certificates, this is an annoyance. For a team managing thousands across cloud load balancers, internal APIs, IoT fleets, and partner integrations, it is a different workload entirely. A process that ran a few times a year on a spreadsheet now has to run dozens of times a month, correctly, with zero tolerance for a missed renewal, because a missed renewal means a public-facing outage.
Why does a shorter certificate lifespan matter if renewal is "just" a technical task?
It matters because most organizations still treat certificate renewal as a manual task owned by whoever remembers to do it, and that model breaks down fast once lifespans shrink. Recent research from DigiCert found manual certificate management can cost enterprises an average of $11.1 million annually once you account for outages, compliance failures, and the labor spent chasing expirations by hand.
That same research found senior security leaders now rank certificate expiration alongside customer trust and regulatory compliance as a top concern, and that CISOs ranked customer trust, regulatory compliance, and certificate expiration as their leading worries tied to certificate management. This is no longer a task you delegate to whoever has five minutes free. It is a named line item on the CISO's risk register.
The outage risk is not hypothetical. Separate research from CSC, a domain and SSL management provider, found that as many as 40% of enterprises are at risk of unexpected service outages caused by out-of-date SSL certificates, tied specifically to upcoming changes in how domain control gets validated. Shorten the renewal cycle without changing how renewal gets done, and that 40% figure does not improve. It gets worse, because the margin for human error shrinks along with the validity window.
The fix is automation, and that is a skills gap, not a tooling gap
The industry's own guidance already points in one direction. NIST's Special Publication 1800-16 on securing web transactions is explicit that manual certificate processes do not scale, recommending that certificate services teams provide a central system supporting automated management while certificate owners automate the management of their own certificates. That guidance predates the 47-day mandate, but the mandate is what turns it from a best practice into a requirement.
Automated Certificate Management Environment, the ACME protocol, is the mechanism most organizations will lean on. It lets servers request, validate, and renew certificates without a human clicking through a portal, and it is already the backbone of free certificate issuance at scale. The problem is not that ACME is hard to configure. The problem is that most IT and security staff have never had to design a certificate lifecycle around machine-speed renewal, map every certificate across an environment that has grown without a central inventory, or build the monitoring that catches a failed automated renewal before it becomes an outage at 2 a.m.
That is the actual skills gap. Discovery, inventory, automation tooling, and the monitoring layer that tells you automation has failed are all operational competencies, not vendor features you buy and forget. A few things tend to separate teams that handle this transition cleanly from teams that get caught by it:
- A complete, current inventory of every certificate in the environment, including ones issued outside central IT's visibility
- An automation pipeline that handles issuance and renewal without manual steps, with alerting when it fails rather than when a certificate has already expired
Those two items sound simple written down. In practice, most organizations fail on the first one, because certificates get issued by individual teams, embedded in IoT devices, or baked into legacy systems nobody has touched in years. You cannot automate renewal for a certificate you do not know exists.
Where this shows up in day-to-day infrastructure work
This change touches server administrators, cloud engineers, network teams, and security operations staff differently, but it touches all of them. A server administrator managing internal services needs to know how certificate lifecycle automation integrates with the systems they run daily, which is core territory covered in Forge University's Server+ certification prep, where certificate management sits alongside the broader discipline of keeping infrastructure available and trusted.
Security operations and governance staff have a parallel responsibility: treating certificate lifecycle failure as an incident category, not just an IT maintenance miss. If your incident response playbooks do not already include a scenario for a mass certificate expiration event, now is the time to add one, because a 47-day window means the blast radius of a single automation failure is larger and more frequent than anything your current runbooks were built for.
If you want a clearer picture of how certificate and infrastructure topics map across different certification paths, the Forge University resources page breaks down curriculum overviews so you can see where this fits for your specific role. And if you are weighing which path actually builds the operational skills this transition demands rather than just the theory behind it, you can start training and work through the hands-on material at your own pace.
What this means for the next three years
The 2026 and 2027 steps down to 200 and 100 days are the warning shots. Most organizations can survive those with incremental process tightening. The 2029 drop to 47 days is the one that forces structural change, because no team renews certificates manually on a 47-day cycle across thousands of endpoints without something breaking.
The organizations that treat this as a two-year runway to build real automation and inventory discipline will absorb the change without drama. The ones that wait until the deadline is close will spend 2029 fighting outages instead of planning for them. Given that the first deadline already landed in March 2026, the runway is shorter than it looks, and the skills needed to manage it are specific enough that waiting to build them is itself a risk decision, whether anyone frames it that way or not.