How to Prepare for 47-Day Certificate Lifetimes

The CA/Browser Forum has voted unanimously. By March 2029, publicly trusted TLS certificates will have a maximum lifetime of 47 days. For organisations managing hundreds of certificates manually, this is not a future problem — the transition starts in March 2026 with 200-day maximums. The window to build automation is now.

For most of the history of TLS, certificate lifetimes were measured in years. Two years became the standard maximum in 2020. One year was pushed by Apple and Google shortly after. Now the industry is heading toward 47 days — roughly six weeks — as the hard ceiling.

The security rationale is sound. Shorter certificate lifetimes limit the window of exposure when a private key is compromised. They force organisations to build reliable renewal processes rather than treating certificates as set-and-forget infrastructure. And they make certificate agility a reality rather than a theoretical goal — when you can rotate certificates in six weeks as a matter of routine, responding to a CA compromise or algorithm deprecation becomes an operational task rather than a crisis.

The operational challenge is significant. An organisation with 500 certificates renews roughly 500 times per year today. Under 47-day lifetimes, the same 500 certificates require around 4,000 renewals per year. Manual processes that are barely sustainable now will be completely untenable.

The transition timeline

The change does not happen overnight. The CA/Browser Forum has set a phased timeline:

March 2026: Maximum certificate lifetime drops to 200 days. Domain validation data must be refreshed every 200 days.
March 2027: Maximum lifetime drops to 100 days.
March 2029: Final enforcement — 47-day maximum lifetime, domain validation refresh every 10 days.

The 10-day domain validation refresh in 2029 is particularly significant. It means that even if you automate certificate issuance, the domain validation process itself must run continuously — not just at renewal time. ACME protocol handles this naturally; manual CA portal processes do not.

Who is most affected

The impact of shorter lifetimes is not uniform. It depends entirely on how certificates are currently managed:

Teams already using ACME automation — Let's Encrypt, ZeroSSL, or a CA with ACME support — will barely notice. Their tooling already handles 90-day certificates. Moving to 47 days changes the renewal frequency but not the operational burden, since renewals happen automatically.

Teams using manual renewal through CA portals will feel the transition most acutely. A process that required one action per certificate per year will require nearly eight. At any meaningful scale, this breaks people.

Teams with hybrid approaches — some automated, some manual — will find that the manual portion becomes increasingly untenable and the pressure to automate everything accelerates.

Internal certificates on private CAs are not directly subject to CA/Browser Forum rules, but the pressure to standardise on shorter lifetimes and automated rotation is building across the industry regardless.

Why ACME is the answer — and what it requires

ACME (Automatic Certificate Management Environment) is the protocol that Let's Encrypt built and that has now been standardised as RFC 8555. It automates the full certificate lifecycle: domain validation, issuance, installation, and renewal — without human intervention.

For ACME to work reliably at scale, a few things need to be in place:

HTTP-01 or DNS-01 challenge support. ACME validates domain ownership by placing a token at a well-known URL (HTTP-01) or in a DNS TXT record (DNS-01). Your infrastructure must support one of these. DNS-01 is required for wildcard certificates and useful for services that cannot serve HTTP challenges.
Automated DNS updates (for DNS-01). If your DNS is managed by a provider with an API, automation is straightforward. If DNS changes require a ticket to a separate team, DNS-01 automation requires process changes first.
Certificate storage and distribution. Renewed certificates need to reach the services that use them. This is often the hardest part — especially for organisations with certificates installed on hardware load balancers, F5 devices, HSMs, or other systems that do not have native ACME support.
Monitoring for renewal failures. Automation that works 99% of the time still fails 1% of the time. Without monitoring for renewal failures, a failed renewal goes undetected until the certificate expires and something breaks.

The cases where ACME does not apply

ACME works well for web servers, APIs, and services with internet-accessible endpoints. It is harder or impossible for some common certificate use cases:

Client certificates and mutual TLS — ACME is designed for server certificates. Client certificate issuance and rotation requires different tooling.
Code signing certificates — not covered by ACME.
Certificates requiring extended validation (EV) — EV involves identity verification steps that cannot be automated.
Hardware security modules and smart cards — certificates stored in hardware often require vendor-specific tooling for rotation.
Air-gapped or restricted environments — ACME requires internet access to the CA. Fully isolated environments need offline or private CA solutions.

For these cases, the answer is not ACME but a combination of private CA automation, strong inventory management, and monitoring with longer lead times to account for the manual steps still required.

What to audit before the transition tightens

The 200-day maximum is already in effect. If you have not started yet, the practical first step is an audit of your current certificate estate:

Count your certificates by renewal method. Which are already automated via ACME? Which require manual renewal? Which are managed by third parties? The manual ones are your highest priority.
Identify dependencies on long-lived certificates. Some processes assume certificates are valid for a year or more — backup validation procedures, audit documentation cycles, manual installation workflows. These need to change.
Map your certificate distribution paths. For each certificate, how does a renewed certificate get installed? If the answer involves a human copying files, that is a process that needs automation before 2029.
Check CA compatibility. Not all CAs support ACME. If your current CA relationships are with providers that only offer portal-based issuance, now is the time to evaluate alternatives or negotiate ACME access.

How CertControl supports the transition

CertControl includes built-in ACME support with Let's Encrypt and configurable renewal windows — so certificates are renewed automatically well before expiry, without manual intervention. The platform handles HTTP-01 and DNS-01 challenges, stores private keys encrypted at rest with AES-256-GCM, and monitors renewal status so that failed automations surface as alerts rather than outages.

For certificates that cannot be automated, CertControl tracks them in the same inventory with configurable alert windows — giving teams the maximum possible lead time for the manual steps that remain. The combined view of automated and manual certificates means nothing falls through the gap between the two approaches. See how CertControl helps prevent certificate expiry incidents across mixed environments.

See the platform Book a demo