The Days of Set-and-Forget Certificates Are Over
For years, the standard approach to SSL/TLS certificates was straightforward: buy a certificate valid for one or two years, install it, and set a calendar reminder to renew it before it expires. That approach is dying. By March 2029, the maximum lifespan for a publicly trusted TLS certificate will be just 47 days.
This shift has been building for a decade. Let's Encrypt launched in 2016 with 90-day certificates, proving that shorter lifespans were viable when paired with automation. Google proposed cutting the maximum to 90 days in 2023. Then Apple went further, proposing a phased reduction down to 47 days. In April 2025, the CA/Browser Forum passed Ballot SC-081v3 with overwhelming support -- 25 votes in favor, zero against -- making it official.
The timeline is already in motion. If you manage certificates for production infrastructure, you need to understand what is changing and when.
The Reduction Timeline
The CA/Browser Forum's phased schedule works like this:
March 15, 2026 (now): Maximum certificate lifespan drops from 398 days to 200 days. Domain Control Validation (DCV) reuse periods also drop to 200 days.
March 15, 2027: Maximum lifespan drops to 100 days. DCV reuse periods drop to 100 days.
March 15, 2029: Maximum lifespan drops to 47 days. DCV reuse periods drop to just 10 days, meaning domain ownership must be reverified almost monthly.
This is not a proposal or a draft. It is an adopted standard. All four major browser vendors -- Apple, Google, Mozilla, and Microsoft -- voted in favor.
Meanwhile, Let's Encrypt is pushing even further. They began issuing optional six-day certificates in early 2025 and made them generally available in January 2026. These ultra-short-lived certificates are valid for just 160 hours and do not include OCSP or CRL URLs, since they expire before traditional revocation mechanisms would even matter. Let's Encrypt has also announced they will reduce their standard certificate lifetime from 90 to 45 days by 2028.
Why Shorter Lifespans Are a Security Win
The security rationale is straightforward. A shorter certificate lifespan limits the damage window when something goes wrong.
Compromised private keys. If an attacker obtains your certificate's private key, they can impersonate your server until that certificate expires or is revoked. With a one-year certificate, that window could be months. With a 47-day certificate, the exposure is measured in weeks. With a six-day certificate, it is less than a week -- potentially short enough that revocation becomes unnecessary.
Mis-issued certificates. If a certificate authority issues a certificate incorrectly, shorter lifespans ensure the mistake ages out quickly. This reduces the blast radius of CA operational errors.
Forced automation. This is arguably the most important benefit. Manual renewal processes are error-prone. They depend on individuals remembering to act, on calendar reminders firing correctly, on the right person being available at the right time. Shorter lifespans make manual renewal impractical, pushing organizations toward automated systems like ACME (Automatic Certificate Management Environment) and certbot. Automated systems, once set up correctly, are more reliable than humans with spreadsheets.
Post-quantum readiness. The CA/Browser Forum has explicitly cited preparation for post-quantum cryptography as a motivator. Organizations that have fully automated certificate management will be better positioned to swap in new algorithms when the time comes.
More Renewals Mean More Chances to Fail
Here is the uncomfortable truth: while shorter certificate lifespans improve security in theory, they also multiply the opportunities for things to go wrong. An organization that previously renewed certificates once a year will need to renew them roughly eight times a year under 47-day lifespans. Every renewal cycle is a potential failure point.
The most dangerous failure mode is not a certificate that fails to renew. It is a certificate that renews successfully but does not deploy correctly. Your ACME client obtains a fresh certificate from the CA, writes it to disk, and reports success. But the web server is still serving the old certificate because it was not reloaded. Or the new certificate was written to the wrong path. Or the load balancer has a cached copy. The renewal automation thinks everything is fine. Your monitoring, if it only checks whether the renewal script ran, also thinks everything is fine. Your users discover the problem when their browsers throw a security warning.
Other failure modes include:
Wildcard certificate edge cases. Wildcard certificates require DNS-01 validation, which means your renewal automation needs write access to your DNS provider's API. If those API credentials expire or the DNS provider changes its API, wildcard renewals silently fail.
Certificate chain issues. A renewed certificate might arrive with an incomplete or incorrect chain. The leaf certificate is valid, but the intermediate is missing or expired. Some clients handle this gracefully; others do not.
Rate limiting. Let's Encrypt and other CAs impose rate limits. If your renewal automation retries aggressively after a failure, you might hit those limits and be unable to obtain certificates at all for a period.
Multi-server deployments. If you run the same certificate across multiple servers or containers, you need a distribution mechanism that updates all of them. A partial rollout -- where some servers have the new certificate and others still serve the old one -- creates intermittent failures that are notoriously hard to diagnose.
Real-World Outages Caused by Expired Certificates
Certificate expiry outages are not hypothetical. They have taken down some of the largest services on the internet.
Microsoft Teams (February 2020). Microsoft Teams went down for approximately three hours because Microsoft failed to renew an authentication certificate. The outage affected millions of users who could not sign in or use the collaboration platform. The root cause was a single expired certificate that had not been tracked by an automated renewal process.
Ericsson / O2 (December 2018). An expired certificate in Ericsson's software knocked out the O2 4G network in the UK for nearly 24 hours, leaving approximately 32 million customers without cellular connectivity. The same issue hit SoftBank in Japan simultaneously. The expired certificate was embedded in network infrastructure software, making it invisible to standard web-focused monitoring.
Spotify / Megaphone (2022). An expired SSL certificate on Spotify's Megaphone podcast platform caused an eight-hour outage that blocked both the content management system and podcast delivery to listeners.
LinkedIn (2019). LinkedIn suffered an outage when an SSL certificate expired. The certificate had been renewed, but the update was not properly reflected by the server -- a textbook example of the "renewed but not deployed" failure mode.
In every case, the root cause was not a lack of awareness that certificates expire. It was a gap between knowing and doing -- a missing automation step, a certificate that fell outside the scope of existing monitoring, or a renewal that completed on paper but not in practice.
New Compliance Requirements Beyond Lifespan
Certificate lifespan is not the only thing changing. Several other compliance requirements are rolling out in parallel.
Multi-Perspective Issuance Corroboration (MPIC). As of September 2025, all publicly trusted CAs must perform domain validation and CAA record checks from multiple geographically distinct network perspectives. This defends against BGP hijacking attacks where an attacker intercepts validation traffic to fraudulently obtain a certificate. MPIC is good for security, but it can introduce validation delays or failures if your DNS infrastructure is not consistently accessible from diverse network locations.
OCSP deprecation. Let's Encrypt shut down its OCSP service entirely in August 2025. Certificates no longer include OCSP URLs; revocation checking has moved to Certificate Revocation Lists (CRLs) and browser-shipped compressed revocation databases like CRLite (Firefox) and CRLSets (Chrome). If your infrastructure relied on OCSP stapling, you need to verify that your revocation checking still works correctly.
Certificate Transparency (CT) requirements. As of Firefox 135 (February 2025), Mozilla requires Certificate Transparency for all certificates issued by CAs in its Root CA Program. All publicly trusted certificates must be logged to CT logs. This is a net positive for security since CT logs let you detect unauthorized certificates issued for your domain, but the increase in logged entries as certificate lifespans shrink (potentially 16-20x more entries) puts new pressure on the CT ecosystem.
What Your Monitoring Should Cover
Given all of these changes, certificate monitoring needs to go beyond a simple "is the certificate expired?" check. Here is what a thorough monitoring setup looks like:
Certificate expiry with graduated alerts. Check the expiry date of the certificate actually being served (not just what your renewal system reports). Alert at 30 days, 14 days, 7 days, and 1 day before expiration. Under 47-day lifespans, a 30-day warning means the certificate is already past the halfway point of its life.
Certificate chain validation. Verify that the full chain is present and valid, from the leaf certificate through intermediates to the root. Chain issues are a common post-renewal failure mode.
Protocol and cipher support. Monitor which TLS versions and cipher suites your server supports. Deprecated protocols (TLS 1.0, 1.1) and weak ciphers should trigger alerts.
Certificate Transparency log monitoring. Watch CT logs for certificates issued for your domains. An unexpected certificate could indicate a compromise or a misconfigured service elsewhere in your organization.
Actual endpoint verification. The most important check is the simplest: connect to your service over HTTPS from an external vantage point and verify that the TLS handshake succeeds. This catches the "renewed but not deployed" problem that has caused so many high-profile outages.
How Alert24 Helps
Alert24's SSL monitoring is built into its uptime checks. Every time Alert24 checks your endpoint's availability, it also inspects the TLS certificate. This means certificate monitoring is not a separate system you need to configure and maintain -- it runs continuously as part of the same monitoring that checks whether your service is responding.
Alert24 checks certificate expiry and sends alerts at configurable thresholds before expiration. Because the check happens from an external perspective against the certificate your server is actually serving, it catches deployment failures that internal monitoring misses. If your ACME client renewed the certificate but your web server is still serving the old one, Alert24 sees the old certificate and alerts you.
Combined with Alert24's incident management and on-call scheduling, a certificate alert does not just fire into the void. It reaches the right engineer through the right channel at the right time, with escalation policies that ensure nothing falls through the cracks.
Best Practices for the Short-Lived Certificate Era
Automate everything with ACME. If you are still renewing certificates manually or semi-manually, stop. Use certbot, acme.sh, or your cloud provider's built-in certificate management (AWS Certificate Manager, Google-managed certificates, Cloudflare). The CA/Browser Forum's timeline makes manual renewal unsustainable.
Monitor independently of your automation. This is the most important principle. Your renewal automation and your monitoring should be completely separate systems. If your renewal pipeline fails silently, your monitoring should catch it. If your monitoring fails, your renewal automation should still work. Never rely on one system to both perform and verify the same action.
Set aggressive alert thresholds. With 47-day certificates, a certificate at 30 days remaining is not a distant warning; it is urgent. Set your first alert threshold at 30 days, escalate at 14 days, and treat 7 days as a critical incident.
Test your renewal pipeline regularly. Do not wait for certificates to approach expiry to find out if your automation works. Use Let's Encrypt's staging environment to test renewal flows. Use short-lived certificates (six-day option from Let's Encrypt) on non-production environments to exercise your pipeline frequently.
Audit your certificate inventory. You probably have more certificates than you think. Internal services, IoT devices, API gateways, legacy systems -- all of these may have certificates that are not covered by your primary automation. A certificate inventory audit, repeated quarterly, catches the certificates that your automation does not know about.
Plan for DCV reuse changes. By 2029, domain control validation will only be reusable for 10 days. This means your automation must be able to complete domain validation challenges reliably and quickly, every single month. Test your DNS-01 and HTTP-01 challenge infrastructure now, while the deadlines are still distant.
The shift to short-lived certificates is not a threat. It is a forcing function that pushes the industry toward better automation, better monitoring, and a smaller attack surface. The organizations that invest in automated renewal and independent monitoring now will not even notice when 47-day certificates become mandatory. The ones that do not will join the growing list of outage postmortems that begin with "an expired certificate."