Your TLS Certificates Will Expire Every 47 Days. Is Your Team Ready?
September 29, 2026
Rodney Hall, COO— AI-assisted and reviewed prior to publication.
Public TLS certificates are moving to a maximum 47-day lifespan by March 2029, replacing the current 398-day standard, under a rule the CA/Browser Forum approved in April 2025. For anyone who manages certificates by hand today, that means renewal work increasing roughly eightfold, and it means the spreadsheet-and-calendar-reminder approach to certificate management stops working within the next few years.
What Is Actually Changing in TLS Certificate Validity?
The change comes from Ballot SC-081v3, passed by the CA/Browser Forum, the industry group that sets the rules every public certificate authority and browser vendor follows. The ballot phases in the reduction in three steps rather than all at once. According to SSL.com's breakdown of the rule, the maximum validity period drops to 200 days in March 2026, then 100 days in March 2027, before landing at 47 days in March 2029.
The vote itself was not close. Apple proposed the measure and Sectigo endorsed it, and when the ballot came up, Sectigo's own announcement of the result noted that Apple, Google, Mozilla, and Microsoft all voted in favor. That kind of unanimity among the browser vendors that decide which certificates get trusted means there is no realistic path where this gets walked back. If your organization runs public-facing TLS at all, the countdown already started.
The reasoning is not cosmetic. Shorter-lived certificates shrink the window an attacker can exploit if a private key leaks or a domain changes hands, and they force faster retirement of weaker cryptography over time. That tradeoff is deliberate, and it shifts the operational burden from "renew twice a year" to something that has to run continuously in the background rather than sit on someone's calendar.
Why Do Expired Certificates Keep Taking Down Production Systems?
Because most organizations still treat certificate renewal as a task a person remembers to do, and people forget. This is not a hypothetical risk. In September 2024, Alaska Airlines suffered an outage tied to certificate issues that forced a ground stop and delayed flights for about two hours, one of several recent incidents where an expired certificate took down a major operational system. The same reporting describes a separate 39-minute outage to a UK real-time settlement system earlier that year, also traced to a certificate problem.
These are not edge cases involving obscure infrastructure. A survey reported by Accutive Security found that a large majority of organizations have experienced an outage caused by an unexpected certificate expiration, with downtime costs running into tens of thousands of dollars per hour. Certificates fail quietly until the exact moment they cause a very loud, very public problem, and that moment tends to arrive without warning because nobody was watching the expiration date.
Once renewal cycles compress to every six or seven weeks, the math gets worse fast. A team managing a modest certificate inventory manually already struggles to track expirations on a 398-day cycle. Multiply the renewal frequency by eight and the same manual process does not scale, it collapses, and it takes production traffic down with it when it does.
How Should Operations Teams Prepare for the 47-Day Certificate Era?
Automate issuance and renewal so no human has to remember an expiration date at all. This is the single change that matters most, and cloud platforms have already built the tooling to support it. AWS Certificate Manager, for example, provides managed renewal that handles Amazon-issued certificates automatically when DNS validation is in place, according to AWS's own documentation on managed certificate renewal, and the certificate authority landscape more broadly is converging on the same automated-first model because manual renewal at 47-day intervals is not a viable long-term process for any team.
Practically, that means a few things need to happen in most environments before 2029, and some of them need to happen well before then given the interim steps in 2026 and 2027:
- Build a complete, current inventory of every public certificate in use, including ones issued outside the primary cloud account or managed by a team nobody thinks to ask.
- Move every eligible certificate onto DNS validation rather than email validation, since DNS-validated certificates in services like ACM renew without a person clicking an approval link.
- Set ownership for every certificate that cannot be automated, with an actual name attached and an escalation path if renewal fails.
None of this is exotic engineering. It is disciplined operations work, and it is exactly the kind of skill gap that shows up when a team has strong security instincts but has never had to operationalize certificate lifecycle management, cloud automation, or infrastructure-as-code renewal pipelines at scale.
Where This Fits Into a Career Building Cloud Operations Skills
This is squarely operational territory, not a policy footnote. Someone on your team needs to understand TLS handshakes, certificate authorities, domain validation methods, and how services like AWS Certificate Manager integrate with load balancers and content delivery networks, because that is the layer where a shortened renewal cycle either gets automated cleanly or turns into recurring fire drills. The CompTIA Cloud+ certification covers exactly this ground, from TLS in transit to certificate automation across cloud platforms, which makes it a practical credential for anyone who owns this problem or wants to.
If you are trying to figure out where certificate and PKI operations fit against the rest of a cloud or security role, the curriculum overview and FAQ is a reasonable place to see how the topic maps against other domains before committing time to a study plan. And if you already know this is a gap on your team, you do not need to wait for a syllabus to land in your inbox. You can start training now and build the automation and PKI fundamentals before the 2027 milestone forces the issue.
What Happens If You Wait
Teams that treat this as a 2029 problem are underestimating how the phased schedule actually works. The validity period drops to 200 days in March 2026, which is already a meaningful compression from 398 days, and it drops again the following year. Waiting for the final 47-day cutoff to start building automation means doing the hardest part of the work, discovering every certificate in your environment and fixing manual processes, under two intermediate deadlines you did not plan for.
There is also a compliance dimension worth naming plainly. Organizations subject to audit frameworks that require evidence of change control and access governance will find that certificate renewal failures do not stay contained to the outage itself. An unplanned expiration is a control failure with a timestamp, and auditors notice patterns of reactive fixes more than they notice a single incident. Building the automation now, while the runway is still six-month cycles rather than six-week ones, is meaningfully cheaper than doing it under pressure later.
The organizations that come through this transition cleanly will be the ones that stopped treating certificate management as a background chore years before the deadline forced their hand. The rule is set, the vote was unanimous among every vendor that matters, and the schedule is public. What is still an open question is whether your team's processes, and your own skill set, are built for a world where certificates renew every seven weeks instead of every thirteen months.