Post-quantum migration — the cryptographic inventory playbook

Use this playbook when you are a regulated operator who must produce a defensible post-quantum migration plan on a supervisor's clock: an EU NIS2 essential or important entity, a DORA financial entity, an EU public-sector body inside the coordinated roadmap, a US federal agency or contractor under Executive Order 14412, or any organization holding secrets whose confidentiality must outlast the arrival of a cryptographically relevant quantum computer.

The deliverable this playbook produces is two things a regulator can read: a cryptographic inventory (often called a CBOM — a cryptography bill of materials) and a sequenced migration plan mapped to the deadlines that bind you.

What is not in scope here: choosing between the algorithms themselves — that decision (ML-KEM, ML-DSA, SLH-DSA under FIPS 203/204/205) is covered in the post-quantum cryptography definition. Symmetric-only estates (AES-256, SHA-384) need a configuration review, not this program — the hard, asymmetric migration is what this playbook sequences.

Unlike an incident playbook, the post-quantum clock is measured in years — but the first gate is already inside your planning horizon.

• End of 2026 — EU coordinated roadmap, Milestone 1. The EU Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography expects every Member State to have laid the groundwork: identified stakeholders, built cryptographic asset inventories and dependency maps including the supply chain, and launched a national awareness program. This is the inventory deadline — and it is this year.
• End of 2030 — high-risk use cases. The same roadmap states that quantum-vulnerable public-key mechanisms shall not be used stand-alone after 2030 for high-risk use cases. NIST IR 8547 aligns: 112-bit-security public-key algorithms (RSA-2048, ECDSA P-256) are deprecated after 2030.
• End of 2030 / 2031 — US federal. Executive Order 14412 (signed 22 June 2026) directs federal agencies to migrate high-value and high-impact systems to post-quantum key establishment by the end of 2030 and digital signatures by the end of 2031.
• 2035 — the backstop. The EU roadmap targets medium-risk use cases by 2035; NIST IR 8547 disallows quantum-vulnerable public-key cryptography entirely after 2035.

Over all of these sits the harvest-now-decrypt-later clock, which has no published date because it has already started: an adversary recording your encrypted traffic today decrypts it retroactively once a quantum computer exists. For any secret whose confidentiality must survive that long, the migration is already late. Sequence accordingly.

Goal: a complete, structured cryptographic inventory (CBOM). You cannot risk-rank or migrate what you have not found.

Enumerate cryptography everywhere it lives — not just the obvious TLS certificates:

• Transport: TLS endpoints (public and internal), the key-exchange and signature algorithms each negotiates, mutual-TLS pairs, VPN tunnels (IKE/IPsec, WireGuard), SSH host and user keys.
• PKI and signing: internal and external certificate authorities, root and intermediate CAs, code-signing keys, document-signing keys, firmware-signing keys — the long-lived trust anchors are the hardest to rotate and the highest-value harvest targets.
• Data at rest: database and disk encryption, backup encryption, KMS/HSM-held keys, envelope-encryption hierarchies.
• Application-embedded: cryptography hard-coded or configured inside your own applications and libraries, JWT/OIDC token signing, API request signing.
• Third-party and supply chain: the crypto your SaaS vendors, cloud providers and embedded/IoT suppliers use on your behalf — the roadmap explicitly requires the dependency map to reach into the supply chain.

For each entry, record: algorithm and key size, purpose, owning team, where the key material lives, the confidentiality lifetime of the data it protects, and whether the system is crypto-agile (can its algorithm be swapped without re-engineering?).

Automate discovery where you can — network scanning for TLS/SSH, certificate-store crawling, source and dependency scanning — but expect gaps: embedded firmware, air-gapped systems and legacy applications usually need manual attestation from their owners.

Goal: turn the flat inventory into a sequenced plan. The ordering principle is confidentiality lifetime versus time-to-CRQC, not ease of migration.

Urgency tiers:

• High: long-lived secrets and trust anchors — root and code-signing CAs, classified or regulated data with multi-decade retention, intellectual property, medical records, state communications. These are the harvest-now-decrypt-later bullseye; migration here is already overdue.
• Medium: data with multi-year but bounded confidentiality — financial records after settlement, internal communications under retention schedules.
• Low: short-lived session data and transient traffic whose value expires before a quantum computer is plausible.

Crypto-agility assessment: for each high and medium entry, decide the migration mode — hybrid (run a classical and a post-quantum algorithm together so you are safe if either holds), direct replacement (where the architecture already abstracts the algorithm), or phased re-engineering (legacy and embedded systems with hard-coded crypto and 10-20-year field lifetimes — VPN gateways, IoT firmware, root CAs).

Run pilots for the highest-risk and a representative medium-risk use case before committing the estate — the roadmap expects pilot projects at this stage, and they surface the integration breakage (larger keys, larger signatures, handshake latency, protocol incompatibility) that a paper plan hides.

Goal: execute the migration in priority order and produce evidence of progress at each gate.

