What’s New in Version 3.0

Why a major version

The eight phases haven’t changed. Neither has the two-track model, the PKI architecture fork, the deployment environment classification, or any v2.x position I haven’t corrected here. If you’re running a program on v2.1, nothing you have built stops being right, and everything v2.x told you about how to migrate is still in the document.

What changed is what the program is for. In v2.x you were migrating. In v3.0 you’re building crypto-agility, and the PQC migration is where you start. When you’re done you should be able to swap an algorithm on a date you pick, and v3.0 makes that measurable.

If you migrate once and can’t show you could do it again, you aren’t finished.

1. Crypto-agility as method and end state

In v2.x, crypto-agility was a design principle. Every workstream was supposed to apply it and nobody owned it. I made it a funded workstream with a named owner, and the program is now measured on it.

• A dual-outcome charter. Phase 0 states readiness and agility together. If your charter funds a PQC project and says nothing about the capability you’re left with, closure has nothing to prove
• Crypto-agility funded from Year 1, with Discovery separated from the permanent Cryptographic Record. Discovery ends and the record doesn’t. Put both in one workstream and the record goes when Discovery does
• An agility criterion at every migration gate and wave exit. A system counts as migrated on four conditions. You observe the negotiated outcome in production traffic, you refuse classical-only connections and test the refusal, you change the algorithm by configuration, and you’ve rehearsed the change with rollback
• An algorithm-change rehearsal in every wave, timed across assessment, decision, change and verification
• An agility-debt register from Phase 3. A system that passes on protection and fails the configuration or rehearsal conditions is recorded as migrated with agility debt, with a dated closure event and an owner
• A closure proof. You close the program on three things. A rehearsed second algorithm change on Tier-1 systems inside the agility window, zero unaccepted agility debt, and a verification disposition for every Tier-1 and Tier-2 service
• A mechanisms catalogue, a rehearsal-based measurement method, and agility KPIs with thresholds in the Crypto-Agility foundation

One boundary I drew explicitly. Swapping to a backup HSM partition counts as a failover and state-management exercise. Its timings stay out of the rehearsed time-to-change KPI.

2. A framework that reads as a framework

• A normative convention. Must is a requirement, should is a recommendation you can depart from on the record, may is an option. Four provisions are program-level musts: the deployment environment classification, the signed accepted-gaps register, the agility criterion at every migration gate, and the closure proof. Depart from any of them and the method stops working
• An Applying This Phase block in every one of them. It names who runs the phase, the minimum viable version if your estate is small, the decision it produces and who takes it, and what it hands on
• A closing common-failure line and Challenge Questions in every phase. I wrote the questions for what your steering committee asks before it accepts a phase output
• Appendix I: ten worked artifacts across the lifecycle and at closure, invented and labeled as such, so you can see what each output looks like on paper
• Appendix J: a requirements register generated from the body text at each build, so the list can’t drift from the document it summarizes. Each of the seven documents generates its own

Phase 3 also changed how you assign a tier. The tier comes from an ordered qualitative test on Dimensions 1, 2 and 4, and the first condition that matches assigns it. The composite score sequences entries inside a tier. I publish no numeric tier bands. The composite is an uncalibrated ordinal construct, and a published band would imply an actuarial precision the method doesn’t support.

3. Evidence and records

• Evidence grades E1 to E5 on every discovery finding: runtime observed, binary confirmed, inventory declared, vendor attested, inferred. The grade attaches to the claim, and how sensitive the system is never raises it
• Coverage measured against a denominator you enumerate before discovery runs, with a signed accepted-gaps register at gate G1 to G2. What the tools found is not a denominator
• A minimum CBOM record of my own, with the five fields Phase 3 scoring consumes, and the unit of a row settled as the cryptographic use. I cite the Applied Quantum CBOM Profile by minimum version as optional machine-readable carriage, never as a requirement
• Concentration questions cross-referenced, not absorbed. When Phase 3 or Phase 7 reaches the question of how many distinct cryptographic implementations you actually run beneath four vendors, the answer belongs to the Cryptographic Concentration Framework. No document in this set computes a concentration figure
• Firmness grades on vendor dates: committed, forecast, announced, unknown. Phase 3 scores the grade independently of the calendar date, and a certification date from a program office stays forecast until the certificate issues
• A verification matrix stating positive evidence, the negative or boundary test, and the residual exposure for every cryptographic function the negotiated-protocol test doesn’t reach
• The HSM and KMS register with entropy references, the Re-Baseline Protocol, and scoring-model ratification with an appeals rule and model-risk treatment

