PQC Migration Framework v3.0: Build the Ability to Change Again

Table of Contents

I have just published version 3.0 of the PQC Migration Framework, covering the Universal edition and all six sector extensions. Alongside it are two new companion frameworks co-authored with Steve Vaile: the Cryptographic Concentration Framework and the Applied Quantum CBOM Profile, both at v1.0 release candidate. All three are free, licensed CC BY 4.0, and usable without ever talking to me or Applied Quantum.

The methodology grew out of enterprise migration programs at telecoms and financial institutions. One program alone ran to more than 120,000 tasks. Roughly a quarter of those tasks changed any cryptography. The other three quarters covered governance, vendor engagement, training, policy, infrastructure modernization, testing and operational integration. Changing the algorithms is the smaller part of the job. The rest is an enterprise transformation program that runs for years and reaches procurement, audit, training, every internal department, and every supplier you depend on. Which is exactly why we need frameworks like these.

An organization should have to stand up a program like this only once. The key change in version 3.0 is that crypto-agility now leads the program. The program does not close until the organization has made a second algorithm change, rehearsed and timed. If you are running a PQC migration program, or about to start one, version 3.0 of the PQC Migration Framework is the most operationally complete methodology I have found.

You can also ignore the agility framing and run version 3.0 as a straight one-off PQC migration methodology. The eight phases work that way, and I have not found anything that covers a single migration as completely. I would not do it, however. A program built that way leaves you able to change your cryptography exactly once, and the next change starts from scratch.

The framework started as an internal document in March 2023, went public in full in June 2025, and is now at version 3.0. Earlier editions have been downloaded more than 20,000 times. The March 2026 survey of more than 80 published PQC frameworks found no other single framework covering the full lifecycle at operational depth, from executive mandate through vendor governance. That includes sector extensions, worked artifacts, a requirements register and a crosswalk to the frameworks you have already adopted. I keep that survey public so anyone can check the claim. If I have missed a framework that covers ground mine does not, I will add it to the next edition and credit it.

Each of the three documents answers a question put to me during those programs or after them:

• From the program teams. How do we finish this migration and come out of it able to change again? Answering it reorganized the program around crypto-agility, and that is why this is a major version.
• From second-line risk and operational resilience teams. Where could one cryptographic defect affect several suppliers we believed were independent? Steve Vaile and I wrote the Cryptographic Concentration Framework to answer that: twelve documents and a reference implementation.
• From engineers and tooling vendors. What do we have to write down about our cryptography so that either of those questions can be answered from the data? That is the purpose of the CBOM Profile, open for comment through October 31, 2026.

Two outcomes before a program can close

Picture the end of a large PQC migration. The priority systems are upgraded and the dashboard is green. The steering committee is a month from accepting closure. Then a vulnerability is disclosed in an implementation you deployed eighteen months ago.

How quickly can you establish what is affected? Who can authorize the change? Can the affected systems switch algorithm by configuration? Will your counterparties accept the alternative? Has anyone rehearsed the rollback? If you cannot answer those today, you will be answering them during an incident.

In v3.0, a program has to deliver two outcomes before it can close. The first is unchanged: post-quantum protection that meets your obligations by their deadlines. The second is crypto-agility, the capability you retain for the next algorithm change, whether that change follows a vulnerability, a revised standard, a supplier failure or a new obligation. Four things make it up: the records, the ownership, the decision process and the technical mechanisms.

The PQC migration is your first algorithm change. The program closes when you can make the second one on a date you choose.

Why the method is crypto-agility

Version 3.0 states the program in four lines:

1. The mandate is readiness against your dated obligations.
2. The method is crypto-agility.
3. The first exercise of that method is the PQC migration.
4. The end state is an organization that changes cryptography on a planned date and keeps that capability under a named owner, funded, after the program closes.

That ordering is the substantive change in version 3.0. Crypto-agility is the capability worth building, and the quantum deadlines are what finally pay for it.

