In December 2018, an expired certificate at Ericsson took mobile data offline for roughly 32 million O2 customers in the UK. In February 2020, Microsoft Teams went down for hours because a certificate lapsed. Both companies had money, talent, and tooling. What they did not have was a specific person whose job it was to make sure that specific certificate got renewed.
I see the same pattern in almost every security program I review. The organization owns a discovery tool, maybe a certificate lifecycle manager, sometimes a full platform with dashboards. The alerts fire. Certificates still expire in production, because an alert is not an owner.
The ownership gap is the actual incident
Dig into a certificate outage and the post-incident story is almost never “the tool failed.” It is “the tool knew, and everyone assumed someone else was handling it.” The certificate belonged to a service run by an application team. The load balancer belonged to infrastructure. The renewal automation belonged to platform engineering. The policy belonged to security. Four teams, zero owners.
That is why I treat certificate management as an operating model problem. The technical work is well understood: issue, deploy, renew, revoke. The hard part is deciding who is accountable for each stage, what evidence proves the work happened, and what happens when the normal path fails.
Why the clock matters more than the org chart
The CA/Browser Forum has put a fixed schedule on this. Ballot SC-081v3, approved in April 2025, cuts the maximum life of a public TLS certificate from 398 days to 200 days (in effect since March 15, 2026), then 100 days in March 2027, and 47 days in March 2029. Domain validation reuse shrinks on the same track, down to 10 days at the end.
At 398 days, renewal is an annual chore and a calendar reminder can carry it. At 47 days, you renew every six or seven weeks. Manual renewal does not survive that math across an estate of hundreds or thousands of certificates. Automation becomes mandatory, and automation without ownership fails quietly. Nobody notices the ACME client that stopped renewing a forgotten-but-still-live service until the certificate expires and the page goes down.
The ownership map that works
Here is the model I put in front of clients. Five lifecycle stages, one accountable owner for each.
Issuance. Platform engineering owns the issuing path: the CA relationships, the ACME endpoints, the templates, the approved key sizes and algorithms. Application teams request certificates through that path, not around it. A certificate bought with a team credit card is how unknown certs end up in production.
Renewal. The team that runs the service owns the renewal outcome. Automation does the work, but the application owner gets paged when renewal fails, not the PKI team. This is the single most important line in the map: the person who feels the outage owns the renewal.
Revocation. Security owns revocation authority and the clock. Compromise response cannot wait for an application team to come back from vacation. Decide who can revoke, how fast, and what the reissue path looks like before you need it.
Exception handling. Some systems cannot automate: legacy appliances, vendor-managed gear, OT equipment. Those go on an exception register with a named owner, a compensating control, and an expiry date on the exception itself. An exception without an expiry date is unmanaged risk with better branding.
Incident response. When a certificate causes an outage, who runs the call? Write it down. The answer should be the person who owns renewal for that service, with security in the room if compromise is suspected.
The evidence a security leader should expect
Ownership is a claim. Evidence is how you check it. When I review a program, I ask for five things.
Start with the inventory and its coverage story. Not a certificate count, but an answer to “how do you know this list is complete?” Discovery scanning, CA issuance records, and cloud and load balancer inventories, reconciled. If the answer is “the tool finds them,” ask what the tool cannot see.
Then the renewal success rate. What percentage of certificates renewed on schedule last quarter, and where did the rest fail? A healthy program knows this number.
The third one is time to revoke. When did you last revoke a certificate, and how long did it take from decision to done? If nobody remembers, run a drill.
Ask for the exception register as well. How many certificates sit outside the automated path, who owns each one, and when does each exception expire?
Close with the most recent incident or drill. A certificate outage, a CA compromise scenario, anything that exercised the response path in the past year.
A team that can produce those five artifacts has real ownership. A team that can only produce the tool’s dashboard has a hope.
Spend on ownership before you spend on tooling
None of this argues against certificate tooling. You cannot run a 47-day renewal cycle by hand, and discovery tools earn their keep. The order of operations is the point. Assign the owners, define the evidence, write down the exception and incident paths, then buy or build automation into that structure. A lifecycle platform deployed into an ownership vacuum becomes an expensive alerting system that everyone ignores.
The 47-day era is on a published schedule, and the first cut already happened. The organizations that come out of it well will not be the ones with the most tools. They will be the ones where a specific person loses sleep over a specific certificate. That is an operating decision, and it costs nothing but the meeting where you make it.
Thanks,
Jeff Sowell
Blue Radius – https://blueradius.io/
Leave a Reply