47-Day TLS Certificates: Preventing Expiry Outages

An expired certificate takes a service down as completely as a power cut, and public TLS certificate lifetimes are now being cut to 47 days. The CA/Browser Forum schedule has already moved the maximum from 398 to 200 days, it drops to 100 days in March 2027 and to 47 days in March 2029, and the window for reusing domain validation shrinks to 10 days. Any renewal step that still depends on a person, a ticket or a calendar reminder will fail more often as the cycle speeds up. This guide covers why expiry outages happen, the exact schedule, how ACME and ACME Renewal Information (ARI) automate renewal, how to monitor expiry, and a phased plan to get every certificate onto automated renewal. It is written for platform, PKI and site reliability engineers; for the wider certificate lifecycle (issuance, private PKI, revocation design and post-quantum planning) see the Machine Identity, PKI and Certificate Lifecycle Guide.

Key takeaways

Expiry is an identity failure, not a hosting glitch. A certificate is the machine identity of a service; when it expires, every client that validates it refuses to connect.
The 47-day schedule is fixed in the Baseline Requirements. 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, with domain validation reuse falling to 10 days.
Renewal must be automated end to end. Issuance, validation, deployment to every endpoint and service reload all have to happen without a human, or the shorter cycle multiplies outages.
Let the CA tell you when to renew. ARI (RFC 9773) gives clients a suggested renewal window, which also covers early renewal when a CA has to revoke certificates at short notice.
Monitor the certificate actually served, not the one in the inventory. Most outages happen where a renewed certificate never reached a load balancer, appliance or pinned client.

Why certificates still expire in production

Expiry outages are rarely caused by a CA. They come from gaps between whoever owns a certificate, whoever installed it and whatever system actually serves it. Recurring causes:

Unknown certificates: certificates bought on a corporate card, installed by a contractor, embedded in an appliance or hidden inside a software build, with no record in any inventory.
No owner: the person who requested the certificate has left, and renewal notices go to a dead mailbox. Let's Encrypt stopped sending expiry notification emails on 4 June 2025, so any process that relied on those emails has no warning at all.
Renewal without deployment: automation renews the certificate on one host but the copy on the CDN, load balancer, API gateway or Java keystore is never replaced.
No reload: the new file is on disk but the process keeps serving the old certificate from memory until restarted.
Chains and roots: the leaf is valid but an intermediate or root in the chain expires, or clients do not trust the new chain. When Let's Encrypt's DST Root CA X3 cross-sign expired on 30 September 2021, older devices, IoT clients and OpenSSL 1.0.x clients that did not trust ISRG Root X1 failed.
Certificates embedded in products: certificates compiled into firmware or software ship with a fixed expiry that the operator may not even know about.

The 398-day era hid these gaps because they surfaced once a year. A 47-day cycle exposes each one roughly eight times a year.

The CA/Browser Forum schedule to 47 days

Ballot SC-081v3 passed in April 2025 with 25 certificate issuers in favour, none against and five abstaining, and all four certificate consumers (Apple, Google, Microsoft and Mozilla) voting yes. The schedule now sits in sections 6.3.2 and 4.2.1 of the TLS Baseline Requirements and applies to publicly trusted TLS server certificates:

Certificate issued on or after	Maximum validity	Domain and IP validation reuse	Subject identity information reuse
Before 15 March 2026	398 days	398 days	825 days
15 March 2026	200 days	200 days	398 days
15 March 2027	100 days	100 days	398 days
15 March 2029	47 days	10 days	398 days

Details that matter in practice:

Do not request the maximum: the Baseline Requirements measure a day as 86,400 seconds and say certificates SHOULD NOT be issued for the maximum permissible time by default. From 2029 the recommended ceiling is 46 days.
Validation becomes the bottleneck: with 10-day reuse from 2029, almost every renewal will need fresh domain control validation, so DNS or HTTP validation has to be automated too, not only issuance.
Persistent DNS validation: the Baseline Requirements now include method 3.2.2.4.22, a TXT record at _validation-persist.<domain> naming the CA and the ACME account (accounturi), optionally with a persistUntil timestamp. Let's Encrypt expects to support it as DNS-PERSIST-01. It removes the need to change DNS at every renewal, but it also means a stolen ACME account key can obtain certificates for that domain until the record is removed.
Short-lived certificates: from 15 March 2026 a certificate valid for 7 days or less counts as a Short-lived Subscriber Certificate and is exempt from the 24-hour and 5-day revocation deadlines.
CAs can move faster than the ballot: Let's Encrypt plans 45-day certificates on its opt-in tlsserver profile from 13 May 2026, 64 days on the default classic profile from 10 February 2027 and 45 days with a 7-hour authorisation reuse period from 16 February 2028. A 6-day shortlived profile is also offered.

Scope: the schedule applies to public TLS server certificates. Private PKI (internal CAs, Microsoft AD CS, service mesh issuers, device certificates) sets its own lifetimes, but the same automation discipline applies. See the AD CS Security Guide and the mTLS Guide.