We have been here before. MD5, SHA-1, DES, 3DES, SSL and early TLS all fell to attacks or obsolescence, and organizations that had hardcoded them faced expensive emergency migrations.

SHA-1 is the recent case. Google and CWI Amsterdam published a practical collision in February 2017. The major browsers had begun refusing SHA-1 certificates a month earlier. Organizations still issuing them found out how many places a hash algorithm can hide.

The post-quantum algorithms will go through the same cycle, and they start from a shorter track record than the ones they replace. NIST is standardizing HQC as a non-lattice backup to ML-KEM, so that the whole transition does not rest on one branch of mathematics. NIST’s additional signature process is still running. Classical cryptanalysis has not stopped. AI-assisted work shortens the interval between a mathematical idea and a practical attack, and that interval is all the notice you get. A serious result against a lattice scheme would put every hardcoded ML-KEM deployment in the same position as the SHA-1 estates in 2017.

The same work prepares you for three different events, each on its own clock:

• A cryptographically relevant quantum computer.
• A standardized algorithm weakened under classical or AI-assisted cryptanalysis.
• The routine deprecation cycle that retired SHA-1 and 3DES.

Only the first has a regulator behind it. That is why you name both outcomes in the charter. The deadlines, the audits and the funding attach to the PQC migration, because that is what regulators wrote down. No regulator has set a deadline for your time-to-change. So you fund agility through the migration. That puts the work inside a program the board has already approved, instead of a separate initiative nobody sponsors.

I have not found another published migration methodology that treats agility as the program’s method and measures it by rehearsal instead of by architecture review. NIST CSWP 39, updated in June 2026, surveys the approaches, the challenges and the trade-offs. NIST calls it a starting point, and says the actionable, environment-specific mechanisms still have to be built on top of it. This framework aligns with CSWP 39 and supplies one of those mechanisms:

• a rehearsed time-to-change you can measure;
• a five-dimension assessment covering architecture, operations, governance, skills and supply chain; and
• agility work carried inside the migration phases instead of alongside them.

The landscape survey behind that claim is public. If someone shows me an earlier agility-led methodology, I will credit it in the next edition.

You do not have to start from agility. The eight phases work as a migration program on their own, and nothing in a v2.1 program becomes invalid. You add agility as a workstream with an owner in Phase 0, a criterion at the gates, a rehearsal inside each wave, and a condition at closure. If your board funded a migration and not a capability, run the migration. Use the first rehearsal record to make the case for the capability.

I kept my summary in the Crypto-Agility foundation: the effort to change cryptography in a system is inversely proportional to the agility built into it from the start. In shorthand, Y ≈ K / A, where K is the complexity of the estate and A its agility. v3.0 is explicit that this is a design heuristic, with no units and no calibration. The only number I trust here is the one a rehearsal produces.

What the framework covers

I organized the methodology into eight phases:

• Phase 0: Executive Mandate and Business Case
• Phase 1: Discovery and Inventory
• Phase 2: CBOM and Documentation
• Phase 3: Risk Scoring and Prioritization
• Phase 4: Roadmap and Governance
• Phase 5: Pilots and Migration Execution
• Phase 6: Infrastructure Modernization and Performance
• Phase 7: Vendor and Supply Chain Governance

After Phase 7 comes a verification and closure stage. Seven program foundations, from the maturity model through SOC and GRC implementation, apply across every phase. Every sector runs the same eight phases. The binding constraint is different in each one, and in six sectors it is different enough that I wrote a separate document:

