The 47 Day Certificate Rule: What the CA/Browser Forum Change Means and When It Hits

I have watched an expired TLS certificate take a checkout page offline on a Sunday morning. No breach, no clever attacker, nothing exotic. A renewal date passed, nobody owned it, and a profitable storefront started throwing browser warnings to every customer who tried to pay. The fix took ten minutes once someone found the right console. Finding the right console, and the right person, took three hours. That gap between the technical fix and the human process around it is the whole story of what is about to happen to certificate management.

In April 2025 the CA/Browser Forum, the body where certificate authorities and browser makers set the rules everyone follows, approved Ballot SC-081v3. The ballot shrinks the maximum validity of a public TLS certificate from 398 days down to 47 days, phased in over four years. That first cut already landed. As of March 15, 2026 the ceiling dropped to 200 days, so if you renewed recently you are already living under the new regime, whether anyone told you or not. The endpoint, 47 days, arrives in March 2029.

What Is the 47 Day Certificate Rule?

A TLS certificate is the file that lets a browser confirm it is really talking to your website and not an impostor, and it underpins the padlock and the HTTPS connection people barely think about. Every public certificate carries an expiry date. When it passes, browsers stop trusting the site and visitors see a full page security warning instead of your content. The maximum lifespan a certificate authority is allowed to issue has been falling for years, from five years a decade ago, to 398 days more recently. Ballot SC-081v3 sets a schedule to take it all the way down to 47 days.

Why such an odd number? Forty seven days is roughly a month and a half, enough to give a renewal a sensible buffer without leaving a certificate valid long after the information inside it might have gone stale. Apple originally proposed the change, and the ballot passed the CA/Browser Forum without a single vote against it. That unanimity matters, because it tells you this is not a proposal you can wait out. The certificate authorities you buy from, including the large ones such as DigiCert and Sectigo, helped write it and are already adjusting their systems.

One detail hides inside the headline. Alongside the shorter certificate lifespan, the period during which a certificate authority can reuse your domain validation is shrinking too. That is the check that confirms you actually control the domain you are requesting a certificate for. By March 2029 that reuse window drops to 10 days, which means you will be proving control of the domain again almost every time you renew. If you only think about the certificate itself, you will miss half the operational load.

The Phased Timeline, and Where We Are Now

The reduction does not happen in one jump. Instead, the CA/Browser Forum spread it across three milestones so teams have runway to change how they work. Here is the full schedule, including the domain validation reuse periods that move alongside the certificate lifespan.

Put the math in front of anyone who controls budget. A single certificate that needed one renewal a year will need around eight by 2029. Multiply that by however many certificates your organization actually runs, which is almost always more than the team thinks, and the change from once a year to every few weeks is the part that decides whether you stay online.

Why Is the Industry Forcing Certificates to Expire Faster?

It feels backwards at first. Shorter lifespans mean more work, so why would the whole industry choose more work on purpose? The answer comes down to how long a problem can quietly persist. A certificate is a statement of trust frozen at the moment it was issued. If the key behind it is stolen, or the certificate was issued in error, or the company it was issued to no longer controls that domain, every one of those problems stays live until the certificate expires.

On paper, revocation is supposed to handle the bad ones. In practice it has always been the weak link. The mechanisms browsers use to check whether a certificate has been revoked are inconsistent, sometimes ignored, and easy for an attacker positioned in the middle to suppress. So the industry reached for the blunt but reliable tool instead. A certificate that only lives 47 days cannot do much damage even if revocation fails completely, because it ages out on its own in under two months. Shorter validity turns expiry into a safety net that does not depend on every browser behaving correctly.

There is a forward looking reason as well. Quantum computing threatens the encryption that today’s certificates rely on, and the migration to post quantum algorithms will be the largest cryptographic change most organizations ever attempt. An estate that can swap a certificate every few weeks without anyone breaking a sweat is an estate that can adopt new algorithms quickly when the time comes. The discipline you build for 47 day renewals is the same discipline you will need for that transition. If you want the foundation underneath this, our explainer on symmetric and asymmetric cryptography covers the key types that certificates depend on.

What It Means for IT and Security Teams

Here is the part that the vendor announcements tend to soften. The certificates themselves are not the hard problem. Renewing one is trivial. The hard problem is that most organizations do not actually know how many certificates they have, who owns each one, or where they all live. They surface only when one expires and something breaks, which is exactly the failure I described at the start. Shortening the lifespan does not create that problem. It removes the slack that has been hiding it.

My work sits on the human layer of security, and certificate management is a human layer problem dressed up as a technical one. An expired certificate is rarely a cryptography failure. It is an ownership failure, a handover that never happened when someone left, a renewal buried in one engineer’s calendar that nobody else could see. Across European clients I keep running into the same pattern, and regulation is sharpening it. The EU’s Digital Operational Resilience Act, which began applying to financial entities in January 2025, expects firms to demonstrate they can keep critical services running through exactly these kinds of operational shocks. An outage caused by a forgotten certificate is no longer just embarrassing. For a regulated firm it is a resilience finding someone has to explain.

The technical answer is automation, and the standard worth knowing by name is ACME, the Automated Certificate Management Environment protocol. ACME lets a server request, prove control of its domain, install, and renew certificates without a person clicking anything. It is the same protocol behind the free certificates that quietly renew on millions of sites already. For larger estates, certificate lifecycle management platforms add discovery, an inventory of what you actually have, and policy controls on top. The tooling is mature. What most teams lack is not software but an owner and a process. A botched automation that nobody monitors fails just as loudly as a forgotten spreadsheet, and an outage from a misconfigured renewal can ripple outward the way a single provider’s problem did during the recent Cloudflare outage.

How to Prepare Before the Next Cut

You do not need to solve 2029 this quarter. What you do need is to be moving in the right direction before the 100 day cut in 2027, because that is the milestone where manual habits stop working. Start with discovery. Find every public certificate your organization runs, across web servers, load balancers, internal services exposed to the internet, and the forgotten subdomain a marketing team spun up two years ago. You cannot automate what you have not found, and the inventory itself usually surprises people.

Then assign ownership. Every certificate needs a named owner and a documented renewal path that survives that person changing jobs. Turn on ACME based renewal anywhere your platform supports it, which is most modern web servers and cloud load balancers. Add monitoring that alerts you well before expiry rather than at the moment a site goes dark, and treat a renewal failure as an incident, not an afterthought. None of this is exotic. It is the same operational hygiene that keeps the rest of your infrastructure healthy, applied to a corner that has been allowed to coast on long expiry dates for years. If you are building toward security roles where this lands on your desk, understanding how certificates chain together is foundational, and our piece on how the SSL certificate chain works and why it breaks is a good place to ground the basics, alongside broader encryption best practices.

Frequently Asked Questions