• Hybrid key establishment first. For most TLS and VPN infrastructure, deploy a hybrid ML-KEM + classical key exchange. Hybrid protects against both a quantum break of the classical algorithm and an as-yet-undiscovered weakness in the new one. This is the single highest-leverage move against harvest-now-decrypt-later because it protects confidentiality immediately.
• Signatures next. Migrate code-signing, firmware-signing and certificate signatures to ML-DSA (or SLH-DSA where a conservative hash-based backup is warranted for long-lived trust anchors). Signatures protect integrity, not past confidentiality, so they follow key establishment in priority.
• Direct replacement where a crypto-agile architecture already lets you swap the algorithm by configuration.
• Phased re-engineering for the legacy and embedded tail — budget this as a multi-year project, not a patch.

At every step, record what moved and when. The regulator's question in 2027 and beyond will not be "are you fully migrated" — nobody will be — it will be "show me your inventory, your risk-ranking, and your evidenced progress against the plan". A migration you cannot evidence is, to a supervisor, a migration that did not happen.

Keep these artifacts current, signed, and exportable (not reconstructed the week before an audit):

• The cryptographic inventory / CBOM, with a last-updated timestamp and the discovery method per entry.
• The dependency map, including the supply-chain reach the EU roadmap requires.
• The risk-ranking rationale: why each system sits in its urgency tier, tied to data confidentiality lifetime.
• The sequenced migration plan with per-system target dates mapped to the 2026 / 2030 / 2031 / 2035 gates.
• Pilot results and the integration issues they surfaced.
• Per-system migration status over time — the evidenced progress line.
• Supplier crypto-agility attestations for third-party and embedded systems.
• The board / management-body approval record — both the EU roadmap and NIS2 Article 21 make this a governance-body responsibility, not a purely technical one.

The hard part is not producing this pack once; it is keeping it current and defensible across every framework that now expects crypto-agility evidence, while the estate changes underneath you. This is where Zero Hunt's automatic-compliance pillar fits: it maps your migration controls across 34 regulatory frameworks worldwide with cross-framework control mapping and severity-weighted scoring, and exports an ECDSA-signed evidence pack with chain-of-custody from the Trust Center — so the progress report a supervisor asks for is an export, not a person-week of reconciliation — while its scheduled, change-triggered campaigns keep the external asset picture live so a newly exposed endpoint still negotiating quantum-vulnerable key exchange surfaces as a finding instead of drifting off the inventory, and the autonomous AI red team validates whether such an endpoint is actually reachable and whether legacy key exchange is still negotiable, turning an inventory line into an exploitability-ranked priority. The engine runs entirely on-premise on private models, so the inventory of your most sensitive long-lived secrets never leaves the appliance.

1. Treating the inventory as a one-time project. The cryptographic inventory is a living asset, not a 2026 deliverable you file and forget. Every new service, certificate and vendor changes it. Without continuous or change-triggered rediscovery, the inventory is stale within a quarter and the supervisor's first spot-check finds an endpoint you never listed.

2. Forgetting the long-lived trust anchors. Teams inventory TLS certificates and miss the root CAs, code-signing keys and firmware-signing keys with 10-20-year validity. These are the hardest to rotate and the highest-value harvest targets — they belong at the top of the plan, not the end.

3. Scoping only the internet-facing estate. Internal TLS, service-mesh mTLS, database encryption, backup encryption and SSH are all in scope. Attackers who are already inside decrypt internal traffic too.

4. Trusting a vendor's "quantum-safe" label without validation. A product marked post-quantum may still negotiate a classical-only handshake by default, or offer the post-quantum mode only in a configuration you have not enabled. Require crypto-agility in contracts and validate the actual negotiated algorithms rather than the datasheet.

5. Migrating signatures before key establishment. Signatures protect integrity; they do nothing for the confidentiality of traffic already being harvested. If you have finite capacity, hybrid key establishment on your highest-confidentiality channels comes first.

6. Ignoring the performance and compatibility tail. Post-quantum keys and signatures are larger; handshakes can grow and some constrained devices, middleboxes and legacy protocols break. The pilots in Phase B exist to find this before it is a production incident.

Post-quantum migration is a worldwide obligation converging from several directions at once, and one inventory feeds all of them:

• EU: the coordinated roadmap sets the 2026 / 2030 / 2035 milestones; NIS2 Article 21 already requires policies and procedures on the use of cryptography and, where appropriate, encryption as a baseline security measure, which supervisors increasingly read to include a crypto-agility plan.
• US: Executive Order 14412 and NIST IR 8547 set the federal 2030 / 2031 / 2035 gates; federal contractors inherit them through procurement.
• Finance: DORA's ICT risk-management framework (Article 9) requires strong, current cryptographic controls, and a documented post-quantum plan is now part of a defensible answer.
• National guidance: ENISA at EU level and national authorities (Germany's BSI, France's ANSSI, the US NSA's CNSA 2.0 for national-security systems) publish migration timelines that may bind you earlier than the headline dates — check the one for your jurisdiction and sector.

In every case the underlying work is the same: one inventory, one risk-ranking, one evidenced migration plan, exported per regime. Building it once and keeping it current is the difference between a roadmap you can defend and a spreadsheet that was true in 2026.