• Financial Services. The CBOM itself becomes a target. It maps the HSM estate, the long-retention data stores and every unmigrated interface, which is a target-selection document for anyone who gets a copy.
• Payments. Almost 20 billion cards are in circulation, most of them on 32-bit processors with 48 KB of RAM, and terminal fleets turn over every 7 to 15 years. No single party can coordinate an upgrade across cardholder, merchant, acquirer, network and issuer.
• Digital Assets. The cryptography is the asset, not the envelope. Changing the signature scheme needs consensus among thousands of independent node operators, and coins whose private keys are lost can never be migrated at all.
• Telecommunications. The operator does not own the code running on most of its network, and cannot deploy a post-quantum SUPI concealment scheme until 3GPP has specified it.
• OT and Critical Infrastructure. Equipment runs 15 to 30 years, sometimes past 40, on processors with kilobytes of memory and cryptography burned into firmware. TNFL outranks HNDL here, because a forged control instruction does physical damage.
• Government and Defense. CNSA 2.0 and CNSSP 15 already set the dates, and classification periods of 25 to 75 years mean the HNDL window opened long ago.

Read the Universal first, then your sector’s extension. An extension is not a standalone document. It adds inventory tracks, re-weights the risk scoring and changes activities inside phases you will already have read, and it assumes the Universal is open beside it. Some readers need two: a bank running card payments takes Financial Services and Payments, because Payments is the specialization of that sector rather than a substitute for it.

Two tracks run through the methodology because the threats have different timelines. Track A covers confidentiality against harvest now, decrypt later (HNDL): traffic recorded today is decrypted when a capable machine exists. Track B covers integrity and authentication against what I have called trust now, forge later (TNFL) since 2018: a forged signature becomes a problem only when the machine exists.

Key establishment and signatures follow separate schedules with distinct dependency chains. A program that treats them as one workstream ends up doing signatures last, which is the wrong order for anyone whose certificates have counterparties.

The US has now put dates on that split. Executive Order 14412 requires PQC key establishment on federal high-value assets by December 31, 2030 and PQC digital signatures by December 31, 2031. OMB Memorandum M-26-15 implements it for civilian agencies through a five-phase schedule ending in 2035. The required migration plans are due on October 22, 2026. I have treated the two-track model as foundational since v2.0, and regulators are now writing it into binding requirements.

My test for every recommendation has not changed: could a CISO assign this to someone next Monday? Where the right answer depends on context, you get a decision tree instead of “it depends.” Each phase ends with an Applying This Phase block naming who leads it, the minimum viable version for a small estate, the decision it produces and what it hands on. Challenge Questions for the steering committee follow.

The methodology was validated at the scale of that 120,000-task program and scales down through four right-sizing profiles, from under 2,000 employees to hyperscale multi-entity groups. What changes with size is which activities merge and how much governance you need. The questions stay the same.

What changed in v3.0

The eight phases did not change. The two-track model, the PKI architecture fork, the deployment environment classification and every v2.x position I have not corrected still stand. If you are running a program on v2.1, everything you have built remains valid. What v3.0 changes is what it takes to close the program.

In v2.x you were migrating. In v3.0 you are building the ability to change your cryptography on a date you choose, and the PQC migration is the first time you exercise it. Five changes put that into practice.

Crypto-agility gets an owner and a budget

In v2.x, crypto-agility was a design principle every workstream was supposed to honor, but nobody owned. In v3.0, it is a funded workstream from Year 1 with a named owner. The Introduction to Crypto-Agility I wrote in 2022 reads as the design brief for that workstream.

Discovery is also separated from the permanent Cryptographic Record. The inventory work has a close date; the record does not. Put them in one workstream and the record disappears when Discovery does. Inventories go stale the month the migration team is reassigned.

“Migrated” comes with four conditions

A system meets the full v3.0 acceptance conditions when all four hold:

• The negotiated post-quantum outcome is observed in production traffic.
• Classical-only connections are refused where your policy requires it, and someone has verified that those handshakes are rejected.
• The algorithm can be changed by configuration.
• That change has been rehearsed, with rollback.

A system that passes the first two and fails the last two is recorded as migrated with agility debt. It goes on a register, with an owner and a dated closure event. It does not disappear into a green cell on a dashboard.

Every wave rehearses the next change

I measure agility by rehearsal rather than by architecture review, for the same reason a fire marshal times the evacuation instead of counting the exit signs. Each migration wave includes one algorithm change, timed across four elapsed intervals: assessment, decision, change and verification. The longest interval tells you where to invest next.

