The 47-day rule: what CA/Browser Forum ballot SC-081v3 says
The maximum lifetime of publicly trusted TLS certificates drops in steps to 47 days by 2029. The decision was taken in April 2025; the dates and durations are fixed.
10 September 2026 · 6 min read
Who decided
The CA/Browser Forum is the industry body in which certificate authorities and browser and operating system vendors have set the rules together since 2005. It is not a legal authority; its power comes from browsers trusting only the authorities that follow its rules.
- Members
- Certificate authorities (Let's Encrypt, DigiCert, Sectigo, GlobalSign and others) and root store owners such as Google, Apple, Mozilla and Microsoft.
- The rulebook
- The TLS Baseline Requirements: how publicly trusted TLS certificates are issued, validated and how long they may be valid.
- SC-081v3
- The change proposed by Apple and adopted by vote in April 2025. It shortens certificate lifetimes and the reuse period of domain validation in steps.
- Enforcement
- An authority that breaks the rule is removed from the root stores and its certificates become invalid in browsers. That is why the decision is binding worldwide in practice.
Source: CA/Browser Forum, Ballot SC-081v3 (April 2025) and the TLS Baseline Requirements, section 6.3.2.
The schedule
| Date | Maximum certificate lifetime | Reuse of domain validation |
|---|---|---|
| since 2020 | 398 days | 398 days |
| 15 March 2026 | 200 days | 200 days |
| 15 March 2027 | 100 days | 100 days |
| 15 March 2029 | 47 days | 10 days |
Each date applies to certificates issued from that day on; certificates issued earlier remain valid until their own expiry.
Why lifetimes are shrinking
- The window in which a leaked or mis-issued certificate can be abused gets shorter.
- Revocation mechanisms (CRL, OCSP) do not work reliably in browsers; short lifetimes largely take the place of revocation.
- Domain ownership information stays current; old certificates do not live on for domains that changed hands.
- The industry is pushed towards automation: a certificate renewed by hand is not sustainable on a 47-day cycle.
What changes for organisations
What is done once a year today will repeat eight times a year for every certificate in 2029. For an organisation with 500 certificates that means thousands of issuances, installations and verifications a year.
- Inventory
- No renewal is safe without knowing which certificate is installed where; discovery and inventory come first.
- Automatic renewal
- ACME (RFC 8555) automates obtaining certificates; wildcards and internal names need DNS validation (dns-01).
- Verified installation
- Obtaining the certificate is not enough; it must be installed on the target, the service reloaded, and the server confirmed to actually serve the new certificate.
- Audit trail
- Every renewal and installation must be recorded; on a 47-day cycle the question of who did what and when cannot be answered by hand.
What to do now
- Inventory01
Scan every TLS endpoint; collect certificates and the systems they are installed on in one list.
- Ownership02
Assign a responsible team and an alert threshold to every certificate.
- ACME03
Clarify ACME support at your authorities and API access to your DNS provider; dns-01 is required for wildcards.
- Installation automation04
Automate installing renewed certificates on targets with backup, atomic writes and verification.
- Rehearsal05
Run the process on real systems during the 200-day period; be ready for 100 days in 2027.
Frequently asked questions
- Does the rule apply to internal certificates?
- No; only to publicly trusted TLS certificates. An internal PKI sets its own rules.
- I have a one-year certificate; does it become invalid after 15 March 2026?
- No. The rule applies to new certificates issued from that date; an existing certificate remains valid until its own expiry.
- Can authorities keep issuing certificates longer than 47 days?
- No. If they did, they would be removed from the root stores; that is why no authority exceeds the rule.
- Why exactly 47 days?
- One month (31 days), half a month (15 days) and one day of slack: a one-month renewal window plus margin for delays.
Sources
More articles
- Why certificate revocation does not work and how short lifetimes fix it5 min read
- dns-01 validation: DNS APIs for wildcards and internal names6 min read
- How expensive is an expired certificate? Outages on the public record5 min read
- How to build a certificate inventory: discovery, ownership, records6 min read
Manage your certificates in one place
Inventory, expiry tracking, renewal through ACME and verified installation, on your own infrastructure.