Chapter 30: Running a PQ migration program
Shipping a post-quantum migration is a program, not a project. A single TLS endpoint moves in weeks; a CA hierarchy moves over weeks-to-months depending on chain depth and client population (Ch 28, Ch 29). A whole organization moves in years, across every team that touches cryptography, under deadlines that come from outside. Ch 30 is the program-management bookend of Part V. The inputs are the five-touchpoint CBOM from Ch 25, the agility policy from Ch 26, the hybrid constructions from Ch 27, and the hands-on migrations from Ch 28 and Ch 29. The output is a measurable, multi-year shipping plan.
The external anchors are NCSC’s 2025 migration timeline (2028 discovery, 2031 first-wave, 2035 full post-quantum) (UK National Cyber Security Centre, 2025), CNSA 2.0 for U.S. National Security Systems (US National Security Agency, 2022, 2024), and, for U.S. civilian federal systems, Executive Order 14412 (June 2026) with its implementing memorandum OMB M-26-15 (Office of Management and Budget, 2026; The White House, 2026). The “Context: timelines and the PQRA rubric” section below sets out what each instrument applies to and when. CNSA 2.0 is not generally binding on non-NSS commercial deployments (the suite is named the “Commercial National Security Algorithm Suite” but the mandate is for National Security Systems). Some commercial programs nonetheless adopt its dates as reference points.
The assessment backbone is the Encryptorium Post-Quantum Readiness Assessment (PQRA), a free seven-domain rubric that produces a scored inventory a program can prioritize against (Encryptorium, 2026). Encryptorium publishes both that rubric and this book. Any equivalent weighted assessment serves the same role in what follows. Operator tooling for this chapter lives at solutions/ch30-migration-program/.
The five-touchpoint program
Section titled “The five-touchpoint program”The Ch 25 CBOM records five touchpoints: tls_endpoint_api, jwt_signing, and password_hashing, together with webhook_hmac and blockchain_validator_sig. Ch 28 landed the tls_endpoint_api migration to TLS 1.3 with X25519MLKEM768. Ch 29 landed the jwt_signing migration from RS256 to Ed25519+ML-DSA-65 composite. password_hashing and webhook_hmac are grover-only rather than Shor-vulnerable, so both carry a margin against quantum attack under current parameters and are scheduled into the second wave. blockchain_validator_sig is a Shor-vulnerable Layer-1 chain operator key. Its first-wave playbook lives outside the Ch 28 / Ch 29 web-and-PKI scope: Ch 37 covers the L1 transaction signature migration, and Ch 39 covers the consensus and staking signature work. Firmware signing sits in an adjacent device fleet and is the longest-tail concern: firmware keys outlast every other key in the deployment.
The program question at this point is not which algorithm to use. Ch 27-29 already answered that. The question is how to schedule the remaining work so the 2028 asset-identification milestone is hit on time, the 2031 first-wave milestone lands with the highest-priority touchpoints migrated, and the 2035 window closes with the classical chains retired. The program needs named phases, exit criteria an outside auditor can check, a governance structure that can approve a phase gate, and a risk register with mitigation owners.
Context: timelines and the PQRA rubric
Section titled “Context: timelines and the PQRA rubric”The outer boundary is set by policy instruments in three jurisdictional tracks: the UK NCSC timeline, the U.S. National Security Systems track (CNSA 2.0), and the U.S. civilian federal track (Executive Order 14412 with OMB M-26-15). A program identifies which instrument carries a binding obligation for it, if any, and treats the others as reference points.
| Instrument | Applies to | Milestones |
|---|---|---|
| NCSC 2025 timeline (UK National Cyber Security Centre, 2025) | UK organizations | 2028 inventory and discovery; 2031 high-priority migrations; 2035 full transition |
| CNSSP 15 / NSA FAQ v2.1, December 2024 (US National Security Agency, 2024) | U.S. National Security Systems | 1 January 2027 new acquisitions; 31 December 2030 phase-out; 31 December 2031 mandatory use; NSM-10 2035 NSS goal |
| NSA CNSA 2.0 advisory, September 2022 (US National Security Agency, 2022) | U.S. NSS, per asset category | 2030 software/firmware signing and traditional networking; 2033 web/cloud, operating systems, and niche equipment including large PKI |
| Executive Order 14412 and OMB M-26-15, June 2026 (Office of Management and Budget, 2026; The White House, 2026) | U.S. civilian federal systems, National Security Systems excluded | 31 December 2030 key establishment for High Value Assets and high-impact systems; 31 December 2031 digital signatures; five phases through 2035 |
CNSA 2.0 occupies two rows because its NSS-wide gates and its per-category exclusive-use planning dates come from different documents: the December 2024 FAQ carries the first set and does not restate the second, which is the September 2022 advisory’s. CNSA milestones are binding for NSS and not generally binding on non-NSS commercial deployments, though some commercial programs adopt them as reference points.
The NCSC row is national guidance rather than a legal mandate. The guidance sets out “indicative timelines” that UK industry, government and regulators can follow, and describes 2028, 2031 and 2035 as “key target dates” that all organizations “should work towards” (UK National Cyber Security Centre, 2025). It is aimed primarily at large organizations, critical-national-infrastructure operators, and organizations with bespoke IT, though it states that the core timelines are relevant to all organizations. Where a UK program carries a hard obligation on these dates, it comes from a sector regulator or a contract rather than from the guidance. The risk register below is the place to resolve that.
Four NIST documents supply the technical framing the program works inside. NIST IR 8547 names each quantum-vulnerable standard and the post-quantum standard that replaces it (Moody et al., 2024). Its initial public draft (November 2024, still the current version as of September 2026) proposes deprecating 112-bit-security quantum-vulnerable signatures and key establishment (RSA-2048, 2048-bit finite-field Diffie-Hellman and 224-bit elliptic curves) after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035. Parameter sets at 128 bits or more, P-256 and Ed25519 among them, go straight to disallowed after 2035 with no deprecation stage. It is a transition-planning report rather than a discovery guide, the distinction Ch 25 draws. NIST CSWP 39 supplies strategies and practices for building crypto agility (Barker et al., 2025). For key-lifecycle and cryptoperiod decisions the program leans on NIST SP 800-57 Part 1 Rev. 5 (Barker, 2020). For the chain-tip PQ-deprecation transition framing it leans on NIST IR 8547 and on the SP 800-131A Rev. 3 Initial Public Draft (October 2024) (Barker et al., 2024) rather than SP 800-131A Rev. 2 (March 2019, predates the FIPS 203/204/205 standards) (Barker & Roginsky, 2019).
The assessment rubric is the Encryptorium PQRA v1.0, a seven-domain weighted questionnaire scored on a 1-5 maturity scale per question and rolled up into four overall risk tiers (Critical, High, Moderate, Low) (Encryptorium, 2026). The seven domains and their weights are:
| Domain | Weight |
|---|---|
| Inventory | 20 percent |
| Migration readiness | 20 percent |
| Data sensitivity | 15 percent |
| Vendor and supply chain | 15 percent |
| Standards compliance | 10 percent |
| Timeline and urgency | 10 percent |
| Governance and policy | 10 percent |
Inventory and migration readiness dominate because discovery without execution capability does not reduce risk, and execution capability without inventory migrates the wrong thing first. The remaining weights reflect the policy view that data-sensitivity and vendor-lock risks feed priority ahead of the softer timeline and governance scores. The source PQRA framework measures organizational readiness against a single dashboard score. Ch 30 applies the same seven-domain rubric per touchpoint rather than per organization, so the CBOM rollup can rank touchpoints within one organization. The per-touchpoint use is an adaptation, not the PQRA’s own scope.
The program in four phases
Section titled “The program in four phases”The program uses four phases anchored to the NCSC 2025 milestones. Each phase has named inputs, named outputs, and exit criteria a program lead can validate before advancing the gate. The phases map onto both CNSA 2.0 timelines tabulated above: the NSS-wide acquisition, phase-out, and mandatory-use gates (US National Security Agency, 2024), and the per-category exclusive-use planning dates (US National Security Agency, 2022). A commercial deployment may compress or extend phases, but the exit criteria survive.
Figure 30.1 shows how to confirm a touchpoint’s current phase and identify whether an NCSC or CNSA deadline is the binding constraint on its exit. The yellow guide marks NCSC 2025 milestones (2028 discovery, 2031 first-wave, 2035 full post-quantum). The purple guide marks the CNSA 2.0 advisory’s per-category exclusive-use planning dates (2030 software/firmware signing and traditional networking; 2033 web/cloud, operating systems, and niche equipment including large PKI). CNSSP 15 / NSA FAQ v2.1 sets 31 December 2031 as the mandatory CNSA 2.0 use date under the NSM-10 2035 NSS goal.
Discovery and assessment (2025-2028)
Section titled “Discovery and assessment (2025-2028)”The phase’s job is to produce a ranked priority list. Inputs: source code, deployment configuration, HSM catalog, third-party integrations. Outputs: a CycloneDX CBOM per Ch 25, a PQRA scoring sheet, an assigned owner for every touchpoint, and a priority-ordered list that drives first-wave resource allocation. Exit criteria: CBOM complete for every estate in scope, PQRA scored across the seven domains, owners assigned per touchpoint.
The CBOM carries the Ch 25 quantum-status and exposure axes. The PQRA adds the seven-domain readiness scores. The priority rollup combines them. A vulnerable touchpoint scores 3 on the quantum multiplier, a grover-only touchpoint scores 1, and a quantum-safe touchpoint scores 0. Public exposure doubles the multiplier. The readiness gap for a domain is (5 - score) * weight. The sum runs over all seven PQRA domains. A perfect readiness score of 5 contributes zero to the gap.
# Block 1: pedagogical slice of migration_program.risk_rollup.migration_urgency (stdlib only).# The score ranks quantum migration urgency, not general operational risk; a# quantum-safe touchpoint can still have weak ownership, telemetry, or rollback# discipline that this rollup does not measure.QUANTUM_MULT = {"vulnerable": 3, "grover-only": 1, "quantum-safe": 0}EXPOSURE_MULT = {"public": 2, "internal": 1}
WEIGHTS = { "inventory": 0.20, "data_sensitivity": 0.15, "standards_compliance": 0.10, "migration_readiness": 0.20, "vendor_supply_chain": 0.15, "timeline_urgency": 0.10, "governance_policy": 0.10,}
CBOM = [ {"name": "tls_endpoint_api", "quantum_status": "quantum-safe", "exposure": "public", "readiness": {d: 5 for d in WEIGHTS}}, {"name": "jwt_signing", "quantum_status": "quantum-safe", "exposure": "internal", "readiness": {d: 5 for d in WEIGHTS}}, {"name": "password_hashing", "quantum_status": "grover-only", "exposure": "internal", "readiness": {"inventory": 4, "data_sensitivity": 2, "standards_compliance": 4, "migration_readiness": 3, "vendor_supply_chain": 4, "timeline_urgency": 3, "governance_policy": 4}}, {"name": "webhook_hmac", "quantum_status": "grover-only", "exposure": "internal", "readiness": {"inventory": 4, "data_sensitivity": 3, "standards_compliance": 4, "migration_readiness": 4, "vendor_supply_chain": 4, "timeline_urgency": 4, "governance_policy": 4}}, {"name": "blockchain_validator_sig", "quantum_status": "vulnerable", "exposure": "public", "readiness": {"inventory": 4, "data_sensitivity": 2, "standards_compliance": 1, "migration_readiness": 1, "vendor_supply_chain": 2, "timeline_urgency": 1, "governance_policy": 2}},]
def migration_urgency(touchpoints, weights): scored = [] for t in touchpoints: qm = QUANTUM_MULT[t["quantum_status"]] em = EXPOSURE_MULT[t["exposure"]] gap = sum((5 - t["readiness"][d]) * w for d, w in weights.items()) scored.append((t["name"], qm * em * gap)) scored.sort(key=lambda item: (-item[1], item[0])) return scored
for name, score in migration_urgency(CBOM, WEIGHTS): print(f"{name:<24} {score:.2f}")# ==> blockchain_validator_sig 18.00# ==> password_hashing 1.60# ==> webhook_hmac 1.15# ==> jwt_signing 0.00# ==> tls_endpoint_api 0.00Every Python block this chapter prints is also a standalone file in the companion repository, under chapter-code/ch30/, one file per block. Appendix C covers the clone and the environment they run on.
The rollup ranks quantum migration urgency rather than general operational risk. A quantum-safe touchpoint scores zero on this axis because the migration is done. Weak ownership, telemetry, or rollback discipline still belong on a separate operational-risk register. Under this rollup the two already-migrated touchpoints score zero.
blockchain_validator_sig lands at 18.00 and dominates the priority list: a Shor-vulnerable public-facing touchpoint scores quantum_mult * exposure_mult = 6 against its readiness gap. The readiness scores reflect the chain-tip 2026 deployment gap rather than a standards gap. FIPS 204 standardizes ML-DSA (National Institute of Standards and Technology, 2024), but major chains still lack finalized protocol profiles, activation rules, validator and wallet client releases, and governance-approved migration paths for post-quantum transaction or consensus signatures. Its first-wave playbook lives in Ch 37 (L1 transaction signature migration) and Ch 39 (consensus and staking signature work), on a separate timeline from the Ch 28 and Ch 29 work.
The two grover-only touchpoints carry the remaining priority on the application side. password_hashing ranks above webhook_hmac because three of its seven readiness scores are lower: data-sensitivity (2 rather than 3), migration-readiness (3 rather than 4), and timeline-urgency (3 rather than 4). The three gaps add 0.15, 0.20, and 0.10 under the default weights, for a rollup delta of 0.45.
password_hashing carries the migration-urgency rank shown here, but password-hashing security in practice is dominated by password entropy, salt uniqueness, memory hardness, online rate limits, breach response, and credential-stuffing controls. Those controls sit outside this rollup, so the migration-urgency score under-weights real-world password-hashing risk relative to the Shor / Grover axis.
First-wave deployment (2028-2031)
Section titled “First-wave deployment (2028-2031)”The first wave takes the top-ranked public-facing vulnerable entries from the discovery phase and routes each one to the relevant domain playbook. Web and PKI touchpoints follow Ch 28 and Ch 29; blockchain validator and consensus-signature keys follow the later Ch 37 and Ch 39 playbooks. The running example’s Block 1 CBOM is a post-Ch 28 / Ch 29 residual snapshot: the tls_endpoint_api and jwt_signing migrations were executed as first-wave exemplars in those chapters, which is why both score 0.00 in the rollup. The residual first-wave priority in the running example is blockchain_validator_sig, whose implementation playbook is deferred to Ch 37 (L1 transaction signature migration) and Ch 39 (consensus and staking signature work) rather than the Ch 28 / Ch 29 web-and-PKI scope.
Inputs: the discovery-phase priority list, the six Ch 26 architectural areas as the work-stream structure, and the organizational mandate for the NCSC 2031 milestone. Outputs: migrated touchpoints, a rollback drill report, an updated CBOM, and a delta against the PQRA score. Exit criteria: public-facing vulnerable touchpoints migrated, JWT signing migrated, rollback drill completed.
The phase-gate check is deliberately mechanical. A gate record maps each criterion to True if it is met. The checker reports missing criteria in the defined order so a runbook can walk them in sequence.
# Block 2: pedagogical slice of migration_program.phase_gate.check (stdlib only).PHASE_EXIT_CRITERIA = { "discovery": ( "cbom_complete", "pqra_scored", "owners_assigned", ), "first-wave": ( "public_vulnerable_migrated", "jwt_signing_migrated", "rollback_drill_completed", ), "broad-rollout": ( "remaining_vulnerable_migrated", "composite_client_adoption_above_threshold", "work_stream_reports_green", ), "end-of-migration": ( "classical_retired", "pq_only_mode", "post_migration_review_signed", ),}
def check(phase, record): if phase not in PHASE_EXIT_CRITERIA: raise ValueError(f"unknown phase: {phase!r}") criteria = PHASE_EXIT_CRITERIA[phase] missing = tuple(c for c in criteria if record.get(c) is not True) return {"phase": phase, "passed": len(missing) == 0, "missing": missing}
record = { "public_vulnerable_migrated": True, "jwt_signing_migrated": True, "rollback_drill_completed": False,}result = check("first-wave", record)print(f"{result['phase']}: passed={result['passed']}, missing={list(result['missing'])}")# ==> first-wave: passed=False, missing=['rollback_drill_completed']The checker refuses to evaluate an unknown phase name. Only the literal True value counts as met; a missing key, a False, or any other value counts as unmet. This matters: “probably done” is not done, and “done but not yet tested under rollback” is not done either.
Broad rollout (2031-2035)
Section titled “Broad rollout (2031-2035)”With the first wave landed, the program parallelizes across the six Ch 26 architectural areas (cryptographic observability, governance and policy, modular cryptographic architecture, protocol-level adaptability, operational tooling, and lifecycle management). The remaining vulnerable and grover-only touchpoints migrate in priority order. Inputs: the residual priority list after the first wave, library and runtime releases that support the NIST standards (FIPS 203 ML-KEM (National Institute of Standards and Technology, 2024a), FIPS 204 ML-DSA (National Institute of Standards and Technology, 2024b), FIPS 205 SLH-DSA (National Institute of Standards and Technology, 2024c)), and SP 800-227 guidance on KEM use (National Institute of Standards and Technology, 2025). Outputs: per-touchpoint migration completions, a running CBOM diff, and updated PQRA scores. Exit criteria: remaining vulnerable touchpoints migrated, composite-aware client population above threshold, every work-stream reporting green.
The threshold for composite-aware clients is a policy choice, tied to the Ch 28 rollout thresholds (99.9 percent handshake-success rate in the TLS work-stream) and to the Ch 29 rotation phases. The Ch 29 condition is that no tokens issued under the classical kid remain within their time-to-live. A program without the Ch 26 agility policy in place at the start of this phase will find itself editing library-version assumptions into every deployment.
End-of-migration and classical deprecation (2035+)
Section titled “End-of-migration and classical deprecation (2035+)”The final phase retires classical chains that survived the rollout window and closes the program. Inputs: the broad-rollout exit record, the client-population telemetry showing no classical-only traffic for an operational period (typically one quarter), and the deprecation cadence set in the Ch 26 agility policy. Outputs: a post-migration CBOM in which no touchpoint still reads vulnerable, retired-classical kid lists for every signer, and a post-migration review document. Exit criteria: classical algorithms retired; PQ-only mode asserted (the classical component of every composite chain is now retired, leaving single-PQ signers everywhere, and the gate criterion pq_only_mode records this state); post-migration review signed.
The program tracks progress through this phase with a milestone list dated against the NCSC 2035 deadline. The tracker reports percentage complete and flags milestones whose target date has passed without completion as slipped.
# Block 3: pedagogical slice of migration_program.milestone_tracker.report (stdlib only).from datetime import date
MILESTONES = [ ("cbom_complete", "2026-12-31", True), ("pqra_scored", "2027-06-30", True), ("owners_assigned", "2025-12-31", False), ("public_vulnerable_migrated", "2028-12-31", False),]
def report(milestones, today): today_d = date.fromisoformat(today) parsed = [(name, date.fromisoformat(target), done) for name, target, done in milestones] total = len(parsed) completed = sum(1 for _, _, done in parsed if done) slipped = [name for name, d, done in parsed if (not done) and d < today_d] pct = (completed / total) if total > 0 else 0.0 return {"total": total, "completed": completed, "percent": pct, "slipped": slipped}
r = report(MILESTONES, "2026-04-17")print(f"{r['completed']}/{r['total']} complete ({r['percent'] * 100:.0f}%), " f"slipped={r['slipped']}")# ==> 2/4 complete (50%), slipped=['owners_assigned']A slipped milestone is a program-management signal. Slippage from 2025-12-31 on owners_assigned (past due at the reporting date) surfaces either an organizational gap (no owner exists) or a discovery gap (an owner exists but has not been recorded against the touchpoint). The program lead remedies it before the next reporting cycle or escalates to the chief information security officer (CISO) if the gap is structural.
Figure 30.2 shows who signs the phase-gate request and which way the decision travels back.
Blockchain touchpoints and the program
Section titled “Blockchain touchpoints and the program”The five-touchpoint Block 1 example is application-layer plus one Layer-1 chain operator key. Three blockchain-stack categories enter the same four-phase shape but with different work-stream owners and a different first-wave deadline. The categories are consensus and staking signatures, rollup-exit verifier contracts, and signature primitives that smart contracts call into via on-chain precompiles.
Consensus and staking signatures are the validator-set keys (ECDSA on secp256k1, Schnorr, Ed25519, or BLS12-381 depending on the chain) that authenticate block proposals and attestations. Discovery names every validator’s signing key, plus the threshold and aggregation parameters. First-wave deployment is the consensus-layer hard fork that activates a PQ signature scheme. Ch 39 derives the byte-budget tradeoffs for its five-candidate set and the per-attestation-set bounds. Broad rollout is the validator set’s progression to PQ-only attestations after the activation block. End-of-migration retires the classical aggregation primitive once no validator slot still ships an ECDSA or BLS signature.
Rollup-exit verifier contracts are the deployed Layer-1 contracts that finalize Layer-2 proofs back to Layer 1. Discovery enumerates every deployed verifier-contract address and records the verifier stack: proof system, polynomial commitment scheme (e.g. KZG, named for Kate, Zaverucha and Goldberg, or FRI, the Fast Reed-Solomon Interactive Oracle Proof of Proximity), pairing and hash precompiles used (BN254, BLS12-381, SHA-256, Keccak-256, Poseidon), transcript hash, and any trusted setup or upgrade authority. First-wave deployment is a verifier-contract upgrade through the rollup’s governance-multisig. Ch 40 derives the gas-budget tradeoffs and the Mosca’s inequality analysis for deployed verifier contracts. Broad rollout is the cutover across every deployed rollup the L1 hosts, on a per-rollup schedule because each rollup’s governance is independent. End-of-migration retires the classical-only verifier contracts once on-chain telemetry shows no proof submissions against them for an operational period.
In-EVM signature-verification primitives are the precompiles plus the in-bytecode Ed25519 verifier libraries that smart contracts depend on for authorization and accounting. The precompiles are ECRECOVER on secp256k1, present since launch, and the BLS12-381 precompiles added by Ethereum Improvement Proposal (EIP) 2537 in the Pectra upgrade of May 2025. Discovery identifies every contract that calls one of these primitives. First-wave deployment depends on the L1 protocol shipping a PQ verification precompile or on contract authors migrating to a PQ verifier library. Ch 37 derives the per-transaction byte and gas overhead and frames the precompile-versus-EVM-bytecode tradeoff. Broad rollout is the per-contract migration across the deployed contract base, on a federated cadence.
This third category is the one whose end-of-migration phase does not close the way the other two do. It does not necessarily remove classical precompiles from the VM. ECRECOVER and the BLS12-381 precompiles are deep backward-compatibility surface that an L1 governance process is unlikely to remove on a cutoff date. The realistic end state is that the chain adds PQ verification support and deprecates classical-only authorization paths for new or high-value contracts, while preserving existing precompiles for compatibility unless a governance process explicitly removes them.
The PQRA seven-domain rubric extends to all three categories without modification. The standards-compliance domain takes a lower score because chain-specific post-quantum profiles are still draft-level at chain-tip 2026. BIP-360, Pay-to-Merkle-Root (P2MR), evolved from earlier Pay-to-Quantum-Resistant-Hash (P2QRH) discussion and remains a Draft proposal (Beast et al., 2024). It is a hash-commitment construction that drops the Taproot key-path spend to resist long-exposure quantum attacks on revealed public keys. It does not itself add a post-quantum signature, and the consensus-layer post-quantum EIPs remain draft. The migration-readiness domain takes a lower score because no major chain ships a PQ-validated client at chain-tip 2026.
The timeline-urgency domain reflects the chain’s harvest now, decrypt later (HNDL) equivalent. Once a currently accepted signing key is recovered, an attacker can forge future authorizations for assets, validator identity, or protocol actions while that key remains valid. Old finalized history is not rewritten, but exposed historical public keys and unspent or still-authorized assets create long-exposure risk. Chapter 37 covers Layer-1 transaction signature migration. Chapter 39 covers consensus and staking signatures. Chapter 40 covers ZK rollup verifier contracts. Chapter 41 covers the governance and hard-fork machinery that activates each transition.
Program-level risks
Section titled “Program-level risks”Ch 27-29 covered primitive and deployment attacks. The program-level threat surface is different. Six risks dominate. Each needs a named mitigation owner, either inside the Ch 26 work-stream structure or at the program-lead level.
Discovery misses. A CBOM that misses an asset class (shadow cryptography inside a library, HSM-managed keys not exposed to source scans, out-of-band cryptography) leaves the program migrating the wrong set of touchpoints. The pathology from Ch 25 Section “What makes an inventory wrong” applies here. Mitigation owner: the cryptographic-observability work-stream runs a second inventory pass against library version manifests and HSM catalogs each quarter. The program lead audits the delta.
Standards drift during the program. The composite-signatures draft (draft-ietf-lamps-pq-composite-sigs, version 19, April 2026) has revised through nineteen versions and may revise further before RFC publication (Ounsworth et al., 2026). OIDs, wire formats, and test vectors can move between draft revisions. A program that pins on a specific draft revision will have to re-verify every signer when the draft advances. A related risk is a malicious or compromised upstream composite-library package inserted during the rollout. The ecosystem is small and pre-RFC, so supply-chain integrity matters here more than for long-standardized algorithms. Mitigation owner: the governance-and-policy work-stream tracks IETF lamps progress, audits upstream package provenance, and issues a deprecation notice when an existing pinned version is superseded.
Vendor dependency chains. OpenSSL 3.5 is a practical 2025 reference point for deploying X25519MLKEM768 because its default TLS supported groups include hybrid PQC KEM groups and its default key shares offer X25519MLKEM768 and X25519 (OpenSSL Project, 2025). Downstream runtimes lag. HSM firmware gaps block stateful-signature deployment for LMS and XMSS specifically. SP 800-208 LMS / XMSS are permitted under the CNSA 2.0 2030 software/firmware signing exclusive-use deadline for NSS, but each token’s monotonic counter and its firmware support for stateful key material are the gating engineering cost. A library or HSM that never releases a post-quantum-capable version forces an architecture change rather than a configuration flip. Mitigation owner: the modular-cryptographic-architecture work-stream keeps a per-dependency release tracker and raises the issue at the quarterly review once a vendor slips past the first-wave window.
Compliance-mandate conflict. The CNSA 2.0 firmware-signing exclusive-use deadline (2030 per the CNSA 2.0 advisory) may not match device fleet refresh cycles; NCSC 2031 first-wave migrations may clash with end-of-support windows for embedded runtimes. Programs that process payment card data or operate in EU financial services may also carry sector-specific expectations that interact with the post-quantum schedule. The Payment Card Industry Data Security Standard (PCI DSS) and the EU Digital Operational Resilience Act (DORA) are two such mandates.
DORA can pull cryptographic migration into the information and communications technology (ICT) risk-management and operational-resilience-testing programme for EU financial entities, where cryptographic dependencies support critical or important functions. A material PQ gap on such a function can become a supervisory concern through the normal ICT risk, resilience-testing, remediation, and third-party-risk channels. Threat-led penetration testing under DORA applies to selected financial entities and to critical or important functions. It is not an automatic “quantum-risk assessment” trigger. It is the channel through which an HNDL-relevant PQ gap can surface as a regulatory finding.
PCI DSS defines “strong cryptography” in terms of industry-tested and accepted algorithms, minimum effective key strength, and proper key management. As NIST IR 8547 and SP 800-131A Rev. 3 move quantum-vulnerable public-key algorithms toward deprecation and disallowance, PCI-scoped environments should treat the NIST timelines as an input to cryptographic risk management, audit preparation, and compensating-control discussions rather than as an automatic PCI-specific PQC deadline (Barker et al., 2024; Moody et al., 2024). Confirm the applicable mandate before adopting the NCSC or CNSA timeline as the binding constraint. Mitigation owner: the governance-and-policy work-stream maintains a mandate-map per deployment region and escalates conflicts to the CISO.
Budget-cycle misalignment. A five-to-ten-year program spans multiple fiscal years with reset budgets. A single under-funded year can push a first-wave touchpoint past the NCSC 2031 deadline. Mitigation owner: the program lead reports variance against a multi-year program baseline at each annual budget cycle, books the budget as multi-year capital where the organizational finance model permits it, and carries a slippage reserve.
Program drift. Scope creep (a tenth touchpoint appearing at month 18 of the program) or deprioritization after a change in leadership erodes the schedule silently. Mitigation owner: the program lead reports quarterly to an executive sponsor against the discovery-phase scope and the PQRA score. A scope change requires sponsor approval.
Tradeoffs
Section titled “Tradeoffs”Five decisions shape every migration program’s posture. The choice on each one depends on two factors: whether the program faces a hard external deadline (pushing toward the centralized, cutoff-aggressive side) and whether the organization carries distributed compliance exposure across business units (pushing toward the federated, long-tail side).
| Axis | Choose A | Choose B | A favors | B favors |
|---|---|---|---|---|
| Organizational shape | Centralized program | Federated work-streams | Programs with a single hard external deadline | Organizations running many business units on independent timelines |
| Transition primitive | Composite (Ed25519+ML-DSA) | Single post-quantum (ML-DSA) | Transition deployments that want the classical assumption kept beside the lattice one, where every relying party parses the composite OID (legacy-client compatibility comes from parallel chains, Ch 29, not from the composite) | End-state deployments once standards, client support, and policy acceptance are in place |
| Deprecation aggressiveness | Hard cutoff at phase gate | Long-tail until client population migrates | Programs with hard external deadlines | Programs with broad external clients |
| Reporting cadence | Monthly | Quarterly | Programs with active slippage | Programs with stable trajectory |
| Risk appetite | First-wave hard deadline | Adaptive schedule | Regulated or reputation-critical organizations | Organizations with distributed compliance exposure |
The transition-primitive row is the inheritance from Ch 27: composite constructions are the draft-era answer, and single post-quantum is the end state. The program flips from composite to single-PQ once RFC 9881 (ML-DSA in X.509, October 2025) (Massimo et al., 2025) and RFC 9909 (SLH-DSA in X.509, December 2025) (Bashiri et al., 2025) have client-side support across the deployment’s client population. RFC 9881 / RFC 9909 are X.509 algorithm-identifier RFCs, not regulatory mandates. The policy gate sits outside them.
The default ML-DSA parameter set is workload-dependent rather than universal. CNSA 2.0 for NSS specifies ML-DSA-87 across all classification levels, alongside ML-KEM-1024 and AES-256 (US National Security Agency, 2024); commercial deployments commonly default to ML-DSA-65 where the NIST category 3 security target and the smaller byte budget fit the workload.
The organizational-shape and reporting-cadence rows interact: a centralized program with a monthly cadence is the response to active slippage; a federated program with a quarterly cadence is the response to a stable rollout across many business units.
Where Part V ends and Part VI picks up
Section titled “Where Part V ends and Part VI picks up”Part V treated ML-KEM, ML-DSA, SLH-DSA, and the hybrid wrappers as given primitives. The focus was fitting them into deployments across six chapters: inventory (Ch 25), agility (Ch 26), composite constructions (Ch 27), TLS (Ch 28), PKI and code signing (Ch 29), and program management (this chapter). Three of the five touchpoints in the running example are Shor-vulnerable, and each reduces to a signature or a key-establishment operation whose post-quantum replacement is built in Part II or Part III. The other two use only symmetric primitives, so Shor does not break them, which is why password_hashing and webhook_hmac are scheduled into the broad rollout rather than the first wave.
Part VI returns to primitive construction, but at a different layer of the stack. A proof system is assembled from its own layers, not from signatures, and the signatures a deployment already runs sit outside the proof rather than being replaced by it. Chapter 31 introduces the four-layer decomposition (arithmetization, commitment, protocol logic, non-interactivity) that organizes the rest of the Part. Chapter 32 builds commitment schemes from Part II and Part III primitives. Chapter 33 treats the Fiat-Shamir transform in the QROM, the same transform Part IV’s SQIsign chapter relied on. Part I previewed it for signatures generally. It sits inside the fourth layer rather than forming one of its own.
Chapter 34 revisits STARKs, scalable transparent arguments of knowledge, and FRI, and Chapter 35 reads three deployed systems off that decomposition. Their postures differ. Zcash’s deployed proof systems are Shor-broken at both the commitment and the non-interactivity layer. ZKsync Era pairs a hash-based inner proof system, a post-quantum candidate whose concrete QROM accounting at deployment parameters is still pending, with a classical pairing-based outer wrapper, and Starknet verifies a FRI-based STARK on chain with no outer wrapper at all.
Readers who finish Part V have a migration toolkit for signatures and KEMs. Readers who finish Part VI have the additional toolkit for zero-knowledge systems, which includes a sharper view of which deployed blockchain and rollup pipelines are post-quantum today and which carry pending-literature risk. The migration logic is the same; the primitive being migrated is one layer up. Part VII covers the same four-phase shape for the blockchain stack. Ch 37 covers Layer-1 transaction signatures. Ch 39 covers consensus and staking signatures. Ch 40 covers ZK rollup verifier contracts. Ch 41 covers the governance and hard-fork machinery that activates each transition.
Exercises
Section titled “Exercises”-
Using the Block 1 rollup, add a sixth fictional touchpoint
legacy_gatewaywithquantum_status = "vulnerable",exposure = "public", and PQRA readiness scores of(inventory=3, data_sensitivity=2, standards_compliance=2, migration_readiness=1, vendor_supply_chain=2, timeline_urgency=1, governance_policy=3). Compute its priority by hand. Confirm where it sits relative toblockchain_validator_sig,password_hashing, andwebhook_hmac, and say what decides the ordering when two touchpoints score the same. State which of these three Ch 26 architectural areas (modular cryptographic architecture, operational tooling, or lifecycle management) owns its first-wave mitigation. -
Write a one-page program brief for a UK-regulated fictional organization on the NCSC 2028 asset-identification milestone. The brief must name the scope (estate in bounds), the four phases with their exit criteria, three top risks with mitigation owners, and a budget order-of-magnitude. Do not invent a specific budget number; state the factors the number is sized against.
-
Pick one program risk from the “Program-level risks” section and name a concrete mitigation owner inside the Ch 26 work-stream structure. Describe one measurable signal the owner reports to the program lead at the quarterly review.
-
Identify one Ch 26 architectural area that you expect will be the program bottleneck for an organization of your choice. State whether the bottleneck is in the Ch 26 area itself (for example, a gap in the modular-architecture work-stream’s dependency tracker) or in its interaction with the program (for example, a cryptographic-observability area that cannot measure composite-chain adoption). Propose a fix that lives inside the work-stream.
-
Name one classical touchpoint from the Ch 25 CBOM and describe the deprecation trigger for its classical kid. The trigger must be measurable (for example, “zero tokens issued under
rs256-2023within TTL for one full reporting quarter”) and must state which work-stream reports the measurement.
Worked solutions and editorial notes for these exercises are in Appendix D, Chapter 30. A separate track, for rebuilding rather than reading: the package exercises/ch30-migration-program has every function the chapter teaches replaced by a stub. Run PQC_IMPL=exercises pytest tests/ch30 to grade your version against the suite that proves the reference one.
References
Section titled “References”Last updated: