TLS certificates are dropping to 47 days.
The CA/Browser Forum has locked in a schedule cutting the maximum certificate lifetime from 398 days to 47 by 2029. Renewal stops being a yearly chore and becomes continuous, exactly what trstctl automates.
This is not hypothetical: the first cut already landed. You are on 200-day certificates today; the schedule ends at 47 days on 15 March 2029.
- 398daysuntil Mar 2026
- 200daysfrom 15 Mar 2026DCV reuse 200
- 100days15 Mar 2027DCV reuse 100
- 47days15 Mar 2029DCV reuse 10
- ~8.5×
- more renewals per certificate per year
- 10 d
- domain-validation reuse by 2029
- 0
- manual renewals with trstctl
15 March 2027 · the next step of CA/Browser Forum SC-081v3. The final step, 47 days, follows on 15 March 2029.
Approved, dated, and already counting down.
In April 2025 the CA/Browser Forum approved ballot SC-081v3, proposed by Apple and endorsed by Sectigo, Google Chrome and Mozilla, which cuts the maximum certificate lifetime in three steps. Each step also shrinks how long a domain-control validation (DCV) can be reused.
- until Mar 2026
398 days
The old ceiling: one renewal a year, often booked on a calendar reminder. Now history.
DCV reuse · 398 days - from 15 Mar 2026
200 days
In effect. Lifetimes are cut roughly in half, and annual workflows have started to slip.
DCV reuse · 200 days - 15 Mar 2027
100 days
Three-month cycles. Manual tracking across an estate becomes unsustainable.
DCV reuse · 100 days - 15 Mar 2029
47 days
Short by design, too short for humans. Validation reuse falls to 10 days, so it must be continuous.
DCV reuse · 10 days
What DCV is, and why it is the real squeeze
Domain Control Validation is how a certificate authority confirms you actually control a domain before it issues a certificate: the DNS or HTTP challenge you pass. Reuse is how long that proof stays valid before you have to pass it again.
Today you can reuse one for over a year. By 2029 it lasts just 10 days, so you re-prove control almost continuously, a cadence that is impossible by hand and the reason the change forces automation.
47 days is engineered to break manual processes.
The ballot’s own rationale is shorter exposure windows and issuance, replacement and rotation that only automation can keep up with. Here is what shifts under your feet.
From yearly to every six weeks
A certificate good for 398 days renewed once. At 47 days you renew it roughly every six weeks, and because you renew before expiry, even more often. Multiply that by every certificate you own.
Validation goes continuous
DCV reuse drops to 10 days. You can no longer cache a domain check for a year; you re-prove control constantly. That is only sane through ACME-style automation, not tickets.
One miss is an outage
An expired certificate does not degrade, it hard-fails: browser errors, broken APIs, dead health checks. Eight renewal windows a year is eight times the chance to miss one.
It is every certificate, everywhere
Not just the public web certificate. Internal services, load balancers, the long tail nobody owns, plus the SSH keys, secrets and tokens on the same short-lifetime trajectory.
Make 47-day rotation boring.
trstctl is a self-hosted control plane for non-human identity. The 47-day deadline is the exact problem it was designed around: discover everything, rotate ahead of expiry, prove it, and never hand a robot your CA keys.
Discover everything first
Agents and connectors inventory certificates, SSH trust, secrets and tokens, each with an owner, source and expiry. See Discover in the console →
Rotate ahead of expiry
Policy-driven renewal acts before the deadline, and every retry is idempotent, so a retried renewal cannot double-issue. See Certificates in the console →
Automate without surrendering keys
Issuance runs through a separate signer process. The control plane orchestrates the churn; private keys never join it. How it is built →
47 days is coming whether your renewals are automated or not.
Stand up trstctl locally, point it at your certificates, and make the deadline a non-event.