Certificate lifetimes on the public web are about to get a lot shorter, and if a team still treats SSL renewal as a once-a-year fire drill, the short-lived certificate standard is going to break that habit whether the team is ready or not. The target keyword here is short-lived SSL certificates, and by the end of this piece there should be no ambiguity about what the 47-day standard actually requires, when it kicks in, and how to survive it without an outage.
What the 47-day standard actually is
In April 2025 the CA/Browser Forum passed a ballot (backed heavily by Apple, with support from Google and Mozilla) that phases down the maximum validity period for publicly trusted TLS certificates. Instead of jumping straight to 47 days, the rollout is staged:
March 15, 2026 – max validity drops to 200 days, domain control validation (DCV) reuse drops to 200 days as well.
March 15, 2027 – max validity drops to 100 days, DCV reuse drops to 100 days.
March 15, 2029 – max validity drops to 47 days, DCV reuse drops to 10 days.
That last number is the one causing the panic. A 47-day certificate means roughly 7.7 renewal cycles per year per host, compared to about 1.2 cycles under the old 397-day maximum. The DCV reuse window shrinking to 10 days is arguably the bigger operational shift — it means domain ownership has to be re-proven almost monthly, not just once a year at issuance time.
Why browsers pushed for this instead of just banning long certs outright
The stated rationale is agility, not paranoia for its own sake. A certificate valid for 13 months can sit in front of a compromised private key for over a year before anyone notices, and revocation checking via CRLs and OCSP has always been unreliable — browsers routinely soft-fail when a revocation check times out. Shorter lifetimes cap the blast radius of a key compromise automatically: if a key leaks and nobody catches it, the certificate expires and stops being trusted within weeks instead of over a year. It also forces the industry to finish automating what should have been automated a decade ago. Let’s Encrypt proved in 2016 that 90-day certificates were viable at massive scale; this ballot essentially drags the rest of the CA ecosystem to a similar posture.
Busting the myth: this is not just a Let’s Encrypt problem
Plenty of admins hear “47 days” and assume it only affects free ACME-issued certs. It doesn’t. The ballot applies to every publicly trusted CA — DigiCert, Sectigo, GlobalSign, GoDaddy, all of them. Enterprise EV and OV certificates from paid CAs are included in the same schedule as DV certificates. A bank running DigiCert OV certs on a hand-managed IIS cluster is just as exposed to this deadline as a startup running Let’s Encrypt on Nginx. The idea that “we pay for premium certs so we’re exempt” is flatly wrong, and it’s the single most common misconception showing up in enterprise PKI planning conversations right now.
What actually breaks when lifetimes shrink
Three failure patterns show up repeatedly wherever teams haven’t automated renewal yet.
The first is orphaned hosts — internal load balancers, legacy Windows servers, or third-party SaaS integrations that someone configured with a manually-issued cert two years ago and then left alone. At 397 days, that cert failing silently once a year was survivable through institutional memory. At 47 days, a team hits that same failure eight times more often, and eight times the chances someone’s on vacation when it happens.
The second is CA rate limits and API throttling. A fleet of 5,000 certificates renewing roughly every 40 days (to leave buffer before the 47-day hard expiry) generates a very different request volume than the same fleet renewing annually. Teams relying on manual CSR generation per host — see how to generate a proper certificate signing request if that process still isn’t scripted — will find it physically impossible to keep up by hand.
The third is DCV reuse expiring mid-cycle. Under the 2029 rules, domain validation has to be re-proven every 10 days regardless of the certificate’s own validity window. Any DNS-01 or HTTP-01 validation flow that isn’t fully automated becomes a liability, not a one-time setup task.
Getting ahead of it: a practical sequence
An experienced PKI lead doesn’t wait for March 2027 to start moving. The sequence that actually works looks like this: first, build a complete inventory of every certificate in the environment, including the ones nobody remembers issuing — internal APIs, IoT gateways, and third-party embeds all count. Second, migrate every host still on manual issuance to ACME, whether that’s Let’s Encrypt, ZeroSSL, or a commercial CA’s ACME endpoint (most major CAs now offer one specifically because of this ballot). Third, wire renewal into deployment pipelines rather than cron jobs on a single box — SSL certificate management in CI/CD pipelines covers the pattern of treating cert renewal as part of the build/deploy graph instead of a side process that can silently stop running. Fourth, for teams already using ACME, revisit the automation itself against the guidance in how to automate SSL certificate deployment with ACME protocol, since a script that worked fine renewing every 60 days may not have alerting tight enough for a 47-day window with almost no slack.
Common mistakes teams make preparing for this
The most frequent mistake is treating the 2026 and 2027 milestones as “not urgent yet” because 47 days feels far off. Automation built under time pressure in early 2029 tends to be rushed and undertested. The second is renewing certificates at 90% of their lifetime instead of building in real margin — at 47 days, a renewal attempt that fails once due to a CA outage leaves almost no runway to retry before expiry. The third, closely tied to the anti-patterns already well documented in common SSL certificate renewal anti-patterns to avoid, is relying on a single monitoring signal — usually just “did the renewal cron job run” — without independently verifying that the certificate actually deployed and is being served correctly.
Frequently asked questions
Does the 47-day rule apply to internal or self-signed certificates?
No. The CA/Browser Forum ballot governs certificates issued by publicly trusted CAs for public TLS. Internal PKI, private CAs, and self-signed certificates on air-gapped or internal-only systems are not bound by this schedule, though many organizations choose to shorten internal lifetimes anyway for consistency.
Can a certificate authority still issue a 1-year certificate after March 2026?
No. Once each phase takes effect, CAs are contractually barred from issuing certificates exceeding the new maximum, and browsers will distrust certificates that violate the schedule. Existing certificates issued before a cutoff remain valid until their original expiry.
Is manual renewal still viable at 47 days?
For a handful of hosts, technically yes, but the operational overhead multiplies roughly eightfold compared to annual renewal. Anything beyond a handful of certificates needs ACME automation with monitoring that independently confirms deployment, not just issuance.
The 47-day deadline is still years out, but the intermediate steps — 200 days in March 2026, 100 days in March 2027 — arrive fast enough that automation built casually won’t survive contact with them. Treat each milestone as a forcing function to retire manual issuance entirely, and the final jump to 47 days becomes a non-event rather than a scramble.