The cross-functional communication required to deal with short certificate lifecycles

Enterprises may have worried about being agile enough to keep up with Google’s suggestion to shorten TLS certificate durations to just 90 days and change certificates four times a year. But now, the CA Browser forum has approved even shorter timescales, with TLS certs becoming valid for just 47 days over the next four years.

In practice that means renewing monthly after an audit — a pace only possible with automation — to discover what certificates you’re using and where.

“Most organizations don’t know their certificate landscape, so you’ve got to wrap your arms around that,” warns Keyfactor CSO Chris Hickman. “Once you understand how big the scope is in your organization, you need to look at the endpoints they reside on and how you’re going to automate those.”

A certificate expiring because it’s not properly managed can be anything from embarrassing to extremely expensive, and more enterprises are already looking for ways to at least track what’s a month or a week away from causing problems. “One of the most asked-for features we have is TLS certificate checks with different time to expiration,” says David O’Neill, COO at APIContext.

The number of certificates varies by company: a 1,000-person tech company might have 60 domain names, often handled by marketing teams rather than IT, and many more internal systems. O’Neill’s customers have hundreds or even thousands of SSL certificates to manage, all with different expiration dates.

“A couple of hundred publicly rooted certificates is not uncommon for a decent sized organization,” Hickman says. “But the more important question is, where are your strategic publicly rooted certificates installed?” A wildcard certificate can cover any number of subdomains like both production and payment systems, so losing track of the expiry date would have an outsized impact.

“If you don’t know where these certs are, you’re asking for defeat and failure right up front,” he warns.

By March 2026, organizations need to be ready to deal with renewals every six months since the 200-day lifespan halves the current 398 days, and doubles the work for IT teams handling this manually. That drops to three months, or 100 days, in March 2027 and monthly renewal by March 2029. But that doesn’t mean CIOs can wait to tackle the problem.

Some organizations have already done a lot of the work. One US Fortune 500 financial services company inventoried 2,000 certificates as part of adopting cloud services, which meant it could handle the forced migration from Entrust to another publicly rooted provider in an hour with no outages. It now has over 160,000 certificates. “Everything that touches the bank has a cert on it,” Hickman says, and Keyfactor’s preparation to move to 47-day lifespans is largely done.

“They can spend their time advising internal customers,” he adds. “They can go to their web server team, their F5 team, or their ATM team and say, we planned for this change a year and a half ago. You don’t have to do anything; we just want to let you know.”

Knock on effects

Even organizations already managing and renewing TLS certificates at scale need to pay attention, says Chris Swan, a senior engineer at Atsign. He describes the changes as relatively straightforward for the systems he manages, but not entirely anxiety free since a shorter renewal window — just 17 days by 2029 — has other implications.

Monthly renewals may impact patching and restart schedules. “While IIS can take a cert renewal on the fly and you don’t need to restart services, for some applications like Tomcat, you have to restart services,” says Jeff Hagen, PKI and IAM security architect at Hyland. “We currently schedule that with our patch window, but we’re likely going to need to do something different because if maintenance windows are monthly, that might be cutting it tight.”

Free services like Let’s Encrypt have rate limits of around 2,000 certificates a day, covering both renewals and new certificates. Heavy users like Atsign may be constrained by those limits while applications using certificate pinning (a technique developed in response to certificate compromises that’s likely better addressed by certificate transparency) may hit other timing problems, Swan notes.

“Any banking apps doing certificate pinning are going to have extra fun and games,” he says. “You need to get the new certificate, update the app to know the new certificate has this signature, get the new app through Apple’s approval process, and only then would you be able to update your services to actually make use of the new certificate — and it can take 14 days to get through App Store approvals.”

On top of all that, you can’t deal with any of these shorter duration certificates manually, he adds. “You have to be automated, and all of the certificates you’re working with have to be inside your automation.”

Outages, compliance risks, and getting the message out

The less time a certificate is valid for, the shorter the exposure if it’s compromised — or incorrectly issued in the first place — and the easier it is to treat it as disposable and simply replace it, rather than revoke and hope all the systems that touch it can deal with it.

>Shorter timescales also deliberately push organizations toward automation for issuing and using certificates, making them better prepared to handle compromised certificates and urgent changes in cryptographic algorithms. The switch to Post Quantum has a similar timescale, with new algorithms promising better protection that aren’t as tested in production; if flaws are discovered, certificates using them need updating quickly. 

For many organizations, the problem isn’t the certificates themselves as much as the applications using them.

Older server applications with a graphical interface for configuring certificates are hard to automate as part of a multi-step certificate update process — generating and submitting a certificate signing request, then configuring and deploying the certificate. Hagen suggests centralizing SSL certificates on load balancers, and using a private certificate authority for the certificate between load balancer and application so you have fewer devices to rotate certificates on, or the need to restart. As well as scalability and labor savings, that can be more cost efficient.

“We had this problem that people believed the only good certificate was an expensive public certificate,” says Hagen. “Using those for client authentication or to verify the connection to an identity service is inappropriate. We needed to start separating the public TLS use cases from the need for a private CA. Moving certificates to load balancers reduces the volume. We’re centralizing by device, and centralizing our use cases. Some applications we have to do SSL offloading on Windows servers but we’re picking off the public ones first.”

Hagen recommends a robust test environment as well. “You might have a complex mutual TLS application that needs to be automated,” he says. “Or you might have a complicated configuration, or inadequate change management databases that don’t have proper ownership declared.”

Any devices where you want to update certificates have to be managed, whether through Active Directory or other options, but since AD Certificate Services won’t get new features like support for the Automated Certificate Management Environment (ACME) protocol, CIOs at organizations relying on that as a free CA need to budget for other options.

“Smart CIOs are realizing they need to build a foundation to better deal with these emerging different standards and changes in technology,” Hickman says. “A whole set of changes are coming in a very short period of time, and that’s going to require a lot of planning for organizations to not be at a point where they’re at risk.”

Organizational and cultural obstacles may be more than an issue than technical challenges, too. Application owners, sysadmins and web admins for the plethora of marketing websites in most organizations who traditionally handle certificate generation don’t always know about such changes. “Your PKI people need to get with the governance people,” adds Hagen. “They need to get with your DNS administrators and get the automation to do to your ACME validation. Network engineers need to be involved. CIOs need to get their people communicating.” He also suggests following Gartner’s idea of having a cryptographic center of excellence to act as a clearing house.

Once you’re ready for the implications of decreasing lifespans, automation will handle ratcheting down validity over the next four years. Certificate management tools monitor certificates and automatically start renewals as required, based on policy and your prescribed change window.

“When the renewal window comes up, it reaches out to the CA and attempts a renewal,” Hagen says. “We’ll keep doing it as the CAs dictate, rather than us manually controlling when the renewal period would be.”