SSL certificates are getting shorter: the 200, 100 and 47-day roadmap

Think about the way good coffee is sold. Some shops let you pay for a whole year of beans up front, but they do not hand you twelve months of coffee on day one. They send fresh bags on a schedule, because beans that sit in the cupboard for a year go stale. You pay once, and the freshness arrives in smaller portions.

SSL/TLS certificates are moving to that same model. Your subscription can still cover a year or more, but each certificate inside it (the file your server actually shows to browsers) now has a much shorter "best before" date. The industry has agreed on a schedule, and we are already past the first step.

In this guide we will walk through what changed, what comes next, why browsers and certificate authorities agreed to it, and what you can do this week so the next deadline does not surprise you. The technical claims are linked to their published sources throughout the article.

The short version

• Since March 15, 2026, a newly issued public TLS certificate can be valid for at most 200 days. Before that, the limit was 398 days.
• From March 15, 2027, the maximum drops to 100 days.
• From March 15, 2029, the maximum drops to 47 days.
• The time a certificate authority (CA) can reuse a previous domain check is shrinking too: 200 days now, 100 days from March 15, 2027, and 10 days from March 15, 2029.
• The time a CA can reuse organization identity checks (the business details behind OV and EV certificates) dropped from 825 days to 398 days on March 15, 2026.
• Certificates issued before a deadline keep working until their own expiry date. The rules apply to certificates issued on or after each date.

These figures come from the CA/Browser Forum’s Ballot SC-081v3 and the resulting TLS Baseline Requirements.

Who decides how long a certificate lasts?

A certificate is a bit like the ID badge a website shows every time someone visits. The badge is issued by a certificate authority, such as Sectigo or Let's Encrypt. Browsers and operating systems (Chrome, Safari, Firefox, Windows and others) decide which CAs they trust.

These two groups meet in the CA/Browser Forum, which publishes the Baseline Requirements: the rulebook every publicly trusted CA must follow for website certificates.

In April 2025 the Forum voted on Ballot SC-081v3, titled "Introduce Schedule of Reducing Validity and Data Reuse Periods." The motion was proposed by Apple and endorsed by Sectigo, Google Chrome and Mozilla. According to the Forum's published results, 25 certificate issuers voted yes, none voted no and 5 abstained. All four certificate consumers that voted (Apple, Google, Microsoft and Mozilla) voted yes. The ballot passed.

A little history helps here. Apple's support page explains that TLS certificates issued on or after September 1, 2020 must not be valid for more than 398 days to be trusted on Apple devices. That 398-day limit was the norm for the next few years. SC-081 is the plan for going below it.

The roadmap, step by step

Here is the schedule as written in section 6.3.2 of the current Baseline Requirements:

The rulebook also says CAs should stay one day below each limit (397, 199, 99 and 46 days), because it counts a "day" as exactly 86,400 seconds and any extra second counts as another day. That is why you will see some CAs talk about 199-day certificates rather than 200. Sectigo, for example, says all certificates it issues or reissues are valid for no longer than 199 days, and that it began enforcing this on March 12, 2026, a few days ahead of the official date.

The second, quieter change: validation reuse

When you order a certificate, the CA first checks that you really control the domain. This is called domain control validation (DCV). You might add a DNS TXT record, upload a small file to your site, or answer an email.

Until now, a CA could "remember" that successful check and reuse it for a long time. SC-081 shortens that memory:

For the business details checked for OV and EV certificates (the Baseline Requirements call this "Subject Identity Information"), the reuse period went from 825 days to 398 days on March 15, 2026. No further step is scheduled for that one in the current text.

In plain words: by 2029, nearly every certificate you get will need a fresh domain check from the last few days. Your business identity check for OV or EV will need refreshing roughly once a year.

Why is this happening?

The ballot and Google's Chrome Root Program give several reasons. Here are the main ones in everyday language.

1. A certificate is a snapshot, and snapshots get old. The ballot describes certificates as "representations of a point in time state of reality." On the day it is issued, everything in it is correct. As time passes, a domain can be sold, a server can be handed to a new team, or a private key can leak. A shorter lifetime means an out-of-date certificate stops working sooner, without anyone having to do anything.

2. Revocation does not work well enough. In theory, a bad certificate can be "revoked" (cancelled) early. In practice, the ballot says revocation services such as CRLs and OCSP "do not adequately protect relying parties at the current scale of the internet," citing privacy, performance and reliability problems. A short expiry date is a safety net that works even when revocation fails.

