# Shorter certificate lifetimes: the deadline that matters is March 15, 2027

Source: https://startwithidentity.com/blog/shorter-certificate-lifetimes-automate-now/
Last updated: 2026-10-28
License: content by Start with Identity. Cite the source URL.

---

The maximum lifetime of a publicly trusted TLS certificate has been 200 days since March 15, 2026. It falls to 100 days on March 15, 2027, and to 47 days in 2029, under CA/Browser Forum [Ballot SC-081v3](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/). The 2029 figure gets the headlines, but March 15, 2027 is the date to plan around. On that day renewals double in frequency, and the [Chrome Root Program policy](https://googlechrome.github.io/chromerootprogram/crp/policy) requires every new public subscriber certificate to assert server authentication only. Any service that uses a public certificate as an mTLS client credential breaks at its first renewal after March 15, 2027, about twenty weeks from this post's date.

## Key takeaways

- Treat March 15, 2027 as the deadline: 100-day certificates, and no client authentication in new public certificates.
- Find every place a public certificate is used to authenticate a client before you automate anything, because automation will renew those certificates into a form that no longer works.
- Automate renewal with ACME and ACME Renewal Information, and make the deploy step automatic too. Renewal that stops at "certificate issued" is half done.

## The schedule, and what each step does to your workload

The Baseline Requirements ([section 1.2.2](https://github.com/cabforum/servercert/blob/main/docs/BR.md)) set three steps, each effective for certificates issued on or after the date:

| From | Maximum validity | Domain validation reuse | Renewals a year, renewing at two-thirds of lifetime |
|---|---|---|---|
| Before March 15, 2026 | 398 days | 398 days | about 1.4 |
| March 15, 2026 | 200 days | 200 days | about 2.7 |
| March 15, 2027 | 100 days | 100 days | about 5.5 |
| March 15, 2029 | 47 days | 10 days | about 11.6 |

The last column is our arithmetic, using the two-thirds renewal point that [Let's Encrypt](https://startwithidentity.com/vendors/pki/lets-encrypt/) recommends for clients without renewal guidance. It explains why the change is operational before it is cryptographic. A team that renews 300 certificates by hand made about 400 renewals a year at 398 days. At 100 days the same estate needs about 1,650, and at 47 days about 3,500.

The domain validation column matters as much. At 10 days of reuse in 2029, a CA will have to re-check control of your domain almost every time it issues. Any process where a person clicks a validation email or pastes a DNS record stops working at that point.

A certificate issued today at the 200-day maximum expires around mid-May 2027, so its replacement will already be a 100-day certificate. Most estates will feel the 2027 step within the first renewal cycle, whether or not anyone planned for it.

## The mTLS trap

The Chrome Root Program policy (version 1.8, last updated February 5, 2026) states the principle plainly: the Chrome Root Store "is solely relied upon for TLS server authentication." It requires that "all corresponding subscriber certificates issued on or after March 15, 2027, MUST include the extendedKeyUsage extension and only assert an extendedKeyUsage purpose of id-kp-serverAuth." New intermediate CAs disclosed from June 15, 2026 already had to be server-only.

Historically many public TLS certificates carried both serverAuth and clientAuth. Teams noticed, and used them as client certificates: a server presenting its public certificate to a partner API, a B2B integration that pins a public certificate as the caller's identity, a device or appliance doing mutual TLS to a cloud endpoint. Those are machine identities, and they rely on a property the public web PKI is removing.

Some CAs moved earlier. Let's Encrypt's [upcoming features page](https://letsencrypt.org/upcoming-features/) says it removed the TLS Client Authentication EKU from its default profile on February 11, 2026, and retired its temporary `tlsclient` profile on July 8, 2026. Its [May 2025 announcement](https://letsencrypt.org/2025/05/14/ending-tls-client-authentication) advised that many client authentication uses are better served by a private certificate authority. Check your own CA's date; it may be before March 2027.

The fix is to move client authentication to a [private PKI](https://startwithidentity.com/glossary/pki/) or a workload identity system, where you control the EKU, the lifetime and the trust anchor. [mTLS](https://startwithidentity.com/glossary/mtls/) between your own services never needed public trust in the first place. For partners, agree a private CA or a federation pattern now, because the change needs both sides.

## What to do, in order

Order matters here. Automating first can make things worse, because a renewal pipeline will happily replace a dual-use certificate with a server-only one and break a client connection at 3 a.m.

1. **Inventory every public certificate and where it is installed.** Certificate Transparency logs will list what CAs issued for your domains; your load balancers, CDNs, appliances and secret stores tell you where those certificates live. The [certificate lifecycle management guide](https://startwithidentity.com/guides/machine-identity/certificate-lifecycle-management-guide/) covers discovery.
2. **Flag every certificate used for client authentication.** Look for clientAuth in the EKU, then confirm actual use in TLS handshake logs or partner configuration. These go to a private CA before March 15, 2027.
3. **Give each certificate an owner.** A certificate is a [machine credential](https://startwithidentity.com/guides/fundamentals/what-is-machine-identity/), and the ownership problem from our [credentials nobody owns](https://startwithidentity.com/blog/credentials-nobody-owns/) post applies directly. An unowned certificate is the one that expires during a holiday.
4. **Automate issuance with ACME.** [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555.html) is widely supported by public CAs, and from March 15, 2027 the Chrome policy also requires every TLS server certificate profile offered by a Chrome-trusted CA to be issuable and renewable through an automation solution.
5. **Let the CA tell you when to renew.** ACME Renewal Information, [RFC 9773](https://www.rfc-editor.org/rfc/rfc9773.html) (June 2025), lets a CA suggest a renewal window, including early renewal when it has to revoke. Let's Encrypt's [45-day announcement](https://letsencrypt.org/2025/12/02/from-90-to-45) says a hardcoded 60-day renewal interval will no longer be enough.
6. **Automate deployment and reload.** A common failure comes after a successful renewal: the new certificate never reaches the process serving traffic. Test that every endpoint serves the new certificate within an hour of issuance.
7. **Automate domain validation.** DNS-based challenges through an API, with credentials scoped to the validation record only, so the automation does not become a way to take over your zone.
8. **Monitor expiry from outside.** An external check that alerts at a fixed number of days before expiry catches the cases where automation silently stopped.

Let's Encrypt's own timeline sets the pace for many estates: its default certificates move to 64 days on February 10, 2027 and to 45 days on February 16, 2028, ahead of the Baseline Requirements maximum.

October gave a live test of the same machinery. After a researcher showed that eight [eMudhra intermediate CA keys](https://startwithidentity.com/blog/2026-10-20-browsers-block-eight-emudhra-intermediate-cas-after-private-keys-leak/) could be computed, Mozilla and Chrome moved to distrust the emSign ECC root, and Chrome counted about 30,800 unexpired certificates chained to it. eMudhra estimated that about 97% of the certificates to replace had been issued through ACME, [The Hacker News reported](https://thehackernews.com/2026/10/emudhra-to-exit-global-ssltls-business.html) on October 22. Teams with that pipeline in place change the CA's directory URL and redeploy. Teams without it file tickets for every certificate. A forced change of issuer is the unscheduled version of a lifetime cut, and the same automation covers both.

## What this does not change

Private CAs that are not in browser root stores are outside both the CA/Browser Forum lifetimes and the Chrome EKU rule. Internal service certificates, device certificates and workload identities can keep whatever lifetime your own policy sets. For many of them, shorter is still better. Let's Encrypt notes that its short-lived certificates are valid for so little time that they do not need revocation information at all. The [workload identity](https://startwithidentity.com/guides/machine-identity/workload-identity-101/) model, where a platform issues short-lived credentials to software automatically, is the end state that makes lifetime limits irrelevant.

## Related reading

- [Certificate lifecycle management](https://startwithidentity.com/glossary/certificate-lifecycle/) and [X.509](https://startwithidentity.com/glossary/x509/) in the glossary
- [Machine identity management guide](https://startwithidentity.com/guides/machine-identity/machine-identity-management-guide/)
- [AD CS certificate template abuse](https://startwithidentity.com/techniques/adcs-certificate-template-abuse/), for what goes wrong when a private CA has weak issuance rules
- [Giving AI agents identities](https://startwithidentity.com/blog/giving-ai-agents-identities/), on short-lived, task-scoped credentials for software