Appendix I includes an invented wave-rehearsal record, clearly labeled as such, so you can see what a rehearsal actually turns up. It follows a key-establishment group swap on an internal service mesh, performed in staging and rolled back at the end:

• Assessment: 6 hours 40 minutes.
• Decision: 19 hours 15 minutes, because the request waited for the weekly change-advisory window.
• Change: 1 hour 5 minutes, for a policy rollout to 412 staging workloads.
• Verification: 2 hours 30 minutes, including the rollback exercise.

The first attempt totaled 29 hours 30 minutes. Full acceptance took six calendar days because two of the 412 workloads had pinned the old group in their own configuration and needed a retest. Two thirds of the first attempt’s elapsed time went to the approval queue. So the next investment is a standing authorization for cryptographic policy changes. The two pinned workloads went on the agility-debt register. Both were caught in staging.

Closure requires a rehearsed second algorithm change on Tier-1 systems inside the agility window: 48 hours to assess plus ten business days to change, by default. It also requires zero unaccepted agility debt and a verification disposition for every Tier-1 and Tier-2 service. The closing report then has a number in it: how long the organization took to change its cryptography the last time it tried.

Evidence gets a grade, and so do vendor promises

A dashboard can look reassuring while the evidence beneath it remains thin. Every discovery finding now has one of five evidence grades:

• E1: runtime observed, such as a handshake captured in production traffic.
• E2: binary confirmed.
• E3: inventory declared.
• E4: vendor attested.
• E5: inferred.

The grade attaches to the claim. A system’s importance has no effect on its evidence grade.

You measure coverage against a denominator you enumerate before discovery starts. “94 percent of the 2,140 TLS endpoints enumerated from the load-balancer and service registries” is a coverage statement. “94 percent coverage” on its own describes one tool’s output.

The empirical case for that rule comes from a January 2026 study in ACM Transactions on Software Engineering and Methodology. It ran six SBOM tools over 3,287 repositories and generated 55,444 SBOMs. Depending on the language, the tools agreed on package detection between 7.84 and 12.77 percent of the time. A proof based on one tool’s output is a proof about one tool. That is also why I have never recommended a single cryptographic inventory vendor as the whole answer.

Vendor dates get the same treatment. Phase 3 scores each one as committed, forecast, announced or unknown, independently of the calendar date itself. A certification date from a program office stays forecast until the certificate is issued. The most dangerous sentence in a Phase 7 status report is “our vendors will handle it”. The second most dangerous is a roadmap date recorded as a deployed state.

Risk tiers, regulation and the crosswalk

Risk tiers now come from an ordered qualitative test, and I publish no numeric score bands. The composite score is an uncalibrated ranking. Attaching score bands to it would imply an actuarial precision the method does not support. Migration difficulty reorders entries within a tier and leaves the tier assignment unchanged.

The framework now states how to read a regulatory deadline instead of listing dates that go stale. A printed list of national deadlines can be wrong within months, and you are stuck with it until the next edition. The framework sets out three deadline archetypes (plan-by, procure-by and migrate-by), five enforcement tiers from market access down to advisory, and one anchor instrument per archetype. So you can read any new instrument for the kind of deadline it sets before it goes on a roadmap.

I publish the current jurisdiction roster on the Global PQC Migration Clock and update it through the PQC Migration Brief.

A crosswalk to NIST CSF 2.0, the PQCC Roadmap, ETSI TR 103 619 and the Dutch PQC Migration Handbook maps the framework onto commitments you have already made, as the execution layer beneath them. Appendix J is a requirements register extracted from the body text at every build, so it cannot diverge from the document it summarizes. Each of the seven documents produces its own.

Who picks up what

If you are the CISO or the executive sponsor, Phase 0 comes first. Under v3.0, you state two outcomes in the charter: readiness against dated obligations and the agility you retain afterwards. You cannot prove the capability at closure if the charter never named it.

The business case has four urgency drivers:

• Regulatory deadlines that are already fixed.
• HNDL exposure on data with long confidentiality requirements.
• TNFL exposure on trust anchors with long validity periods.
• Client, investor and insurer expectations already appearing in due diligence.

You can document every one of those four from published rules, your own data and your own contracts, with no Q-Day prediction attached. I would keep predictions out of the business case, because boards fund obligations, not threats.

The budget strategy is to use the migration to fund modernization that is overdue anyway. PKI automation is one example. It is required for the 47-day public-certificate lifetimes the CA/Browser Forum schedule reaches in March 2029, whether or not a quantum computer ever exists.

If you manage the program, each Applying This Phase block names who leads it, the minimum viable version for a small estate, the decision it produces and who takes it forward. At any size, the non-negotiables are risk-driven scoping, a queryable CBOM, questionnaires to your top ten vendors, and hybrid TLS on internet-facing endpoints.

The agility-debt register and the rehearsal record are the two artifacts that change your status reports. The 90-day quick-start checklist in Appendix E gives you the first fifteen actions, from appointing a Quantum Readiness Program Manager to sending the vendor questionnaires. The quarterly board report template also gains a line for rehearsed time-to-change, using the most recent Tier-1 rehearsal and reporting it against the agility window.

If you are the security architect or the engineer implementing the changes, Phase 5 opens with a table identifying which single layer to convert first for each architecture pattern, from a SASE edge to an OT gateway to mail transport. The two-track model gives you separate sequencing for key establishment and signatures. You start signatures early despite TNFL’s lower urgency, because a forged update propagates to every system that trusts it.

Track B has an immediate deployment path. LMS and XMSS under NIST SP 800-208 are standardized and available now for firmware signing, software update signing and secure boot chains. These are the trust anchors with the longest validity periods in the estate.

If you build or buy the tooling, the Applied Quantum CBOM Profile is the document here for you. It defines the fields a CBOM has to carry so that another institution could compare theirs with yours.

If you are in GRC or internal audit, Phase 3 and the GRC Implementation foundation are your starting points. The KRI cascade reports at three levels: weekly operational, monthly management and quarterly board. The evidence dossier has a stated litigation-defense purpose.

Supervisors have started placing institutions along adoption paths. The Hong Kong Monetary Authority published a Quantum Preparedness Index for its banking sector in July 2026, and FINMA ran its own survey the same month. Know which stage your organization maps to before the supervisor asks. The requirements register in Appendix J is the view to hand to whoever audits you.

If your firm is in scope for DORA, the Cryptographic Concentration Framework is the other document here that concerns you. Articles 28(4)(c) and 29 ask about concentration at the vendor layer. The framework measures the shared dependencies underneath that layer, which is where a cryptographic defect actually travels.

If you are in procurement or vendor management, Phase 7 opens with two agility questions and one firmness question. Vendor-date grading means a roadmap date from a product manager stays forecast until the certificate is issued. The framework puts the lead time from first inquiry to contractual commitment with a strategic vendor at six to eighteen months. Phase 7 is numbered last and started first.

The model contract language gives you clauses to put in front of a vendor. The counterparty coordination pattern in Activity 7.6 covers the parties you cannot contractually compel. The vendor governance cadence outlives the program.

Four vendors, one dependency

The rest of this post covers the two companion documents. The first is the Cryptographic Concentration Framework, which Steve Vaile and I wrote to measure something the migration framework can identify but cannot quantify on its own: how far one cryptographic defect reaches across suppliers that look independent.

An institution with four HSM vendors, three TLS terminators and two certificate providers comfortably passes a vendor substitutability test. It should: every one of those suppliers could be replaced. Now trace each product to the code and hardware executing underneath it. Every vendor implements RSA and elliptic-curve cryptography. Several of the post-quantum implementations descend from one reference implementation. Some of the hardware shares a random number generator design. The count of things that can fail independently collapses to one or two.

