TLS certificate lifetimes: the 200, 100 and 47-day schedule explained

Since March 15, 2026, a publicly trusted TLS certificate can be valid for at most 200 days. The maximum falls to 100 days for certificates issued on or after March 15, 2027, and to 47 days from March 15, 2029. The schedule comes from CA/Browser Forum ballot SC-081v3, which also shortens how long a certificate authority may reuse a domain validation, down to 10 days by 2029.

The rules below are taken from the current TLS Baseline Requirements (version 2.3.1) as of October 2026.

Maximum certificate validity by issue date

• Issued before March 15, 2026: up to 398 days.
• Issued from March 15, 2026 until March 14, 2027: up to 200 days.
• Issued from March 15, 2027 until March 14, 2029: up to 100 days.
• Issued on or after March 15, 2029: up to 47 days.

At each step the Baseline Requirements also recommend staying one day below the maximum (397, 199, 99 and 46 days). A day is counted as exactly 86,400 seconds, and any extra fraction or leap second counts as an additional day, so CAs are told not to issue for the full maximum by default.

The limits apply by issuance date. A 398-day certificate issued in early March 2026 stays valid until it expires, and nothing has to be replaced on March 15, 2027. Each change hits at your first renewal after the cutoff.

Validation reuse periods are shrinking too

Lifetime is only half of the change. When a CA issues a certificate, it may rely on an earlier check instead of repeating it, but only within a set window:

• Domain name and IP address validation: 398 days before March 15, 2026; 200 days from that date; 100 days from March 15, 2027; 10 days from March 15, 2029.
• Subject identity information, such as the organization details in OV and EV certificates: 825 days before March 15, 2026 and 398 days since.

For teams that prove domain control by hand, the 10-day window matters more than the 47-day lifetime. From 2029, nearly every issuance will need a fresh validation unless that step is automated.

Who decided, and why

The CA/Browser Forum brings together certificate authorities and the browser and operating system vendors that decide which CAs to trust. Ballot SC-081v3 passed in April 2025. Among certificate issuers, 25 voted yes, none voted no and five abstained; all four certificate consumers, Apple, Google, Microsoft and Mozilla, voted yes.

The ballot argues that certificates containing information that was once correct but no longer is, for example after a domain changes hands, pose a real risk to site owners and users. Shorter lifetimes and reuse periods limit how long such stale data can sit in a valid certificate. It also argues that revocation checking through CRLs and OCSP does not protect users reliably at internet scale, so shorter lifetimes offer protection that does not depend on revocation working.

What it means for renewal workload

The arithmetic is simple. A 398-day certificate needed roughly one renewal a year. At 200 days that becomes at least two, at 100 days at least four, and at 47 days at least eight, before counting the safety margin most teams leave before expiry. A renewal process that depends on a ticket and someone copying files to a server stops being workable somewhere along that path.

The limits cover publicly trusted TLS server certificates governed by the Baseline Requirements. Certificates from a private, internal CA follow whatever policy the organization running it sets, which is one reason some teams move internal-only hostnames to a private PKI.

Let's Encrypt is moving faster

Let's Encrypt already issues 90-day certificates and announced in December 2025 that it will reach 45 days ahead of the industry deadline:

• May 13, 2026: the opt-in tlsserver ACME profile was due to switch to 45-day certificates, and Let's Encrypt's profile documentation now lists a 45-day validity period for it.
• February 10, 2027: the default classic profile moves to 64-day certificates, and authorization reuse drops from 30 days to 10 days.
• February 16, 2028: the classic profile moves to 45-day certificates with a 7-hour authorization reuse period.

Let's Encrypt recommends that ACME clients use ACME Renewal Information (ARI), which tells a client when to renew, and warns that a hard-coded 60-day renewal interval will no longer be enough. Without ARI, it suggests renewing about two-thirds of the way through a certificate's lifetime. Renewals are exempt from its rate limits on new orders, so shorter lifetimes alone should not trigger rate limiting, according to a February 2026 post.

A validation method designed for automation

Ballot SC-088 added a DNS validation method based on a persistent TXT record to the Baseline Requirements in late 2025. Instead of publishing a fresh token for every validation, the domain owner publishes a standing record that names the CA and the specific ACME account allowed to issue. Let's Encrypt calls its implementation DNS-PERSIST-01: the record lives at _validation-persist under the domain name and can optionally cover wildcards or carry an expiry time. In February 2026, Let's Encrypt said it was targeting a production rollout in the second quarter of 2026. The catch, Let's Encrypt notes, is that the record keeps authorizing issuance for as long as it exists, so the security of the ACME account key matters most.

What to do before March 15, 2027

1. Inventory every public certificate. Certificate Transparency logs show what has been issued for your domains, including certificates on appliances, load balancers and SaaS custom domains that are easy to forget.
2. Automate issuance and deployment. Use ACME or your CA's API for both renewal and installation; automation that stops at issuance still leaves a manual step.
3. Remove fixed renewal intervals. Renew based on remaining lifetime or ARI rather than a calendar entry.
4. Monitor expiry yourself. Let's Encrypt stopped sending expiration emails in 2025, so alerts have to come from your own monitoring.
5. Plan for 10-day validation reuse. Decide whether HTTP-01, DNS-01 or a persistent DNS record fits each domain.
6. Separate internal names. Hosts that never face the public internet can move to a private CA with its own policy.

Certificate and PKI changes are covered in our security section, and ACME clients and automation tools in DevOps tooling.

Frequently asked questions

What is the maximum SSL certificate validity in 2026?

Publicly trusted TLS certificates issued on or after March 15, 2026 can be valid for at most 200 days. Certificates issued before that date could still run up to 398 days.

When do 100-day certificates start?

The 100-day maximum applies to certificates issued on or after March 15, 2027. It stays in place until March 15, 2029, when the limit drops to 47 days.

When do 47-day SSL certificates become mandatory?

From March 15, 2029. Certificates issued on or after that date cannot be valid for more than 47 days, and domain validation can be reused for only 10 days.

Do I have to replace existing certificates when the limit changes?

No. The limits apply to the issuance date, so a valid certificate keeps working until it expires. The shorter maximum applies at your next renewal.

Do the new limits apply to internal or private CA certificates?

No. The CA/Browser Forum Baseline Requirements cover publicly trusted TLS server certificates. Certificates from a private CA follow the policy set by the organization that runs it.