The CA/Browser Forum voted, and the vote wasn't close. Ballot SC-081v3 passed 29 to 0 in April 2025, with Apple, Google, Mozilla and Microsoft all in favour. It sets a schedule that drags the maximum lifetime of a publicly trusted TLS certificate down from 398 days to 47 days by March 2029.
This is not a proposal. It is a dated schedule that every certificate authority has already agreed to enforce. If you renew certificates by hand, or through a portal, or off a calendar reminder someone set up two years ago, the clock has already started.
The schedule, in dates that matter
The reduction happens in three steps, each on March 15:
- March 15, 2026: maximum validity drops to 200 days.
- March 15, 2027: maximum validity drops to 100 days.
- March 15, 2029: maximum validity drops to 47 days.
Domain Control Validation reuse shrinks alongside it, from 398 days today toward 10 days by 2029. That second number matters more than it looks. Today you can validate a domain once and reuse that validation for a year. By 2029 you re-prove control of every domain roughly every ten days. For ACME clients that revalidate on each renewal, this is invisible. For anything that leans on cached validation, it is a second deadline hiding behind the first.
Where you are right now
It is August 2026. You are already inside Phase 1. The 200-day ceiling took effect in March, so certificates you renew today cannot exceed 200 days, whether you noticed or not.
Two things follow from that. Any workflow that assumed annual renewals is now running twice a year. And any 398-day certificate still in your inventory was issued before March 15, 2026 and is living on borrowed time. Some commercial CAs let customers hold longer-lived certs through the transition window, so those are fine today and a liability the moment they expire. Look at actual expiry dates, not what your renewal policy claims.
What breaks first is the manual renewal
Automation doesn't care how often it runs. A cron job that renews every 60 days behaves the same way whether the cert lasts 90 days or 47. The frequency changes. The work stays flat.
Manual renewal is the opposite. Everything about it scales with how often you do it. A cert you renew by hand at 200 days is roughly two renewals a year. The same cert at 47 days is nearly eight. Same process, same clicks, four times as many chances to forget one. The workflow never got harder. The frequency did, and frequency is what kills manual work.
So the honest first step is a count. How many certificates are you actually managing? Which ones run on ACME, and which get renewed through a portal, a CSR emailed to someone, or a reminder in a shared calendar? Every one in that second group is a renewal you will be doing eight times a year by 2029. Migrate them to ACME while there is no deadline pressure, not after a cert has already expired in production.
Tuning renewBefore before the frequency climbs
If you run cert-manager in Kubernetes, renewBefore is the lever:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: your-cert
spec:
duration: 2160h
renewBefore: 720h
At 47-day certificates, duration comes down to 1128h. Keep renewBefore proportional, or cert-manager will try to renew almost immediately after every issuance and hammer your CA's rate limits. A renewBefore pinned to 30 days made sense at 90-day certs. At 47-day certs it means renewing when the cert is barely two weeks old.
Certbot has the same trap under a different name. If you have fixed renew_before_expiry to a set number of days, recalibrate it against the certificate's actual duration instead of a value you picked when certs lasted a year.
DNS-01 challenges deserve a look too. If they already give you grief at 90-day lifetimes, they will give you more of it at quarterly and then monthly renewals. Fix the challenge configuration now, while frequency isn't yet the thing pushing on it.
What shorter certs do to your monitoring
The window between "renewal failed" and "certificate expired" shrinks with every phase.
At 398 days, a renewal that failed at 60% of lifetime left four or five months to notice. At 100 days, that same missed renewal leaves about 40 days. At 47 days, fewer than 20. The safety margin you never thought about is quietly evaporating.
A 30-day expiry alert made sense when certs lasted a year. At 47-day certs the certificate might not even be a month old when that alert fires. The thresholds that actually matter move inward, to 14 days, then 7, then 3. Anything earlier is background noise. Anything later is a fire.
And monitoring only ever tells you something broke. It is not a fix. As lifetimes compress, the gap between an alert and an outage compresses with them. That is an argument for tightening automation, not for adding more alerts.
Seven months is less time than it feels like
March 2027 sounds distant. It isn't. The 100-day ceiling lands then, and six months from now the DevOps community will be having this same conversation at higher volume, with the easy migration paths harder to hear over the noise.
The certificates that will hurt are the ones nobody owns. The portal renewal. The emailed CSR. The calendar event. Those survive at 200 days because twice a year is forgivable. At 100 days they start slipping, and at 47 days they fail on volume alone, not because of any single mistake.
The schedule will not move. Every CA voted yes, every major browser voted yes, and there is no opposition to appeal to. The only variable left is whether your renewals are automated before the frequency makes manual work impossible.
Frequently asked questions
When exactly does the 100-day maximum take effect? March 15, 2027. From that date, CAs stop issuing certificates valid for more than 100 days. Anything issued before then can run to its natural expiry, but no new cert above 100 days gets signed.
Does this affect Let's Encrypt 90-day certificates issued today? Not directly. 90 days already sits under both the current 200-day ceiling and the coming 100-day one. The pressure on Let's Encrypt users comes from Let's Encrypt's own move toward shorter defaults, not from the CA/Browser Forum schedule.
What happens to certificates renewed through a CA portal instead of ACME? They still work, but the renewal frequency multiplies. Twice a year at 200 days becomes roughly eight times a year at 47 days. At that pace a manual portal workflow fails because of volume, not because of any one dropped renewal.
Will my ACME client handle the shorter lifetimes on its own?
Mostly. ACME revalidates the domain on every renewal, so the shrinking DCV reuse window isn't your problem there. The thing to check is renewBefore or renew_before_expiry. If it is pinned to a fixed number of days, recalibrate it against the certificate's duration or you will renew far more often than you need to.
What is the DCV reuse change and does it affect me? Domain Control Validation reuse is how long a CA will trust a past domain validation without repeating it. It drops from 398 days toward 10 days by 2029. If you use ACME it is a non-issue, since validation happens at every renewal anyway. If you rely on cached or manual validation, it becomes a second, faster-moving deadline behind the lifetime cut.
