---
title: "Certificates now last 200 days, then 47: one renewal a year becomes eight"
summary: "What the CA/Browser Forum's shorter TLS lifetimes mean for renewals, domain validation and automation, from the 200-day cap of 15 March 2026 to 47 days in March 2029."
url: https://www.thetechbag.com/blog/certificates-200-days-renewals-multiply
format: Analysis
desk: "Security operations"
published: 2026-03-16
facts_checked: 2026-03-16
author: TechBag (The TechBag Journal)
tags: ["TLS","certificates","CA/Browser Forum","SC-081","certificate lifecycle management","ACME","PKI","Let's Encrypt","domain validation","automation"]
cover: https://www.thetechbag.com/blog/covers/certificates-200-days-renewals-multiply.png
---

# Certificates now last 200 days, then 47: one renewal a year becomes eight

*What the CA/Browser Forum's shorter TLS lifetimes mean for renewals, domain validation and automation, from the 200-day cap of 15 March 2026 to 47 days in March 2029.*

Analysis · Security operations · By TechBag · Published 2026-03-16 · Facts checked 2026-03-16 · Canonical: https://www.thetechbag.com/blog/certificates-200-days-renewals-multiply

The short version

- Since 15 March 2026 no publicly trusted TLS certificate may be issued for more than 200 days. The cap falls to 100 days on 15 March 2027 and to 47 days on 15 March 2029. No certificate authority voted against it, and Apple, Google, Microsoft and Mozilla all voted for it.[1][2]
- A certificate renewed once a year now needs about two renewals a year, almost four from 2027 and almost eight from 2029. Renew with a safety margin and the 2029 figure is nearly twelve. The domain check behind each certificate shrinks from once every 398 days to once every 10.[2]
- Renewal by hand stops being a process and becomes a full-time job. The answer is ACME automation for every server that can run a client, an inventory of every certificate, and a plan for the appliances that can do neither.

Every website, API, VPN portal and load balancer that presents a certificate to a browser now runs on a shorter clock, and the clock gets shorter twice more. The question for anyone who owns those systems is practical. How many renewals will your team do in 2027 and 2029? Which of your certificates can renew themselves, and which ones still depend on someone remembering a date? And what does it cost to close that gap before 15 March 2027, the next step, a year from now?

## The first of three cuts: 398 days to 200, then 100, then 47

The schedule comes from the CA/Browser Forum, the body where certificate authorities and browser makers agree the rules for public TLS certificates. Apple proposed the ballot, SC-081v3; Sectigo, Google Chrome and Mozilla endorsed it. When voting closed on 11 April 2025, 25 certificate issuers voted yes, none voted no and five abstained (Entrust, IdenTrust, Japan Registry Services, SECOM and TWCA). All four certificate consumers, Apple, Google, Microsoft and Mozilla, voted yes.[1]

It is the fourth cut in eleven years. The Baseline Requirements capped certificates at 39 months from 2015, at 825 days from March 2018 and at 398 days from September 2020. The new steps are 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.[2] DigiCert moved early: it set 24 February 2026 as the day it would start issuing at most 199 days, a day under the cap, so its systems were settled before the deadline.[3]

**Figure: The longest a public certificate may last has fallen four times since 2015, and two more cuts are already scheduled**

*Maximum validity of publicly trusted TLS certificates, by the date each cap applies, 2015 to 2029*

| Date | Event | Detail |
| --- | --- | --- |
| 1 Apr 2015 | 39 months | Earlier five-year certificates end |
| 1 Mar 2018 | 825 days | Validation data reuse also 825 days |
| 1 Sept 2020 | 398 days | The one-year certificate |
| 11 Apr 2025 | SC-081v3 passes | 25 issuers yes, 0 no; 4 of 4 browsers yes |
| 15 Mar 2026 | 200 days | In force now |
| 15 Mar 2027 | 100 days | Domain validation reuse also 100 days |
| 15 Mar 2029 | 47 days | Domain validation reuse 10 days |

Source: CA/Browser Forum, Baseline Requirements v2.2.5, §1.2.2 Relevant Dates; Ballot SC-081v3 · as of 16 March 2026 · Caps apply to certificates issued on or after each date. 39 months is about 1,186 days.

Nothing you already hold breaks today. The cap applies when a certificate is issued, so a 398-day certificate bought in February runs to its printed expiry; the new limit reaches it at its next renewal. That is why the change feels quiet now and will not by the end of the year.

Our view

