Under a CA/Browser Forum rule adopted in April 2025, the maximum lifetime of a public TLS certificate fell to 200 days on 15 March 2026, drops to 100 days on 15 March 2027 and reaches 47 days on 15 March 2029. Teams that still renew certificates by hand should automate discovery, renewal and deployment before March 2027 to avoid outages.
The timeline at a glance
The schedule comes from CA/Browser Forum Ballot SC-081v3, which changed the TLS Baseline Requirements. The vote closed on 11 April 2025.
The ballot sets two limits: how long a certificate can be valid, and how long a CA can reuse a completed domain validation before it must check again.
| Certificate issued | Maximum validity | Domain validation reuse |
|---|---|---|
| Before 15 March 2026 | 398 days | 398 days |
| From 15 March 2026 | 200 days | 200 days |
| From 15 March 2027 | 100 days | 100 days |
| From 15 March 2029 | 47 days | 10 days |
The same ballot cut the reuse period for verified organization details (called subject identity information, as used in OV certificates) from 825 days to 398 days from 15 March 2026.
The Baseline Requirements also advise CAs not to issue for the full maximum by default. From 15 March 2029, for example, certificates should not be valid for more than 46 days and must not be valid for more than 47.
Why the CA/Browser Forum is shortening certificate lifetimes
- Less damage from mistakes and leaks. A shorter life limits how long a misissued certificate or a leaked key stays useful. The ballot notes that revocation checking through CRLs and OCSP does not protect users well at internet scale, so expiry is the dependable safety net.
- Fresher data. Domain control and company details inside a certificate go out of date. Shorter lifetimes and shorter reuse periods keep them current.
- Faster algorithm changes. When every certificate is replaced every few weeks, moving to new algorithms, including post-quantum ones, becomes far easier.
What changes for your team
Many more renewals
At 398 days, a certificate is renewed about once a year. At 47 days, it must be replaced at least 8 times a year (365 divided by 47), and closer to 12 times if you renew around day 30 to leave a safety margin.
Multiply that by the number of public certificates you run. Manual work stops scaling quickly.
Domain validation almost every time
From 15 March 2029, a domain validation can be reused for only 10 days. In practice, almost every renewal will need a fresh, automated check, such as an ACME DNS-01 or HTTP-01 challenge, or your CA’s own API.
That means DNS and web teams must be part of the plan, not only the PKI team.
Deployment is the hard part
Getting a new certificate is easy. Installing it everywhere, on load balancers, CDNs, appliances, Java keystores and apps that pin certificates, is where outages happen.
List the systems that cannot be automated today. Then plan to replace them or put something automatable in front of them.
What is not affected
The schedule is part of the TLS Baseline Requirements, which cover publicly trusted TLS server certificates. Certificates from your own private CA, trusted only by devices you manage, are outside their scope, so you set those lifetimes in your own policy.
S/MIME and code signing certificates follow separate CA/Browser Forum requirements.
This is a good moment to ask which certificates really need to be public. Our comparison of private CA vs public CA covers that decision. If you decide to run your own private certificate authority, DictaLabs CA is built for that.
A readiness plan by deadline
Now: the 200-day limit is in force
- Build a full inventory of public TLS certificates, each with a named owner. Certificate Transparency logs record publicly trusted certificates, so searching them for your domains shows certificates you may not know about.
- Find every renewal that still needs a person. A PKI risk assessment looks for expiry risks, visibility gaps and automation opportunities.
Before 15 March 2027: the 100-day limit
- Automate renewal and deployment for your most critical services first.
- Standardize on ACME where your CA and servers support it, and use the CA’s API where they do not.
Before 15 March 2029: the 47-day limit
- Aim for zero-touch renewal for every public certificate, with alerts only when something fails.
- Test failure paths. What happens if your CA or your DNS provider’s API is down on renewal day?
Eight questions to ask your team this month
- Do we know how many public TLS certificates we have?
- Does each one have an owner?
- Which renewals are still manual?
- Which systems cannot use ACME or an API?
- Who controls DNS changes, and can validation be automated?
- Do we get alerts at least 30 days before expiry?
- Could we replace every certificate within 24 hours if our CA had to revoke them?
- Which certificates could move to a private CA?
How Certinium CLM helps
Certinium CLM is our certificate lifecycle management platform, built for what its product page calls the 47-day certificate era. It combines discovery, inventory, alerts before expiry and high-frequency renewal designed for rising certificate volumes and shorter validity periods.
It automates with ACME, SCEP, EST and REST APIs, and works across CAs, including Microsoft ADCS, EJBCA, DictaLabs CA and other public, private and cloud-based CAs.
Its integration framework is designed to support Kubernetes and cert-manager, Terraform and Ansible, subject to connector availability and implementation scope.
Next step
Start with a PKI risk assessment to find manual renewals and expiring certificates, or ask for a Certinium CLM demo. If you are not sure where to begin, contact our PKI team.
