I've been in enough CA/Browser Forum meetings to know that the certificate lifetime debate generates more heat than light. The timeline is now set: TLS lifetimes dropped to 200 days in March 2026, dropping again to 100 days by 2027 and 47 days by March 2029. On that same timeline, domain validation reuse drops to 10 days. 

When I explain this to customers, I get a predictable response: "Where's the evidence that private keys are being compromised? If they are, we have much bigger problems." 

They're not wrong. But they're also missing the point. 

Remember Heartbleed? 

In April 2014, a vulnerability in OpenSSL's heartbeat extension allowed attackers to read server memory in 64KB chunks. That memory could contain anything: session tokens, user credentials, and yes, private keys. The bug had been in the wild for two years before anyone noticed. 

The vulnerability itself was bad. The response was worse. 

Server operators needed to patch OpenSSL, regenerate their private keys, get new certificates issued, and deploy them—ideally within hours.  

What actually happened? Many servers ran with potentially compromised keys for weeks. Some for months. Organizations discovered they had no documentation of where their certificates were deployed, no automated way to replace them, and no tested procedures for emergency rotation. 

Certificates at the time could be valid for up to five years. The processes to manage them reflected that pace. When the crisis hit, the infrastructure simply wasn't there. 

That's the actual security problem these lifetime reductions are trying to solve. Not routine key compromise—surviving the next Heartbleed. 

Agility is the point 

The browser vendors pushing these changes aren't naive about operational burden. They're making a calculated bet: that forcing the ecosystem to handle frequent certificate rotation will build the muscle memory needed for rapid response when it actually matters. 

If your organization can deploy certificates every 47 days without breaking anything, you've already proven you can do emergency replacement. You have automation. You have inventory visibility. You've tested your processes hundreds of times. 

If you're still managing certificates with spreadsheets and a prayer, renewing once a year when someone's calendar reminder fires—you're going to have a very bad day when the next major vulnerability drops. 

There are secondary benefits, too. Shorter lifetimes reduce our dependence on certificate revocation, which has always been unreliable. Some browsers don't check OCSP by default for privacy reasons. CRLs can grow unwieldy. When a certificate naturally expires in weeks rather than months, the window for a compromised certificate to cause damage shrinks regardless of whether revocation works. 

The quantum connection 

I spend a lot of my time these days on post-quantum cryptography, and I can tell you: Organizations that struggle with basic certificate hygiene are going to be overwhelmed by what's coming. The transition to quantum-resistant algorithms will require touching every certificate in your infrastructure, probably more than once as the standards mature. 

The organizations that will handle that transition are the ones building cryptographic agility now. Complete certificate inventory. Automated deployment pipelines. The ability to swap out algorithms without a fire drill. 

Shorter certificate lifetimes are forcing exactly this kind of modernization. It's not always comfortable, but it's necessary. 

What to do about it

The timeline gives you room to prepare, but not as much as you might think. If you haven't started automating certificate lifecycle management, now is the time. 

This is exactly why we built Trust Lifecycle Manager—to give organizations visibility across their entire certificate landscape regardless of issuing CA), automation for the full lifecycle from discovery through renewal, and the agility to respond quickly when requirements change. Because they will change, and probably sooner than you'd like. 

Security infrastructure is a lot like bridges: People only pay attention when one collapses. The industry is trying to get ahead of the next collapse. Whether the execution has been perfect is a separate debate—but the underlying goal of building a more agile, more resilient web PKI is the right one.