Chapter 30: Running a PQ migration program
Shipping a post-quantum migration is a program, not a project. A single TLS endpoint can move once its stack supports the hybrid group and the rollout signals hold (Ch 28). A CA hierarchy cannot be scheduled that way, because retiring its classical chain waits on the client population (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 (UK National Cyber Security Centre, 2025), the EU’s coordinated roadmap for its Member States (NIS Cooperation Group, 2025), CNSA 2.0 for U.S. National Security Systems (US National Security Agency, 2022, 2026), 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 scores an organization’s readiness to migrate (Encryptorium, 2026). This chapter adapts it to score and prioritize the touchpoints of the Ch 25 inventory. 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 broad rollout that follows the first 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 are among the longest-lived keys 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 NCSC’s 2028 discovery-and-assessment milestone is hit on time, its 2031 first-wave milestone lands with the highest-priority touchpoints migrated, and its 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 four jurisdictional tracks: the UK NCSC timeline, the EU coordinated roadmap, 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 |
| NIS Cooperation Group roadmap, June 2025 (NIS Cooperation Group, 2025) | EU Member States, for public administrations and critical infrastructure | 31 December 2026 first steps and initial national roadmaps; 31 December 2030 high-risk use cases transitioned; 31 December 2035 medium-risk use cases, and low-risk ones as far as feasible |
| CNSSP 15 / NSA FAQ v2.2, October 2026 (US National Security Agency, 2026) | 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 October 2026 FAQ carries the first set and does not restate the second, which is the September 2022 advisory’s. The first set’s gates bind NSS through CNSSP 15, subject to the exceptions and waivers that policy provides, while its 2035 entry is that policy’s stated objective rather than a further gate (Committee on National Security Systems, 2024, para. 18). Neither set is 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.
The EU row is a recommended timeline rather than a legal mandate. It is the first deliverable of the NIS Cooperation Group’s work stream on post-quantum cryptography, “a first high-level paper aimed at the Member States” (Section 1 in NIS Cooperation Group, 2025). Public administrations and other critical infrastructure, notably entities in scope of the NIS 2 Directive, “should refer to” it (Section 3.1 in NIS Cooperation Group, 2025). NIS 2 is the EU directive that requires the entities in its scope to adopt cybersecurity risk-management measures, including on the use of state-of-the-art cryptography (Section 1 in NIS Cooperation Group, 2025). Its 2030 milestone covers high-risk use cases, after which, in the roadmap’s wording, quantum-vulnerable public-key mechanisms “shall not be used stand-alone”, and its 2035 milestone extends that rule to medium-risk ones (Section 4.1 in NIS Cooperation Group, 2025).
The U.S. civilian federal row combines two instruments. Its 2030 and 2031 dates are the Executive Order’s. The order directs OMB to issue guidance requiring each agency to move its High Value Assets and high-impact systems to post-quantum key establishment and signatures by those dates (Section 4(b) in The White House, 2026).
OMB M-26-15 implements the order, and it words the migration itself as an obligation. Agencies “must execute a prioritized migration” with “the objective of mitigating as much quantum risk as feasible by December 31, 2030” (Section 3.A in Office of Management and Budget, 2026). They must also submit a migration plan within 120 days of the memorandum’s date and align it with NIST IR 8547, and the plan “should” run in five phases (Section 3.D in Office of Management and Budget, 2026). The fifth phase is qualified: it “should focus on completing the migration of remaining systems with consideration based on risk assessment and the availability of commercial offerings by 2035” (Section 3.D in Office of Management and Budget, 2026).
Four NIST documents supply the technical framing the program works inside. NIST IR 8547 identifies the quantum-vulnerable standards and the quantum-resistant standards that products and services will need to transition to (Moody et al., 2024). Its initial public draft (November 2024, still current on 19 October 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 post-quantum deprecation framing it leans on NIST IR 8547 and on the SP 800-131A Rev. 3 Initial Public Draft (October 2024) (Barker & Roginsky, 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 categories (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 carry the most weight because they are, in the PQRA’s words, “the two most actionable dimensions: knowing what you have and being able to change it” (p. 46 in Encryptorium, 2026). The PQRA calls the weights “a reasonable default for most organizations”, which specific sectors may need to change (p. 51 in Encryptorium, 2026). The PQRA itself scores one organization: a maturity score for each domain and a weighted overall score that maps to a risk category. 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, 2026), 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 target date or a CNSA deadline is the binding constraint on its exit. Its markers take their dates from the context table’s NCSC and CNSA 2.0 rows. CNSSP 15’s mandatory-use date gets a marker of its own, because it falls in the same year as NCSC’s 2031 milestone and comes from a different instrument.
tls_endpoint_api, key establishment and not authentication), and one before the next dashed line is on schedule.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. Two entries are the exception: tls_endpoint_api and jwt_signing, migrated in Ch 28 and Ch 29, carry a status assessed for the roles those chapters migrated, as the rollup discussion after Block 1 explains. So Block 1 runs on a residual snapshot, the CBOM after those two migrations, which the first-wave section explains. Ch 25’s CBOM records both entries as vulnerable. 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 touchpoint recorded as quantum-safe scores zero on this axis. Weak ownership, telemetry, or rollback discipline still belong on a separate operational-risk register. Under this rollup the two touchpoints migrated in Ch 28 and Ch 29 score zero. Their status records the roles those chapters completed, hybrid key establishment for tls_endpoint_api and composite signing for jwt_signing, and comes from assessing those constructions rather than from Ch 25’s family lookup. For the TLS endpoint, that status covers recorded sessions against harvest now, decrypt later, but not authentication: the certificate chain is still classical and needs its own migration. Retiring the classical halves of both touchpoints is the end-of-migration phase’s work.
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 deployment gap at chain-tip 2026, the date Ch 36 defines, rather than a standards gap. FIPS 204 standardizes ML-DSA (National Institute of Standards and Technology, 2024b), 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. Block 1’s residual snapshot is taken inside this phase: the tls_endpoint_api and jwt_signing migrations were executed as first-wave exemplars in Ch 28 and Ch 29, 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. The record below is illustrative: a gate with only the rollback drill outstanding, which the running example has not reached. The first criterion covers blockchain_validator_sig, a public-facing vulnerable touchpoint, so it stays unmet until the Ch 37 and Ch 39 work migrates that key. It also stays unmet while the certificate chain of tls_endpoint_api is still classical: that touchpoint’s recorded status covers key establishment, not authentication.
# 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 on every composite chain, 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 NCSC’s 2035 target date. Block 3’s milestones are the phase’s three exit criteria, each with a target date, and the report is run in January 2036. pq_only_mode concerns only the composite chains and classical_retired every classical public-key algorithm, so the first can be met while the second slips. 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 = [ ("classical_retired", "2035-12-31", False), ("pq_only_mode", "2035-06-30", True), ("post_migration_review_signed", "2036-06-30", 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, "2036-01-15")print(f"{r['completed']}/{r['total']} complete ({r['percent'] * 100:.0f}%), " f"slipped={r['slipped']}")# ==> 1/3 complete (33%), slipped=['classical_retired']A slipped milestone is a program-management signal. Slippage from 2035-12-31 on classical_retired (past due at the reporting date) surfaces either a client gap (clients still send classical-only traffic, so the classical chain serving them stays in service) or a recording gap (the chain is retired but unrecorded). 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, the BLS12-381 precompiles added by Ethereum Improvement Proposal (EIP) 2537 in the Pectra upgrade of May 2025, and a P-256 ECDSA verifier. EIP-7951 added that verifier in the Fusaka upgrade of December 2025 (Beekhuizen et al., 2025; Beiko et al., 2024). 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. These 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, released in April 2025 (OpenSSL Project, 2025), is a practical reference point for deploying X25519MLKEM768: its default group list prefers the hybrid, and its client sends key shares for X25519MLKEM768 and X25519 by default (The OpenSSL Project Authors, 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 advisory’s 2030 target for exclusive use in firmware signing 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 program 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 & Roginsky, 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 NCSC’s 2031 milestone. 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, 2026); 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.
The later chapters build those layers from earlier ones. Chapter 32 uses Chapter 13’s sieving costs for its lattice commitment’s quantum posture and builds its hash-based commitments on Chapter 14’s Merkle trees. Its KZG and inner-product argument (IPA) commitments come from neither Part II nor Part III: they rest on variants of the discrete logarithm problem, which Shor’s algorithm breaks (Shor, 1994). 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. Chapter 33 also covers the QROM treatment of Chapter 12’s Fiat-Shamir with aborts, the form ML-DSA takes. The transform sits inside the fourth layer rather than forming one of its own. Chapter 34’s FRI rests on Chapter 19’s codes and minimum distance, since its proximity test asks how far a committed word lies from a Reed-Solomon code.
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 with a classical pairing-based outer wrapper. The inner system is a post-quantum candidate, but no QROM accounting at its deployment parameters had been published by 19 October 2026, the date Chapter 34’s literature search runs to. 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 discovery-and-assessment 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: