Most organisations are only solving half of the certificate problem

Certificate lifespans are shrinking, and every enterprise with a public-facing footprint is already living through it. Under CA/Browser Forum rules, the maximum validity of a publicly trusted TLS certificate dropped to 200 days this year, falls to 100 days in March 2027, and reaches 47 by 2029 - roughly an eightfold increase in renewal frequency compared to the 398-day standard most organisations built their processes around. At the same time, machine identities - certificates, keys, secrets, tokens - now outnumber human identities 109 to 1, according to Palo Alto Networks' 2026 Identity Security Landscape report, driven by cloud-native architecture and now agentic AI.

Almost every conversation about this shift is aimed at the same target: faster automation. Shorter renewal cycles, tighter rotation, more scheduling. That's a reasonable response to a real problem, but it's solving only half of it, and arguably the easier half.

The half nobody's talking about is confirmation. A certificate can renew exactly on schedule, and the deployment can still fail - the new certificate never reaches the endpoint it was meant to protect, while every system involved in the renewal reports success. The change record closes. The CA record looks current. Nothing in that chain was ever built to confirm the actual outcome, because the systems asked to issue and deploy a certificate are the same systems relied on to say the job worked. This isn't a rare failure. Earlier research from CyberArk, now part of Palo Alto Networks, found 72% of organisations had at least one certificate-related outage in the preceding year, and the frequency has climbed sharply: 67% saw these outages monthly and 45% weekly, up from just 26% and 12% respectively in 2022.

Speeding up the renewal side of this equation, without adding anything on the confirmation side, doesn't fix the underlying gap - it multiplies the number of chances to hit it. Eight times the renewal frequency means eight times the opportunities for a deployment to be missed, not eight times the safety.

The public record already has two clear illustrations of what happens when this gap goes unaddressed, one from ordinary neglect and one from forced urgency. In 2021, an expired internal wildcard certificate at Epic Games disrupted login across Fortnite, Rocket League, and the Epic Games Store; the company's own review pointed to a gap in monitoring and renewal automation, not a single dramatic failure. Then in July 2024, DigiCert discovered a five-year-old bug in its domain validation process and, under CA/Browser Forum rules, had no choice but to revoke roughly 83,000 certificates across 6,800 customers within 24 hours - CISA issued an alert urging critical infrastructure operators to act immediately, and thousands of organisations had to redeploy replacement certificates against the clock, with essentially no time to independently confirm every one actually landed. One event shows the failure mode in slow motion; the other shows what it looks like compressed into a single day, which is precisely the direction the industry's shortening timelines are pushing every organisation.

The scope of the exposure is also wider than the current conversation acknowledges. Almost all of the attention on shrinking validity periods is about public-facing web TLS, because that's what the CA/Browser Forum mandate governs. But the same deployment-confirmation gap exists on Active Directory, database connections, internal email, VPNs and load balancers, service-to-service APIs, and operational technology - certificates with no regulatory deadline forcing anyone to pay attention, and often no browser warning giving early notice when something's wrong. When one of them fails, the cost is the same for a business of any size: staff who can't work, customers who can't get through, and an IT team pulled off planned work to hunt down a certificate nobody knew was there.

This is a gap that takes someone close to the work to spot. Working with one large Australian public sector organisation running thousands of servers, our team saw it first-hand. Certificates were renewed by hand and emailed to individuals to install. Installing one was a simple file copy, so if it landed on the wrong server, the service kept running with the wrong certificate. Nothing broke, so nothing alerted. Elsewhere in the same estate, an expired certificate could take an internal platform offline or lock the team out of the server entirely. Rather than simply speeding up the renewals, we're working with the client to add what was missing: independent verification.

In practice, that means checking each certificate from the outside, the way a user or connecting system actually encounters it, rather than trusting the record of what was deployed. It starts with knowing what you have: a full inventory of certificates across public and internal systems, including the ones nobody remembers setting up. From there, each endpoint is checked independently against what it should be serving - the right certificate, on the right server, with the right expiry - and a mismatch raises an alert even when every renewal system reports success. Those results belong in the monitoring and operations tools teams already watch, so a missed deployment surfaces as an incident to fix, not an outage to explain.

None of this argues against the automation investment already underway - it argues for adding to it. Verification needs to be treated as its own discipline, sitting outside the systems doing the issuing and deploying, the same way a well-run finance function reconciles independently even though the payroll system and the bank both report a payment as completed. Assurance produced by the process being assured is not independent assurance. As certificate lifespans keep shrinking and renewal cycles keep accelerating, that discipline is going to matter a great deal more than another round of faster automation.