The 100-Day TLS Certificate Deadline: Getting Renewal Ready Before March 2027

Key ManagementOctober 08, 2026

From 15 March 2027, public TLS certificates may last no more than 100 days. Here is what changes, why it matters for key management, and a checklist to automate renewal now.

Abstract navy illustration of nested translucent teal and blue panels shrinking toward a set of concentric partial arcs, suggesting ever-shorter certificate renewal cycles

On 15 March 2027, the maximum lifetime of a publicly trusted TLS certificate halves again, from 200 days to 100. The same date cuts how long a certificate authority (CA) may reuse a domain validation to 100 days. Both changes come from the CA/Browser Forum's Ballot SC-081v3, which passed in April 2025, and they are now part of the TLS Baseline Requirements that every public CA must follow.

The first step, to 200 days, took effect in March 2026. For many teams that meant moving from one renewal a year to two, which a spreadsheet and a calendar reminder can still just about handle. At 100 days, and at 47 days from March 2029, that stops working. Five months is enough time to fix renewal properly, but only if the work starts now.

What changes, and when

The Baseline Requirements set out the schedule plainly. A certificate issued on or after 15 March 2027 must not be valid for more than 100 days, and should not exceed 99. From 15 March 2029, the limit drops to 47 days. Domain and IP address validation data can be reused for 100 days from 2027, then for only 10 days from 2029.

Two details matter in practice:

The limit applies at issuance. A certificate issued before the deadline keeps its original expiry date. Nothing breaks on 15 March itself; renewals start failing or piling up over the weeks that follow.
Some CAs move earlier. Let's Encrypt announced that its default profile moves to 64-day certificates with a 10-day authorization reuse period on 10 February 2027, and to 45 days in February 2028. Check your own CA's timeline, not only the industry deadline.

These rules cover publicly trusted certificates only. Certificates from a private, internal CA are governed by your own policy, although the same argument for shorter lifetimes applies to them.

Why shorter lifetimes are the point

Shorter lifetimes are a key management decision, not a paperwork one. A certificate binds a name to a private key. If that key leaks, or a certificate is issued in error, revocation is the remedy, but revocation does not always reach every client in time. A short lifetime limits how long a compromised or mistaken certificate can be misused, whether or not anyone revokes it.

The trade-off is operational. Each renewal is a moment where something can fail: a validation record missing from DNS, an expired API credential, a load balancer that never reloads the new certificate. Shorter lifetimes turn rare failures into regular ones. Teams that rely on people to renew will see more outages; teams that automate will hardly notice.

Build renewal around automation

The Automated Certificate Management Environment protocol (ACME) is the common way to automate issuance and renewal, and it is widely supported by public CAs, internal PKI products and client tools. Three things make an ACME setup ready for 100-day and shorter lifetimes.

Let the CA tell you when to renew

RFC 9773, published in June 2025, defines ACME Renewal Information (ARI). With ARI, the CA publishes a suggested renewal window for each certificate, and the client follows it. This lets the CA spread renewal load and, more importantly, ask clients to renew early ahead of a mass revocation. A client that supports ARI can recover from a CA incident without anyone on your team being paged.

If your client does not support ARI yet, Let's Encrypt suggests renewing about two-thirds of the way through a certificate's lifetime. A fixed 60-day renewal interval, still common in older setups, will not work with 45-day certificates.

Make validation repeatable

With validation reuse falling to 100 days and then 10, domain validation becomes part of nearly every renewal. Every validation path must therefore be automated: the DNS records or HTTP responses a CA checks must be published by tooling, using credentials scoped to exactly that job. A DNS API token that can edit any record in your zone is itself a high-value secret; limit it to the validation records it needs.

Tighten who can issue

RFC 8657 adds two parameters to CAA DNS records: accounturi, which limits issuance to specific accounts at a CA, and validationmethods, which limits the validation methods a CA may use. From 15 March 2027, the Baseline Requirements say CAs must process both. That makes them a dependable control for the first time: you can state in DNS that only your automation account, using only the validation method you chose, may obtain certificates for your domains.

A checklist for this week

Build an inventory. List every public certificate, its CA, its expiry, the service and team that own it, and how it is renewed today. Certificate Transparency logs and your CA accounts are good starting points for finding certificates you did not know about.
Mark every manual renewal. Any certificate renewed by a person copying files or pasting a CSR into a portal is a future outage. Rank them by business impact.
Check what consumes the certificate. Appliances, CDNs, load balancers and SaaS custom domains often need their own integration or API to take a new certificate. Confirm each one can be updated without a human.
Turn on ARI where your client supports it, and replace fixed renewal intervals with a share of the certificate's lifetime elsewhere.
Scope validation credentials. Give DNS and web automation the narrowest permissions that work, store them in a secrets manager, and rotate them.
Publish CAA records naming your CAs, and plan to add accounturi and validationmethods once you have confirmed your CA supports them.
Monitor from outside. Alert when a certificate on a live endpoint is closer to expiry than your renewal policy allows, not just when renewal jobs report errors. Test that the alert reaches someone.
Rehearse a mass replacement. Pick a non-critical service and replace its certificate and key outside the normal schedule. If that takes more than a few minutes of effort, you are not yet ready for a CA incident.

Don't forget the keys

Automating renewal is a good time to look at the private keys behind your certificates. Decide whether each renewal generates a new key pair, which limits the impact of an undetected key leak, and make sure keys are generated and stored where your policy says they should be. For high-value services, that may mean a hardware security module or a managed key service rather than a file on disk. Keep a record of which keys protect which names, so that if one is exposed you know exactly what to replace.

Centralising key handling helps here. Services such as OXU KMS aim to make encryption and key management simple and secure by design, so that policy is applied in one place rather than service by service.

Conclusion

The move to 100-day certificates in March 2027 is not a crisis, but it ends the era of renewing by hand. Inventory what you have, automate validation and renewal with ARI, use CAA to control who can issue, and monitor from the outside. Do that before March, and the later step to 47 days becomes a configuration change rather than a project.