Starting July 2027, every CA with a TLS root certificate trusted in Mozilla's store will have to hand over a Detailed Controls Report that exposes exactly what controls they run, how they test them, and where they fail. That's the real news in Mozilla Root Store Policy v3.1, published today and effective July 1, 2026.
CP/CPS Documentation Gets an Enforceable Standard
Mozilla has seen CP/CPS quality vary from “extensive implementation detail” to “vague hand-waving with heavy incorporation by reference.” MRSP v3.1 kills that. Revised section 3.3 now demands documentation that is explicit, bounded, auditable, and sufficiently detailed for a technically competent reviewer to understand the CA's commitments and how they're implemented. RFC 3647 conformance is still required, but Mozilla layers on version control, accessibility, and maintenance expectations. The goal: reduce misissuance by forcing CAs to write down what they actually do — not what they wish they did.
Detailed Controls Reports: What the Auditors Won't Tell You
Traditional WebTrust and ETSI audits give you a binary pass/fail on a high-level criteria checklist. They don't tell you which controls were tested, how they were tested, or what the tester found. DCRs fill that void. Beginning with audit periods starting on or after July 1, 2027, any CA with a root enabled for TLS website authentication must obtain a DCR. The report must include the audited system's scope and boundaries, applicable criteria, the controls implemented, the auditor's testing procedures, test results, and all control exceptions or deficiencies. Mozilla says it will only review DCRs on an as-needed basis — compliance reviews, incidents, root inclusion evaluations — but the threat of scrutiny is the point.
Root Key Age Cap and Other Housekeeping
MRSP v3.1 also tightens several loose screws. Root CA key pairs submitted for inclusion must now have been generated within the previous five years — no more dusting off a key from 2015 and calling it contemporary. Mass revocation planning requirements now align with the CA/Browser Forum Baseline Requirements, eliminating a compliance gap that could have caused chaos during a widespread incident. And if a CA changes ownership or operational control, Mozilla expects timely notice and an impact evaluation. These aren't flashy, but they close the kind of procedural loopholes that cause real incidents.
Looking forward, Mozilla has published wiki guidance on both CP/CPS documentation and Detailed Controls Reports to help CAs prepare. The clock is ticking: CP/CPS requirements kick in July 2026, DCRs follow a year later. CAs that drag their feet on documentation quality or control transparency will find their trust decisions in Firefox under a much brighter spotlight. Expect more CAs to merge, sell, or simply retire their TLS roots rather than comply — that's the result Mozilla is after.
Source: Improving Transparency and Assurance in the Web PKI: Mozilla Root Store Policy v3.1
Domain: blog.mozilla.org
Comments load interactively on the live page.