Every publicly trusted TLS certificate your organisation buys is governed by a document most certificate owners have never read: the CA/Browser Forum Baseline Requirements. The Baseline Requirements (BRs) set how certificate authorities validate domains, how long certificates may last, which keys are allowed, and how fast a CA must revoke. Since 2024 they have changed faster than at any time in their history, with shorter lifetimes, the end of most email and phone validation, mandatory multi-perspective checks and DNSSEC validation. This guide explains the structure of the BRs, the rules that reach subscribers, what changes when, how root programmes enforce them, and how to turn them into an operating plan for your certificate estate. It is written for PKI owners, platform and SRE teams and security architects; for the renewal mechanics of the 47-day schedule, see the companion guide linked below.
Key takeaways
- The BRs bind CAs, not you, but you feel every change. They apply to publicly trusted TLS server certificates and are enforced by browser and operating system root programmes; enterprise-only PKI is out of scope.
- Lifetimes and validation reuse are shrinking together. Maximum validity is 200 days from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029, with domain validation reuse falling to 10 days by 2029.
- Revocation deadlines are short and not negotiable. A CA must revoke within 24 hours for key compromise and within 5 days for most other problems, and root programmes say they grant no exceptions.
- Validation is moving to DNS and ACME. Email, phone and several legacy methods are being sunset in stages to 2028, and CAs must validate DNSSEC and corroborate results from multiple network perspectives.
- Treat certificates as machine identities. Shorter lifetimes and fast revocation only work with an inventory, automation and an owner for every certificate and key.
What the Baseline Requirements are
The CA/Browser Forum is a voluntary organisation of certificate authorities and suppliers of browsers and other relying-party software. Its Server Certificate Working Group maintains the Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates. At the time of checking (27 October 2026) the current text is Version 2.3.1, dated 4 October 2026, published in the Forum's servercert repository on GitHub. Changes are made by numbered ballots (for example SC081, which introduced the schedule of reducing validity and data reuse periods, effective 16 May 2025).
Two points about scope matter for certificate owners:
- Enforcement comes from root programmes: the BRs state they are not mandatory for CAs unless and until adopted and enforced by Application Software Suppliers. The Chrome Root Program Policy (v1.8, 5 February 2026) requires adherence to the latest BRs and states that no single organisation, including Google, can grant exceptions. Mozilla's Root Store Policy (v3.1, effective 1 July 2026) also requires BR compliance and takes precedence where it is stricter.
- Private PKI is outside: the BRs do not cover enterprises that run their own PKI for internal purposes with roots that no software supplier distributes. Internal certificates follow your own policy. See the Enterprise PKI Design and CA Hierarchy Guide.
Separate CA/B Forum documents cover S/MIME and code signing certificates. The document follows the RFC 3647 outline, so section numbers such as 3.2.2.4 (domain validation), 4.9.1.1 (revocation reasons) and 6.3.2 (validity) are the same in every CA's Certification Practice Statement, which makes CPS comparison straightforward.
The rules that reach certificate owners
| BR section | Rule (Version 2.3.1) | What it means for you |
|---|---|---|
| 6.3.2 Validity | Maximum 398 days before 15 March 2026; 200 days from then; 100 days from 15 March 2027; 47 days from 15 March 2029. A day is 86,400 seconds and extra time counts as another day | Manual renewal stops scaling; plan for automation before 2027 |
| 4.2.1 Data reuse | Domain and IP validation reusable for 200 days from 15 March 2026, 100 days from 15 March 2027, 10 days from 15 March 2029. Subject identity information (OV, EV) 398 days from 15 March 2026 | Domain control must be re-proven almost continuously by 2029, so validation must be automatable |
| 4.9.1.1 Revocation | 24 hours for key compromise, an unauthorised request or unreliable domain validation (including CAA errors); 5 days for other reasons such as misissuance or misuse | A CA misissuance can force replacement of your certificates within days |
| 6.1.5 Keys | RSA at least 2048 bits and divisible by 8; ECDSA on P-256, P-384 or P-521 only; no other algorithms | Check key generation defaults in appliances and scripts |
| 4.2.2 Names | No Internal Names or Reserved IP addresses; no names ending in an IP reverse zone suffix from 15 March 2026 | Internal hostnames need private PKI |
| Definitions, Short-lived Subscriber Certificate | Validity of 7 days or less from 15 March 2026 (10 days before); CAs may choose not to support revocation of these | Very short certificates trade revocation for lifetime |
| 7.1.3.2.1 SHA-1 | All remaining use of SHA-1 in certificates and CRLs sunset from 15 September 2026 | Legacy clients that need SHA-1 chains cannot use public certificates |
| 4.9.7 CRLs | CRLs mandatory; updated at least every 7 days if all certificates carry an OCSP pointer, otherwise every 4 days, and within 24 hours of a revocation. OCSP became optional through ballot SC063 | Relying applications should check CRLs, not assume OCSP |
For relying-party revocation checking, see the Certificate Revocation Guide.
Domain validation methods and their sunset dates
Section 3.2.2.4 lists the methods a CA may use to confirm that an applicant controls a domain. The table shows the main methods and their status under Version 2.3.1.
| Method | How control is shown | Status |
|---|---|---|
| 3.2.2.4.2 Email, fax, SMS or postal mail to domain contact | Message to WHOIS-style domain contact | No longer usable from 15 July 2025 |
| 3.2.2.4.15 Phone contact with domain contact | Phone call to domain contact | No longer usable from 15 July 2025 |
| 3.2.2.4.8 IP address | Domain resolves to an IP the applicant controls | No longer usable from 15 March 2026 |
| 3.2.2.4.16 and 3.2.2.4.17 Phone to DNS TXT or CAA phone contact | Phone number published in DNS | Ends 15 March 2027 |
| 3.2.2.4.4, 3.2.2.4.13, 3.2.2.4.14 Constructed email, email to CAA contact, email to TXT contact | Email to admin@, or to an address in DNS | Ends 15 March 2028 |
| 3.2.2.4.7 DNS change | Random value placed in DNS | Current |
| 3.2.2.4.18 and 3.2.2.4.19 Agreed-upon change to website (v2 and ACME) | File at a well-known path over HTTP (ACME http-01) | Current |
| 3.2.2.4.20 TLS using ALPN | ACME tls-alpn-01 challenge | Current |
| 3.2.2.4.21 DNS labelled with account ID (ACME) | DNS record tied to the ACME account | Current (added by SC084) |
| 3.2.2.4.22 DNS TXT record with persistent value | A standing record at _validation-persist. naming the CA and the applicant's account URI, with optional persistUntil | Current (added by SC088) |
The direction is clear: by March 2028 domain validation will rest on DNS, HTTP and TLS challenges, most of them ACME-native. The persistent TXT method is designed for the 10-day reuse world, because one standing record authorises a specific CA account without a new challenge each time; the CA must reject the record after its persistUntil time. See the ACME and Automated Certificate Management Guide.
DNSSEC, CAA and multi-perspective checks
- DNSSEC validation: from 15 March 2026 the CA's primary network perspective must perform DNSSEC validation back to the IANA root trust anchor on domain validation and CAA lookups, and a DNSSEC failure such as SERVFAIL must not be treated as permission to issue. A broken DNSSEC chain on your zone therefore blocks issuance. See the DNSSEC Deployment Guide.
- CAA: CAA records state which CAs may issue for a domain. From 15 March 2027 CAs must process the RFC 8657
accounturiandvalidationmethodsparameters, so you can restrict issuance to a specific ACME account and challenge type. - Multi-Perspective Issuance Corroboration (3.2.2.9): since 15 March 2025 CAs must confirm domain validation and CAA results from multiple remote network perspectives to resist BGP hijacks. Perspectives must be at least 500 km apart; with 2 to 5 remote perspectives one may disagree, with 6 or more, two may. See the BGP and Routing Security Guide.
How CAs are held to the rules
| Mechanism | Source | What it requires |
|---|---|---|
| Annual audit | BR 8.4 | WebTrust for CAs plus SSL Baseline (and Network Security) criteria, or ETSI EN 319 411-1, by a qualified auditor |
| Self-audits | BR 8.7 | Quarterly review of a random sample of at least 3% of issued certificates; linting of the sample recommended |
| Pre-issuance linting | BR 4.3.1.2 | Since 15 March 2025, test each to-be-signed certificate for technical conformity |
| Mass revocation plan | BR 5.7.1.2 | From 1 December 2025, CPS states the plan, its testing and improvements |
| Incident reporting | Mozilla policy and CCADB | Non-compliance is an incident; delayed revocation needs public justification and appears as an audit finding |
| Root programme rules beyond the BRs | Chrome Root Program Policy 1.8 | Dedicated serverAuth hierarchies (subscriber certificates serverAuth-only from 15 March 2027), automation for every subordinate CA from 15 March 2027, removal of root keys older than 15 years |
The Chrome serverAuth-only rule matters to anyone using public TLS certificates for client authentication (for example mTLS between partners): plan a private CA for client certificates. See the mTLS Guide.
Turning the BRs into an operating plan
- Inventory: find every publicly trusted certificate using Certificate Transparency logs and network scans, with its CA, validation method, key type, expiry and owner. See the Certificate Transparency Monitoring Guide for Web Teams.
- Classify by renewal path: ACME-capable, API-capable, manual. Every manual certificate is a 2027 risk.
- Move validation off email and phone: switch to DNS or HTTP challenges now rather than at the 2027 and 2028 deadlines; where DNS changes are slow, use the persistent TXT method or delegated DNS for the challenge label.
- Publish CAA: list only the CAs you use, then add
accounturiandvalidationmethodsas your CAs support them. - Check DNSSEC health: if your zones are signed, monitor for validation failures, which now block issuance.
- Pilot shorter lifetimes: request 90-day or shorter certificates on a pilot ring of services before the CA forces it, measure failures, then widen. Keep the previous certificate available as a rollback until the new chain is confirmed in production.
- Prepare for forced revocation: keep a runbook to replace any certificate set within 24 hours, including a second CA account ready to use.
- Separate client authentication: move clientAuth uses to private PKI before the Chrome cut-over.
Small versus large organisations: a small organisation with a few dozen certificates on web servers and a CDN can usually meet everything with ACME clients and CAA records. Large estates with appliances, load balancers and legacy applications need a certificate lifecycle management platform, an owner per certificate and a tested mass replacement process. The schedule mechanics are covered in the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
Where identity fits
A TLS certificate and its private key are a machine identity: they authenticate a service to every client that connects. The BR changes push certificate management into the same discipline as other non-human credentials.
- Ownership: each certificate needs a named owner who will act on a 24-hour revocation notice.
- Key custody: key compromise triggers the shortest revocation deadline, so keys belong in HSMs, cloud key services or secret stores, not on file shares.
- ACME account credentials: with persistent DNS validation and CAA
accounturi, the ACME account key becomes the credential that authorises issuance for your domains. Protect and rotate it as a privileged secret. - DNS credentials: API tokens that can edit DNS can also pass domain validation; scope them to the challenge records where your DNS provider allows.
See the Machine Identity, PKI and Certificate Lifecycle Guide.
Detection and measurement
- Automation coverage: percentage of public certificates renewed without human action (target close to 100% before March 2027).
- Legacy validation: number of certificates still validated by email or phone methods.
- Unknown issuance: CT log entries for your domains not matched to the inventory, alerted within a day.
- Replacement time: time to replace a set of certificates in a revocation drill, against the 24-hour and 5-day deadlines.
- CAA coverage: percentage of registered domains with a restrictive CAA record.
- Ownership: percentage of certificates with a current named owner.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-17 Public Key Infrastructure Certificates; SC-12 Cryptographic Key Establishment and Management; IA-5(2) Public Key-based Authentication | Certificate issuance under an approved policy, key management and certificate validation |
| NIST CSF 2.0 | PR.DS-02 data in transit; PR.AA-03 users, services and hardware authenticated; ID.AM-08 life cycle management | Certificates protect transit and authenticate services through their life cycle |
| ISO/IEC 27001:2022 | Annex A 8.24 Use of cryptography | Key and certificate management rules |
| MITRE ATT&CK | T1588.004 Obtain Capabilities: Digital Certificates; T1587.003 Develop Capabilities: Digital Certificates; T1557 Adversary-in-the-Middle | Domain validation, CAA and MPIC raise the cost of obtaining a certificate for a domain an attacker does not control |
Common failure patterns
- Assuming lifetimes are a CA choice: teams negotiate longer certificates with a vendor; the BR maximum applies to every publicly trusted CA.
- No plan for forced replacement: when a CA must revoke within 24 hours or 5 days, owners discover they cannot find or redeploy their certificates. Exposure of certificates at a provider has the same effect: after the Imperva Breach 2019, customers whose SSL certificates were in the exposed data were told to generate and upload new ones, and thousands were replaced.
- Email validation dependency: renewals rely on someone clicking a link sent to admin@, which stops working as methods are sunset.
- Broken DNSSEC: a misconfigured signed zone now stops issuance and renewal outright.
- Public certificates for internal names or client authentication: both are excluded or being phased out; they belong on private PKI.
- Unprotected ACME and DNS credentials: a leaked DNS API token or ACME account key lets an attacker obtain valid certificates for your domains.
Practitioner checklist
- Inventory every public certificate from CT logs and scans, with CA, validation method, key type, expiry and owner.
- Automate renewal for every certificate that can be automated, starting with services that will fail first at 100 days.
- Replace email and phone validation with DNS, HTTP or TLS-ALPN challenges.
- Publish restrictive CAA records and plan for
accounturiandvalidationmethods. - Monitor DNSSEC validation health on signed zones.
- Run a revocation drill that replaces a certificate set within 24 hours.
- Move client authentication and internal names to private PKI.
- Store private keys, ACME account keys and DNS API tokens as privileged secrets with owners.
- Read the change log of each new BR version and each root programme policy update.
Standards and references
- CA/Browser Forum: Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates
- Google: Chrome Root Program Policy
- Mozilla: Root Store Policy
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Obtain Capabilities: Digital Certificates
Related NHI Mgmt Group resources: Certificate Expiry Outages and 47-Day TLS Certificates Guide · ACME and Automated Certificate Management Guide · Certificate Transparency Guide · Machine Identity, PKI and Certificate Lifecycle Guide