Welcome to the third installment in “A Walk in the Park,” a new short video series that explores the forces reshaping the future of digital trust. Over the next five weeks, we’ll take conversations out of the conference room and into the open air as our experts unpack some of the biggest challenges facing security leaders today. Watch the first and second episodes here.
There’s a movie called Gone in 60 Seconds. If you haven’t seen it, the plot is simple. A crew of car thieves has one night to steal 50 high-end cars. It’s a race against the clock, and the title says it all: things disappear fast.
I’m borrowing it for a reason.
Because there’s a clock running in security right now, too. The thing vanishing isn’t a fleet of cars. It’s the lifespan of your TLS certificates. And it’s happening in broad daylight, run by the entire browser industry.
By 2029, the certificate that keeps your website trusted will expire about every six weeks. A lot of people still have no idea it’s coming. So let me walk you through it.
▶️ Watch the episode: Ryan and I get into this on another episode of A Walk in the Park. Here’s the short take. Below, I go deeper into what it means and how to prepare.
First, what these things even are
A TLS certificate is the thing that makes the little lock icon show up in your browser.
There are two flavors. Public certificates are trusted by basically everyone, everywhere. Think of them like a passport. Private ones are more like an enterprise ID badge. Trusted inside your company, not beyond it.
They do two jobs. First, they prove a website is actually that website. So you know you’re on the real site and not an imposter. Second, they secure the encrypted tunnel between your browser and that site. So whatever you send can’t be read along the way.
When a certificate works, you never think about it. When one fails, you think about nothing else.
What’s actually changing
The lifespan of public certificates is collapsing.
It used to be two years. Then thirteen months. Then one year. Now look at where it’s headed:
- March 2026: down to 200 days.
- March 2027: down to 100 days.
- March 2029: down to 47 days.
This isn’t a rumor, and it isn’t a proposal anymore. The CA/Browser Forum voted it in. All four major browsers said yes. Zero votes against. It’s happening.
And there’s a sleeper in the fine print. By 2029, the window to reuse your domain validation drops to just 10 days. So you’re not only renewing more often. You’re re-proving you control the domain almost every single time.
If you’ve got 100 public TLS certificates. Today, that’s about 100 renewals a year. Under the 47-day model, it’s closer to 800. Manual processes do not survive that number without at least a couple slipping through the cracks.
I’ve read the Reddit threads
I’ve seen endless subreddits filled with folks venting about renewing certificates—both public and private certificates. My favorite line: “Tell me you’re not in IT without telling me you’re not in IT.”
Because it nails the gap: the people who don’t do this work think it’s a checkbox. The people who do work with TLS certificates want to poke their eyes out everytime a renewal comes their way.
So let me say the unglamorous part out loud. There are good security reasons for shorter lifespans. A shorter-lived certificate means a stolen key is useful for less time. That shrinks your exposure to man-in-the-middle attacks. This isn’t the browsers being cruel for sport.
But it is a lot more work. Pretending otherwise helps nobody.
What breaks first
If I forget my password, I’m locked out. Annoying, sure, but I reset it and move on. If a certificate expires, the website, system, or application it’s attached to is down. That’s not annoying. That’s a hit to your customers and your revenue.
You can do your best to dodge outages, but the bigger problem is that teams will still spend 8 to 10 times more of their day babysitting certificates instead of the strategic work you actually need from them.
Neither one is a good outcome.
We still see the old ways everywhere. Spreadsheets. Calendar reminders. Emails. Those were always a patch. At 47 days, they fall apart completely.
Where to start
Automation is the answer. But it’s not a single switch you flip.
Every team and every system needs its own workflow. Some certificates can renew automatically. Others need an approval step before anything changes. Some systems can lean on a protocol like ACME or SCEP to handle it. Others need more robust lifecycle automation to get the job done.
That variety is exactly why you start now. Not in 2029. The 200-day cap is already here, and the drop to 100 days hits next March. Working out the right approach for each system takes time, and you want that time on your side.
Now, about your private certificates. Your internal PKI isn’t governed by these rules, so you could keep running longer-lived certificates inside your own walls.
I’d push back on that instinct.
Reflecting the same approach across your internal PKI buys you consistency, and consistency is good security. Long-lived certificates are a real risk on their own. We routinely walk into environments and find internal certificates with lifespans measured in decades to avoid the pains of renewal.
Automation helps overcome renewal pain while allowing teams to follow best practices. Auto-enrollment covers a good chunk of that internal world, and it’s a solid start. But it’s not the full picture. Don’t mistake it for done.
Certificate volumes will grow, and lifespans will shrink. The only real question is whether that’s a non-event for you, or a fire drill every six weeks. The right automation, matched to each system, decides which one.
This is one of the four forces reshaping your Trust Infrastructure, but it’s only the beginning.
Next up: Join Chris Hickman, Chief Security Officer at Keyfactor, to hear about the fastest-growing unmanaged security risk in enterprises today—cryptographic debt.
