TLS certificate lifetimes: 200 days, then 100, then 47

Public TLS certificates are on a published step-down. The maximum lifetime is about 200 days for certificates issued now. It becomes 100 days in March 2027 and 47 days in March 2029. Forty-seven days is not the maximum today. If a chart, a vendor blog, or a slide treats 47 as the current cap, it is wrong.

This page is the schedule and the operational consequence. It is not a prediction that every certificate in your fleet already lasts 200 days. Authorities can issue shorter certificates. Existing certificates keep the expiry they were born with.

The schedule that is in force

CA/Browser Forum ballot SC-081v3 set a timetable in the Baseline Requirements for publicly trusted TLS:

• Certificates issued on or after 15 March 2026 and before 15 March 2027: maximum validity of 200 days. A CA can choose a shorter lifetime.
• Certificates issued on or after 15 March 2027: maximum validity of 100 days.
• Certificates issued on or after 15 March 2029: maximum validity of 47 days.

The ballot also shortens how long domain-control evidence can be reused, on its own timetable, down to 10 days in the final phase. The separate validation reuse requirements describe that schedule. A persistent DNS delegation can support fresh challenges; it does not make validation permanent. See ACME DNS validation.

These ceilings apply to certificates issued on or after each date. They do not rewrite a certificate that is already installed.

What 200 days means in October 2026

As of this guide's October 2026 update, the public ceiling is the first step. A certificate issued this month should not use the old 398-day maximum. Annual billing can still exist, but that does not make each issued certificate valid for a year. Separate your subscription term from the certificate's actual validity.

Two hundred days is still long enough to hide a manual process. Teams renew, it works, and the ticket feels rare. The risk is building the next year of automation on the assumption that this cadence holds.

What changes on 15 March 2027

Certificates issued from that date top out at 100 days. A name you used to touch twice a year becomes a name you touch about every quarter, plus overlap so you are not renewing on the expiry morning.

One hundred days is where spreadsheet renewals get late. The person who owned the row is in a project, the firewall change window is monthly, and the certificate expires between windows. See certificate lifecycle management vs spreadsheet renewals.

What 47 days is, and what it is not

From 15 March 2029, public TLS issued that day or after is capped at 47 days. That is roughly a month, with a small buffer. It is a scheduled change. It is two and a half years out from this page. Calling it the current maximum scares people with the wrong number and trains them to ignore the 100-day step, which arrives first.

At a 47-day cap, a manual install on every firewall and every IIS binding is not a process. It is a queue. The work that has to be automatic by then is the install, not the reminder email. Automatic certificate deployment is that work.

What IT teams should do now

Do this against the 200-day ceiling, so the 100-day date is a cadence change and not a project start.

• Inventory the names that are public TLS, including appliance portals and VPN hostnames. The website is the easy row.
• Separate domain renewal, certificate expiry, and "we proved we control this domain." They are three clocks. Renewing the domain name at the registrar does not renew the certificate.
• Measure how many installs were done by hand in the last renewal. That number is the backlog you will multiply.
• Automate renewal and the install for the names you would hate to explain. Keep a rollback. A shorter certificate that you cannot undo is a faster outage.
• Alert when renewal fails, not only when expiry is close. The public outage reports linked in the renewal automation guide illustrate why a failure notification and an independent endpoint check both matter.

What Certonomy does with this schedule

The product renews and installs. It does not change the CA/Browser Forum timetable, and it is not the only software that can renew a certificate. The path is domain validation with a CNAME, an on-site agent that creates the key and keeps it, an ACME order, then an install that is checked on the live service and rolled back if the check fails.

Platforms at launch are FortiGate, IIS, Windows Server, and RDS, Palo Alto PAN-OS and GlobalProtect, SonicWall, Sophos, WatchGuard, NGINX, Apache, and HAProxy. The checklist is in device certificate auto-renew.

See how it works if you want that loop instead of a reminder tied to a 398-day year that public TLS no longer has.