On March 13, 2019, three days after Ethiopian Airlines Flight 302, the FAA grounded every Boeing 737 MAX in the United States. Regulators in China and Europe had already done the same. Every airline that flew the type lost the use of those aircraft at once, whatever its brand, maintenance record or safety culture. A passenger who had switched carriers to avoid the problem found the same aircraft at the gate.

Cryptographic concentration has the same shape, and the regulatory tests are written around vendors instead of the implementations beneath them. DORA has applied since January 2025. Article 28(4)(c) asks whether an arrangement reinforces concentration risk, and Article 29 asks if a critical provider is easily substitutable.

The UK’s Critical Third Parties regime took effect on January 1, 2025, but applies to a provider only after HM Treasury designates it. HM Treasury designated the first four providers on July 13, 2026. Each regime assumes one provider fails at a time. A cryptographic defect can cause simultaneous failures across suppliers that have never heard of each other.

“Switching vendors moves the contract, not the dependency.” That line is on the cover of the Cryptographic Concentration Framework.

The incident record is documented, and none of it required a quantum computer:

• KyberSlash, disclosed from late 2023 into early 2024, reached twelve libraries because the vulnerable division was inherited from one reference implementation. Independently written decapsulation paths were unaffected.
• ROCA, in 2017, came from one key-generation library from one semiconductor vendor and crossed TPMs, authentication tokens, smartcards and a national identity scheme. On November 2, 2017, the Estonian government endorsed suspending the certificates on 760,000 ID cards. The suspension took effect at midnight the next day.
• The 2008 Debian OpenSSL defect reduced the random seed to a process identifier and made two years of generated keys predictable.

The framework measures all three without modification. The Universal ships a validation annex that re-runs its key-generation assessment over the public ROCA record. Quantum is the method’s first use case; the method itself is general.

The framework examines six layers, each a place where a single defect can cross nominally independent vendors: algorithm, implementation lineage, trust root, key custody platform, protocol and negotiation, and key generation. For each important business service, the assessment reports:

• Cryptographic Concentration Index: how concentrated the executing estate is at a layer.
• Failure-domain reach: how far one shared upstream failure travels, reported beside the index every time.
• Effective Coverage: whether every party and hop on the service path, including your counterparties, operates at target state.

Putting a number on what a supplier will not disclose

Where a supplier will not disclose its implementation lineage, the framework records the reach as a bound instead of dropping it from the assessment. The worked example uses a synthetic mid-size acquiring processor with 4,200 cryptographic assets. Its evidenced failure domain at the lineage layer is 2,400 assets; its bounded domain is 3,300. The 900 assets between them are the ones whose lineage nobody has disclosed.

The evidenced figure passes a two-hour recovery tolerance. The bounded figure fails it. The 21.4 reach points between them are the price of one supplier’s silence. That spread goes into the Supplier Lineage Disclosure Request that ships with the framework, so procurement has a number to put in front of the supplier.

The migration creates its own concentration while it removes the old kind. Institutions are working toward the same migration horizon, using a small number of young libraries under the same time pressure. Several of those libraries share ancestry. PQClean, one of the reference implementations in that lineage, was archived read-only on August 4, 2026. Algorithm migration and implementation concentration have to be assessed together, or the migration creates the correlation it was meant to reduce.

Discovery procedures, tooling and detection logic are published in a separate Technical Companion, so the method does not age with the tools. The framework also deliberately omits loss estimation, likelihood scoring, CVSS-style severity and a maturity taxonomy. A concentration figure packaged with a loss estimate would be read as the loss estimate.

The reference implementation and ten canonical test vectors are Apache-2.0 on GitHub. Every figure in the published documents can be reproduced from them, and an implementation that matches all ten vectors is conformant. The release schedule is on the ccframework.org site. We will run a pilot cycle in October and publish version 1.0 final in November 2026, with the first snapshot of the payments frontier census.

An inventory that supports a decision

The second companion document is the Applied Quantum CBOM Profile. Both migration and concentration assessment depend on the quality of the cryptographic inventory, and both need facts in it that the inventory standard does not model.

