47-day TLS certificates explained: the CA/B Forum SC-081 timeline (200, 100, 47 days), DCV reuse limits, renewal math and a 6- and 12-month preparation plan.
47-day TLS certificates are the end point of CA/Browser Forum Ballot SC-081, which cuts the maximum validity of publicly trusted TLS server certificates from 398 days to 200 days (15 March 2026), 100 days (15 March 2027) and 47 days (15 March 2029). The same ballot shortens how long a certificate authority may reuse domain validation, down to 10 days in 2029. In practice, every public certificate will be replaced roughly every month, and that only works with automated issuance and deployment.
This is not a future problem. As of 15 October 2026, the 200-day certificate validity limit has been in force for seven months, and the next step, 100 days, applies to certificates issued from 15 March 2027, five months from now. Teams that still renew through tickets, calendar reminders and manual uploads will see their workload roughly double next spring and grow about eightfold by 2029.
This guide gives the full SC-081 certificate lifetime reduction timeline as the Baseline Requirements state it, explains who is affected, shows what breaks and how often you will renew, and lays out a 6-month and 12-month preparation plan built on inventory, ownership and certificate lifecycle management.
The table below combines the three schedules from the TLS Baseline Requirements (section 6.3.2 for certificate validity, section 4.2.1 for data reuse). Each limit applies by issuance date: a certificate is judged by the rule in force on the day it was issued.
| Certificate issued | Maximum certificate validity (BR 6.3.2) | Domain / IP validation data reuse (BR 4.2.1) | Subject Identity Information reuse (BR 4.2.1) | Status on 15 Oct 2026 |
|---|---|---|---|---|
| Before 15 March 2026 | 398 days | 398 days | 825 days | Superseded |
| 15 March 2026 to 14 March 2027 | 200 days | 200 days | 398 days | In force now |
| 15 March 2027 to 14 March 2029 | 100 days | 100 days | 398 days | Next step (in 5 months) |
| From 15 March 2029 | 47 days | 10 days | 398 days | Final step |
What the table means:
The Baseline Requirements define the validity period as running from notBefore through notAfter, inclusive (the RFC 5280 definition), and they add that CAs should issue somewhat shorter certificates than the maximum.
Ballot SC-081v3, "Introduce Schedule of Reducing Validity and Data Reuse Periods", amended the TLS Baseline Requirements that every publicly trusted CA must follow. The key facts from the ballot page:
| Item | Detail |
|---|---|
| Proposer | Clint Wilson (Apple) |
| Endorsers | Nick France (Sectigo), Ryan Dickson (Google Chrome), Ben Wilson (Mozilla) |
| Voting period | 4 April 2025 to 11 April 2025 |
| Certificate Issuers | 25 yes, 0 no, 5 abstain |
| Certificate Consumers | 4 yes (Apple, Google, Microsoft, Mozilla), 0 no |
| IPR review | 13 April 2025 to 13 May 2025 |
| Scope of change | Validity 398 → 47 days; SAN (domain/IP) validation reuse 398 → 10 days; non-SAN (identity) validation reuse 825 → 398 days, phased from March 2026 to March 2029 |
The ballot's stated aim is to reduce reliance on stale validation data and limit the impact of misissued certificates, with "reasonable and attainable timelines upfront". It points to "certificate lifecycle management components which enable automated issuance, replacement, and rotation of certificates" as a benefit, and notes that automation "is not a panacea for challenges in the Web PKI, but it certainly helps."
The Baseline Requirements cover the "issuance and management of Publicly-Trusted TLS Server Certificates". That sets the boundary:
| Certificate type | Bound by SC-081? | What to do |
|---|---|---|
| Public TLS server certificates (websites, APIs, public load balancers, CDNs, mail servers with public certs) | Yes | Automate renewal and deployment before March 2027 |
| OV / EV certificates | Yes (validity and domain reuse); identity reuse is 398 days | Keep organization validation current with your CA |
| Private / internal CA certificates (service mesh, internal APIs, Kubernetes, mTLS, devices) | No | Not required, but aligning on short lifetimes and automation reduces risk and reuses the same tooling |
| Code signing, S/MIME, client authentication | No (separate CA/B Forum requirements or none) | Check the applicable requirements separately |
Internal CAs are not bound by the TLS Baseline Requirements, so a 2-year internal certificate is still allowed. Two reasons to align anyway: one automation pipeline for public and private certificates is cheaper than two processes, and short-lived internal certificates limit the damage of a leaked key. The same reasoning applies to the coming post-quantum migration: an estate that can rotate every certificate on demand can also change algorithms on demand.
How many times a year will you renew one certificate? Two ways to count:
| Maximum validity | Renewal point at 2/3 of lifetime | Renewals per certificate per year (2/3 policy) | Minimum issuances per year (no buffer) | 500 certificates, renewals per year (2/3 policy) |
|---|---|---|---|---|
| 398 days | Day 265 | about 1.4 | 1 | about 690 |
| 200 days | Day 133 | about 2.7 | 2 | about 1,370 |
| 100 days | Day 67 | about 5.5 | 4 | about 2,740 |
| 47 days | Day 31 | about 11.7 | 8 | about 5,825 (about 16 per day) |
The jump from 398 to 47 days is roughly an eightfold increase in renewals per certificate. If one manual renewal costs an hour across request, approval, install and verification, a 500-certificate estate goes from about 690 hours a year to about 5,800.
DCV reuse adds a second clock. From March 2029, validation data can be reused for only 10 days, so a renewal at day 31 will almost always need a new domain control check. With ACME, that check (an http-01 or dns-01 challenge) runs inside the renewal. With manual processes, it is one more email or DNS change per certificate per month.
Shorter lifetimes do not create new failure modes; they make existing ones happen more often. The table lists what typically fails first.
| Weak point | Why it breaks at 100 or 47 days | Impact | Mitigation |
|---|---|---|---|
| Manual renewals (calendar reminders, spreadsheets) | Renewal volume grows about 4× (100 days) to 8× (47 days) | Expired certificates, outages | ACME or other enrollment automation for every endpoint |
| Ticket-based request and approval | Each ticket cycle can take days; a 31-day renewal window leaves little slack | Missed renewal windows | Pre-approved policies per domain; approval by exception |
| Manual domain validation (email, manual DNS) | 10-day DCV reuse from 2029 means a check almost every issuance | Issuance blocked | Automated http-01 or dns-01 challenges with API-driven DNS |
| Certificate pinning (apps, APIs, partners) | Pinned leaf certificates change monthly | Client connection failures | Stop pinning leaf certificates; pin to CA or public key only with a rotation plan, or remove pinning |
| Appliances without ACME (older load balancers, firewalls, VPN gateways, printers, OT) | Certificates must be uploaded by hand or by vendor-specific scripts | Outages on edge devices | Deployment connectors or vendor APIs; plan upgrades or replacement |
| Load balancers and CDNs with manual uploads | Same certificate on many listeners; one missed listener breaks traffic | Partial outages that are hard to diagnose | Automated deployment with validation per target |
| Inventory gaps (unknown certificates, shadow IT) | Unknown certificates cannot be renewed on time | Surprise expirations | Continuous discovery of certificates across hosts, keystores and domains |
| Untested revocation and replacement | Mass replacement after a CA incident or key compromise has never been rehearsed | Long recovery times | Regular replacement drills |
You cannot automate what you have not found. Scan hosts, keystores, cloud services and public domains for certificates, and record for each: subject and SANs, issuer, expiry, key algorithm and size, where it is deployed, and how it is renewed today. A cryptographic inventory built this way also feeds your cryptographic bill of materials.
Every certificate needs a named owner and a team, plus the system it protects. Group certificates by renewal path: ACME-capable, API-capable, manual only.
ACME (RFC 8555) is the standard protocol for automated issuance and renewal. Most public CAs support it, and clients such as certbot, acme.sh, Caddy and Kubernetes cert-manager handle challenges and renewals. Set the renewal point well before expiry (two-thirds of the lifetime is a common default). For the private side, the ACME private CA automation guide explains how to run the same workflow against your own CA.
Issuance is half the job. The new certificate must reach every load balancer, web server, appliance and keystore that uses it, and each target must be checked after the change. Use connectors or vendor APIs, verify that the new certificate is served, and roll back automatically if it is not.
Monitor expiry from the outside (what clients actually see), not only from the inventory. Alert the owner when a renewal fails, not when the certificate is about to expire. Track renewal success rate and the number of certificates still on manual paths.
Rehearse replacing all certificates from one CA, or all certificates using one key, within a set time. This covers CA distrust events, key compromise and algorithm changes.
A certificate lifecycle management (CLM) platform covers the steps above in one place: discovery, inventory and ownership, policy, enrollment protocols, deployment, monitoring and revocation. The difference from scripts is coverage and evidence: every certificate has an owner, every renewal is logged, and failures are visible before they become outages.
| Capability | Manual / scripts | CLM platform |
|---|---|---|
| Inventory | Spreadsheets, partial | Continuous discovery, central inventory |
| Issuance | Per-team scripts or tickets | Standard protocols (ACME, EST, SCEP, CMP) with policy |
| Deployment | Manual uploads | Connectors with validation and rollback |
| Revocation | Ad hoc | CRL and OCSP, revocation reasons, audit trail |
DuoKey is a private and internal PKI and certificate management platform. It does not issue publicly trusted WebPKI certificates; your public certificates still come from a public CA. What DuoKey provides for a 47-day world, according to the DuoKey PKI documentation:
A cert-manager ClusterIssuer points at a DuoKey CA through its ACME directory:
# ClusterIssuer pointing cert-manager at a DuoKey CA over ACME
server: https://{cockpit-url}/api/pki/acme/{ca-id}/directory
cert-manager renews at two-thirds of the certificate lifetime by default, configurable with renewBefore. Details are on the certificate management page; to see where your estate stands first, start with the free Quantum Readiness Score.
Q: What are 47-day TLS certificates?
They are publicly trusted TLS server certificates with a maximum validity of 47 days, required by CA/B Forum Ballot SC-081 for certificates issued on or after 15 March 2029. Before that, the limit is 200 days (from 15 March 2026) and 100 days (from 15 March 2027).
Q: When do TLS certificates become 47 days?
On 15 March 2029. Certificates issued from that date can be valid for at most 47 days, and domain validation data can be reused for only 10 days. The intermediate steps are 200 days from 15 March 2026 and 100 days from 15 March 2027.
Q: What is CA/B Forum ballot SC-081?
SC-081v3, "Introduce Schedule of Reducing Validity and Data Reuse Periods", is a CA/Browser Forum ballot proposed by Apple and passed in April 2025 with support from all four browser vendors that voted (Apple, Google, Microsoft, Mozilla). It amended the TLS Baseline Requirements to phase in shorter certificate lifetimes and validation reuse periods between March 2026 and March 2029.
Q: Does the 47-day rule apply to internal certificates?
No. The TLS Baseline Requirements cover publicly trusted TLS server certificates only, so certificates from a private or internal CA are not bound. Aligning internal lifetimes and automation with the public rules is still good practice, because it reuses one pipeline and limits exposure from leaked keys.
Q: How many times a year will I renew a certificate?
If you renew at two-thirds of the lifetime, about 2.7 times a year at 200 days, 5.5 times at 100 days and 11.7 times at 47 days. Without any safety margin the minimum is 2, 4 and 8 issuances a year.
Q: Is the 200-day limit already in force?
Yes. Since 15 March 2026, newly issued public TLS certificates are limited to 200 days. Certificates issued earlier with up to 398 days stay valid until they expire.
Q: What are 100-day TLS certificates?
They are the second step of SC-081: public TLS certificates issued from 15 March 2027 to 14 March 2029 are limited to 100 days, and domain validation can be reused for 100 days.
Q: What happens to domain control validation (DCV)?
The reuse period follows the certificate lifetime (398, 200, 100 days) and then drops to 10 days from 15 March 2029. Organization identity information can be reused for 398 days since March 2026, down from 825 days.
The 200-day limit is already here, and the 100-day step arrives on 15 March 2027. Treat that date as the deadline for automation, not 2029: by the time certificates last 47 days, a manual renewal process will be running about 12 renewals per certificate per year.
Written by
DuoKey Team
Related Resources
Tell us where control is difficult today. We will help you identify a practical next step.
