What the 47-day SSL certificate limit means for agencies

Corrections: support@domainvane.com

The cap that is already in force

If you still tell clients that "an SSL certificate lasts about a year," that sentence is out of date for any publicly trusted certificate issued on or after 15 March 2026.

The CA/Browser Forum adopted Ballot SC-081v3 on 11 April 2025. Apple proposed it. Sectigo, Google Chrome, and Mozilla endorsed it. Certificate issuers voted 25 yes and 5 abstain. Apple, Google, Microsoft, and Mozilla all voted yes as certificate consumers. The ballot is recorded as Baseline Requirements revision SC081, adopted 11 April 2025. The shorter lifetimes themselves land on later dates, which the current Baseline Requirements (version 2.3.0, 7 September 2026) still list in the relevant-dates table.

Those dates, for the maximum validity of a subscriber certificate:

Certificates issued on or after	Maximum validity
Before 15 March 2026	398 days
15 March 2026	200 days
15 March 2027	100 days
15 March 2029	47 days

Today is inside the 200-day phase. The 100-day cap and the 47-day cap are scheduled. They are not in force yet. A certificate issued before a cutoff keeps the maximum that applied on the day it was issued. The rule is about validity period at issuance. It is a cap on new certificates, applied on the date they are issued.

The same table cuts how long a CA may reuse domain-validation evidence: 200 days from 15 March 2026, 100 days from 15 March 2027, and 10 days from 15 March 2029. Subject-identity information for organization-validated certificates has its own reuse period, 398 days from 15 March 2026. Domain control is the one that gets short.

The Baseline Requirements apply to publicly trusted TLS certificates, the kind whose root is distributed in browsers and operating systems. Section 1.1 of the requirements says they do not govern an enterprise PKI whose root is not distributed by an application software supplier. An internal certificate authority you run for a private network is outside this schedule. The hostnames your clients serve on the public web are inside it.

Why 47 days changes an agency's year

A day in this context is the unit the requirements use for validity. A certificate issued at the 47-day maximum covers less than seven weeks. A hostname that stays online for a full year cannot do that on one issuance. Divide 365 by 47 and you get a bit under eight issuance windows if every certificate uses the full maximum. That figure is arithmetic on the cap. It is not a measurement of how often any particular client renews, and many certificates will be shorter than the maximum.

The practical effect for an agency is simpler than the arithmetic. A book of client sites that used to have one public-certificate event per hostname per year already has a shorter cycle, and it gets shorter again in 2027 and 2029. Each event is a chance for automation to fail, for a deploy to ship the leaf without the intermediate, or for a hostname you forgot to be left on the old file. The names are scattered across hosts, registrars, and clients, and the ballot does not build that inventory for you.

Let's Encrypt is on a tighter clock than the Forum cap

Let's Encrypt's public post of 2 December 2025 says it currently issues 90-day certificates and will cut that lifetime in stages, because it has to follow the Baseline Requirements along with every other publicly trusted CA.

The dates in that post, confirmed again on Let's Encrypt's upcoming-features page (last updated 22 July 2026):

13 May 2026: the opt-in tlsserver ACME profile issues 45-day certificates. This profile is opt-in.
10 February 2027: the default classic profile issues 64-day certificates, and the authorization reuse period on that profile drops to 10 days.
16 February 2028: classic issues 45-day certificates, and authorization reuse drops to 7 hours.

Let's Encrypt's authorization reuse (how long after a validation they will issue again without a new challenge) is already tighter than the Forum's domain-validation reuse cap, and it gets tighter on Let's Encrypt's own dates. Do not treat "the Forum says 100 days in 2027" as the date your Let's Encrypt client will start seeing 100-day certificates. The Forum number is a maximum. A CA may issue shorter certificates sooner. Let's Encrypt has published the schedule above.

The same post says a client that renews on a hardcoded 60-day interval will not be compatible with 45-day certificates. Renewing at about two thirds of the certificate's lifetime is the pattern they describe as acceptable. They recommend ACME Renewal Information (ARI) so the client asks Let's Encrypt when the renewal window is, instead of guessing from a constant. They also say manual renewal gets worse as lifetimes shrink, and they point readers at monitoring so a missed renewal is visible.