3. Mistakes happen, and short lifetimes limit the damage. Sometimes a CA issues a certificate it should not have. Shorter lifetimes and fresher validation reduce how long such mistakes can stay in circulation.

4. The web needs to be able to change its locks quickly. When an encryption algorithm becomes weak, every certificate using it has to be replaced. The Chrome Root Program notes that a shorter maximum lifetime supports "smoothly, and when necessary, swiftly" moving to new practices. That matters more as the industry prepares for post-quantum cryptography.

5. Automation becomes the normal way. Both the ballot and Chrome say frequent renewal pushes the ecosystem toward automated tools, which tend to be more reliable than calendar reminders.

What Let's Encrypt is doing

Let's Encrypt, the free and fully automated CA, has always issued short certificates (90 days). It has published its own plan for going shorter:

• May 13, 2026: its opt-in tlsserver ACME profile was scheduled to switch to 45-day certificates for early adopters and testing.
• February 10, 2027: its default classic profile is scheduled to issue 64-day certificates with a 10-day authorization reuse period.
• February 16, 2028: the classic profile is scheduled to move to 45-day certificates with a 7-hour authorization reuse period.

Let's Encrypt also made 6-day certificates generally available on January 15, 2026. They are valid for 160 hours, are opt-in through a shortlived profile, and it says it has "no plan to make them the default at this time."

Two other changes are worth knowing about:

• OCSP has ended at Let's Encrypt. It turned off its OCSP service on August 6, 2025, and now publishes revocation information only through CRLs.
• No more expiry emails. Let's Encrypt stopped sending expiration notification emails on June 4, 2025. If you relied on those emails, you need your own monitoring now.

Let's Encrypt is also working on a new validation method, DNS-PERSIST-01. You publish one DNS TXT record once, instead of changing a record at every renewal. The CA/Browser Forum approved the method (Ballot SC-088v3) in October 2025. In February 2026, Let's Encrypt said it planned staging for late Q1 2026 and production "some time in Q2 2026." Check its current documentation before counting on it.

If you want to understand ACME itself (the protocol behind all of this automation), our guide on automated SSL/TLS certificates and the ACME protocol goes step by step.

What this means for you today

It is September 30, 2026, so we are in the 200-day phase. Here is what that looks like in practice.

Your certificate is no longer a once-a-year chore. Any certificate issued since mid-March 2026 lasts about six and a half months at most. If you still install certificates by hand, you now do it at least twice a year. From March 2027, you will do it roughly every three months.

Your subscription and your certificate are two different things. This is the coffee subscription again. Sectigo's guidance explains that its 1- to 5-year TLS subscriptions are still available, but each issued certificate is valid for up to 199 days. You reissue during the term to get the next certificate, and the final certificate only covers the time left in your purchased term. So a 1-year order now works like a multi-year one used to: one purchase, several certificates.

The next deadline is less than six months away. March 15, 2027 halves the maximum again, to 100 days, and halves domain validation reuse to 100 days as well.

Some validation methods are on their way out. The current Baseline Requirements say the email-based domain validation methods (email to a constructed address like admin@ or webmaster@, and email to contacts published in DNS) "SHOULD NOT" be used from March 15, 2026. From March 15, 2028, CAs must not rely on them at all. Two phone-based methods face the same end on March 15, 2027. If your routine is "click the link in the approval email," now is a good time to switch to a DNS TXT record or a file-based check.

DNSSEC now matters for validation. Since March 15, 2026, CAs must perform DNSSEC validation on the DNS lookups they use for domain validation and CAA checks. A DNSSEC error cannot be treated as permission to issue. If you sign your zone, make sure it is signed correctly. Our guide on how DNSSEC works explains the basics.

How our SSL certificates fit this roadmap

Our SSL Certificates currently offers three Sectigo certificates:

Current pricing and available terms are confirmed on our SSL Certificates page before purchase. All three options include free reissues and support encryption up to 256 bits.

A one-year or multi-year order does not require buying a new certificate every 47 days. The order term continues, while each certificate issued within that term must be reissued and reinstalled more often. Reissues are included with these Sectigo certificates at no additional certificate cost.

Here is how the roadmap touches each option:

