47-Day Certificates Force Cloud TLS Automation Now

The maximum lifetime of a publicly trusted TLS certificate is already shrinking: 200 days is the cap in force since March 2026, and maximum public TLS certificate validity drops from 398 days to 47 days under the adopted CA/Browser Forum schedule, with the final step on March 15, 2029. For cloud teams, 47-day certificates turn an annual renewal chore into a near-weekly pipeline event: simple arithmetic says an endpoint that renewed about once a year under the old 398-day cap will renew roughly eight times a year at 47 days. That volume is only survivable with ACME automation, renewal monitoring, and a real inventory of every endpoint that presents a certificate.

The Phase-Down Schedule

The 200-day maximum took effect on March 15, 2026; the cap then falls to 100 days on March 15, 2027 and to 47 days on March 15, 2029. Ballot SC081v3, proposed by Apple and endorsed by Sectigo, Google Chrome and Mozilla, also compresses how long validation data can be reused, and non-SAN validation data reuse drops from 825 to 398 days. The practical consequence is that domain control will need to be re-proven on almost every issuance cycle by 2029, not banked once a year.

Why Shorter Lifetimes Win

Revocation is the weak link the schedule works around. CRLs and OCSP are unreliable at internet scale: browsers soft-fail when status checks time out, and a certificate that cannot be dependably revoked is only contained by its own expiry. Cutting validity to 47 days bounds the window in which a stolen key or a misissued certificate stays trusted — the same containment logic behind session lifetime controls that contain token theft.

Validation data moves in the same direction: domain-validation data reuse falls from 398 days to 10 days under the same schedule, so stale ownership assertions age out in days instead of more than a year. Shorter cycles also buy crypto agility. Swapping algorithms across a fleet is far cheaper when every certificate is already replaced several times a year, which strengthens the case for the sequencing discipline in a post-quantum cryptography migration plan.

Let’s Encrypt Moves Earlier

The largest public CA is not waiting for 2029. Its opt-in tlsserver ACME profile began issuing 45-day certificates on May 13, 2026, and the defaults tighten on a published clock: Let’s Encrypt will switch its default classic profile to 64-day certificates with a 10-day authorization reuse period on February 10, 2027, then to 45-day certificates with a 7 hour authorization reuse period on February 16, 2028. If your renewal job is a hardcoded 60-day cron, it will start missing expirations long before the CA/Browser Forum deadlines arrive.

For teams that want the smallest blast radius today, the shortlived profile is generally available: it issues certificates valid for 160 hours, just over six days, selected with the ‘shortlived’ profile option in a modern ACME client. Let’s Encrypt also issues certificates for IP addresses, and it requires those to be short-lived because addresses change hands more often than domains. The CA recommends enabling ACME Renewal Information (ARI) so clients renew on the issuer’s schedule, and renewing at roughly two-thirds of a certificate’s lifetime as the safe default when ARI is unavailable.

Renewal Math for Cloud Teams

Count what actually presents a certificate: load balancer listeners, API gateways, Kubernetes ingress controllers, service-mesh sidecars, origin servers and internal mTLS endpoints. A fleet of 300 certificate-bearing endpoints — my own worked example, not a measured case study — renews about 300 times a year under a 398-day cap and roughly 2,300 times a year at 47 days. Every renewal is another chance for a failed DNS-01 challenge, an expired API token or a rate limit, so failure handling matters as much as the happy path.

Three design decisions drive the outcome. First, centralize issuance in one ACME pipeline with per-team ownership metadata, because scattered scripts are what actually expire. Second, prefer DNS-01 with delegated zones so renewal never depends on a live web server; the standardized DNS-PERSIST-01 method, expected from Let’s Encrypt in 2026, will let a single static TXT record authorize renewals without live DNS write access. Third, treat certificate expiry as a first-class monitoring signal with paging, not a weekly email digest.

A Preparation Checklist

1. Build a complete inventory of certificate-bearing endpoints using discovery scans and Certificate Transparency logs, and assign an owner to each entry.
2. Move all issuance and renewal to one ACME pipeline, retiring manual CSR requests and portal uploads.
3. Enable ARI in your ACME client so renewals follow the issuer’s schedule instead of guessed intervals.
4. Replace fixed renewal intervals with renewal at two-thirds of the certificate’s actual lifetime.
5. Add expiry alerting at 14, 7 and 2 days before expiration, wired to the on-call rotation.
6. Keep the previous certificate and key deployed for rollback, and test that failback path quarterly.
7. Rehearse the 45-day and 6-day profiles in staging before the February 2027 default switch, then decide per service class when to opt in.

Sources

• CA/Browser Forum — Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods
• Let’s Encrypt — Decreasing Certificate Lifetimes to 45 Days
• Let’s Encrypt — 6-day and IP Address Certificates are Generally Available
• My-SSL — SSL Certificate Validity in 2026: The 200-Day Limit and the Road to 47 Days