That last point matters if you have been relying on Let's Encrypt's own expiration mail. That service ended on 4 June 2025. The announcement is explicit: subscribers who had given Let's Encrypt an email address through the ACME account no longer get expiration mail, and those addresses were deleted from the CA database. A failed renewal used to have a chance of arriving as mail from the CA. That chance is gone.

What to write down before March 2027

You do not need a new tool on the day you read this. You need a list that is true.

For each hostname the agency is responsible for, record:

the exact name that is on the certificate (the apex and www are different names)
who can renew it (agency, client, or a host you do not control)
which CA issued it, if you know
the notAfter date, read from the live handshake, not from a proposal PDF
whether renewal is automated, and where that job runs
the domain-registration expiry, from the registrar or from RDAP, kept as a separate column from the certificate date

The certificate date and the registration date fail independently. A site can have a fresh certificate on a domain the registrar is about to delete, or a paid-up domain serving an expired certificate. Short certificate lifetimes increase the first kind of work. They do nothing to shrink the second.

Then look for the jobs that will not survive the next cut:

a calendar reminder set for "once a year"
an ACME client pinned to a 60-day renew interval
a server that was issued a certificate by hand in 2025 and has no client installed
a certbot timer on a machine nobody can log into
a hostname that is on the contract and not on the server

The 200-day certificates issued in March 2026 are already coming due. A certificate issued at a 200-day maximum in mid-March 2026 reaches notAfter in early October 2026. That is this autumn, not a 2029 problem. Sectigo's 21 September 2026 note describes that wave as the first real set of 200-day renewals. The Forum table is the reason the wave exists. Your list is how you find out whether it includes your clients.

A monitor is a backstop

Automation renews the certificate. A registrar renews the domain. A monitor watches the live handshake and the registration record and tells a person when the date is close or the check is failing.

Domainvane does that second job for the hostnames an agency adds: TLS on port 443 and domain expiry from RDAP, with alert state at 30, 14, 7, and 1 days shown on the dashboard. Email alerts are delivered to external inboxes, including Gmail. Inbox placement is not guaranteed for every provider (Outlook and Yahoo have not been tested). It does not install an ACME client, and it does not talk to the registrar. A hostname it cannot read shows the status it actually got, including "unknown" when RDAP has no usable date, rather than a filled-in guess.

If the list above is still a spreadsheet, the useful next step is to put the hostnames where a check runs without someone opening the sheet. Free accounts cover three hostnames and show their status and alert state on the dashboard. Email alerts are delivered to external inboxes, including Gmail. Inbox placement is not guaranteed for every provider (Outlook and Yahoo have not been tested).

Create a Domainvane account and add the hostnames whose renewal you do not want to discover from a browser warning.

Sources

Checked 2026-09-25.

CA/Browser Forum, Ballot SC-081v3 (voting results and scope), 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/
CA/Browser Forum, Baseline Requirements for TLS Server Certificates, version 2.3.0 (7 September 2026), section 1.2.2 relevant dates: 200 days on 2026-03-15, 100 days on 2027-03-15, 47 days on 2029-03-15; domain-validation reuse 200 / 100 / 10 days on those dates. https://github.com/cabforum/servercert/blob/BRs/v2.3.0/docs/BR.md
Ballot text as merged from the SC-081 pull request: validity limits apply to subscriber certificates issued on or after each date (398 / 200 / 100 / 47 days). https://github.com/cabforum/servercert/pull/553
Let's Encrypt, "Decreasing Certificate Lifetimes to 45 Days," Matthew McPherrin, 2 December 2025. https://letsencrypt.org/2025/12/02/from-90-to-45
Let's Encrypt, Upcoming Features, "Decreasing Certificate Lifetimes to 45 Days," page last updated 22 July 2026. https://letsencrypt.org/upcoming-features/
Let's Encrypt, "Expiration Notification Service Has Ended," Josh Aas, 26 June 2025 (service ended 4 June 2025). https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended
Sectigo, "200-day certificates are starting to expire," 21 September 2026, restating the Forum table. https://www.sectigo.com/blog/200-day-certificate-expiration-begins