Our view: the browsers are trading your operations time for their users’ safety. A short-lived certificate limits how long a mis-issued certificate or a stolen private key stays useful, without relying on revocation checks that clients often skip. That is a reasonable trade, and it is not going to be reversed; plan for 47 days, not for another extension.

## One renewal a year becomes eight

The arithmetic is simple. Divide a year by the maximum lifetime and you get the fewest renewals a certificate can need: under one a year at 398 days, almost two at 200, almost four at 100 and almost eight at 47. Nobody sensible renews on the last day, though. Let’s Encrypt tells clients that cannot ask the CA when to renew to renew about two-thirds of the way through a certificate’s life.[4] On that schedule a 47-day certificate is replaced about every 31 days, nearly twelve times a year.

**Figure: At 47 days a certificate needs about eight renewals a year, and nearly twelve with a sensible safety margin**

*Renewals per certificate per year at each maximum validity, before and from 15 March 2026*

|  | Renew on the last day | Renew at two-thirds of life |
| --- | --- | --- |
| 398 days (to Mar 2026) | 0.9 | 1.4 |
| 200 days (now) | 1.8 | 2.7 |
| 100 days (Mar 2027) | 3.7 | 5.5 |
| 47 days (Mar 2029) | 7.8 | 11.6 |

Source: TechBag arithmetic on CA/Browser Forum Baseline Requirements v2.2.5 §6.3.2; two-thirds rule from Let's Encrypt, 2 December 2025 · as of 16 March 2026 · 365 divided by the renewal interval. Two-thirds schedule: renew when two-thirds of the lifetime has passed.

TechBag countTechBag count: what that means in hours

Take an organisation with 500 public certificates and assume a manual renewal costs one hour of staff time end to end: raise the request, pass validation, install the certificate on every server that uses it, restart, check. The hour is our assumption, not a measured figure. At the minimum renewal rate that is 459 hours a year at 398 days, 913 at 200, 1,825 at 100 and 3,883 at 47. The last figure is about two people doing nothing else all year, before a single renewal is missed.

The hours are not the real risk. Each renewal is a chance to miss one, and a missed public certificate is an outage the moment it expires: browsers refuse the connection, and API clients fail without any warning to a person. Eight chances a year per certificate, instead of one, is what turns a calendar reminder into a liability.

## The quieter cut: proving you own the domain every ten days

Before a CA issues a certificate it must check that the applicant controls the domain, by finding a value it chose in a DNS record, on the website or in a reply to an email. The rules let a CA reuse that check for later certificates for a set period. Until 15 March 2026 that period was 398 days; it is now 200, falls to 100 in March 2027 and to 10 days in March 2029. Checks of the organisation’s identity, used in OV and EV certificates, may be reused for 398 days, down from 825.[1][2]

**Figure: Domain validation shrinks far more than the certificate itself: from 398 days to 10**

*Maximum validity and maximum reuse of validation data, in days, before 15 March 2026 and from 15 March 2029*

|  | Before 15 March 2026 | From 15 March 2029 | Change |
| --- | --- | --- | --- |
| Certificate validity | 398 | 47 | -88% |
| Domain validation reuse | 398 | 10 | -97% |
| Organisation identity reuse | 825 | 398 | -52% |

Source: CA/Browser Forum, Ballot SC-081v3 and Baseline Requirements v2.2.5, §4.2.1 and §6.3.2 · as of 16 March 2026

This is the change that breaks semi-manual processes. Many teams validate a domain once a year by approving an email sent to admin@ or webmaster@, then reissue freely for twelve months. From 2029 that approval would be needed for almost every certificate. And the email route itself is closing: the Baseline Requirements say CAs should not use the “constructed email” method from 15 March 2026 and must not rely on it from 15 March 2028, and a November 2025 ballot, SC090, phases out the remaining email- and phone-based methods.[2] What survives is a value placed in DNS or on the web server, which is exactly what software can do on its own. Let’s Encrypt plans to cut its own reuse period from 30 days to 7 hours by February 2028.[4]

## What automation is, and what it costs

The automation is a published standard. ACME, the Automatic Certificate Management Environment, became IETF RFC 8555 in March 2019.[5] A small client on the server asks a CA for a certificate, proves control of the domain by answering the CA’s challenge, installs what it receives and does it again before expiry. A 2025 extension, ACME Renewal Information (RFC 9773), lets the CA tell the client when to renew, which matters when a CA has to replace certificates early.[6][4]

**Figure: ACME turns a renewal into four machine steps that repeat without a ticket**

