Certificate Lifespan to move to a 47-day lifecycle in 2029.  

Even before that date, the lifecycle period shortens:

• IN EFFECT March 15, 2026: Maximum certificate lifespan reduced to 200 days

• March 15, 2027: Further reduction to 100 days

• March 15, 2029: Final enforcement of the 47-day maximum lifespan

AUTOMATION is a MUST!!   The digital certificates team is here to help!

NO ONE should be replacing certificates manually! You should have this process happening through self-implemented automation or proprietary application based automation process.
MONITOR: You should monitor certificates expiration dates! Plenty of internal tools to assist with that task, as well as internet tools for externally hosted servers and hists.

• https://www.sectigo.com/47-day-ssl

• https://www.digicert.com/blog/tls-certificate-lifetimes-will-officially-reduce-to-47-days

• https://www.cyberark.com/resources/blog/tls-certificate-validity-cut-to-47-days-what-you-need-to-know

Open

The move to much shorter TLS certificate lifespans is primarily about reducing risk in a web ecosystem where trust data ages fast. A certificate is really a snapshot: it says that, at the time of issuance, the domain control, validation data, and cryptographic setup were correct. As more time passes, the chance increases that something important has changed — ownership may shift, validation data may go stale, keys may be exposed, or infrastructure may drift out of policy. The CA/Browser Forum’s approved ballot argues that shorter validity periods improve the overall reliability of certificates by limiting how long outdated or inaccurate information can remain trusted. 

There is also a blunt security reason: when a certificate’s private key is compromised, or when a serious flaw is discovered in software or cryptographic components, long-lived certificates leave a wider window for abuse. Google’s Chromium team has said the goal behind repeated certificate lifetime reductions has consistently been to improve security by shrinking the impact of compromised keys and speeding up the replacement of insecure technologies and practices across the web. The CA/Browser Forum makes a similar case, noting that shorter lifespans reduce the harm caused by misissued certificates and help the ecosystem respond faster when algorithms, libraries, or validation processes need to change. 

A third driver is operational reality: revocation has never been a perfect safety net. Certificate status systems such as CRLs and OCSP can be slow, inconsistent, privacy-sensitive, or ineffective at internet scale, which means a bad certificate may continue to be accepted longer than anyone would like. Shorter lifespans act as a built-in expiration fuse, reducing dependence on revocation alone. At the same time, the phased deadlines in 2026, 2027, and 2029 are meant to force broader adoption of automated certificate management, so organizations can renew, replace, and rotate certificates routinely instead of treating them like annual paperwork. In other words, this is not just a policy tweak — it is the industry trying to drag certificate management out of the manual-clicking swamp and into something that behaves like modern infrastructure.