Public TLS certificate lifetimes are being reduced in stages, ending at 47 days by 2029 under a ballot the CA/Browser Forum passed in 2025. If your renewals are automated, this is a non-event. If somebody in your team renews certificates by hand each year with a calendar reminder, that task is about to become a weekly one, and the calendar reminder will not survive it.
Why lifetimes are being cut
Revocation has never worked well in practice. Browsers cannot reliably check whether a certificate has been withdrawn, so a compromised key stays useful for as long as the certificate remains valid. Shortening the lifetime limits that window without depending on revocation infrastructure. It also forces automation, which removes the human error behind most expiry outages. The NCSC’s guidance on using TLS makes the related point that key material should have a defined life, and a shorter maximum enforces that on everyone rather than leaving it to individual diligence.
What will break first
Anything renewed by a person. Network appliances where certificates are uploaded through a web interface, load balancers with manual configuration, mail gateways, remote access appliances and management consoles all tend to be handled by hand. Mobile applications that pin a certificate are a separate problem, because each renewal requires an application update unless pinning is done against a longer-lived certificate authority key. Internal certificate authorities are unaffected by the ballot, and organisations often discover their internal habits are just as manual once they start looking. Certificates a hosting provider issues on your behalf belong on the list too, since that renewal happens somewhere you cannot see.
“The organisations that will feel this are the ones where certificate renewal lives in one person’s head. Ask who renewed the last certificate on your VPN appliance and what happens if they are on holiday when it expires. If the honest answer is an outage, the deadline is doing you a favour by forcing the automation now rather than during an incident.”
William Fieldhouse, Director, Aardwolf Security Ltd
Getting to automation
Start with an inventory of every public certificate, where it is installed and who renews it. Certificate transparency logs give you a reliable outside view that catches the ones your inventory missed. Then work through the list by effort: services behind a load balancer or content delivery network can often be centralised so one automated renewal covers many hosts, and anything supporting the ACME protocol can be automated directly. Where a device cannot automate, plan its replacement or accept that somebody will be renewing it every few weeks. Give each certificate an owning team rather than an individual, because a task at this frequency cannot depend on one person being available.
Monitoring as the backstop
Automation fails quietly, so monitor expiry independently of the tool doing the renewal. Alert at fourteen and seven days remaining, to a team rather than an individual, and include internal certificates because those outages hurt just as much. A dashboard nobody opens does not count as monitoring. External network testing services will pick up expired and mismatched certificates across your perimeter, and certificate and vulnerability scanning between tests gives you the weekly view that a shorter lifetime now demands.
Frequently asked questions about certificate lifetimes
These questions come up as the first reduction approaches.
Does this affect internal certificate authorities?
Not directly, since the ballot governs publicly trusted certificates. Aligning internal practice is still sensible, because the operational habits and the tooling are the same.
What about certificate pinning in mobile apps?
Pin to an intermediate or root rather than the leaf certificate, or use a pinning approach that tolerates rotation. Pinning a short-lived leaf certificate guarantees an outage every few weeks.