Automating renewal with ACME and ARI

ACME (RFC 8555)

Account: the client registers an account key pair and signs every request with it. Treat the account key as a non-human identity credential: store it in a secrets manager, scope it to one team or environment and rotate it if a host is compromised.
Order flow: the client creates an order, proves control of each identifier, finalises with a PKCS#10 CSR and downloads the certificate. The order moves from pending to ready, processing and valid, or to invalid on error.
Challenges: http-01 (a token served over HTTP on port 80) suits single web servers; dns-01 (a TXT record at _acme-challenge) suits wildcard certificates, servers not reachable from the internet and load-balanced pools. dns-01 needs a DNS API credential, which should be limited to the challenge records where the DNS provider allows it.
External Account Binding: commercial and private CAs that speak ACME can require externalAccountBinding, tying the ACME account to a customer account with a MAC key issued out of band. Vault that MAC key like any other secret.
Revocation: the revokeCert endpoint lets the client revoke its own certificates, which is part of incident response if a private key leaks.

ACME Renewal Information (RFC 9773)

How it works: the CA advertises a renewalInfo URL in its ACME directory. The client sends an unauthenticated GET with an identifier built from the certificate's Authority Key Identifier and serial number, and receives a suggestedWindow with start and end times, an optional explanationURL and a Retry-After header saying when to check again.
When to renew: the client picks a random time inside the window, which spreads load, and renews immediately if that time has passed.
Why it matters for outages: if a CA must revoke certificates early (for example after a validation error), it can move the window forward and ARI-aware clients renew on their own before revocation lands.
Replacement tracking: the new order carries a replaces field naming the old certificate; a second replacement attempt is rejected with HTTP 409 and alreadyReplaced.
Without ARI: renew at about two thirds of the lifetime. Let's Encrypt warns that a fixed 60-day renewal interval will not work with 45-day certificates. cert-manager renews at two thirds of the issued duration by default and recommends renewBeforePercentage over a fixed renewBefore to avoid renewal loops when the CA issues a shorter certificate than requested.

Choosing a renewal pattern

Pattern	Fits	Watch for
ACME client on the host (Certbot, acme.sh, built-in web server ACME)	Single servers and small estates	Reload hooks, port 80 reachability for http-01, one account key per host
Platform-native issuance (cloud load balancer or CDN managed certificates)	Public endpoints already terminated by the cloud provider	CNAME or DNS validation records that someone deletes; certificates cannot be exported for other uses
Kubernetes controller (cert-manager)	Ingress, gateways and in-cluster TLS	Secret sync to pods, issuer credentials, `status.RenewalTime` drift
Central certificate lifecycle management (CLM) platform	Large estates, multiple CAs, appliances without ACME	Connector coverage for every endpoint type; the CLM service account is highly privileged
Short-lived certificates (7 days or less)	Highly automated services, internal mTLS	Clock skew, CA availability becomes a dependency for uptime
Manual renewal	None from 2027 onwards	Should be treated as an exception with a dated exit plan

Small organisations: move public sites to a managed certificate service or an ACME client with ARI support, and add external expiry monitoring. That covers most of the risk.
Large organisations: the hard part is the long tail: appliances, mainframes, partner integrations and vendor products without ACME. Budget for a CLM platform or scripted connectors and put renewal support into procurement requirements. See the CLM Buyer's Guide.
Do not use public certificates where you control both ends: internal service-to-service traffic, device identity and client authentication are better served by a private CA with its own lifetimes, so the public schedule does not dictate outages for systems the public never sees.

Monitoring certificate expiry

Endpoint scanning: connect to every listening TLS port (443, 8443, 636 for LDAPS, 993, 465, 587 with STARTTLS and internal admin ports) and record the served leaf and chain, including SNI variants behind shared IP addresses.
Certificate Transparency: public CT logs list every publicly trusted certificate issued for your domains, which finds certificates you did not know about and issuance you did not authorise.
Controller and CLM telemetry: alert on failed orders, failed challenges, renewals that did not happen inside the ARI window and certificates whose renewal time has passed.
Synthetic checks: monitor from outside the network so that a CDN or WAF certificate is checked as users see it.
Alerting thresholds: with 47-day certificates, an alert at 30 days remaining is normal operation, not a warning. Alert on "renewal overdue" (past two thirds of lifetime or past the ARI window) and page at 7 days remaining.

Metric	What good looks like
Share of certificates renewed automatically	Rising towards 100% for public certificates before March 2027
Certificates with a named owning team	100%; no certificate without an owner
Served certificates not found in inventory (from scans and CT)	Falling each month
Renewals overdue (past renewal time, not yet replaced)	Zero for more than 24 hours
Expiry-caused incidents per quarter	Zero
Median days remaining on served certificates	Close to one third of lifetime, showing renewal happens on schedule rather than at the last minute

A phased rollout to automated renewal

