# Ballot SC-081: TLS certificates fall to 47 days by 2029

> Ballot SC-081v3 cuts maximum TLS certificate validity from 398 to 200, 100 and finally 47 days between 2026 and 2029, and shortens validation reuse.

Source: https://ssl.sh/news/ballot-sc-081-shorter-certificate-lifetimes/
Last updated: 2026-11-10

Ballot SC-081v3, adopted by the CA/Browser Forum on 11 April 2025, cuts the maximum lifetime of publicly trusted TLS certificates from 398 days to 47 days by March 2029. The Apple-proposed ballot also cuts domain validation reuse to 10 days. Each step applies to the issuance date, so certificates already in use are not shortened.

## What happened

The ballot passed with no votes against. Voting ran from 4 to 11 April 2025: certificate issuers voted 25 in favour with 5 abstentions, and certificate consumers, the browser and operating system vendors, voted 4 to 0. The ballot amends the [Baseline Requirements](https://ssl.sh/glossary/baseline-requirements/), the rulebook every publicly trusted [certificate authority](https://ssl.sh/glossary/certificate-authority/) must follow.

The maximum [validity period](https://ssl.sh/glossary/validity-period/) and the reuse period for [domain control validation](https://ssl.sh/glossary/dcv/) now depend on when a certificate is issued:

| Issued | Maximum validity | Domain validation reuse |
|---|---|---|
| Until 2026-03-14 | 398 days | 398 days |
| From 2026-03-15 | 200 days | 200 days |
| From 2027-03-15 | 100 days | 100 days |
| From 2029-03-15 | 47 days | 10 days |

Subject identity information validated for [OV](https://ssl.sh/glossary/ov-certificate/) and [EV](https://ssl.sh/glossary/ev-certificate/) certificates can still be reused for up to 398 days, so organisation checks do not have to be repeated every time a certificate is replaced. The 398-day ceiling that SC-081 replaces had applied since September 2020.

## Who is affected

Every website, API or mail server on a publicly trusted certificate is affected. Teams that renew by hand once a year feel it first: from March 2026 a one-year purchase needs at least two certificates, and a 47-day maximum means at least eight issuances a year.

The shorter reuse period ends one-off domain checks. From 2029 a CA can rely only on a domain check that is at most 10 days old, so in practice every renewal needs a fresh [HTTP-01](https://ssl.sh/glossary/http-01/) or [DNS-01](https://ssl.sh/glossary/dns-01/) challenge. DNS-based validation that depends on someone adding a TXT record by hand will not scale.

Users of [ACME](https://ssl.sh/glossary/acme/) clients that already renew automatically, which covers most Let's Encrypt setups, mainly need to confirm that automation really runs everywhere, including load balancers, CDNs and appliances. Let's Encrypt's own move to 45-day certificates is covered in [a separate report](https://ssl.sh/news/lets-encrypt-45-day-certificates/). Certificates from a [private CA](https://ssl.sh/glossary/private-ca/) are out of scope.

## What you should do

The deadline that matters most is the 100-day step on 2027-03-15 (upcoming).

1. Inventory every public certificate and note how each one is renewed.
2. Move manual renewals to ACME or your provider's automation before that date.
3. Monitor expiry independently of the renewal system.

Check what a server currently serves:

```bash
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates
```

Test that ACME renewal works without waiting for expiry:

```bash
sudo certbot renew --dry-run
```

Use the [validity calculator](https://ssl.sh/tools/validity-calculator/) to see the maximum lifetime for a given issuance date and the [SSL checker](https://ssl.sh/tools/ssl-checker/) to confirm what is deployed. The [certificate validity timeline](https://ssl.sh/timeline/certificate-validity/) shows the full history, and the [47-day certificates guide](https://ssl.sh/learn/47-day-certificates/) covers automation in depth.