What’s New in Version 2.1

Version 2.1: positions, closure, and a complete suite

Version 2.0 introduced the structures: the two-track migration model, deployment environment classification, the PKI architecture fork, and the SOC and GRC foundations. Version 2.1 takes positions inside those structures, closes the program lifecycle, and brings every sector extension onto the same baseline.

Universal Framework: new positions

Where v2.0 modeled the constraints, v2.1 states what to do inside them:

• Hybrid and composite signatures. An explicit position on the contested signature question, complementing the settled hybrid key exchange guidance on Track A
• Algorithm-specific vulnerability weighting added to Phase 3 risk scoring, grounded in ECC/RSA quantum resource analysis. ECC is not a safe harbor; estates heavy in elliptic curve cryptography score differently than RSA-era assumptions suggest
• SP 800-208 hash-based signatures foregrounded as the deploy-now component of Track B, with firmware and code signing as the immediate application
• The identity and authentication stack brought into Track B scope, alongside Activity 3.3 sequencing harmonized with the two-track model

Universal Framework: new sections and activities

• Activity 2.5: Secure the CBOM and Program Artifacts. The cryptographic inventory is a precise map of where an organization is weakest. v2.1 specifies how to protect the program’s own artifacts as the sensitive targeting data they are
• Migration Verification & Program Closure. A new section covering how to prove the migration held: verification methodology, decommissioning, and the evidence dossier, including its role as litigation defense. A migration you cannot prove is a claim, not a control
• Data-at-rest decision framework (Activity 5.6). A per-store decision method: re-encrypt, key-wrap, or delete, driven by confidentiality horizon against asset and media life
• AI-assisted migration position (Activity 5.7), with a corresponding Phase 1 tool category for AI-assisted discovery and code transformation
• Counterparty coordination (Activity 7.6) for the dependencies an organization cannot compel: payment counterparties, roaming partners, federation peers
• Cloud shared responsibility and SaaS (Activity 7.7), separating what cloud providers will migrate from what remains the customer’s problem
• Accelerated Execution Profile (Activity 4.7) for organizations that must compress the standard sequencing

Universal Framework: further additions

Reference program economics (Activity 0.2c) and the confidentiality-horizon method (Activity 1.1); M&A due diligence and procurement model-language references; a risk-weighted coverage KPI; algorithm sovereignty and standards fragmentation; crisis communications and industry information sharing in the GRC section; a skills matrix, role-based reading paths, and right-sizing profiles; additional common failures and benefit arguments; and two new appendices: a framework crosswalk (Appendix G) and a protocol coverage matrix (Appendix H). The web PQC adoption datapoint was corrected to its F5 Labs mid-2025 attribution.

Three extensions move directly to v2.1

The Government & Defense, CNI/OT, and Telecommunications extensions move directly from v1.1 in major alignment releases, adopting the v2.0 structural foundations and the v2.1 positions in a single step. Each gains a new Alignment with Universal Framework v2.1 section, mapping the two-track model, the FIPS validation gap, and the Merkle Tree Certificates position onto its sector, followed by six v2.1 position subsections. Each also gains a new Challenge 11:

• Government & Defense — Two-Speed Federal Mandates. The 2026 bifurcation of US federal PQC policy: hard gates for national security systems, discretion for civilian agencies. Challenge 1 gains the January 1, 2027 CNSA 2.0 acquisition gate and the late-2026 compliance sequence; Challenge 9 gains the allied hybrid-mandate divergence (BSI and ANSSI mandates against the NSA standalone position). The regulatory map and Further Reading reflect the June 2026 state, including the CNSA 2.0 article series
• CNI/OT — Process Historians and Long-Horizon Operational Data. The data-at-rest decision framework applied to the OT data estate, where the confidentiality horizon is set by the plant, not the record. The alignment section carries the OT inversion (Track B leads) and the FIPS validation gap compounded by safety certification. Challenge 10 gains the EU coordinated roadmap dates (national strategies end-2026, high-risk and critical use cases by 2030, the remainder by 2035) and the COM(2026) 13 proposal naming PQC in NIS2; the regulatory map gains CISA/DHS OT guidance
• Telecommunications — The 6G Standardization Window. A once-per-generation opportunity now open: 3GPP Release 19 froze in March 2026 with SA3’s quantum-safe protocol inventory complete, Release 20 carries the 6G studies and an approved PQC transition study, and Release 21 will produce the first normative 6G specifications. The regulatory map reflects the June 2026 standards state, including GSMA PQ.03 v2.0 and PQ.07 (non-terrestrial networks)

Financial Services, Payments, and Digital Assets: targeted alignment

The three extensions already on v2.0 receive targeted alignment releases. Each gains six new alignment subsections mapping the v2.1 positions into sector terms: Financial Services covers hybrid and composite signatures as the Track B default and why ECC is not a safe harbor; Payments covers composite and dual signatures under payment message size constraints and the EMV ECC transition, and adds payment passkeys to the mobile wallet challenge; Digital Assets covers where the custodial hybrid default meets protocol-governed on-chain signature schemes. Each also receives editorial corrections, including a Phase 3 dimension-count fix (Financial Services, Payments) and Merkle Tree Certificates wording aligned with the Universal Framework position (Financial Services).

Suite-wide changes

All seven documents gain cross-references to the companion book, Quantum Ready, which provides the reasoning behind each phase, extended case examples, and guidance for leading the program from the first board conversation through closure. The full suite also received an editorial revision for prose clarity and consistency.

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.

Version 2.0: 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.

Version 2.0: 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.

Version 2.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.

Version 2.0: 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. The Financial Services extension was updated to the v2.0 methodology, and two new sector extensions were 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). The Government & Defense, CNI/OT, and Telecommunications extensions remained on v1.1 at the v2.0 release and move directly to v2.1, above.

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.