Every scored entry also records a delivery state: available, dependent, blocked, or unknown. A blocked migration keeps the risk tier the ordered test gives it and shows up on the roadmap against its unblocking date. Difficulty changes the sequence inside a tier, never the tier.

4. Regulation stated as a mechanism

Print a list of national deadlines in a document and it goes out of date fast. You are then stuck with the error until the next edition. So the framework states the mechanism, and I keep the list somewhere I can update it.

• Three deadline archetypes: plan-by, procure-by, migrate-by. Read an instrument for which archetype it sets before you put it in a roadmap
• Five enforcement tiers, from market access through supervisory directive, binding mandate, authoritative guidance, and advisory. Phase 3’s regulatory dimension scores the tier of the instrument that binds the entry
• Three anchor instruments, one per archetype: NIST IR 8547 for deprecation and disallowance, NSA CNSA 2.0 for the procurement gate, and the EU coordinated roadmap for the dates set for Member States
• A dated snapshot, not a claim of currency. The jurisdiction roster prints as the September 2026 state. I maintain the current roster on the Global PQC Migration Clock page on PostQuantum.com and update it from the PQC Migration Brief, which is now the framework’s interim-update channel

I moved commercial vendor and product names out of the body and into a front-matter Tool and Vendor References section with an as-of date. Open-source libraries and kits stay named in the body, where you need them.

5. Corrections made in the open

When I get a published position wrong, I correct it in the open. I date the entry and quote the published wording. A correction that paraphrases the error can’t be audited against the published document. Every entry names what the earlier edition said, what’s true, the source that settles it, and, where the error changed a recommendation, what you should re-check if you acted on the published text.

In the Universal Framework

• HNDL is inference, not observation. Harvest Now, Decrypt Later is still an active planning risk, on the basis that the means, motive, opportunity and precedent for passive collection are demonstrated. You can’t observe the harvest itself, and finding no trace of it is the expected condition. Appendix F quotes three published statements at the strength their authors used, from CISA, NSA and NIST, from AIVD with CWI and TNO, and from Federal Reserve Board staff, each dated and linked
• SOC Use Case 5 is reframed as exfiltration detection weighted by confidentiality horizon. I retired the HNDL Exposure Score
• The v2.0 FIPS validation-gap statement was false when I published it. CMVP certificate #5247 issued in April 2026. Validation is now decided per product, per operation and per certificate
• CNSSP 15 now supplies the binding dates for the CNSA 2.0 schedule, with the advisory’s per-category chart recorded inside them by its own provenance and status

In the sector extensions: twelve published errors across four documents

I confirmed each one against the published June 2026 file before writing its entry. The full entries, with the published wording quoted, are in the documents.

• OT & Critical Infrastructure, three, on what IEC 61850 actually relies on for GOOSE and MMS, and on which modern OT protocols use TLS and X.509. Corrected against IEC 62351-6:2020, OPC UA Part 6, and IEEE 1815 with the 2026 DNP Users Group update
• Payments, three: the short-APDU limit, PIN translation master keys treated as needing PQC key generation, and tokens described as cryptographically irreversible. The entry separates the first as unsupported from the other two as factually wrong
• Telecommunications, three: the every-subscriber SIM reprovisioning campaign, N32 described as a single TLS-protected interface, and hybrid TLS key establishment described as requiring PQC certificate reissuance. The first changed a multi-year logistics argument, so its entry includes the re-check. If you planned against the published text, read your own EF_UST provisioning records. They decide the split between your handset population and your USIM population
• Digital Assets, three: the claimed size multiple of PQC signatures over ECDSA, the key described as the sole proof of ownership, and the 4 MB block limit, which is a units error. The limit is 4,000,000 weight units, and BIP-141 weights witness bytes at one unit and all other bytes at four

