47-Day TLS Certificates: What Infrastructure Teams Need to Do Now

In March 2026, the maximum validity period for a publicly trusted TLS certificate dropped from 398 days to 200 days. Most teams absorbed this without incident — their tooling handled it, or they were already on 90-day Let's Encrypt certs. But the schedule doesn't stop there, and the next two cuts are more disruptive.

By March 2027, the maximum drops to 100 days. By March 2029, it drops to 47 days. Domain validation reuse periods shrink on the same schedule, falling to as low as 10 days by 2029 — meaning a certificate's proof of domain ownership expires almost as fast as the cert itself.

For infrastructure teams, this isn't an abstract policy change. It's a forced migration away from any process with a human in the critical path.

What the timeline actually means in practice

The math is stark. If you have 20 certificates and each one previously renewed once a year, you had 20 renewal events annually. At 47-day maximum lifetime — with a sensible policy of renewing at the halfway point — those same 20 certs now require roughly 160 renewal events per year. Each renewal needs to succeed, deliver the new cert to the right targets, and trigger a service reload. Eight times more often than before.

That's not a process you run manually. It's not a process you run with a cron job that emails someone when it fails. It's a process that needs to be fully automated end-to-end, with automatic recovery when something goes wrong.

Teams that handle this well already have ACME clients managing their renewals. The transition to shorter lifetimes costs them almost nothing — the client just runs more often. Teams that have been manually managing renewals, or running semi-automated scripts that still require human sign-off somewhere, are the ones facing a real problem.

The full CA/Browser Forum schedule

Here's the complete reduction schedule that the CA/Browser Forum adopted:

Until March 14, 2026: Maximum 398-day certificates (the post-2020 standard)
March 15, 2026: Maximum 200 days — already in effect
March 15, 2027: Maximum 100 days
March 15, 2029: Maximum 47 days

Domain Control Validation (DCV) reuse periods — how long a CA can rely on a previously completed domain validation — shrink on a parallel track. By 2029, domain validation reuse is capped at 10 days. This matters because it closes a common loophole: even if a CA could theoretically issue a longer cert, they'd need to re-validate the domain every 10 days anyway.

The 2029 deadline is still three years out, but the 2027 cut to 100 days is less than 12 months away. Infrastructure teams running 12-month or 2-year commercial certificates need to start planning now — not because their current certs will be revoked, but because everything they issue after March 2027 will be 100-day maximum, and they need automation in place before that date.

Why the industry is doing this

The compression isn't arbitrary. It's solving a real problem: long-lived certificates stay in circulation long after they should have been revoked.

When a private key is compromised or an organization loses control of a domain, certificate revocation is supposed to remove the cert from service. In practice, revocation doesn't work well. OCSP stapling adoption is incomplete, CRL distribution points are often slow or unreachable, and many clients don't check revocation status at all. The result: a compromised certificate can remain in active use for its full lifetime even after revocation.

Shorter lifetimes solve this differently. Instead of fixing revocation, they limit how long any certificate is valid in the first place. A compromised cert on a 47-day schedule is out of circulation within 47 days of issuance even if revocation fails entirely. The security window shrinks from potentially years to less than two months.

It also forces better hygiene around domain ownership. Infrastructure changes frequently — servers get decommissioned, domains change hands, organizational structures shift. Short-lived certificates mean that domain validation has to reflect current reality, not a snapshot from 18 months ago.

What ACME-integrated infrastructure looks like

The good news for infrastructure teams is that the protocol designed for automated certificate management — ACME (RFC 8555), originally built for Let's Encrypt — is already supported by most of the tools you're running.

HAProxy has included a native ACME client since version 2.3. You configure an ACME endpoint directly in haproxy.cfg, and HAProxy requests, stores, and renews certificates automatically, including triggering its own graceful reload when a new cert is available. At 47-day lifetimes, this just runs more frequently with no operational change required.

WIN-ACME is the standard ACME client for Windows IIS. It handles certificate binding to IIS sites, handles renewal, and can be pointed at any ACME-compatible endpoint. Teams using WIN-ACME today are already well-positioned for shorter lifetimes — the renewal schedule is a configuration change, not an architectural one.

Certbot, acme.sh, and Caddy all support configurable renewal thresholds. The question for teams using these tools isn't whether they can handle shorter lifetimes, but whether their delivery pipeline — getting the renewed cert to the right place and triggering the right reload — is fully automated.

The weak point for most infrastructure teams isn't the ACME client. It's everything after issuance: cert delivery to multiple targets, service reloads, confirmation that the new cert is actually being served, and auditability when something goes wrong.

Three categories of team, three different situations

Already on ACME with automated delivery: You're in good shape. The transition to 47-day certs is a configuration change to your renewal threshold, not a process redesign. Verify your delivery and reload hooks are fully automated, and you're done. The main thing to double-check: whether your monitoring and alerting is calibrated for shorter renewal cycles — alerts designed for annual renewals will fire constantly at 47-day intervals.

Using ACME for issuance but manual delivery: This is the most common gap. The cert renews automatically, but someone still has to SSH into the target server, copy the cert, and reload the service. At 47-day lifetimes, that's roughly 8 manual operations per cert per year instead of 4. The delivery and reload chain needs to be automated before the 2027 cut takes effect.

Still managing certificates manually end-to-end: This is untenable past 2027. The combination of shorter validity periods and shorter DCV reuse means the entire lifecycle — validation, issuance, delivery, reload — needs to run without human intervention. The time to design and test that system is now, not when a cert expires and the on-call engineer is trying to fix it in the middle of the night.

What to prioritize before March 2027

The 100-day cut in March 2027 is the near-term forcing function. Here's a practical priority list:

Audit your certificate inventory. Know every cert you're managing, where it's deployed, how it's being renewed, and who owns the renewal process. Spreadsheets are fine for the audit; they're not fine as the ongoing management tool.
Identify every certificate without an ACME client. Any cert being renewed by downloading from a CA portal and uploading manually is a cert that breaks under shorter lifetimes.
Automate delivery end-to-end. The cert needs to get from your management system to its target without a human step. HAProxy native ACME, WIN-ACME on IIS, and similar integrations handle this natively. For services without built-in ACME support, you need a delivery mechanism with an authenticated pull model.
Test your renewal process. Trigger a renewal manually in a non-production environment and verify the entire chain: issuance, delivery, service reload, confirmation that the new cert is live. If this has never been tested end-to-end, it will fail at the worst possible time.
Calibrate your monitoring. At 47-day lifetimes, an alert at "30 days remaining" fires almost immediately after issuance on a cert that's actively being managed. Tune your monitoring to alert on renewal failures, not on time remaining.

The structural shift this forces

The practical effect of 47-day certificates is that they make certificate management indistinguishable from infrastructure automation. You can't manage TLS at 47-day lifetimes with a calendar reminder and an SSH session. You need the same level of automation you'd apply to any other recurring infrastructure process: idempotent, observable, recoverable, and not dependent on any single person's availability.

Teams that treat this transition as an opportunity to build that infrastructure properly will end up with a cert management system that genuinely doesn't produce incidents. Teams that retrofit manual processes will spend the next few years fighting fires at higher and higher frequency.

The CA/Browser Forum's timeline is a mandate. The question is whether you respond to it proactively or reactively.