Contents
If you’ve recently issued a new SSL/TLS certificate and noticed the expiration date is much sooner than expected, you aren’t alone. As of March 15, 2026, the industry has officially moved away from the 398-day (one-year) standard.
We have entered a phased “step-down” period mandated by the CA/Browser Forum (Ballot SC-081). This represents one of the biggest operational changes to public TLS certificate management in years. By 2029, certificates will expire in less than seven weeks.
The Roadmap: 200, 100, and 47 Days
The industry-wide transition follows a strict timeline. Each milestone reduces the “margin of error” for manual management:
| Effective Date | Max Certificate Validity | Max Domain Validation (DCV) Reuse |
| March 15, 2026 (Active Now) | 200 Days | 200 Days |
| March 15, 2027 | 100 Days | 100 Days |
| March 15, 2029 | 47 Days | 10 Days |
Although the final 47-day limit doesn’t arrive until 2029, organizations that wait until then to automate certificate management will likely find themselves under significant operational pressure.
Why the 47-Day Era Changes Everything
Not long ago, managing SSL certificates was a low-maintenance chore. Prior to 2016, certificates could last up to five years, allowing teams to track renewals on a simple calendar or spreadsheet. However, the industry has been steadily tightening the window, dropping maximum validity to 39 months, then to 825 days (roughly two years) in 2018 via CA/Browser Forum Ballot 193, and finally to 398 days in September 2020 when Apple unilaterally forced the one-year standard. Now, as lifespans plummet toward 47 days, continuing to rely on manual tracking is a high-risk gamble for three reasons:
- The “Ghost” Outage: With 47-day lifespans coming in 2029, you will be renewing certificates ~8 times per year. If you manage 10 domains, that’s 80 potential points of failure annually.
- The DCV Crisis: By 2029, your Domain Control Validation (DCV), the proof that you own the site, will expire every 10 days. This means your automation must not only renew the cert but also successfully re-verify your domain ownership almost weekly.
- No More Safety Net: As we noted in our coverage of Let’s Encrypt ending expiration email alerts, the world’s largest CA is stepping back from manual notifications just as the frequency of renewals is exploding.
Why Are Browsers Forcing This? (The “Bygone SSL” Threat)
If you are frustrated by the rapid reduction in certificate lifespans, it helps to understand why Browser vendors, including Google, Apple, and Microsoft supported the change through the CA/Browser Forum process. They aren’t trying to make your life harder. they are trying to solve a massive vulnerability known as “Bygone SSL.”
When certificates lasted for 398 days (or years, historically), a major security flaw lingered in the background: domain transfers.
Imagine you own example.com and generate a certificate for it today. Next month, you sell that domain to someone else. The new owner controls the domain, but you still possess a valid, cryptographically sound TLS certificate for example.com that doesn’t expire for nearly a year. Security researchers discovered that millions of domains, including massive platforms like Stripe, had valid certificates floating around that were owned by previous registrants.
If an attacker also gains a position to impersonate the service (for example through DNS hijacking, BGP attacks, or other infrastructure compromise), an old but still-valid certificate significantly increases the opportunity for abuse.
The industry realized that certificate revocation systems (like CRLs and OCSP) are notoriously unreliable at scale. The only mathematically guaranteed way to kill these lingering certificates is to let them naturally expire. By shrinking validity down to 47 days, the window during which an outdated certificate remains usable is dramatically reduced.
The browser ecosystem is driving the internet to adopt automated, rapid rotation to ensure that if a domain changes hands, or if a private key is exposed, the window of vulnerability is closed in a matter of weeks, not years.
3 Steps to Prepare Your Infrastructure
As certificates get shorter, the “window for recovery” shrinks. With 47-day certificates, every failed renewal consumes a much larger percentage of the certificate’s lifetime. A problem that might once have gone unnoticed for weeks can now result in user-visible outages within days. This is now one of the 7 leading causes of downtime that is entirely preventable.
1. Audit Your “Manual” Debt
Any certificate still being handled via a manual CSR (Certificate Signing Request) is a ticking time bomb. You must transition to ACME (Automated Certificate Management Environment) protocols wherever possible. Use our Free SSL Expiry Checker to identify which of your current certificates are already on the new 200-day limit.
2. Transition to ACME Automation
The push toward 47-day validity isn’t just about defending against today’s security threats, it’s a forcing function to prepare the internet for the next era of cryptography.
Quantum computers are rapidly advancing, and a Cryptographically Relevant Quantum Computer (CRQC) will eventually be able to break current public-key encryption methods like RSA and Elliptic Curve Cryptography (ECC) using algorithms like Shor’s. The National Institute of Standards and Technology (NIST) has already released its finalized Post-Quantum Cryptography (PQC) standards, such as ML-KEM and ML-DSA, to replace these vulnerable protocols.
Over the coming years, many organizations will migrate to post-quantum or hybrid certificates as standards mature. If you are still managing certificates manually, transitioning to PQC will be a massive, year-long crisis of hunting down and replacing keys across every server, load balancer, and firewall.
By encouraging organizations to adopt automated Certificate Lifecycle Management (CLM) today, shorter certificate lifetimes also make future cryptographic migrations, including the move toward post-quantum certificates, far easier to execute.
3. Implement Third-Party Verification
Automation is critical, but it can fail. A broken DNS configuration, an expired token, or a server restart failure can prevent an automated script from applying a new certificate. You need an external SSL Certificate Monitoring service like UptimeObserver to verify that the outside world is actually seeing the updated certificate.
The Bottom Line
The shift to 47-day certificates is about Crypto-Agility. It forces the internet to be faster and more secure. But for the unprepared, it is an express lane to frequent outages.
The transition has already begun. If you still rely on manual certificate renewals, now is the time to automate renewals and independently monitor every certificate before shorter validity periods become the norm.