Four external reviews of the v3.0 drafts produced roughly 200 findings. Three verification rounds established which of those were real, corrected several of the reviewers’ own claims, and independently found contradictions nobody had raised. Errors I caught before publication are part of what this edition is, so I owe no open entry for them.

6. Standards currency through September 2026

RFC 9954 and RFC 10024 for hybrid TLS, with the registry rule for pure ML-KEM. RFC 9881, RFC 9882 and RFC 9814 for S/MIME, and RFC 9980 for OpenPGP. The 2026 FIPS 140-3 Implementation Guidance updates, CycloneDX 1.7 and ECMA-424, and current FN-DSA and HQC status. I state the federal CBOM-guidance and FAR directions under Executive Order 14412 as directed rulemaking, with the rules themselves still to publish. Phase 5 adds first-layer selection by architecture pattern, long-lived session and resumption handling, and pre-standard code-point retirement. PKI modernization adds the client-authentication sunset and signature placement in mixed chains. Payments and Digital Assets join the Sector Adaptation Notes.

All six sector extensions at v3.0

Each extension reads the v3.0 method for its own sector. It states what you control, and names what a standards body, a scheme, a network peer or a protocol sets for you instead. Each one generates its own requirements register.

• Financial Services. As a bank you’re crypto-agile when you can change the algorithm on your own edge, issuers and signing services on a planned date, and name the date each shared interface follows its network. Regulatory content states three named instruments: PCI DSS 12.3.3, DORA with Delegated Regulation (EU) 2024/1774 Article 6, and FINMA Guidance 05/2026. I rewrote the validation subsection to the per-product rule with CMVP certificates #5247 and #5497, and corrected the Federal Reserve attribution to staff working paper FEDS 2025-093
• Payments. The rehearsal runs on the external payment API gateway, the firmware-signing pipeline and the internal issuer. A key ceremony that generates a PQC-authorized key is the payment HSM estate’s rehearsal. Expect your scheme-set interfaces and enclosed terminal populations to be the agility-debt entries
• Digital Assets. Challenge 7 now documents the shared-verifier-defect failure mode, written from OtterSec’s disclosure of March 3, 2026, where six independent proof systems shared one verifier defect, and cross-referenced to CCF layer 2, implementation lineage. On-chain keys take the full delivery-state set, and I name every protocol change they wait on with its firmness grade
• Telecommunications. The rehearsal runs on the management plane, the SBA policy, the SEPP and the NF issuing CA. You record an interface a standard or a peer operator sets as agility debt. You read closure against the roaming and interconnect population
• OT & Critical Infrastructure. Two artifacts the Universal cites by name arrive here. Phase 1 adds the cryptographic ownership register, with The Cryptography Nobody Owns as a new sector characteristic. Phase 5 adds the Encapsulate strategy, including what the pattern doesn’t cover. The facilities estate becomes its own discovery scope, and Phase 7 adds an OT tender template that asks for agility first
• Government & Defense. This sector’s regulatory picture changed more than any other’s. The CNSSP 15 milestones of January 1, 2027, December 31, 2030 and December 31, 2031 replace the prior date summary as the binding NSS schedule. Challenge 11 is retitled Concurrent NSS and Civilian Federal Mandates and rewritten on Executive Order 14412, OMB M-26-15 and the Department of War PQC Strategy. I removed SLH-DSA from the CNSA 2.0 algorithm list, recorded the CMMC Phase 2 suspension with its instrument chain, and corrected the NCSC UK guidance date to March 2025

All seven documents cross-reference the companion book, Quantum Ready, and name Quantum Academy for the trainings and certifications matching the roles in Skills & Team Structure.

Version history

The framework is free and open at PQCFramework.org under CC BY 4.0. There’s no email wall.

I publish my surveys of the global PQC migration framework landscape at PQCFramework.org/research.