CycloneDX 1.7, released in October 2025 and ratified as ECMA-424 second edition in December 2025, is the standard I would recommend for a cryptographic bill of materials (CBOM). Its cryptoProperties structure records algorithms, keys, certificates and protocols.

What CycloneDX leaves out is governance state. It has no concept of:

• a post-quantum migration horizon;
• what a path negotiates, as distinct from what an endpoint supports;
• whether a supplier’s lineage disclosure was received, refused, deflected or never answered; or
• what fraction of a service the discovery actually reached.

That is the right scope for a standard. A bill of materials describes what is there. A migration program has to describe what is being done about it, and the two do not belong in the same schema.

The Profile adds those fields and only those. It uses the extension mechanism CycloneDX built for the purpose: a vendor property namespace. IBM, Siemens, NVIDIA, GitLab, Amazon and Germany’s BSI already hold namespaces using the same mechanism. The Profile defines fifty property names under an appliedquantum namespace, across eight subnamespaces and four tiers:

• Tier 1 is native CycloneDX and nothing else.
• Tier 2 adds migration governance: horizons, negotiated state and evidence tiers.
• Tier 3 adds financial-sector and custody context.
• Tier 4 adds the concentration and dependency inputs the Cryptographic Concentration Framework consumes.

The tiers are additive and independently adoptable; the tier number is not a maturity grade. An institution migrating adopts Tiers 1 to 3. An institution measuring concentration adds Tier 4. Adopting one does not commit you to the other.

The Profile follows three rules:

• Add a field only where the standard is silent.
• Use what already exists where the standard provides it. Implementation ancestry, the hardest input to collect, gets no new field because CycloneDX already has pedigree.
• Upstream anything that generalizes. Section 9 records which fields are candidates for the CycloneDX core and why.

The Profile is designed to be deprecated. I will count it a success when CycloneDX absorbs enough of its fields to make parts of it unnecessary.

It ships with a JSON Schema, a validator, and fixtures designed to pass or fail. The failing fixture contains twelve seeded violations and fails on all twelve. Four controlled vocabulary files cover entropy source designs, entropy generation designs and HSM firmware families. These let identical designs group as one dependency across institutions, even when they appear under three vendor names.

The appliedquantum namespace was filed with the CycloneDX property-taxonomy registry as issue #189 on August 14, 2026. The issue is open, and the published registry table does not include the namespace yet. The site will say so the day that changes.

Executive Order 14412 §5(d) directs CISA, coordinating with NIST, to publish guidance on the minimum elements of a cryptographic bill of materials within 270 days of June 22, 2026: by March 19, 2027. That is directed rulemaking. The order compels no organization to produce a CBOM, and the guidance itself is still to be written.

Anything practitioners want reflected in those federal minimum elements has to be public, tested and citable well before March. That is the window for this release. Comments are open through October 31, 2026, as issues on the taxonomy repository.

How the three fit together

Both frameworks cite the Profile by minimum version, v1.0-RC or later, and neither absorbs it. A change to either framework leaves the Profile version untouched. When CycloneDX absorbs a field, the Profile deprecates it on the published schedule, regardless of what either framework would prefer.

Version 3.0 of the migration framework defines its own minimum CBOM record in Phase 2, descended from the Minimum Viable CBOM model. A CBOM built to it can be written as plain CycloneDX. If you adopt the Profile, you record the same fields as Profile properties, and the framework’s five evidence grades map one to one onto the Profile’s evidence tiers. Adopting the Profile is never a requirement of the migration framework.

The Cryptographic Concentration Framework does require a Profile-conformant CBOM. Its CBOM Conformance Statement identifies the fields needed at each conformance level and for each layer. When a program team reaches Phase 3 or Phase 7 and asks how many distinct implementations execute beneath four vendors, the concentration framework supplies the answer. No document in the migration set computes a concentration figure of its own.

What I corrected

When I get a published position wrong, I publish the original wording, the sourced truth and, where the error changed a recommendation, what to re-check. Version 3.0 publishes twelve corrections. Here are three of them.

