When they hear that TLS certificate validity periods are being shortened, many enterprise administrators react by asking, "Why should we have to bear this burden?" However, the real purpose of this change is not to increase the number of renewals. It is to put in place, in advance, the infrastructure that will allow organizations to survive when the next major security incident hits. 

Timothy Hollebeek of DigiCert explains the essence of this change based on the perspective he has gained firsthand from CA/Browser Forum discussions.

Why Shorter Certificate Validity Periods Actually Matter

Speaking as someone who has sat through plenty of CA/Browser Forum meetings, the debate over certificate validity periods tends to generate more heat than substantive discussion. The schedule has already been set. TLS validity was reduced to 200 days in March 2026 and will be shortened to 100 days in 2027 and 47 days in March 2029. On the same schedule, the domain validation reuse period will also be reduced to 10 days.

When I explain this to customers, the reaction is predictable: "Where is the evidence that private keys are actually being compromised? If that were happening, wouldn't there be a much bigger problem?"

That is not wrong. But it misses the point.

Do You Remember Heartbleed?

In April 2014, a vulnerability was discovered in OpenSSL's heartbeat extension. Through this vulnerability, attackers could read server memory in 64KB chunks. That memory could contain session tokens, user credentials, and even private keys. The bug had already existed for two years before it was discovered. The vulnerability itself was serious, but the response was even more so. Server operators had to patch OpenSSL, regenerate private keys, issue new certificates, and deploy them, ideally within a few hours.

What actually happened? Some servers ran for weeks, and in some cases months, with potentially compromised keys. Most organizations had not documented where their certificates were deployed, had no means of replacing them automatically, and had never tested an emergency replacement procedure.

At the time, certificates were valid for up to five years. Certificate management processes were designed to match that pace. When the crisis came, the infrastructure to respond was not in place. This is the real security problem that shorter certificate validity periods aim to solve. It is not about routinely responding to key compromises; it is about surviving the next Heartbleed.

Agility Is the Key

The browser vendors driving this change are not unaware of the operational burden. What they are making is a calculated bet. By forcing frequent certificate replacement across the entire ecosystem, they ensure that organizations build the capability to respond quickly at the moment it is actually needed.

An organization that can deploy certificates every 47 days without any problems has already proven that it is capable of emergency replacement. That is because it has automation in place, has visibility into its inventory, and has tested the process hundreds of times.

On the other hand, if you manage certificates with spreadsheets and calendar reminders and renew them once a year, you will find yourself in a very difficult situation when the next major vulnerability is disclosed.

There is also a side benefit. Short validity periods reduce reliance on certificate revocation mechanisms. Certificate revocation is inherently not fully reliable. Some browsers do not check OCSP by default for privacy reasons, and CRLs become difficult to manage at scale. If certificates expire naturally in weeks rather than months, the window in which a compromised certificate can be abused shrinks, even if revocation does not work properly.

The Connection to Quantum Computing

I have been spending a lot of time on post-quantum cryptography (PQC) work lately, and one thing is clear: organizations that struggle with basic certificate management will be overwhelmed by the changes ahead. The transition to quantum-resistant algorithms requires touching every certificate in the infrastructure again, and it may need to be repeated several times as standards mature.

The organizations that will be able to handle this transition are those building cryptographic agility now. The foundation is a complete certificate inventory, automated deployment pipelines, and a framework in which algorithms can be replaced without disruption. Shorter certificate validity periods are forcing exactly this kind of modernization. It is not always a comfortable process, but it is a necessary one.

What to Do Now

The transition schedule gives you time to prepare, but not as much as you might think. If you have not yet started automating your certificate lifecycle, now is the time to begin.

Security infrastructure is like a bridge. It only gets attention when it collapses. The industry is trying to prevent the next collapse in advance. Whether the execution is perfect is a separate discussion, but the direction itself, building a more agile and more resilient web PKI, is right.

As an official DigiCert partner, CloudNetworks supports building automation frameworks in response to shorter TLS certificate validity periods, as well as certificate lifecycle management as a whole. If you need a strategy to prepare for the phased transition that began in 2026, please contact CloudNetworks.

▶ DigiCert TLM Learn More