CA/Browser Forum vs PKIC — who actually enforces what
Two bodies appear constantly in PQC migration conversations: the CA/Browser Forum and the PKI Consortium. People confuse them. Vendors cite them interchangeably. Compliance teams treat them as equivalent. They are not. Understanding exactly what each one does, and specifically what power each one has, is essential for reading migration timelines and vendor claims accurately.
Unit 2 progress
By the end of this lesson you will be able to
Explain what the CA/Browser Forum is and what its Baseline Requirements actually require
Explain what the PKI Consortium is and what power its frameworks actually carry
Describe how CA/B Forum requirements become enforceable, the browser trust store mechanism
Distinguish between PKIC guidance (influential but voluntary) and CA/B Forum requirements (enforced via trust stores)
Explain what it means practically when the CA/B Forum passes a ballot requiring ML-DSA
Part 1 — Side by side: the two bodies
Both organizations are voluntary. Neither has legal authority. But their mechanisms of influence are completely different, and the difference has direct consequences for your migration timeline.
Governance / enforcement
CA/Browser Forum
What it is
A voluntary consortium of certificate authorities and browser/OS vendors. Produces the Baseline Requirements (BR), the rules for what a publicly-trusted TLS certificate must contain and how CAs must operate.
Members
CAs (DigiCert, Let's Encrypt, Sectigo, GlobalSign…) + browsers/OS (Google, Apple, Microsoft, Mozilla). Both groups vote on ballots.
Enforcement mechanism
Browser and OS vendors embed root certificates in their trust stores. A CA that violates the Baseline Requirements loses trust store inclusion, their certificates stop being trusted by Chrome, Safari, Firefox, Windows, macOS. This is a commercial death sentence for a public CA.
How requirements pass
Ballot process: a ballot is proposed, discussed for 7 days, then voted on by both CA and browser members. Requires majority support from each group. Once passed, requirements have a specific effective date.
Hard enforcement via trust stores
Influence / frameworks
PKI Consortium (PKIC)
What it is
A voluntary, nonprofit industry collaborative of 390+ members: CAs, vendors, enterprises, governments, academics. Produces frameworks (PQCMM, PKIMM), guidance documents, and reference materials.
Members
Open membership. Security vendors, CAs, enterprises, government agencies, academics. No browser vendors as a voting bloc.
Enforcement mechanism
None directly. PKIC cannot remove anyone from a trust store. Its frameworks gain authority through adoption, when regulators, procurement requirements, or compliance frameworks cite PKIMM or PQCMM, those documents become effectively mandatory in specific contexts.
How guidance passes
Working groups produce guidance documents through consensus. No formal ballot process. Output is recommendations, frameworks, and reference materials, not binding requirements.
Influence through adoption and citation
Part 2 — How the CA/B Forum actually enforces things
The CA/B Forum's power deserves a closer look because it is non-obvious. The Forum has no legal authority. It cannot fine anyone. It cannot issue subpoenas. It enforces its requirements through a single mechanism: browser and OS trust store inclusion. Understanding this mechanism explains why CA/B Forum requirements are effectively mandatory for any CA that wants to serve public TLS certificates.
1
CA/B Forum passes a ballot
A ballot requiring, for example, that all new TLS certificates use ML-DSA by a specific date passes with majority support from both CA and browser member groups. The ballot includes an effective date, typically 12–18 months in the future to give the ecosystem time to prepare.
Voluntary vote — no legal force yet
2
Browser vendors update their root programs
Google (Chrome Root Program), Apple (Apple Root Certificate Program), Mozilla (Mozilla Root Store Policy), and Microsoft (Microsoft Trusted Root Program) each incorporate the CA/B Forum requirements into their own root program policies. These policies define what CAs must do to remain in each browser's trust store.
Requirement is now enforceable by browsers
3
CAs must comply or face removal
A CA that fails to comply with the Baseline Requirements by the effective date faces removal from browser trust stores. Once removed, every certificate that CA has issued stops being trusted by that browser. This affects every website that uses the CA's certificates, a commercial catastrophe. CAs comply.
Real commercial consequence — compliance is not optional
The requirement propagates to all certificate users
When the CA migrates to ML-DSA, every new certificate it issues uses ML-DSA. Every organization that receives a certificate from that CA automatically benefits from the migration. The CA/B Forum requirement propagates through the entire certificate ecosystem via the trust store mechanism.
Ecosystem-wide migration happens through the CA layer
This chain explains why the CA/B Forum's PQC ballot timeline matters so much to your migration planning. When the Forum passes a ballot requiring ML-DSA certificates, every major public CA will migrate within the specified window, and all certificates they issue to you will automatically use ML-DSA. Your Track 2 certificate migration is therefore partly gated on the CA/B Forum timeline, not just your own readiness.
Part 3 — The CA/B Forum PQC ballot process: where things stand
As of 2025, the CA/B Forum has not yet passed a ballot mandating ML-DSA for TLS certificates. The discussion is active. The working group that would drive this ballot is the Server Certificate Working Group (SCWG). The key question being debated is timing and transition approach, specifically how to handle the hybrid certificate period and backward compatibility.
1
Pre-ballot discussion (2023–2025): SCWG members have been discussing PQC certificate requirements, algorithm choices, and transition approaches. PKIC TCWG has contributed reference materials to inform this discussion.
2
Ballot proposal (expected 2025–2026): A formal ballot proposing ML-DSA requirements for TLS certificates will be drafted. Expected to include a hybrid certificate transition period allowing both classical and ML-DSA signatures simultaneously.
3
Voting and effective date: Once passed, ballots typically include an 18–24 month implementation window. A 2026 ballot passing would suggest a 2027–2028 effective date for ML-DSA requirements in new TLS certificates.
4
CA migration and new certificate issuance: Once the effective date passes, public CAs begin issuing ML-DSA certificates (likely hybrid initially). Your new TLS certificates will use ML-DSA. Existing certificates continue until expiry.
BFor SMB decision-makers: the CA/B Forum timeline is the mechanism that will drive your public TLS certificate migration whether you act or not. When the Forum mandates ML-DSA and your CA complies, your next certificate renewal will automatically use ML-DSA, you don't need to do anything except ensure your web server supports the new certificate format. The migration you need to drive yourself is your internal PKI, VPN, and any non-TLS certificate infrastructure.
AFor motivated learners: the CA/B Forum ballot process is publicly documented at cabforum.org. Reading the ballot discussions in the Server Certificate Working Group mailing list archives is one of the best ways to understand how industry-scale PKI policy is actually made. It is also the venue where you might eventually contribute: PKIC members can participate in TCWG, which feeds into CA/B Forum discussions.
Part 4 — What PKIC guidance does and does not do
PKIC's influence operates differently from the CA/B Forum's. PKIC cannot remove anyone from a trust store. But PKIC has produced frameworks, the PQCMM and PKIMM, that are increasingly cited by regulators, procurement requirements, and compliance frameworks as the basis for assessing PQC readiness. When a government agency says "demonstrate PKIMM Level 3 compliance," PKIC's voluntary guidance has become effectively mandatory for that context.
Scenario
CA/B Forum role
PKIC role
Public TLS certificate migration
Mandates algorithm requirements via Baseline Requirements. Hard deadline enforced through trust stores.
Advisory: TCWG provides technical guidance to inform CA/B Forum ballots. No direct enforcement role.
Government agency PQC compliance assessment
Not directly involved in government-internal PKI requirements.
PKIMM self-assessment is the tool agencies use. PQCMM maturity levels are referenced in emerging procurement requirements.
Enterprise procurement vendor evaluation
Relevant if vendor issues public certificates, their CA compliance matters.
PQCMM level is increasingly used in procurement questionnaires as a vendor readiness metric.
Internal PKI migration planning
Only relevant for certificates issued by public CAs. Internal CA migration is not directly governed by CA/B Forum.
PKIMM provides the framework for assessing internal PKI program maturity. PQCMM guides migration level assessment.
CFor IT professionals: the practical split is clean. For public-facing TLS certificates, the ones your web servers present to browsers, CA/B Forum requirements govern the algorithm and timeline. You don't have to do anything except accept new certificates from your CA when they migrate. For internal PKI (your private CA, internal certificates, code signing, VPN), CA/B Forum has no authority, you own the migration timeline and the PKIMM framework is the right assessment tool for your program maturity.
Part 5 — A third enforcement model: regulation
The CA/Browser Forum and PKIC represent two ends of a governance spectrum: industry-led enforcement through trust store control, and expert consensus through voluntary frameworks. There is a third model that this course's audience encounters in practice and that has direct bearing on PQC migration timelines: statutory regulation with penalties. Three frameworks in this category are now live or actively enforced and are directly relevant to PQC migration planning.
Unlike the CA/Browser Forum, whose enforcement relies on the commercial consequences of trust store exclusion, and unlike PKIC, whose frameworks gain authority through voluntary adoption, these regulatory frameworks are backed by financial penalties, enforcement by supervisory authorities, and in the Canadian government's case, by mandatory departmental reporting obligations. For organizations in scope, these are not optional frameworks to adopt when convenient. They are compliance obligations with deadlines.
Regulatory enforcement frameworks: direct PQC relevance
Framework
Scope
Key PQC obligation
Effective date
Penalty
CCCS ITSM.40.001
Government of Canada departments and agencies (non-classified systems)
Departmental PQC migration plan by April 2026; high-priority systems migrated by end of 2031; all systems by end of 2035
June 23, 2025 (SPIN effective October 9, 2025)
Policy compliance: TBS reporting obligations; non-compliance with Policy on Government Security
EU NIS2 (Directive 2022/2555)
Essential and important entities across 18 critical sectors in all EU member states
Article 21 requires cryptography and encryption as a security measure; Article 21 also requires supply chain security. Suppliers' PQC readiness is a due-diligence obligation
Transposition deadline October 2024; now national law across EU member states
Up to €10M or 2% of global turnover (essential entities)
EU DORA (Regulation 2022/2554)
21 types of EU financial entities and their critical ICT third-party providers
ICT risk management framework must address evolving threats including cryptographic risk; Chapter V requires assessment of ICT third-party risk including vendor cryptographic resilience
January 17, 2025: in force and being enforced
Up to €10M or 10% of annual global turnover; individual liability up to €1M
AFor motivated learners: understanding the difference between these three governance models (industry enforcement via the CA/B Forum, framework influence via PKIC, and statutory regulation via NIS2, DORA, and ITSM.40.001) is a level of policy literacy that most technical practitioners lack. Being able to explain which body governs which obligation in a specific client or organizational context is the kind of expertise that gets you into rooms where migration decisions are made.
BFor SMB decision-makers: if your business operates in the EU financial sector, DORA's ICT risk management requirements mean your vendors' PQC readiness is your compliance problem, not just their product roadmap. The Chapter V third-party risk management requirements require you to assess and monitor ICT service providers' resilience, including cryptographic risk. If you operate any business in the EU across critical sectors, NIS2 requires cryptography as a security measure in your supply chain assessment. Neither regulation explicitly names PQC yet, but ICT risk management frameworks that ignore quantum risk are increasingly difficult to defend to supervisors.
CFor IT professionals working in or with Canadian federal departments: ITSM.40.001 means your organization needs a departmental PQC migration plan by April 2026. That plan requires the same elements this course covers: cryptographic inventory (CBOM), vendor assessment, migration sequencing, and executive briefing. The course's Unit 3 CBOM work and Unit 4 migration planning directly produce the artefacts that ITSM.40.001 requires.
How does the CA/Browser Forum enforce its Baseline Requirements without having any legal authority?
Question 2 of 5
An organization's IT team says: "We don't need to worry about PKIC's PQCMM requirements, they're voluntary and have no enforcement mechanism." What is the most accurate response?
Question 3 of 5
When the CA/Browser Forum eventually passes a ballot mandating ML-DSA for new TLS certificates, what happens to an organization's public-facing HTTPS certificates without any action from the organization?
Question 4 of 5
A Canadian federal department's IT director says the ITSM.40.001 roadmap is useful guidance but their department will decide its own timeline based on budget availability. What is the most accurate assessment of this position?
Question 5 of 5
Under EU DORA, a bank's CISO argues that their internal cryptographic practices are sound and they have no obligation to assess their ICT vendors' quantum readiness since DORA does not explicitly mention post-quantum cryptography. Is this argument sound?