In the Digital Assets extension, I described Bitcoin’s block limit as 4 MB. It is 4,000,000 weight units. BIP-141 counts a witness byte as one unit and every other byte as four, so a signature-size ratio alone cannot give you a throughput figure. A reader who estimated throughput impact from the published text should redo the calculation in weight units, using their own transaction mix.

In the Telecommunications extension, I argued for a subscriber-wide SIM reprovisioning campaign. 3GPP TS 31.102 specifies both mobile-equipment and USIM calculation of the SUCI, selected per subscription by two services in the USIM service table. Only the population whose USIM computes the SUCI needs a new or reprovisioned card. That error changed a multi-year logistics argument, so the correction names what to re-check. Your own EF_UST provisioning records determine the split between your handset base and your USIM base.

In the Universal, v2.0 stated that no validated module offered post-quantum algorithms in approved mode. I was wrong when I published it. CMVP certificate #5247 covers a software module validated on April 27, 2026 and lists ML-KEM-768 and ML-KEM-1024 among its approved algorithms. Of the twelve corrections, this is the one I mind most, because it was checkable on the day I wrote it. The v3.0 deployment environment classification replaces the calendar-based gap with a per-product validation decision, which is what it should have been from the start.

A fourth correction changes what I say the HNDL planning case rests on. Earlier editions described harvest now, decrypt later as observed harvesting. That overstates the evidence. It is an inference from demonstrated means, motive, opportunity and precedent. A passive collector leaves no trace in your network; finding none is the expected condition, as I set out in July in why HNDL cannot be detected.

I did not change the planning posture, only the description of what it rests on. Appendix F now quotes three published statements, each dated and linked: one from CISA, NSA and NIST; one from AIVD, CWI and TNO; and one from Federal Reserve Board staff. No product detects harvesting, and a vendor that claims to is detecting something else.

Four external reviews of the v3.0 drafts produced roughly 200 findings. I ran three verification rounds to establish which were valid, corrected several of the reviewers’ own claims, and found contradictions nobody had raised. The full list is on the What’s New page.

Where to start

If you are launching a program, start with Phase 0 and the 90-day quick-start checklist. Put both readiness and the capability to change again into the charter.

If you are already on v2.1, read What’s New before you download. The revised acceptance conditions, rehearsal requirements, evidence grades and agility-debt register are the parts that change your status reports.

If you need to understand shared dependencies across suppliers, start with the Cryptographic Concentration Framework and its worked example, then read the provenance page. It lists what the framework claims as original as of August 2026, and invites counterexamples.

If you build, buy or maintain CBOM tooling, review the Applied Quantum CBOM Profile. Tell us where its fields work, where they fail and what is missing by opening issues on the taxonomy repository before October 31, 2026. A taxonomy nobody argued with is a taxonomy nobody read.

What I would most like to see from this release is evidence of use: a rehearsal that exposed a delay, a supplier disclosure that changed an assessment, a field that proved impossible to populate reliably. Those findings are how the next versions get better. Updates will appear through the PQC Migration Brief, and subscribing is optional. Nothing here is behind an email address, and nothing ever will be.

At the end of a migration, I want a team to be able to answer two questions. When our cryptography has to change again, how quickly can we do it? What evidence do we have?

Commercial interest

Applied Quantum sells post-quantum migration advisory services. The conclusions above favor that commercial interest, and you should read them knowing that. The method, the instruments, the field set and the reference implementation are published in full. Every figure can be reproduced without engaging us. That disclosure is printed on every cover in the family. It is the test I would apply to any framework a vendor publishes, including mine.

The three documents: PQC Migration Framework v3.0, Cryptographic Concentration Framework v1.0-RC, Applied Quantum CBOM Profile v1.0-RC. The companion book is Quantum Ready, and Quantum Academy runs the training that matches the roles in the framework’s Skills and Team Structure foundation.

The post appeared first on PostQuantum - Quantum Computing, Quantum Security, PQC.