SaaSFort Ballot SC-081v3 passed the CA/Browser Forum in April 2025 with twenty-nine votes in favour and none against. Apple proposed it. Google, Mozilla and Microsoft all voted yes.
It reduces the maximum lifetime of a publicly trusted TLS certificate from 398 days to 47, in three steps.
| From | Maximum lifetime | Renewals per year |
|---|---|---|
| 2026-03-15 | 200 days | ~2 |
| 2027-03-15 | 100 days | ~4 |
| 2029-03-15 | 47 days | ~8 |
The first step is already in force. Any certificate issued today is capped at 200 days.
The step that actually breaks things is 2027
Most teams survive 200 days without changing anything, because a twice-yearly renewal is still something a human can hold in a calendar.
100 days is where that stops. Four renewals a year, across every domain and every subdomain, with a hard failure mode that takes the product offline and shows every visitor a browser interstitial. Teams that renew manually will discover the problem the way these things are always discovered: on a weekend.
There is a second change running in parallel that gets less attention. Domain Control Validation reuse drops to 10 days by 2029. Today you can validate a domain once and reuse that validation for over a year. Soon you will be re-proving control of every domain roughly three times a month. No manual process survives that at all.
Why the ceiling exists
Two arguments, both reasonable.
The first is compromise containment. A leaked private key is exploitable for as long as the certificate stays valid. Revocation is supposed to handle this and largely does not, because revocation checking is unreliable in practice. A 398-day certificate gives an attacker up to thirteen months. A 47-day certificate gives them at most seven weeks.
The second is crypto-agility. Short lifetimes mean the entire web’s certificate population turns over quickly, so a future algorithm migration, for example toward post-quantum signatures, takes weeks rather than years. The 47-day figure was chosen deliberately: short enough to make manual renewal impossible at scale, long enough for automation to absorb a failed attempt and retry.
What to do about it
Automate issuance with ACME. The tooling is mature and free.
- certbot, the reference client, fine for a handful of hosts.
- lego, a single Go binary, good for CI and unusual DNS providers.
- cert-manager, the right answer on Kubernetes, where it renews and reloads without human involvement.
The principle that matters more than the tool: renewal frequency must be decoupled from certificate lifetime. Configure renewal at a fixed fraction of the lifetime, typically one third remaining, so that when the ceiling drops again your process needs no change at all. Teams that hardcode “renew 30 days before expiry” will have to revisit that number twice more.
Then monitor externally. Internal automation that silently stops is worse than no automation, because it removes the human who used to notice.
The check most scanners get wrong
There are two different questions about a certificate and they are routinely conflated.
When does it expire? This is the operational question. It tells you whether the site breaks next Tuesday.
How long was it issued for? This is the process question. A certificate minted for 300 days tells you the issuing process predates the current rules, or that the team is buying the longest certificate available and renewing by hand.
Only the second one predicts the outage you will have in 2027. It is also the one that has to be judged against the ceiling in force on the certificate’s issuance date, not today’s date, because a 398-day certificate issued in 2025 was perfectly compliant when it was minted and is still valid now.
Getting that wrong produces a scanner that fails every legitimately issued legacy certificate, which is how tools train teams to ignore them.
Where it maps for compliance
- NIS2 Article 21(2)(h), cryptography and encryption.
- ISO/IEC 27001:2022 A.8.24, use of cryptography.
- DORA Article 9, for financial entities.
Auditors are beginning to ask not just whether certificates are valid, but how renewal is performed. “Manually, by the platform team” is an answer that now invites a follow-up question about what happens when that person is on leave.
How to check it yourself
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null \
| openssl x509 -noout -dates
Subtract notBefore from notAfter. If the result is above 100 days, your renewal cadence has to change before March 2027. If it is above 200 days and the certificate was issued after 2026-03-15, something is wrong with your issuance path.
The short version
The deadline is not 2029. The deadline is 2027-03-15, because that is the step that breaks a process a human can still perform today.
Automate now, while it is a planned project rather than an incident.
Ready to put this into practice?
Two ways to start — pick what fits. Free Scan if you want to see your security grade in 60s with no commitment. Free 14-day Growth trial if you're ready to monitor multiple domains, export NIS2 reports, and download Deal Reports — no credit card required.
No credit card · Cancel anytime · GDPR-ready · EU-hosted