Discover (weeks 1 to 4): combine CT log searches, network scans, cloud certificate services, Kubernetes secrets, keystores and CA order history into one inventory with expiry, issuer, endpoints and owner.
Assign ownership: map each certificate to a team and a service, not a person. Unowned certificates go to a default owner with a deadline to reassign.
Classify by renewal path: ACME capable, platform managed, CLM connector, or manual. The manual list is your risk register.
Pilot: move a low-risk public service to ACME with ARI, use the CA's staging environment first and set the shortest available lifetime (for example a 45-day profile) to prove the pipeline under the 2029 conditions now.
Automate deployment and reload: every renewal hook must push to all copies (CDN, load balancer, keystore) and reload the service, then run a check that the served certificate has the new serial number.
Roll out in rings: internal tools, then customer-facing services, then high-traffic and regulated services, with change freezes respected by renewing ahead of them.
Rollback: keep the previous certificate and key until the new one is confirmed in service; if a new chain breaks clients, redeploy the old certificate while it is still valid and fix the chain. Never let rollback depend on a certificate that is about to expire.
Close the manual list before 15 March 2027: at 100 days, manual renewal of a large estate becomes a quarterly fire drill.

Where identity fits

Certificates are non-human identities, and renewal automation creates more of them. The ACME account keys, DNS API tokens, EAB MAC keys and CLM service accounts that renew certificates can each obtain trusted certificates for your domains. Store them in a vault, scope them per environment, log their use and review them like privileged access. ATT&CK tracks certificate theft and forgery as T1649 Steal or Forge Authentication Certificates and adversary acquisition of certificates as T1588.004 Digital Certificates. See the Secrets Management Guide and the Secrets Rotation Runbook Template.

Framework mapping

Framework	Reference	How it applies
NIST SP 800-53 Rev. 5	SC-17 Public Key Infrastructure Certificates	Issue certificates under a defined policy from an approved provider
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management	Key generation and replacement at each renewal
NIST SP 800-53 Rev. 5	CM-8 System Component Inventory	Certificate inventory with owners and locations
NIST CSF 2.0	PR.AA-01, ID.AM-08, DE.CM-09	Credentials for services are managed; assets managed through their life cycle; monitoring finds adverse events such as overdue renewals
CIS Controls v8.1	3.10 Encrypt Sensitive Data in Transit	Valid certificates are a precondition for TLS in transit
ISO/IEC 27001:2022	A.8.24 Use of cryptography	Rules for key and certificate management, including lifetimes
MITRE D3FEND	D3-CERO Certificate Rotation, D3-PCA Passive Certificate Analysis	Rotate certificates routinely; analyse certificates observed on the network

Common failure patterns

Automating issuance but not deployment: the renewal job succeeds and reports green while the load balancer keeps serving the old certificate until it expires.
Hard-coded renewal intervals: cron jobs set to renew every 60 or 90 days that will miss 45 and 47-day certificates. Use ARI or a percentage of lifetime.
Pinning to a leaf or intermediate: mobile apps and API clients that pin a specific certificate break at every renewal; pin to keys you control or do not pin public certificates.
Relying on CA emails: CA notices go to individuals and are being withdrawn; Let's Encrypt's ended in June 2025.
Ignoring embedded and appliance certificates: these lack ACME support and fail on a fixed date, often in network or telecoms equipment.
Over-privileged automation credentials: a DNS API token with full zone write access on every web server turns a single host compromise into domain takeover.

Lessons from incidents

Ericsson, December 2018: Ericsson said its initial root cause analysis pointed to an expired certificate in two software versions of its SGSN-MME core network nodes, disrupting a limited number of operator customers in multiple countries. Certificates embedded in vendor software need expiry dates in the asset inventory.
Microsoft Teams, February 2020: an authentication certificate was allowed to expire, stopping users signing in from roughly mid-morning to late afternoon US Eastern time, as reported by Dark Reading. Authentication certificates inside your own platform deserve the same monitoring as public web certificates.
DST Root CA X3, September 2021: a root expiry broke older clients and IoT devices that had never received the newer root. Track trust stores on clients you cannot update, not just certificates on servers.

Practitioner checklist

Build one certificate inventory from CT logs, scans, cloud services, Kubernetes and CA records, with an owning team for each entry.
Move every public certificate to ACME or platform-managed renewal, with ARI enabled where the client supports it.
Replace fixed renewal intervals with ARI windows or renewal at two thirds of lifetime.
Automate deployment to every copy and reload, then verify the served serial number.
Test today with the shortest lifetime your CA offers to prove readiness for 47 days and 10-day validation reuse.
Vault and scope ACME account keys, EAB keys and DNS API tokens; log and review their use.
Monitor served certificates externally and alert on overdue renewal, not only on days remaining.
Close or formally accept every manual renewal before 15 March 2027.
Move internal service, device and client authentication certificates to private PKI.

Certificate Expiry Outages and 47-Day TLS Certificates Guide: Automating Renewal