Public TLS certificate lifetimes drop to 47 days by March 2029. It's usually framed as a renewal problem. That's a mistake: the real bottleneck is domain control validation (DCV) — and its reuse window falls to just 10 days. Here's the exact timeline, the math, and the method to automate without breaking a single service.
The official timeline: from 398 to 47 days
The CA/Browser Forum has locked it in. The reduction is phased, which gives you a window to prepare — not to wait.
| Date | Max certificate lifetime | Domain validation (DCV) reuse |
|---|---|---|
| Today | 398 days | 398 days |
| March 15, 2026 | 200 days | 200 days |
| March 15, 2027 | 100 days | 100 days |
| March 15, 2029 | 47 days | 10 days |
Two parameters shrink, not one: the certificate lifetime and the time a domain-control proof stays valid. Most guides forget the second — and it's the one that hurts most.
Why this is an operations problem, not a security one
A shorter certificate isn't "more dangerous." The risk shifts: from cryptography to operations.
Take a modest fleet of 500 certificates:
- Today (~398 days): roughly 460 renewals per year.
- At 47 days:
500 × (365 / 47) ≈3,900 renewals per year.
That's 8–9× more operations, each with its own failure window. And the number-one cause of certificate-related outages isn't a crypto flaw — it's an unnoticed expiry. Multiplying renewals by 8 without automation mechanically multiplies your outage risk.
Manual management — a spreadsheet, a calendar reminder, a ticket — becomes simply unsustainable well before 2029.
The real bottleneck: domain validation (DCV)
Issuing a public TLS certificate means proving you control the domain. That's DCV, typically done via:
- DNS-01: publish a TXT record in the domain's DNS zone.
- HTTP-01: expose a file at a specific URL on the domain.
While DCV reuse was ~398 days, you validated once and forgot about it for a year. From March 2029, the proof of control is valid for only 10 days. In other words, on a 47-day certificate you'll have to re-prove domain control several times per cycle.
Manual DCV — placing a TXT record by hand, waiting for propagation, checking — does not scale to that. Automating domain validation becomes the critical link in the whole chain.
The three pillars of automation that holds
Automating "renewal" isn't enough. You need all three tiers, or the chain breaks at the missing link.
- Inventory & discovery. You can only automate what you can see. A centralized inventory of every certificate — by CN, authority, algorithm, expiry, owner — is the prerequisite. Outages almost always come from a certificate nobody was watching.
- Automated issuance & renewal. Via standard protocols: ACME (RFC 8555) for the web, EST (RFC 7030) and SCEP for devices and IoT, CMP for industrial, or a REST API. Renewal must trigger before expiry, with no human in the loop.
- Automatic, pre-validated domain validation. The pillar everyone underestimates. It isn't enough to validate at renewal time: you must keep the domain "ready to issue" at all times, continuously re-validating before the 10-day window closes.
Automating DCV: DNS-01, multi-provider, pre-validation
Prefer DNS-01 over HTTP-01 where possible
The DNS-01 challenge is usually the better fit for a fleet:
- it covers wildcard certificates (
*.example.com), impossible with HTTP-01; - it exposes no web service (no file to publish on each server);
- it's driven entirely through the DNS provider's API.
The trade-off: you need a connector for each DNS provider in your estate.
Multi-provider DNS isn't optional
Few organizations run a single DNS. Between OVH, Azure DNS, Cloudflare, Google Cloud DNS, Gandi and internal zones, credible DCV automation must speak all those APIs — otherwise orphan domains fall back to manual handling, and that's exactly where the outage will happen.
Pre-validate, don't validate under pressure
The right architecture doesn't validate at renewal time (where a DNS-propagation glitch blocks issuance). It pre-validates continuously: a worker checks and refreshes the proof of control before the DCV window expires, so the actual renewal is instant and risk-free. That's the difference between "works in a demo" and "holds across 3,900 renewals a year."
Preparation checklist (start now)
- Inventory the whole estate (including non-public-CA and wildcard certificates).
- Identify the owners of every domain and certificate.
- Map your DNS providers and confirm each is covered by a DCV connector.
- Choose the DCV method per domain (DNS-01 by default, HTTP-01 as fallback).
- Set up automatic renewal (ACME/EST/SCEP/CMP/API) with a threshold triggered well before expiry.
- Enable continuous pre-validation to absorb the future 10-day DCV window.
- Wire monitoring and alerts on validation failures and approaching expiries.
Do it on the 200-day step (March 2026), not at 47: every tier shrinks your margin.
Where PKIFactor fits
PKIFactor is a sovereign CLM built for exactly this problem. It pre-validates your domains continuously and automates DCV over DNS-01 and HTTP across OVH, Azure, Cloudflare, GCP and Gandi, with a generic connector as fallback. Renewal is driven natively over ACME, EST, SCEP and CMP, across all your existing authorities (Vault, ADCS, EJBCA, DigiCert, ZetaCA) behind one console — no migration. And since the 47-day deadline lands alongside the post-quantum transition, the same platform also issues in ML-DSA and hybrid: see our hybrid vs composite guide for IT leaders and the ANSSI migration view.
Want to know where your estate stands today? The free tool audit.zetacert.com checks the cryptographic health of your certificates, no account required.
FAQ
When does the 47-day limit actually take effect?
March 15, 2029. But the reduction starts on March 15, 2026 (200 days), then 100 days in 2027. Prepare on those steps, don't wait for 2029.
Who is affected?
Every issuer of public TLS certificates (web servers, APIs, exposed load balancers). Internal PKIs aren't bound by the CA/B Forum but often adopt the same best practices.
Is ACME enough?
ACME automates issuance and part of DCV, and it's an excellent starting point. But it doesn't cover multi-CA inventory, anticipated pre-validation, or heterogeneous multi-provider DNS estates — that's the job of a CLM.
What about wildcard certificates?
They require DNS-01 validation: all the more reason to automate DCV through your DNS providers' APIs.
Does the reduction also apply to organization validation (OV)?
The most constraining parameter is DCV reuse (10 days in 2029). Organization identity validation follows its own rules, but automating DV/OV is the right answer in both cases.
Bottom line: the 47-day deadline isn't won by renewing faster, but by automating domain validation — pre-validated and multi-provider — before the window closes. Start at 200 days.