*How an ACME client obtains and renews a certificate, as standardised in RFC 8555 (2019) and RFC 9773 (2025)*

1. 01OrderThe client on the server asks the CA for a certificate for its names.
2. 02ProveThe CA sets a challenge: a file on the web server or a TXT record in DNS. The client places it.
3. 03InstallThe CA issues; the client installs the certificate and reloads the service.
4. 04RepeatARI tells the client when to renew; without it, renew at about two-thirds of the lifetime.

Source: IETF RFC 8555; IETF RFC 9773; Let's Encrypt, 2 December 2025 · as of 16 March 2026

The protocol costs nothing, and the cheapest certificates are free: Let’s Encrypt issues 90-day certificates today and plans 45-day ones as its default by February 2028, ahead of the industry cap.[4] Cloud providers bundle renewal into their own services. AWS Certificate Manager gives public certificates at no charge to use inside AWS’s load balancers and CDN. When AWS launched certificates you can export to your own servers in June 2025, it priced them at $15 per name and $149 per wildcard, for a 395-day certificate paid once for its lifetime.[7]

Our view

Our view: read any price quoted “per certificate” as a price per issuance until the seller says otherwise. A fee paid once per 395-day certificate is paid about eight times as often at 47 days. Ask whether reissues inside a subscription are included, and get the answer in the contract.

The paid layer is certificate lifecycle management (CLM): software that discovers every certificate on the network and in the cloud, records who owns it and when it expires, enforces which CAs and key sizes are allowed, and pushes renewals to load balancers and servers through connectors. The enterprise suites are generally sold on quote and priced by the number of certificates managed. You need one when the inventory is the problem: several CAs, hundreds of certificates, nobody sure where each is installed. For a team with a few dozen certificates on servers that can run an ACME client, the free tools are enough.

## The certificates no script reaches: appliances

The hardest certificates are the ones inside boxes: firewall and VPN portals, load balancers, storage and server management consoles, printers, cameras. Many are installed by pasting a file into a web console, which no ACME client can do. Expired certificates inside equipment have taken down large networks before. In December 2018 Ericsson traced an outage at mobile operators in several countries to “an expired certificate in the software versions installed with these customers”, in its packet-core software.[9]

**Figure: Seven in ten organisations surveyed had a certificate-related outage in a year, before the first cut**

*Share of 1,200 security leaders in six countries reporting a certificate-related outage in the previous 12 months, survey published 2025*

72%

Had a certificate-related outage in the previous 12 months

Source: CyberArk, 2025 State of Machine Identity Security Report, via CSO Online (sponsored content, 1 April 2025) · as of 1 April 2025 · A vendor survey: CyberArk sells certificate lifecycle software. Countries: US, UK, Australia, France, Germany, Singapore; India was not surveyed.

Some appliances have caught up. FortiOS 7.0 lets a FortiGate obtain and renew its own Let’s Encrypt certificate over ACME, with limits: the interface must be public with a DNS name, ports 80 and 443 must not be forwarded elsewhere, and the certificate covers the device’s own hostname only, with no wildcards.[8] Check each model’s admin guide for the same feature rather than assuming it. Where it is missing there are three routes: a lifecycle tool with a connector for that vendor’s API, a reverse proxy or load balancer that renews automatically in front of the device, or, for a console only staff ever reach, a certificate from your own private CA, which the 200-day rule does not cover.

**In order, before 15 March 2027:**

1. **Count them.** List every public certificate, where it is installed, who owns it and how it renews today. Certificate Transparency logs show every public certificate issued for your domains, including ones nobody told IT about.
2. **Automate the easy majority.** Web servers, Kubernetes ingress and cloud load balancers move to ACME or the cloud provider’s managed certificates first.
3. **Move validation to DNS.** Replace email approvals with DNS-based validation that your automation can answer.
4. **Sort the appliances.** Mark each one ACME-capable, API-capable or neither, and put the “neither” list into the next refresh or behind a proxy.

If you are buying this in India

**It applies in full, through the browsers.** The cap is a CA/Browser Forum rule, not an Indian regulation, and it binds every CA that wants its certificates trusted by Chrome, Safari, Edge and Firefox, including certificates sold to Indian banks, government portals and online businesses by Indian resellers. We found no Indian regulator that has set a separate rule on certificate lifetimes; the obligation arrives through the trust stores.

