Your Certificates Are About to Expire a Lot Faster: Here's What to Do About It

Saturday morning. Your customer portal is down. The checkout page is throwing a browser security warning. Customers are leaving. Your on-call engineer eventually traces it back to a TLS certificate that expired three days ago, sitting on a spreadsheet nobody had looked at in two months.

That happens regularly. In a few years, the pace at which certificates expire will be roughly eight times faster than it is today. If your business is still managing this with calendar reminders and manual renewals, you have a problem building.

What the CA/Browser Forum decided

In early 2026, the CA/Browser Forum (the standards body that governs how TLS certificates work on the web) passed Ballot SC081v3 with zero dissenting votes from any major browser vendor. Apple, Google, Microsoft, and Mozilla all voted yes. The rule is settled.

The result is a phased reduction in the maximum lifespan of publicly trusted TLS certificates, alongside a tightening of domain validation windows:

Phase 1 is already live. Any certificate you renew from here lasts a maximum of 200 days, not the roughly 398 days you were used to. By March 2029, certificates max out at 47 days. Renew every six weeks, without end.

One clarification: this applies strictly to publicly trusted TLS server certificates (the ones that put the padlock in your browser's address bar). Your internal private PKI, code signing certificates, and document signing certificates are not in scope for this timeline.

Why the change was made

The traditional system for pulling bad certificates off the web is broken, and has been for years.

When a TLS certificate's private key is stolen, or a certificate was issued based on incorrect information, the correct response is revocation: flagging it as invalid and telling browsers not to trust it. The mechanisms designed for this, Certificate Revocation Lists (CRLs) and the OCSP protocol, are slow, clunky, and frequently ignored by browsers when they time out or fail to load. The upshot: a compromised certificate can stay in active use for up to a year before it naturally expires, regardless of whether anyone knows it has been compromised.

Shorter lifespans bypass the broken revocation system. If a key is stolen but the certificate expires in 47 days anyway, the window of potential abuse collapses.

Two other things drove this change. The first is misissuance. Certificates are a time-stamped record that a specific entity controlled a domain at a specific moment. Domains get sold. Companies change ownership. Information that was accurate at issuance can become false. A year is a long time for a certificate to remain valid when the underlying facts have changed.

The second is what the industry calls cryptographic agility. SHA-1 took years to phase out because long-lived certificates kept it in circulation. Once issued, there was no incentive to replace a certificate before it expired. With 47-day cycles, a broken algorithm can be cycled out across the entire web in roughly a month.

There is a longer-term angle too. Quantum computers capable of breaking current RSA and ECC encryption will eventually exist. The infrastructure being built for 47-day certificates is the same infrastructure that will allow a rapid transition to quantum-safe cryptography when that moment arrives.

The part most people miss: domain validation

Certificate renewal is the headline, but the change to Domain Control Validation (DCV) is arguably the bigger operational headache.

Before a Certificate Authority issues a TLS certificate, they need proof that you actually control the domain. Under the current system, once you have passed that validation, the CA can reuse the proof for up to 398 days, roughly once per year.

That reuse window is closing on the same schedule:

By 2029, even if a certificate lasts 47 days, your organisation needs to re-prove control of its domains roughly every 10 days. Browsers are dropping support for manual email-based domain validation by March 2028. At a 10-day window, clicking a verification link once a week just does not scale. DNS-based automated validation is where this ends up.

Combining shorter certificate lifespans with shorter DCV windows, you get something like a 35-fold increase in total validation work compared to today.

What this means if you are still doing it manually

A single manual certificate renewal (generating a new key pair, submitting a CSR, going through validation, downloading the certificate, installing it correctly, verifying the deployment) takes three to five hours of human effort on average.

Under the 47-day mandate, a business managing 100 certificates faces roughly 1,200 certificate renewals per year. At three to five hours each, that is somewhere between 3,600 and 6,000 hours of work annually. For a small IT team, that is not a workflow problem. It is an impossibility.

Even today, with Phase 1 live and certificates capped at 200 days, the workload has roughly doubled for any cert renewed since March.

The failure mode is rarely a gradual slide. It tends to be a sudden crunch. When your team is handling twice the renewals they were six months ago, something gets missed. Microsoft, Google, and Spotify have all had significant outages from missed certificate renewals. This is not a problem that only hits under-resourced IT teams. It catches anyone relying on human attention at scale.

A crunch point arrives in September 2026

Any certificate issued or renewed after 15 March 2026 lasts a maximum of 200 days. The first wave of Phase 1 certificates starts expiring around 30 September 2026, roughly six months from now.

Businesses that were renewing certificates once a year will suddenly face double the renewal workload almost overnight. If you have not audited your certificate estate and started moving toward automation before September, you hit that crunch with no preparation.

What to do now

Find everything first

You cannot manage what you cannot see. Start with a complete inventory of every publicly trusted TLS certificate in your environment. Your main website is the obvious starting point, but it does not stop there. Every subdomain, every customer-facing portal, every API endpoint, every web-accessible application.

Certificate transparency logs are public. Every certificate issued by a publicly trusted CA is logged, which means discovery tools can scan your domains and surface certificates your IT team may not even know exist. These are sometimes called shadow IT certificates: something somebody provisioned for an internal application with a public web front, then forgot about.

While you are at it, map every manual step in your current renewal process. Every form a human fills in, every verification email someone clicks, every date entered into a spreadsheet. Those are the steps that break first.

Automate with ACME

The ACME protocol is the industry standard for automating certificate lifecycle management. It lets your server communicate directly with a Certificate Authority, prove domain control through automated DNS or HTTP challenges, request a new certificate, and install it without anyone needing to touch it.

Let's Encrypt popularised ACME and remains a free, widely used option. But ACME is not exclusive to Let's Encrypt. Google Trust Services, ZeroSSL, Sectigo, and DigiCert all support it, so you can automate against a commercial CA if your compliance requirements demand it.

If you manage certificates across a mixed environment (a load balancer here, an Azure Web App there, an on-premises server somewhere else), a Certificate Lifecycle Management (CLM) platform pulls it all into one view. Renewals, installations, and audit history, all tracked in one place.

If your current system sends you an email when a certificate is about to expire, that is a notification, not automation. True automation handles key generation, domain validation, certificate request, and installation with no human action required. A notification system does not survive 47-day cadence.

Start with what matters most

Automating everything at once is not realistic. Start with the systems where an outage causes the most immediate damage: your public website, customer portal, payment integration. Get one working with automated renewal, then expand. Legacy systems and anything awkward to automate can stay on manual or migrate to private PKI for now. The aim is to get the risk of a missed renewal off your most important systems first.

Check what third parties handle

Not every certificate in your estate is under your direct control. Cloud platforms, SaaS tools, and managed services often manage their own TLS certificates. Find out whether those providers support ACME-based automation, and whether their renewal cadence will hold up at 100 days and then 47 days. A provider that automates annually will not be compliant by 2027, and the outage risk becomes theirs to manage unless you push them on it now.

Start here, for free

Bluestone's Cert-Scout scans your public domains against certificate transparency logs and returns a clear picture of which certificates are active, when they expire, and which ones need attention. Free, no installation, about two minutes.

If you do not know what is in your certificate estate right now, that is the fastest way to find out. Run it today and you will know whether September is a problem before it becomes one.

If the results look like more than a couple of renewals to sort out, get in touch and we can help you work out an approach that fits your environment.