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.
Updated August 18, 2026: added persistent validation (SC-088v3 / DNS-PERSIST-01), its actual adoption status, Let's Encrypt's 6-day certificates, and the sunset of email and phone validation (SC-090).
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 |
|---|---|---|
| Until March 14, 2026 | 398 days | 398 days |
| Since 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.
The market is already moving faster than the mandate
While the CA/B Forum plans for 47 days in 2029, Let's Encrypt has been issuing 160-hour certificates — just over six days — in general availability since January 15, 2026, along with certificates for IP addresses. The shortlived ACME profile must be explicitly enabled on the client side; IP certificates are short-lived only and accept just the http-01 and tls-alpn-01 challenges. Let's Encrypt recommends renewing these certificates roughly every three days.
Six days, when the mandate sets 47 for 2029: an organization sizing its automation to "survive 2029" is really preparing for a regime that's already obsolete. The right target isn't the regulatory minimum — it's a pipeline where certificate lifetime becomes a free parameter.
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:
- Under the old ~398-day regime: roughly 460 renewals per year.
- Since March 2026, at 200 days: roughly 910 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 what takes services down is not a crypto flaw: it's a certificate that expires with nobody watching. Multiplying renewals by 8 without automation mechanically multiplies the chances of missing a deadline.
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.
Since November 2025, DNS-01 is no longer the only DNS-based method either: DNS-PERSIST-01 (see below) keeps its advantages — wildcards, no exposed web service — and additionally removes the need for standing write access to DNS APIs. That's a security argument as much as an operational one: DNS API credentials rank among an infrastructure's most sensitive secrets.
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.
Persistent validation doesn't remove this need: it relocates it. The job is no longer writing to every zone on every cycle, but placing once and then monitoring the persistent record on each of them. Multi-provider remains non-negotiable — for a different reason.
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."
This is the reference strategy as long as your CA doesn't offer persistent validation — which, in the summer of 2026, is still the case for the vast majority of public CAs (see the next section).
The CA/B Forum's answer: DNS-PERSIST-01
Since late 2025, the problem described above has a normative answer. Ballot SC-088v3, proposed by Amazon Trust Services and endorsed by Google Chrome, DigiCert and Sectigo, was adopted on October 9, 2025 and took effect on November 10, 2025. It adds section 3.2.2.4.22, "DNS TXT Record with Persistent Value," to the TLS Baseline Requirements: CAs may use the method since that date — implementing it remains at their discretion.
The mechanism: an account-scoped TXT record, published once at the label _validation-persist.[domain], identifying the requester's account at the CA (an account URI in the sense of RFC 8657, with an optional expiry). The CA revalidates against that same record, with no DNS change on any cycle.
On the ACME side, the corresponding challenge is called dns-persist-01 (IETF draft draft-ietf-acme-dns-persist, adopted by the working group in mid-October 2025 — still a draft, more on that below).
The format, concretely
_validation-persist.example.com. IN TXT (
"letsencrypt.org;"
" accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/1234567890;"
" policy=wildcard"
)
| Element | Role |
|---|---|
letsencrypt.org | The issuer's domain name — lets you authorize several CAs (one record per CA) |
accounturi | Binding to the ACME account (RFC 8657). Mandatory. Survives account key rotation. |
policy=wildcard | Optional: covers subdomains and wildcard issuance. Absent, only the exact FQDN is covered. |
persistUntil | Optional: UNIX timestamp bounding the authorization's validity |
Two operational traps worth knowing:
- if
persistUntilis used, the record must be monitored and updated before it lapses, or renewal fails silently. The cost of managing that expiry can cancel out the "set once" benefit — weigh it; - the record's TTL matters: if it's shorter than the CA's reuse period, the TTL becomes the effective reuse period (and a TTL of 0 forbids any reuse).
What the method changes — and what it doesn't
An important precision, because you can read everything and its opposite: section 3.2.2.4.22 carries its own reuse cap of 10 days, applicable today — while the other DCV methods still enjoy 200 days until March 2027. The BR text is explicit: "CAs MUST consider 10 days as the maximum validation data reuse period for validations completed using this method."
In other words, DNS-PERSIST-01 doesn't sidestep the shrinking reuse windows: it makes them painless. The CA rechecks the record at least every 10 days, but that check no longer requires any DNS write. The trade-off is explicit — you exchange freshness of proof for operational simplicity. It is precisely the "continuous pre-validation" described above, moved from your tooling into the standard.
Also worth noting: ballot SC-091 (adopted in November 2025, in effect since December) extends the method to IP addresses, via an _ip-validation-persist record placed in the reverse .arpa zone (BR section 3.2.2.5.8).
Where adoption stands (August 2026)
The standard is voted and in force on the Baseline Requirements side, but the ACME specification isn't stable and no mainstream deployment is in production. The regulatory timeline is moving faster than the tooling.
| Actor | Status as of August 18, 2026 |
|---|---|
| IETF specification | draft-ietf-acme-dns-persist-01 (March 2026). A -02 revision is expected; open items: populating metadata (issuer-domain-names, caaIdentities), accounturi privacy, wildcard validation, DNSSEC requirements. |
| Let's Encrypt | Staging only (draft-01 support since late April 2026). Production was announced for Q2 2026, then slipped; the rollout has been on hold since late June pending a spec clarification. No firm date. |
| Sectigo | Available in Certificate Manager since May 2026 — the first commercial support. |
| ACME clients | lego: implemented since v5.0.0 (May 2026). cert-manager and Caddy: open requests, no implementation — waiting for the spec to stabilize. |
The draft is co-authored by engineers from Fastly and Amazon Trust Services; neither of their CAs has publicly announced support to date.
The practical consequence: check what your CAs support, place persistent records where you can, and keep an automated DNS-01 fallback everywhere else — which is what the checklist below is for.
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.
- Check whether your CAs support DNS-PERSIST-01 (implementation is at their discretion).
- Place
_validation-persistrecords on the zones where your CA allows it — and monitorpersistUntilwhere used. - Keep a DNS-01 fallback for the CAs that don't implement it yet.
- Identify domains still validated by email or phone and plan their migration: ballot SC-090 sunsets phone validation on March 15, 2027 and email on March 15, 2028.
- Wire monitoring and alerts on validation failures and approaching expiries.
You have been on the 200-day step since March 2026. The next one, 100 days on March 15, 2027, is the one to prepare for now, not the 2029 tier: every step 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. Persistent validation, meanwhile, relocates the problem rather than removing it: knowing which domains carry a persistent record, which don't, which CA supports it, and managing the fallback — that's an inventory and coverage problem, not a DNS-write problem, and it's exactly what the PKIFactor inventory is built to show. Renewal is driven natively over ACME, EST, SCEP and CMP, across all your existing authorities (Vault, ADCS, EJBCA, DigiCert, ZetaCA) behind one console, with 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 started on March 15, 2026 (200 days), and the next step, 100 days, lands on March 15, 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. ACME itself keeps evolving, too — a fourth challenge method, dns-persist-01, is being standardized at the IETF. Automation isn't a stable state: it's an ongoing project.
What about wildcard certificates?
They require DNS-based validation: DNS-01 today, or DNS-PERSIST-01 with policy=wildcard where your CA supports it. 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.
