TLS Certificate Lifecycle Automation: The March 2027 Step Most Teams Will Miss

Most teams think they solved certificates in 2017. They installed a client, pointed it at Let's Encrypt, and stopped thinking about it. That worked while certificates lasted 90 days and validation data could be reused for a year. Both of those numbers are now on a published countdown, and the next step lands on 15 March 2027. TLS certificate lifecycle automation that was tuned for a 90-day world will not quietly adapt. We have audited a dozen client estates this year and the same three defaults were wrong in almost all of them. Fixing them before March is the whole job.

What SC-081v3 actually locked in

The CA/Browser Forum passed Ballot SC-081v3 with 25 of 30 Certificate Issuers and all 4 Certificate Consumers voting yes. Voting closed on 11 April 2025. It is in the Baseline Requirements now, so this is not a proposal anyone is going to argue their way out of.

Two numbers step down on the same dates. One is the maximum lifetime of a public TLS certificate. The other is how long a CA may reuse the domain control validation it already performed for you. DigiCert published the full table:

| Certificate issued on or after | Max validity | Max DCV reuse | |---|---|---| | (before 15 March 2026) | 398 days | 398 days | | 15 March 2026 | 200 days | 200 days | | 15 March 2027 | 100 days | 100 days | | 15 March 2029 | 47 days | 10 days |

The 200-day limit has been live since March. Almost nobody noticed, because 200 days is still longer than the 90-day certificates most automated estates were already issuing. That is the trap. The first step was invisible, so teams concluded the whole schedule was a non-event.

The validation reuse cut matters more than the validity cut

Everyone writes about the 47 days. The column that will actually generate incident tickets is the one on the right.

Today a CA can validate that you control api.example.com and reuse that proof for months. Your renewal is then a quiet request for a fresh certificate against validation that already exists. In March 2029 that reuse window drops to 10 days. At that point essentially every renewal carries a fresh domain control validation with it.

If your validation is a DNS-01 challenge served by an API token against a zone your automation owns, you will not feel this. If it involves a human, a ticket, a firewall exception, or a DNS zone managed by a team that is not yours, it moves from a once-a-year annoyance to a continuous dependency. We have seen estates where a single certificate covering a customer-facing hostname required a change request to a network team for the validation record. That model has a hard expiry date.

Do not treat this as a 2029 problem. The work is re-platforming who owns DNS and how validation is delegated, and that is a quarters-long negotiation in most organisations, not a sprint.

Do the renewal arithmetic for your own estate

Renewal frequency is the input to everything else in this post, and most teams have never calculated it. A client that renews at two thirds of the certificate lifetime, which is the common default, produces this:

| Certificate lifetime | Renews at day | Renewals per name per year | |---|---|---| | 90 days | 60 | 6.1 | | 64 days | 42.7 | 8.6 | | 47 days | 31.3 | 11.7 |

Going from 90-day to 47-day certificates does not add a little load. It nearly doubles your issuance volume, your validation volume, and the number of chances per year for a renewal to fail silently.

Now multiply by your name count. Run this and get an honest number before you plan anything:

# Every cert-manager Certificate, with its issued lifetime in days
kubectl get certificates -A -o json | jq -r '
  .items[]
  | select(.status.notBefore != null and .status.notAfter != null)
  | [ .metadata.namespace,
      .metadata.name,
      ((( .status.notAfter | fromdate) - (.status.notBefore | fromdate)) / 86400 | floor),
      (.spec.renewBefore // "unset"),
      (.spec.renewBeforePercentage // "unset")
    ] | @tsv' | sort -k3 -n

The third column is what your CA actually issued, which is not necessarily what you asked for. The fourth and fifth are where the next section's problem lives.

Where cert-manager defaults turn into a renewal loop

cert-manager's Certificate resource docs are explicit about the failure mode, and it is the one we find most often. The default spec.duration is 90 days, the minimum is 1 hour, the minimum effective renewBefore is 5 minutes, and spec.duration must be greater than spec.renewBefore.

The catch is that an ACME issuer does not have to honour spec.duration. The docs note that "some issuers might be configured to only issue certificates with a set duration, so the actual duration may be different". Let's Encrypt is one of those issuers. You ask for 90 days, you get whatever the profile gives you, and your renewBefore is still measured against a number you invented.

Picture a Certificate with renewBefore: 720h, a reasonable 30 days against a 90-day certificate. On 10 February 2027, Let's Encrypt switches the default classic profile to 64-day certificates with a 10-day authorization reuse period, and on 16 February 2028 it goes to 45 days. Your renewal point moves from day 60 to day 34. Annoying, survivable. Now picture the team that set renewBefore: 1440h because they wanted a comfortable 60-day buffer. Against a 45-day certificate, renewBefore exceeds the entire lifetime, and cert-manager's own warning applies: setting renewBefore close to duration "can lead to a renewal loop, where the Certificate is always in the renewal period".

A renewal loop is not a slow leak. It is a client asking for a new certificate for the same name as fast as the controller will let it, until a rate limit stops it.

The fix is in the same doc and takes one field. Use renewBeforePercentage, which the docs recommend "to prevent renewal loops in case the actual duration is less than expected":

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: api-tls
  namespace: edge
spec:
  secretName: api-tls
  dnsNames:
    - api.example.com
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  # Renew at 2/3 of whatever the CA actually issued, not of what we asked for.
  # Survives 90 -> 64 -> 45 day steps with no edit.
  renewBeforePercentage: 66

Delete every hardcoded renewBefore in your estate and replace it with a percentage. This is the single highest-value change in this post and it is a one-line diff per Certificate.

One gap you cannot close with configuration. ACME Renewal Information, now RFC 9773, lets a CA tell a client exactly when to renew, including during a mass revocation event. Let's Encrypt recommends it, and for clients without it says to renew at about two thirds of the lifetime. cert-manager does not implement it: issue #6010 has been open since May 2023. Certbot has had it since 4.1.0. If your risk model includes a CA-initiated emergency revocation, know that your Kubernetes certificates will not hear about it and plan a manual path.

The ACME rate limits you will hit first

Let's Encrypt's rate limits were sized for a 90-day world. Two of them get tight as lifetimes fall.

| Limit | Value | What trips it | |---|---|---| | Certificates per registered domain | 50 every 7 days | Many subdomains under one apex, all renewing faster | | Duplicate certificate, exact identifier set | 5 every 7 days | A renewal loop on one name | | New orders per account | 300 every 3 hours | A fleet-wide re-issue or a restored cluster | | Failed validations per identifier per account | 5 per hour | Broken DNS-01 delegation |

Work the first one. Take 200 distinct hostnames under a single registered domain. At 90-day certificates renewing on day 60, that is 200 × (7 ÷ 60) = 23.3 issuances per 7 days, comfortably under 50. At 47-day certificates renewing on day 31, it becomes 200 × (7 ÷ 31) = 45.2 per 7 days. You are at 90% of a limit you have never thought about, with no headroom for a re-issue after an incident.

The duplicate limit is the one that turns a misconfiguration into an outage. Five per week for the same exact set of identifiers means a renewal loop burns your entire weekly budget in minutes, and then that specific certificate cannot be issued again for seven days. If the existing certificate expires inside that window, the name goes dark and there is nothing you can do to bring it back early.

Two mitigations, both worth doing. Split large multi-name estates across registered domains or accounts so one apex is not carrying the whole fleet. And put a staging issuer in front of every change to Certificate specs, the same way you gate everything else in your CI/CD pipeline.

While you are in the Let's Encrypt docs, check which profile you are actually on. classic is 90 days with 30-day authorization reuse. tlsserver is 45 days with 7-hour reuse. shortlived is 160 hours. The tlsclient profile was withdrawn on 8 July 2026, which matters if anything in your estate was still using public certificates for client authentication.

The certificates ACME will not renew for you

Public web certificates are the easy half. The inventory that hurts is everything else, and it is invariably larger than teams expect.

Internal mTLS between services usually runs on a private CA, which is not bound by the Baseline Requirements at all. That sounds like relief until you realise most private CA deployments have worse automation than the public ones, because nobody imposed a deadline on them. If you are building service-to-service identity, treat lifetime and rotation as a first-class design input rather than a later hardening pass. Our zero trust implementation guide covers where mTLS sits in the wider model.

Then there is the long tail that no ACME client touches: load balancer certificates uploaded by hand, certificates pinned into mobile clients, appliances with a web UI and no API, SAML and identity federation signing certificates, code signing keys, and certificates a vendor manages on your behalf under a contract nobody has read since procurement. Each of these has a renewal process that is a person, and each one gets more expensive on exactly the schedule above.

Build the inventory before you build the automation. An estate you have not enumerated cannot be automated, and the certificate that takes you down will be one that was never in the spreadsheet. The same discipline we apply to Kubernetes production readiness applies here, and the same inventory is the first step of the post-quantum TLS migration, so build it once and reuse it.

A 90-day plan before the March 2027 step

Ninety days is enough if you start now and take these in order.

In the first month, enumerate. Every certificate, its issuer, its actual issued lifetime, its renewal mechanism, and a named owner. Scan from the outside as well as reading your configuration, because the certificates that are missing from your config are the dangerous ones.

In the second month, fix the defaults. Replace hardcoded renewBefore with renewBeforePercentage everywhere. Confirm which Let's Encrypt profile each issuer resolves to. Calculate your issuance rate against the 50-per-registered-domain limit and split accounts if you are above roughly 60% of it. Alert on certificate expiry as an SLO with a threshold expressed as a percentage of remaining lifetime, never as a fixed number of days, because a fixed threshold silently stops being a warning when lifetimes shrink.

In the third month, attack the manual tail. Pick the certificates whose renewal is a human and either automate them or move the service behind something that terminates TLS with a certificate you do control. A gateway in front of an appliance you cannot automate is a legitimate answer.

Two things we would not do. Do not buy a certificate lifecycle management platform before you have the inventory, because you will size and scope it wrong and pay for the privilege. And do not chase the 47-day number in 2026. Build automation that reads the lifetime the CA actually issued and renews at a percentage of it, and every future step-down becomes a non-event you read about afterwards.

When to Get Help

If your inventory is genuinely unknown, if certificate renewal still routes through a ticket queue, or if you are carrying a private CA that nobody wants to own, this is worth doing with someone who has unpicked it before. The deadline is fixed, the work is mostly archaeology, and the failure mode is a public outage on a date you could have written down two years in advance.

We help teams inventory their certificate estate, move renewal onto lifetime-relative automation, and get the manual tail down to something a rota can carry. Talk to us if that sounds like your March.