What’s New in Version 2.0

Why a major version

Version 1.1 provided an 8-phase execution methodology validated through real migration programs. Between March and June 2026, three developments exposed gaps that a point release could not address.

The deployment environment fractured. Organizations entering Phases 5 and 6 discovered that the FIPS 140-3 validation gap, contradictory jurisdictional guidance on hybrid deployment, and the emerging Merkle Tree Certificate architecture created deployment constraints that no framework had modeled. Migration planning could no longer assume a uniform deployment path.

Key exchange and signature migration diverged. Hybrid key exchange (ML-KEM + X25519) is deployable now. Signature migration depends on PKI architecture decisions, FIPS validation timelines, and the MTC standardization path that remain unresolved. Treating these as a single prioritized sequence caused organizations to under-invest in whichever track was not their starting point.

Operational security was missing. Programs that reached production deployment had no framework guidance for SOC detection of cryptographic drift, incident response for PQC-specific scenarios, or the GRC instruments needed to govern a multi-year migration at the board level. The framework told organizations how to migrate but not how to verify the migration was holding or how to govern it with the same discipline applied to other material risks.

Three methodological changes

1. Two-Track Migration Model

What changed

Key exchange migration (Track A, driven by HNDL exposure) and signature/authentication migration (Track B, driven by TNFL risk and PKI evolution) are now treated as parallel tracks with different urgency drivers, deployment patterns, and infrastructure dependencies.

Why

Track A can be executed today using hybrid key exchange with available libraries and browser support. Track B depends on PKI architecture decisions (X.509 with PQC algorithms vs. Merkle Tree Certificates), FIPS 140-3 validation of signing modules, and certificate lifecycle automation. Treating them as a single sequence causes organizations to either delay key exchange protection while waiting for signature readiness, or neglect signature migration because key exchange feels “done.”

Where in the framework

Introduced in Phase 3 (risk scoring separates HNDL and TNFL dimensions), fully specified in Phase 5 with track-specific deployment patterns, and reflected in the Phase 4 roadmap construction guidance.

2. PKI Architecture Fork

What changed

Phase 6 now takes a definitive position on the emerging split in post-quantum PKI architecture: Merkle Tree Certificates (MTCs) for public Web PKI, and X.509 certificates with PQC signature algorithms for internal enterprise PKI.

Why

Let’s Encrypt committed to MTCs as its path to post-quantum Web PKI (June 3, 2026), targeting production readiness in 2027. Google Chrome’s stated preference for MTCs and Cloudflare’s parallel testing confirm the direction. Organizations that planned PKI migration as a straightforward algorithm swap now need to plan for two parallel architectures.

Where in the framework

Phase 6, “PKI Architecture Evolution” section, with classification guidance for mapping PKI deployments to the appropriate architecture.

3. Deployment Environment Classification

What changed

A four-tier classification system (Unrestricted, FIPS-Aware, FIPS-Required, CNSA 2.0) determines when and how PQC can enter production for each class of system.

Why

As of June 2026, no FIPS 140-3 validated cryptographic module offers PQC algorithms in approved mode. For regulated environments, this gap determines deployment sequencing. An “Unrestricted” web application can deploy hybrid TLS today; a “FIPS-Required” payment processing system cannot until validated modules exist. The framework needed to model this constraint explicitly.

Where in the framework

Phase 5, “Deployment Environment Classification” section, with environment-class-specific deployment guidance feeding into Phase 4 roadmap construction.

New Program Foundation sections

SOC Implementation

A complete specification for the Security Operations Center’s role in PQC migration and ongoing quantum security.

• Five detection use cases with illustrative rules and thresholds: hybrid downgrade detection, cryptographic drift monitoring, certificate lifecycle anomalies, TNFL/signature integrity monitoring, and enhanced HNDL-indicator detection
• A three-horizon quantum cyber threat intelligence model (tactical, operational, strategic) with source requirements, skills assessment, and the quarterly Quantum Threat Landscape Assessment
• Four incident response playbooks: PQC algorithm vulnerability disclosure, confirmed hybrid downgrade attack, credible CRQC announcement, and emergency algorithm rotation
• Five tabletop exercise scenarios designed for SOC/CTI teams
• Seven SOC-specific metrics with illustrative targets
• Skills and tooling gap assessment (protocol parsing, CTI skills, east-west visibility)
• A four-phase SOC implementation roadmap

Why

Every SOC detection capability depends on the migration program’s cryptographic posture registry, and every migration program depends on the SOC to verify that migrated systems stay migrated. No published PQC migration framework before v2.0 specified SOC detection capabilities, quantum-specific incident response, or CTI requirements.

GRC Implementation

The governance, risk, and compliance instruments needed to make PQC migration governable, measurable, and auditable.

• Quantum risk appetite statement templates with strategic-level and operational-level tolerances (HNDL exposure, TNFL exposure, regulatory compliance buffer, crypto-agility adoption)
• A 17-indicator cascading Key Risk Indicator framework across three organizational levels (board quarterly, CISO monthly, operational weekly/real-time), each with illustrative thresholds
• Regulatory intelligence process specification: sources, quarterly Regulatory Horizon Report format, escalation criteria
• Third-party quantum readiness assessment: vendor tiering, assessment mechanics, CBOM requirements for Tier 1 vendors, contractual provisions, concentration risk and substitution planning
• Audit and assurance: what to audit, evidence artifacts, audit timing
• Insurance implications and preparation
• The GRC-SOC handoff: four specific data flows connecting GRC outputs to SOC detection capabilities
• A four-phase GRC implementation roadmap