**What it does not touch.** The Baseline Requirements govern publicly trusted TLS server certificates only.[2] Digital signature certificates issued under the IT Act by CCA-licensed CAs, the ones used to sign GST, income-tax and MCA filings, are outside this ballot, as are certificates from an internal CA such as Active Directory Certificate Services and code-signing certificates.

TechBag countTechBag count: the same 500 certificates in rupees

At an assumed fully loaded cost of ₹800 per IT hour (our assumption) and one hour per manual renewal, 500 public certificates cost ₹3,67,200 a year in staff time at 398 days and ₹31,06,400 a year at 47 days. Any paid certificate, ACME-capable certificate plan or lifecycle subscription bought in India attracts 18% GST on top; compare quotes inclusive of it, and over three years rather than one, because the renewal count is what changes.

How we did this

Figures as of 16 March 2026

The schedule, validation reuse periods and email-method sunset are read from the CA/Browser Forum’s Baseline Requirements v2.2.5 (25 February 2026), §1.2.2, §3.2.2.4.4, §4.2.1 and §6.3.2; the vote and sponsors from the SC-081v3 ballot page. Renewals per year are 365 divided by the maximum lifetime, or by two-thirds of it for the safety-margin series, rounded to one decimal; the labour and rupee figures multiply those rates by 500 certificates, one hour per renewal and ₹800 per hour, all three our assumptions. Prices are the vendors’ own at the dates given. The outage share is a vendor survey and is labelled as one; it has no India sample. TechBag’s own vendor pages on certificate lifecycle and PKI products were not yet published on this date and are not used.

Spotted an error? Write to us; corrections are published at the foot of the piece.

Sources

1. [CA/Browser Forum, Ballot SC-081v3: Introduce schedule of reducing validity and data reuse periods (proposer, endorsers, vote)](https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/) — 11 April 2025
2. [CA/Browser Forum, Baseline Requirements for Publicly-Trusted TLS Server Certificates, version 2.2.5 (§1.2.2, §3.2.2.4.4, §4.2.1, §6.3.2)](https://cabforum.org/working-groups/server/baseline-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.5.pdf) — 25 February 2026
3. [DigiCert, TLS/SSL certificate validity FAQ (199-day maximum from 24 February 2026, 18:00 UTC)](https://www.digicert.com/faq/tls-ssl-certificate-validity) — undated; written ahead of 24 February 2026
4. [Let's Encrypt, Decreasing certificate lifetimes to 45 days (schedule, authorization reuse, ARI, two-thirds renewal)](https://letsencrypt.org/2025/12/02/from-90-to-45/) — 2 December 2025
5. [IETF, RFC 8555: Automatic Certificate Management Environment (ACME)](https://www.rfc-editor.org/info/rfc8555) — March 2019
6. [IETF, RFC 9773: ACME Renewal Information (ARI) Extension](https://www.rfc-editor.org/info/rfc9773) — 2025
7. [AWS, AWS Certificate Manager introduces exportable public SSL/TLS certificates to use anywhere](https://aws.amazon.com/about-aws/whats-new/2025/06/aws-certificate-manager-public-certificates-use-anywhere/) — 17 June 2025
8. [Fortinet, FortiOS 7.0.0 New Features: ACME certificate support](https://docs.fortinet.com/document/fortigate/7.0.0/new-features/822087/acme-certificate-support) — FortiOS 7.0.0, 2021
9. [Ericsson, Update on software issue impacting certain customers](https://www.ericsson.com/en/press-releases/2018/12/update-on-software-issue-impacting-certain-customers) — 6 December 2018
10. [CSO Online (BrandPost sponsored by CyberArk), The urgent reality of machine identity security in 2025: 72% had a certificate-related outage](https://www.csoonline.com/article/3951921/the-urgent-reality-of-machine-identity-security-in-2025.html) — 1 April 2025

**Disclosure.** TechBag is a software reseller: it earns a margin when a reader buys through it, including from vendors named here. The analysis is TechBag’s own; no vendor paid for or saw this piece before publication. Facts are labelled reported, TechBag count or our view.

Go deeper on TechBag

- [Entrust Certificate Lifecycle](https://www.thetechbag.com/entrust/entrust-certificate-lifecycle) — discover every certificate, then renew over ACME and EST
- [Entrust PKI](https://www.thetechbag.com/entrust/entrust-pki) — a private CA for the internal certificates the 200-day rule does not cover
- [Encryption and rights management guide](https://www.thetechbag.com/browse/data-security-privacy/encryption-rights) — where certificate and key management sit among the encryption tools