• PositiveSSL (DV): Validation is quick, but it has to be repeated more often as the reuse window shrinks. A DNS TXT record or file check is easier to repeat than an email approval, especially with email methods being phased out.
• EssentialSSL Wildcard: One certificate covers shop., app., login. and other first-level subdomains, so there is one certificate to reissue instead of many. The catch is that a wildcard usually lives on several servers, and each one needs the new file every time. Keep a list of every place it is installed.
• PositiveSSL EV: EV validation includes checks on the legal business, its address and an approved phone callback. Under the new rules, those business details can be reused for up to 398 days. The domain check still follows the shorter schedule. Keeping your company records consistent and up to date makes the yearly refresh smoother.

Our SSL FAQ covers the basics: what DV, OV and EV mean, what happens when a certificate expires, and how to validate your domain (email, DNS TXT record or a file on your server). Renewal timing depends on the billing and certificate workflow selected for the product, so review renewal notices early. If you are not sure which certificate fits, our guide on which SSL certificate you need can help, and our support team can talk it through with you.

How to prepare: a friendly checklist

1. Make an inventory. Write down every certificate you have: which domain, where it is installed (web server, load balancer, CDN, mail server), who is responsible, and when it expires. Sectigo lists certificate discovery as the first step, and it applies to small sites too.

2. Automate where you can. ACME clients can request, validate, install and renew certificates on a schedule. Many control panels and servers support ACME. Let's Encrypt recommends that clients use ACME Renewal Information (ARI) (standardized as RFC 9773), which lets the CA tell your client when to renew. Chrome's Root Program also encourages wider use of ARI.

3. Don't hard-code "renew at 60 days." Let's Encrypt warns that a fixed 60-day renewal interval won't work with 45-day certificates. It suggests renewing about two-thirds of the way through a certificate's lifetime. Sectigo suggests treating the current 199-day certificates as 6-month certificates and renewing around the 180-day mark to leave recovery time.

4. Pick a validation method you can repeat easily. DNS-based validation works well with automation and is the only option for wildcards with many ACME CAs. If you need a refresher on TXT and CNAME records, see DNS records explained.

5. Remember the edges. If your site sits behind a CDN, there may be a certificate at the edge and another at your origin server, and both must stay valid. Our guide on CDNs for domain owners explains how the pieces connect.

6. Set up independent monitoring. Use an external check that alerts you before any certificate expires. Don't rely on one reminder email. Let's Encrypt no longer sends them at all.

7. For OV and EV, plan an annual identity refresh. Keep your legal name, address and phone details consistent everywhere the CA might check them, so the yearly revalidation goes smoothly.

8. Look for systems that cannot automate. Older appliances, embedded devices and hand-configured servers are where short lifetimes cause trouble. Find them now, while you still have 200 days, not 47.

If you want a refresher on what the certificate does during the connection, how SSL works covers encryption, certificates and TLS in plain language.

Frequently asked questions

Does my current certificate stop working on the next deadline? No. The limits apply to certificates issued on or after each date. A certificate issued before March 15, 2026 keeps its original expiry date.

Do I have to buy a new certificate every 47 days in 2029? Not necessarily. You can still buy a subscription for a year or more. The certificate covered by that order is reissued and reinstalled more often, without requiring a new purchase every 47 days.

Is 47 days the final number? It is the last step in the current SC-081 schedule. Nothing further has been adopted. Let's Encrypt already offers 6-day certificates as an opt-in, and Chrome says its "Moving Forward, Together" ideas are proposals, not requirements.

Does a shorter certificate mean weaker encryption? No. Lifetime and encryption strength are separate. A 47-day certificate encrypts the same way. It simply expires sooner.

What does the 10-day validation reuse mean for me? From March 15, 2029, the CA can only rely on a domain check completed within the previous 10 days. For practical purposes, domain validation becomes part of almost every issuance, which is why automated DNS or HTTP validation matters so much.

Are OV and EV affected differently from DV? All three follow the same certificate lifetime limits. OV and EV also carry business identity checks, which can now be reused for up to 398 days instead of 825.

Is email validation still allowed? For now, but it is being phased out. Email methods "SHOULD NOT" be used since March 15, 2026, and CAs must stop relying on them from March 15, 2028.

A last sip

Shorter certificates can sound like more work, and at first they are. The goal, though, is a web where certificates are always fresh, a leaked key stops mattering quickly and renewals happen quietly in the background. Set up automation and monitoring once, and each new certificate should just arrive on time.

If you would like help choosing or installing a certificate, visit our SSL Certificates page or check the SSL FAQ.