Post-Quantum Migration Kit

This stopped being a someday topic on 22 June 2026. Executive Order 14412 gave federal encryption a 31 December 2030 date and authentication 2031, ordered a FAR rule binding contractors to PQC-capable FIPS by the end of 2030, extended vulnerability disclosure programmes to cryptographic weaknesses, and commissioned a CBOM standard. OMB wants agency migration plans by late October 2026. NIST IR 8547 deprecates RSA-2048 and P-256 after 2030 and disallows them after 2035. CNSA 2.0 binds new national-security acquisitions from 1 January 2027. The EU wants inventories started by the end of 2026.

The algorithms are final — ML-KEM, ML-DSA and SLH-DSA — and hybrid TLS is already a configuration change on mainstream stacks: X25519MLKEM768 is default in browsers and CDNs, OpenSSH 10 defaults to hybrid, OpenSSL 3.5 ships PQC. The reason organisations will miss 2030 is not the cryptography. It is that they cannot say what they are using.

Count uses, not systems. This is the idea the whole kit is built on. One application is six inventory rows — TLS inbound, TLS outbound, SSH, JWT signing, database encryption with an RSA-wrapped key, a code-signing certificate — each with its own algorithm, data longevity, exposure and migration path. An inventory of systems produces a number that cannot be migrated against. An inventory of uses produces a work list.

And the trap most inventories miss: "AES-256 at rest" is quantum-vulnerable if the data key is wrapped with RSA. The discovery runbook names it explicitly, because a symmetric algorithm in a summary column hides an asymmetric key-wrap underneath it.

Mosca decides the order. The roadmap takes your planning horizon, your migration lead time and your secrecy threshold and reports whether you are already late. For ten-year secrets against a three-year migration and a 2032 threshold, you are. Wave 1 is therefore exposed long-lived data and the trust anchors — PKI roots, code and firmware signing — because those take longest and everything else chains from them. The web server is Wave 2, which is the opposite of where most programmes start.

Agility before swapping. A ten-item checklist scores whether changing an algorithm in a given system is a configuration change or a rewrite. That score, more than any migration budget, separates the organisations that will meet 2030 from the ones that will not — and it is worth knowing before the first swap rather than after.

What you get

01 Cryptographic Inventory (XLSX) — one row per cryptographic use across 21 CBOM-aligned fields, with the quantum-vulnerable flag derived automatically from the algorithm and the migration wave derived from data longevity × exposure × use type. Readiness percentage on the summary.

02 Discovery Runbook (Markdown) — layer by layer: network and protocol telemetry, application CBOMs, PKI and certificates, HSM/KMS and key-wrap, data and backups, devices and firmware, vendors. Plus hygiene items, a monthly close and what to keep as evidence.

03 Crypto-Agility Roadmap (XLSX) — the Mosca check against your own horizon and thresholds, four waves with the rules that assign them, 14 workstreams with dependencies, and the ten-item agility checklist with its score.

04 Vendor PQC Questionnaire (XLSX) — 20 weighted questions covering CBOM, roadmap dates per interface, EO 14412 and CNSA 2.0 commitments, agility, FIPS 140-3, PKI, key-wrap, devices, dual-signing, VDP and contract terms. Hard stops for a Tier 1 vendor with no roadmap, no hybrid-KEM date, no agility story or no contractual commitment.

05 Cryptographic VDP Addendum (DOCX) — the public addendum text, internal handling, severity guidance with a data-longevity factor, and researcher scope. It lands ahead of the VDP rule the executive order commissioned rather than after it.

06 Board One-Pager (PPTX) — two slides: the dates, the inventory and the Mosca result, then the waves, the exposure and the decisions.

07 Deadline Calendar (XLSX) — 15 milestones from 2024 to 2035 across EO 14412, OMB, the FAR, VDP and CBOM rules, CNSA 2.0, the EU roadmap and IR 8547, each with an applicability flag.

08 Practitioner Guide (PDF) — what changed, harvest-now-decrypt-later, the algorithms, the dates, uses not systems, Mosca and the waves, agility first, the hard parts, vendors, hybrid today, VDP, governance, a ninety-day plan, failure patterns and an FAQ.

pqc01.json — waves, thresholds, the algorithm map and the milestones, machine-readable.

Harvest-now-decrypt-later is not a forecast. Anything that must stay secret past 2035 and crosses classical TLS today is already collected. That is why the Mosca check comes before the roadmap rather than after it.

Pairs with the CRA 24-Hour Reporting Clock, whose disclosure policy this addendum extends, the CRA Conformity Package if you ship product and your SBOM has to become a CBOM, the TPRM Program Kit and Vendor Risk Operations Kit for the vendor overlay, the First 100 Days Kit if this is the board question you have just inherited, and the Security Metrics & KPI Library for reporting readiness over time.

The FAR rule, the VDP rule and the CBOM minimum elements are all pending at publication and are marked "verify final" in the files, as are the CNSA 2.0 category dates and HQC finalisation. A practitioner's toolset, not legal advice.