Shorter certificate lifetimes will not break your public TLS. They will break the certificates nobody owns.

Sometime in the next two years, someone is going to ask you for a list of your certificates.

If your answer is a spreadsheet somebody maintains by hand, this post is about the gap between that spreadsheet and your actual estate — and about why that gap is the thing that breaks first.

The deadline is dated, and the arithmetic is the whole argument

In April 2025 the CA/Browser Forum adopted Ballot SC-081v3, which reduces the maximum lifetime of publicly trusted TLS certificates on a fixed schedule. The vote was 29 in favour, none against, with five abstentions — 25–0–5 among the certificate issuers, and 4–0 among the browsers, with Apple, Google, Mozilla and Microsoft all voting yes.

Effective	Max TLS lifetime	Max domain-validation reuse
Before 15 Mar 2026	398 days	398 days
15 Mar 2026	200 days	200 days
15 Mar 2027	100 days	100 days
15 Mar 2029	47 days	10 days

Divide 365 by each of those and you get the renewals per certificate per year: about 1.8, then about 3.7, then about 7.8. That is the entire argument. Nothing else in this post is as important as those three numbers, because they are what turns a once-a-year clerical task into a process that runs most months.

The second column matters as much as the first and gets a fraction of the attention. When domain-validation reuse falls to 10 days while certificates last 47, revalidation stops being something you did once at issuance and becomes part of every renewal. A workflow that depends on a human approving a validation email does not survive that.

And your CA may move before the mandate does. Public CAs publish their own cutover dates, and some land earlier than the Forum's. If you are planning against 15 March, check your own CA's calendar first.

Public TLS is the easy half, and that is exactly the problem

Here is the part that catches people out: for most organisations, the certificates covered by this mandate are already fine.

If your public web endpoints already renew on their own, through Let's Encrypt, another ACME client or ACM, the 47-day wall is not a wall for them. Some teams read the headlines, check their public endpoints, confirm they are automated, and conclude they are done.

They are not done, because the mandate does something else on its way past. It makes somebody go and look. And looking is what surfaces the rest of the estate.

The five places the rest of the estate lives

None of these are covered by the ballot. All of them are certificates, all of them expire, and in most organisations at least three of them are undocumented.

1. The internal CA nobody meant to run permanently. Someone stood up a private CA for an internal service, years ago, with a ten-year root. It works, so nobody has touched it. Nobody has checked when the root or the intermediate expires, and an internal root expiring takes down everything it ever signed, at once, with no browser warning to give you a week's notice.

2. Load balancers and appliances. Certificates that live in a device's own config, uploaded through a web UI by whoever set the device up. They are not in your config management, not in your certificate inventory, and frequently not in any system that would tell you they are about to expire.

3. Service-to-service mTLS. Client certificates issued to services so they can authenticate to each other. These are the worst failure mode in the list. When one expires you do not get "the website is down". You get an intermittent authentication failure between two internal services at three in the morning, and it takes hours to recognise as a certificate problem.

4. VPN and device certificates. Issued to laptops and phones, often by an MDM, often on a different schedule from everything else, and usually owned by a team that does not think of itself as owning certificates.

5. Vendor consoles. Certificates bought through a SaaS vendor's portal, on someone's corporate card, visible only to whoever has that login — who may well have left.

You cannot automate the renewal of a certificate you do not know exists. That sentence sounds obvious and it is the reason these projects run long.

"No owner" is the real defect, not "expiring"

The word that does the work here is ownership, and it means something narrower than "we have a list".

A certificate has an owner when a named person or team meets three conditions. They would be told before it expires. They have the access required to renew it. They have the authority to change the service that depends on it. Break any one of those and you have an unowned certificate wearing a name.

The most common real-world version: the certificate is in an inventory, the inventory names a team, and that team has no access to the appliance the certificate lives on. The renewal fails at the point where someone has to raise a ticket with a different department.

How to enumerate your estate, without buying anything

This is a method you can run yourself, and it is deliberately written so that you do not need us to do it.

Start with public issuance, because it is free and complete. Every publicly trusted certificate issued for your domains is in the Certificate Transparency logs, by design. Query CT for your own domains and you get an authoritative list of what has been issued — including certificates issued by teams who never told you, which is usually the interesting part.

Then sweep what CT cannot see. CT covers public issuance only. Internal CAs, self-signed certificates and private PKI are invisible to it. For those: pull certificates from your own hosts and devices, and inventory what your private CAs have issued from the CA's own database.

Then inventory the CAs themselves. For every private CA you find, record the expiry of the root and every intermediate. This is a small list and it is the highest-consequence list you will produce.

Then, for each certificate, answer three questions in writing: who renews it, how they are told it needs renewing, and what breaks when it expires. The third question is the one that reorders your priorities, because it is usually the first time anyone has written down that the expiry of one internal client certificate takes out a payments path.

Finally, split the list in two: certificates that can be automated with free tooling, and certificates that cannot. For the first list, automate them with free tooling. Genuinely — if it can be an ACME client or cert-manager, it should be, and you do not need a consultancy for that. The second list is where the actual work is.

What we would tell you not to pay us for

Two items on that list should never be a consulting engagement, and we would rather say so here than in a meeting.

Anything an ACME client can renew. If a certificate can be issued and rotated automatically with free, well-maintained tooling, use the free tooling. That is most of your public estate and a fair amount of your Kubernetes estate. Nobody should be billing you for it.

Watching for expiry dates. Knowing that a certificate expires in fourteen days is a solved problem and a cheap one. If you have nothing doing it, fix that first — it is the smallest item in this post. It is also not a service worth buying from a consultancy.

Here is what neither of those does. An expiry warning names a date. It does not name a person, it does not hold credentials for the appliance the certificate lives on, and it cannot renew an internal CA root that signs forty services. A warning with no owner attached is advance notice that an outage has been scheduled.

So the work worth paying for is the other side of that sentence: the capacity to remediate the hard remainder, a named owner for every certificate in the estate, and an independent attestation that the estate is current and owned. Self-attestation is not attestation, and the vendor-review questionnaires your customers send you have started to notice the difference.

Where this usually lands

The pattern is consistent. The deadline prompts someone to look. Looking produces a list longer than anyone expected. Most of the list is automatable and gets automated cheaply. What remains is a smaller set of internal CA, appliance and mTLS certificates that no ACME client can reach, and a much larger ownership problem that nobody had a reason to fix until now.

The ownership problem is the one that is still there in 2029.

If you are staring at the 47-day schedule and cannot currently produce the list, that is the normal starting position and it is worth a conversation rather than a purchase. Talk to us about your certificate estate.

Sources. CA/Browser Forum, Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (adopted April 2025) for the schedule and the vote tally. DigiCert, Domain validation reuse changes in 2026, for the CA-side dates. Renewals-per-year figures are 365 divided by each maximum lifetime, shown so you can check them.