The TL;DR
Mozilla Root Store Policy (MRSP) v3.1 took effect July 1, 2026. The three changes with teeth:
- Root inclusion requests are only accepted for key pairs generated within the last 5 years
- CP/CPS documentation quality requirements got stricter
- CAs with TLS-enabled roots must obtain Detailed Controls Reports (DCRs) for audit periods beginning on or after July 1, 2027
1. Root CA Keys Must Be Young (≤5 Years at Submission)
Historically, CAs could generate a root key pair, park it for years, and submit it for inclusion whenever business priorities aligned — meaning "new" roots sometimes entered the store with a decade-old key.
Under v3.1, Mozilla accepts inclusion requests only for root CA key pairs generated no more than 5 years before submission.
Who this bites: CAs sitting on pre-generated root inventory. If you have parked keys from 2020 or earlier awaiting submission, they are no longer eligible — plan a fresh key ceremony.
2. Tighter CP/CPS Documentation Standards
v3.1 raises the bar on CP/CPS content and quality (MRSP Section 3.3), continuing the industry-wide shift from "policy documents exist" to "policy documents are specific, accurate, and auditable."
This aligns with the CP/CPS content compliance deadline already tracked in the hub: CAs must fully comply with MRSP sections 3.3.1–3.3.6 by July 1, 2027.
Who this bites: CAs whose CP/CPS still uses vague boilerplate, stale version references, or doesn't map cleanly to actual practice. Auditors and root store operators will now compare the documents against observed practice more aggressively.
3. Detailed Controls Reports (DCRs) — the Big One for 2027
For audit periods beginning on or after July 1, 2027, CA operators with TLS-enabled roots in the Mozilla program must obtain Detailed Controls Reports — audit deliverables that document not just whether controls passed, but the design of each control and evidence of its operating effectiveness.
Think SOC 2 Type II-style transparency applied to WebTrust/ETSI CA audits: Mozilla (and the public, via CCADB) gets visibility into what the auditor actually tested and what they found, instead of a one-page seal.
Who this bites: every CA in the Mozilla program with TLS trust bits.
Practical prep
- Talk to your WebTrust/ETSI auditor now about DCR scope and pricing — this is a bigger engagement than a standard period-of-time report.
- Inventory your control matrix — controls that exist only as tribal knowledge need documenting before an auditor can attest to their design.
- Budget extra audit time — expect the first DCR cycle to surface documentation gaps.
Timeline
| When | What |
|---|---|
| 2026-07-01 | MRSP v3.1 effective; 5-year root key age limit applies to inclusion requests. |
| 2027-07-01 | CP/CPS full compliance with MRSP sections 3.3.1–3.3.6. |
| 2027-07-01 | DCRs required for audit periods beginning on or after this date. |
Sources
- Mozilla Security Blog: Improving Transparency and Assurance in the Web PKI — MRSP v3.1
- Mozilla Root Store Policy (canonical text)
Track this deadline and others affecting your certificates on the PKI Compliance Hub deadline tracker.