Why

The GRC function produces the instruments the board uses to oversee the program, the CISO uses to manage it, and internal audit uses to verify it. Without risk appetite statements, cascading KRIs, and a regulatory intelligence process, PQC migration programs operate without the governance infrastructure that regulated organizations apply to every other material risk. No published framework provided these instruments before v2.0.

Expanded Program Foundation sections

Governance (Phase 0)

The governance reference paragraph in Phase 0 has been replaced with a full subsection under Activity 0.3 (Establish Governance Structure), covering program leadership (CISO-led vs. CIO-led vs. joint, with evidence-based recommendation), board oversight (minimum engagement model with quarterly KPIs and escalation triggers), risk appetite statement templates (strategic and operational tolerances), three lines of defense mapping for PQC migration, cascading key risk indicators, and operational security integration.

Why

The two most common questions from organizations starting Phase 0 are “who should lead this?” and “how does the board oversee it?” The previous version pointed to external articles for answers. The framework now contains the full guidance.

Crypto-Agility

Expanded from six architectural principles and an OKR table to a full operational discipline: five dimensions of crypto-agility (architectural, operational, governance, skills, supply chain), each with a testable criterion; seven architecture principles (added approved algorithms policy with enforcement); a four-year implementation roadmap integrated into the migration phases; six OKRs with measurement methods; and NIST CSWP 39 alignment analysis.

Why

Organizations reported that the architectural principles were the easy part. The hard part was the operational, organizational, and process transformation. A system with a perfect abstraction layer is not crypto-agile if the organization has no process for deciding when to swap algorithms, no monitoring to verify the swap propagated, and no team trained to evaluate the replacement.

Skills & Team Structure

Expanded from a six-row roles table and brief training list to a full section: team sizing heuristics (one FTE per 500 CBOM instances for the first two years), a build/borrow/buy decision matrix for six capability areas, a four-level training approach with specific audiences and outcomes, the crypto champion program, and guidance on sustaining capability beyond the migration.

Why

The previous version told organizations what roles they needed. It did not tell them how many people, whether to hire or contract, how to train existing staff, or how to ensure the capability outlasts the program.

Additional updates

Cost estimation methodology. An eight-category cost driver taxonomy (discovery tooling, cryptographic engineering labor, infrastructure modernization, vendor upgrade costs, testing and validation, training, program management, opportunity cost of deferred modernization) integrated into the Phase 0 business case. The survey of 80+ frameworks found cost estimation “almost entirely absent” across the global landscape.

Regulatory timeline convergence (2026–2030). A consolidated timeline of 14+ regulatory deadlines converging in a 48-month window, from the September 2026 FIPS 140-2 sunset through the 2030 CNSA 2.0 software compliance deadline. Includes new developments since v1.1: the EU NIS2 PQC amendment (January 2026), the G7 PQC Roadmap for Financial Sector (January 2026), and NIST’s additional digital signature candidates (May 2026).

Multinational regulatory navigation. A “highest common denominator” strategy for organizations operating across jurisdictions with contradictory hybrid deployment guidance: deploy hybrid as default, document a pure-PQC transition plan, evaluate pure PQC for new deployments.

Algorithm pipeline update. Updated coverage of FN-DSA (draft FIPS 206), HQC (selected March 2025, standard forthcoming), nine additional signature candidates advanced to the third round (May 2026), and CNSA 2.0 algorithm requirements (ML-KEM-1024, ML-DSA-87 mandatory for national security systems).

Deployment ecosystem status. Current PQC deployment data integrated into Phases 5 and 6: library readiness (OpenSSL 3.5+, BoringSSL, AWS-LC, Go, .NET), browser support (Chrome 131+, Firefox 132+, Safari 26+, Edge 131+), HSM firmware status, and cloud platform capabilities.

Objection-handling reference (Appendix F). Evidence-based responses to eight common organizational objections to PQC migration, each grounded in specific data points.

Sector extensions. All existing sector extensions (Financial Services, Telecommunications, Government & Defense, Critical National Infrastructure/OT) updated to reflect v2.0 methodology, including two-track model adaptations, deployment environment classification per sector, and updated regulatory timelines. Two new sector extensions published: Payments (separated from the Financial Services extension into a dedicated document, reflecting the complexity of cross-border payment flows, real-time payment systems, card network cryptographic dependencies, and the BIS Leap Phase 2 findings) and Digital Assets (covering blockchain protocols, DeFi smart contract cryptographic dependencies, custodial wallet infrastructure, and the unique challenges of migrating systems where cryptographic algorithms are embedded in consensus mechanisms and on-chain logic).

Version history

The framework is free, open, and available at PQCFramework.com under CC BY 4.0.

Comprehensive surveys of the global PQC migration framework landscape are published at PQCFramework.com/research.