TL;DR
Post-quantum cryptography (PQC) means cryptographic algorithms designed to resist attack by a future large-scale quantum computer. Migrating to it is now a dated obligation across Europe, the Americas and Asia-Pacific — not a research topic anymore.
The first deliverable everywhere is an inventory, not a code change. Every regime, such as NIST IR 8547, Transition to Post-Quantum Cryptography Standards, the EU roadmap, Spain's CCN-TEC 009 and similar ones for other regions, plus sectorial recommendations such as PCI DSS 12.3.3, starts by asking you to enumerate the cryptography you use.
A proposed incarnation of such an inventory for cryptographic assets is the CBOM (Cryptographic Bill of Materials), which is a machine-readable list of the algorithms, keys, certificates and protocols that a system uses. It is an extension of the well-known SBOM and the recommended standardized format for that inventory.
Check your earliest binding date; it may not be 2035. Most jurisdictions converge on discovery by 2026–2028, high-risk by 2030–2031, complete by 2035. The targets are known, but they are not one substitution. ML-KEM replaces key exchange, ML-DSA replaces general-purpose signatures, while hash-based schemes (SLH-DSA, XMSS/LMS) cover firmware and long-lived roots. Key establishment is already shipping at internet scale; certificates and signatures are years behind — so urgency order and lead-time order differ, and your plan needs both.
The transition is a decade of coexistence, not a cutover. Until the mid-2030s most organizations will run classical and post-quantum cryptography side by side, and often literally combined: a hybrid construction. Crypto-agility is what makes that period survivable. It means being able to change algorithm, parameters, or whether you use a hybrid at all through configuration and policy, rather than by rewriting and redeploying code.
There are two "clocks" ticking, not one: the regulatory clock above, and "harvest now, decrypt later" (HNDL). The latter involves adversaries recording encrypted traffic today to decrypt it once a quantum computer exists. This means that data with a long confidentiality life is already exposed.
The hard part is not the algorithms, it is the discovery. Cryptography hides in source code, dependencies, certificates, key files, infrastructure-as-code, container images, protocol configuration and third-party products. A credible inventory has to say honestly what it cannot see.
Xygeni can help you prepare for PQC by producing the CBOM, classifying every crypto asset by quantum risk, ranking a migration backlog by HNDL exposure, mapping the results to six regulatory regimes, and reporting on the post-quantum readiness of your dependencies. Full details: Quantum-Safe Compliance.
What a quantum computer breaks — and what it does not
This distinction is the single most important technical fact for a GRC audience, because it decides whether a finding is a replacement project or a configuration change. Getting it wrong produces remediation advice that is not merely useless but actively harmful.
Shor’s algorithm — a quantum algorithm that factors large integers and computes discrete logarithms efficiently — structurally breaks today’s public-key cryptography: RSA, ECDSA, EdDSA, Diffie-Hellman and ECDH, or DSA. There is no key-size fix. A 4096-bit RSA key is not meaningfully safer than a 2048-bit one against a quantum adversary. These algorithms must be replaced. The same applies to national variants built on the same mathematics — China’s SM2, for instance, is elliptic-curve based and therefore equally exposed.
Grover’s algorithm — a quantum search algorithm — weakens symmetric ciphers and hash functions, but only by roughly halving their effective strength. These are hardenable in place: move from AES-128 to AES-256, from SHA-256 to SHA-384 or SHA-512. NIST IR 8547 makes the point directly: NIST’s symmetric standards “are significantly less vulnerable to known quantum attacks than the public-key cryptography standards”, and any approved symmetric primitive offering at least 128 bits of classical security still meets NIST’s lowest post-quantum security category.
The machine that would do this is called a CRQC — a cryptographically relevant quantum computer. Public policy is careful about its status; the US implementing memorandum puts it plainly: “A CRQC is not yet known to exist, but steady advancements in the quantum computing field may yield a CRQC in the coming decade.”
What has changed is not that the machine arrived — it is that the estimate of what it would take keeps shrinking. In May 2025, Craig Gidney of Google Quantum AI published a resource estimate showing that RSA-2048 could be factored in under a week by a quantum computer with fewer than a million noisy qubits — roughly a twentyfold reduction from his own 2019 estimate of ~20 million. That is an engineering estimate, but an estimate that falls 20x in six years is exactly the kind of trend a risk function is paid to take seriously.
The clock that already started: harvest now, decrypt later
Harvest now, decrypt later (HNDL) is the practice of capturing encrypted traffic or data today and storing it until a CRQC can decrypt it. It converts a future capability into a present-day exposure for anything that must stay confidential for years: health records, legal files, intellectual property, state secrets, long-lived credentials, signed evidence.
Regulators have stopped hedging on this. The European Commission’s January 2026 proposal to amend NIS2 states in Recital 8 that “the possibility of ‘harvest now – decrypt later attacks’, likely occurring already now, and the future risks induced by quantum attacks on forging signatures” justify the transition.
The planning consequence is simple arithmetic, an argument Michele Mosca has been making since 2015: add the number of years your data must remain confidential to the number of years your migration will take. If that sum reaches beyond the point where a CRQC plausibly exists, you are already late. For most regulated organizations, a multi-year migration plus a decade of data retention comfortably exceeds any credible estimate.
NIST draws the operational conclusion in IR 8547: it “expects to prioritize the migration to quantum-resistant key-establishment schemes … to protect against ‘harvest now, decrypt later’ attacks, particularly in interactive protocols like TLS and IKE.” Key establishment first, signatures second — an ordering the US federal phasing follows literally, with post-quantum key establishment due a full year before signatures. (IKE is the key-negotiation protocol behind IPsec VPNs.)
Why is this a GRC problem before it is a cryptography problem?
There are three reasons why this ends up on the desks of CISOs and compliance officers rather than staying with crypto engineers.
The deadlines come from law and regulation, not from physics. Nobody knows when a CRQC arrives. Everybody can look up that the EU expects high-risk use cases migrated by end-2030, that Australia’s ASD expects the whole transition finished by end-2030, and that NIST deprecates RSA and elliptic-curve cryptography at the 112-bit security-strength level after 2030 and disallows all quantum-vulnerable public-key cryptography after 2035. Those dates are auditable; the quantum timeline is not.
The first deliverable is an audit artifact. Before any algorithm is swapped, every regime asks the same question: what cryptography do you have, and where? That is an inventory obligation — a governance deliverable with an owner, a review cadence and evidence requirements. PCI DSS has required exactly this since March 2025, quantum or no quantum.
It is a procurement problem. Most of the cryptography in your estate is not yours. It is in libraries, platforms, appliances, SaaS providers and payment terminals. The EU roadmap asks entities to “create dependency maps … looking at both internal dependencies and third party dependencies”; ASD publishes a companion list of post-quantum questions to ask your vendors. Both are supplier-management activities, and both need evidence you can put in front of an auditor.
The rulebook: what actually applies to you
The algorithms are settled
NIST finalized the core post-quantum standards in August 2024 — ML-KEM for key establishment (FIPS 203), and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures — so there is no longer a “wait for the standards” defense. A KEM, or key-encapsulation mechanism, is the post-quantum replacement for key exchange: it establishes a shared secret between two parties, and it is the piece that stops HNDL.
Two more are in flight: FN-DSA (FIPS 206, based on Falcon) is still not published even as a draft, and HQC was selected in March 2025 as a code-based backup key-encapsulation mechanism, documented in NIST IR 8545. Neither should block a plan today, but both are reasons to build for crypto-agility — being able to change algorithm by configuration rather than by rewriting code. Which of your algorithms becomes which is set out in the replacement map further down.
The reference timeline: NIST IR 8547
NIST IR 8547, Transition to Post-Quantum Cryptography Standards, is the document most other roadmaps calibrate against, because it puts dates on the retirement of classical public-key cryptography:
A note on units: NIST states security strength, not key length. Per SP 800-57 Part 1 Rev. 5, Table 2, the 112-bit strength level is RSA-2048 and elliptic curves with a 224–255-bit order (P-224); the 128-bit level is RSA-3072 and curves of 256–383 bits (P-256). So “112-bit RSA” is not a 112-bit key — it is the RSA-2048 that still terminates a large share of production TLS. And the ubiquitous P-256 / RSA-3072 pairing is not in the 2030 deprecation bucket; it is in the 2035 disallowance bucket. Both buckets end at the same place: after 2035 no quantum-vulnerable public-key algorithm is approved at any parameter size.
One caveat worth knowing before you cite it in a steering committee: IR 8547 is still an initial public draft — published November 2024, comment period closed January 2025, no final version at the time of writing. That has not stopped it becoming the reference; national roadmaps and vendor products, Xygeni included, calibrate against it. Note also what it is not: it says nothing about inventories, discovery or crypto-agility. Those obligations come from elsewhere.
The global map: who says what, and by when
This table summarizes the regulatory framework by region:
Three divergences are worth more than a table row.
- Australia is five years ahead of everyone else. ASD’s guidance is not “deprecate the weak parameters by 2030” — it is “have completed the transition by end-2030”, and the ISM recommends ceasing the use of traditional asymmetric cryptography, “including cryptographic algorithms such as the Rivest-Shamir-Adleman (RSA), Diffie-Hellman (DH), Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA) primitives”, by that date. If you operate in Australia or sell into Australian government supply chains, that is your binding date, not 2035.
- China is running a sovereign track. It has not adopted ML-KEM and ML-DSA; the State Cryptography Administration’s institute ran its own call for next-generation commercial algorithms, with submissions closing in June 2026 and standards to follow. For a multinational this means planning for two post-quantum algorithm families in the same estate, with SM2 — elliptic-curve based, so equally Shor-broken — as the incumbent to migrate off. Crypto-agility stops being an abstraction here.
- Most of the world has no national PQC mandate at all — and it changes little. Across most of Latin America, and in much of the Middle East and Asia-Pacific, no PQC deadline has been published. Obligations still arrive, through three channels that ignore borders: sector regulators (a Singapore-style advisory to financial institutions; a central bank’s expectations), horizontal standards that already demand a cryptographic inventory (PCI DSS, ISO/IEC 27001 control sets), and customers. A supplier to an EU, Australian or US federal buyer inherits their deadline through the contract.
What binds a private organization anyway
Set the national roadmaps aside for a moment. For most private organizations the enforceable obligations come from four places, none of which was written for quantum:
- NIS2 (Directive (EU) 2022/2555) requires, in Article 21(2)(h), “policies and procedures regarding the use of cryptography and, where appropriate, encryption” as a baseline risk-management measure. COM(2026) 13 would make the quantum dimension explicit by adding PQC transition to Article 7(2).
- DORA — the Digital Operational Resilience Act and its technical standards, Commission Delegated Regulation (EU) 2024/1774. Article 6 requires financial entities to include in their encryption policy “provisions for updating or changing, where necessary, the cryptographic technology on the basis of developments in cryptanalysis”, and where they cannot update, to “adopt mitigation and monitoring measures that ensure resilience against cyber threats”. That is a crypto-agility obligation with a supervisor attached, and its recitals name quantum advancements explicitly.
- PCI DSS v4.0 requirement 12.3.3 — the one most organizations already fail without realizing it is a PQC requirement in disguise. The PCI SSC describes it as a “new requirement to document and review cryptographic cipher suites and protocols in use at least once every 12 months”, and it stopped being a best practice on 31 March 2025. No PQC deadline, no quantum algorithm list — but the annual cryptographic inventory and the documented plan for responding to cryptographic change are precisely the controls a PQC program needs, already in force and already audited.
- Procurement cascade. Two clauses will reach further than any national roadmap. The Cyber Resilience Act (Regulation (EU) 2024/2847) applies from 11 December 2027 and already makes an SBOM a manufacturer obligation for products with digital elements — it does not mandate a CBOM, but it establishes machine-readable bills of materials as product-compliance artifacts. And in the US, EO 14412 directs the Federal Acquisition Regulation (FAR) Council to propose a rule requiring covered contractors to comply with NIST FIPS incorporating PQC algorithms by 31 December 2030, and — the clause with the widest reach — orders CISA and NIST to publish, within 270 days (around 19 March 2027), “public guidance describing the agencies’ considered view as to the minimum elements for a cryptographic bill of materials. These elements shall enable the automated assessment of the cryptographic assets utilized by a hardware or software element.”
That last one matters far beyond Washington. “Minimum elements for an SBOM” is precisely how the software bill of materials went from a good idea to a contractual artifact worldwide. CBOM is now on the same track, with automated assessment written into the requirement — a manual spreadsheet will not satisfy it.
The format: CycloneDX CBOM
CycloneDX is the standard that gives CBOM a concrete shape. Version 1.7, released 21 October 2025 and ratified as ECMA-424 2nd Edition, is the current crypto-focused revision: it adds a standardized list of cryptographic algorithm families and a comprehensive list of elliptic curves, explicitly to support “audits, compliance reviews, and PQC readiness assessments”. A CycloneDX CBOM describes four kinds of crypto asset — algorithms, protocols, certificates, and related material such as keys, IVs and salts — plus the software components that implement them.
The point is narrow but useful: when CBOM minimum elements are published, CycloneDX is the format the market will already be speaking.
The consolidated timeline
The pattern is the same shape almost everywhere: discovery by 2026–2028, high-risk migration by 2030–2031, everything else by 2035. Plan against that shape and you are broadly aligned with all of them. Then find the single date that binds you first — it is rarely 2035, and for anyone in PCI DSS scope the inventory obligation started back in 2025.
The migration itself: what replaces what
Deadlines are only half the briefing. The other half is what you are actually migrating to — and the answer is not one substitution but several, with different maturity, different sizes and very different lead times.
The replacement map
Hybrid — combining a post-quantum algorithm with a classical one so that an attacker must break both — is the default posture during the transition, and RFC 9794 (June 2025) finally standardized the vocabulary for it (“PQ/T hybrid”). Policy diverges here, so it is a jurisdiction question, not an engineering preference: Spain’s CCN recommends hybridizing lattice-based signatures (ML-DSA, FN-DSA) while stating that hash-based schemes (XMSS, SLH-DSA) do not need it, and the EU posture is broadly hybrid-friendly; CNSA 2.0, by contrast, wants pure PQC for national security systems. A multinational will need both configurations, which is an argument for making the algorithm choice configuration rather than code.
What has no drop-in replacement
NIST has standardized exactly two things: key encapsulation and digital signatures. That is enough for most of an estate, and nothing for the rest. If your systems rely on pairing-based constructions, identity- or attribute-based encryption, threshold, blind or group signatures, or other advanced protocol-level cryptography, there is no approved post-quantum equivalent to migrate to today — the honest answer is to identify those uses now, flag them as unresolved, and design an exit rather than wait for a standard. The same applies to hardware roots of trust: HSMs (hardware security modules), TPMs and smartcards move on silicon refresh cycles that are longer than the regulatory window.
Not one migration, but several with different lead times
This is where the replacement map changes the readiness timeline. The order of urgency and the order of lead time are not the same, and a plan built on only one of them will miss a deadline.
- Data in transit — key establishment. Highest urgency (it is the HNDL surface) and the shortest lead time: for most stacks it is a library upgrade and a configuration change. It is also demonstrably tractable — Cloudflare reported in October 2025 that over half of human-initiated traffic to its network already used post-quantum key agreement. The gap is on your side of the connection: only ~39% of the top 100,000 public web servers supported it, and 3.7% of origin servers behind Cloudflare. Current figures are on Cloudflare Radar. Start here, finish early.
- Code, firmware and secure-boot signing. Low HNDL urgency — nobody harvests a signature — but a long lead time and an early deadline, because a device shipped in 2027 must still verify signatures in 2040, and signing roots have decade-plus lifetimes. The standards are ready (SP 800-208, SLH-DSA); CNSA 2.0 and Spain’s CCN both put firmware signing at the front of the queue for exactly this reason. Start now despite the low urgency.
- PKI and certificates. You do not control this schedule. Post-quantum certificates were not expected to be broadly available and trusted across browsers before 2027, hybrid certificate formats were still unsettled at the IETF as of late 2025, and chain sizes grow several-fold. Pilot and budget; do not promise a date you do not own.
- Data at rest and long-lived archives. The bulk encryption is fine — AES-256 is a parameter change. The exposure is in the key hierarchy above it: key wrapping and key transport that use RSA or ECDH. Re-encryption campaigns are slow and touch backups, archives and escrow.
- Embedded, OT (operational technology — industrial and control systems) and third-party systems. Refresh cycles longer than the window, and some assets that simply cannot be migrated. For those the answer is replacement, compensating controls, or a documented, accepted risk — and the earlier you name them, the cheaper each of those options is.
Two practical consequences for a GRC plan. First, schedule backwards from your earliest binding date by lead time, not by risk score alone: the ranked backlog tells you what to fix first among the things you can fix quickly; the lead-time list tells you what to start first regardless. Second, the inventory has to record the use case, not just the algorithm. “RSA-2048 in this repository” is not actionable; “RSA-2048 used for key transport in a public-facing service” and “RSA-2048 used to sign firmware” are two different projects with two different targets, two different deadlines and two different owners. That is why an inventory has to capture the primitive class and the surface the cryptography was found on, not just an algorithm name — and why building one turns out to be harder than it sounds.
Why PQC readiness is hard: cryptography really is everywhere
Every regime asks for the inventory first because the inventory is the hard part. Organizations discover this the moment they try.
Where cryptography actually hides
- Call sites in your own source — a cipher constructed in a service, a hash chosen in a utility class, a curve named in a signing routine. Eight languages in one monorepo means eight sets of idioms.
- Dependencies — the majority of crypto in most applications is executed by libraries the team never chose deliberately: BouncyCastle, OpenSSL, libsodium, node-forge, PyCryptodome, Tink. Which algorithm actually runs is a property of the library, not of your code.
- Certificates and key material — X.509 certificates checked into repositories, PEM key files in config directories, keystores baked into images.
- Infrastructure-as-code and protocol configuration — a minimum TLS version in a Terraform module, a cipher suite list in an ingress controller, an SSH configuration in a base image.
- Container images and compiled binaries — crypto libraries linked into layers nobody’s source scan ever reads.
- Third-party products and SaaS — the crypto you can neither see nor change, only ask about.
- HSMs, key management services and network devices — the crypto that lives outside software entirely.
The four things that make this a program, not a scan
Honest coverage. An inventory is only evidence if it states its own limits. “We scanned source, dependencies, certificates, key files and IaC configuration; we did not scan runtime traffic, TLS handshakes, HSM contents, compiled binaries or container layers” is a defensible position. A number with no denominator is not.
Prioritization, not enumeration. A large estate produces thousands of crypto findings. A flat list is unusable. The ranking that matters combines four things: is the algorithm Shor-broken or merely Grover-weakened; how long must the data it protects stay confidential (the HNDL factor); is it exposed to a network; and is it actually reachable in running code rather than sitting in a test fixture or a vendored sample. Every roadmap that says “high-risk use cases first” is issuing a prioritization instruction, and you cannot answer it from an alphabetical list.
Agility, not just replacement. As the replacement map showed, the target set is still moving and the hybrid rules differ by region — the swap you make in 2027 will not be your last. Hardcoded algorithm names, pinned cipher suites, no provider abstraction and non-negotiable protocol versions are what turn the next swap into another multi-year project. These are findings in their own right, cheap to fix now and expensive to fix later.
The supply chain. You cannot migrate faster than your slowest upstream. Which of your dependencies support PQC, which offer hybrid modes, which have published a roadmap, which publish a CBOM at all — that determines your critical path, and it is also the evidence a procurement team needs under NIS2 and DORA supplier-risk obligations.
One more trap: the inventory is a control, not a project
The instinct is to run a discovery exercise, produce a spreadsheet, and file it. PCI DSS already forecloses that with its twelve-month review cycle; Spain’s CCN closes its migration checklist with “update the inventory of cryptographic assets and their dependencies”; and the US implementing memorandum is blunter still:
Given the scale and complexity of Federal IT environments, manual approaches to discovery and management of cryptography are often insufficient. Agencies should use automation when feasible and appropriate to achieve a comprehensive and continuously updated understanding of their cryptographic posture. Automation is critical for inventory management, policy enforcement, and compliance reporting.
Cryptography drifts: a developer adds a library, a base image changes, a new service ships with a default cipher suite. An inventory that is regenerated on every build is a control; one regenerated annually by hand is an archaeology project you will repeat forever.
What “PQC readiness” means in practice
Strip away the vendor language, and PQC readiness is the ability to produce six things on demand:
- A cryptographic inventory in a standard machine-readable format, covering the surfaces you can see, regenerated automatically.
- A risk classification of every asset in it: must be replaced (Shor-broken), can be hardened in place (Grover-weakened), or already quantum-safe.
- A ranked migration backlog that reflects data longevity, exposure and reachability — so “high-risk use cases first” is answerable.
- A coverage statement that names your blind spots explicitly.
- Compliance evidence mapped to the regimes that actually bind you, with their dates.
- A supply-chain readiness view telling you which upstreams block your migration.
Everything else — key rotation, certificate lifecycle, HSM orchestration, network discovery — matters, but it is downstream of these six. You cannot rotate what you have not found.
How Xygeni helps
Xygeni’s Quantum-Safe Compliance capability produces all six from the scan that already runs in your pipeline. No separate crypto-estate product, no agent, no change to how you build — crypto discovery runs alongside the SCA (software composition analysis — the dependency scan), SAST (static application security testing — the source-code scan) and IaC analysis you already have.
1 · The CBOM. Xygeni emits a CycloneDX CBOM covering the four crypto asset types — algorithms, protocols, certificates and related material such as keys and salts — across Java, Kotlin, JavaScript/TypeScript, Python, Go, C#, PHP and Swift, and links each algorithm to the library that implements it. Crypto assets are first-class inventory objects on the platform, alongside components, vulnerabilities, secrets and IaC findings, so they carry the same provenance and history. Key material is never included in the inventory — only its presence, type and location.
2 · Quantum-risk classification. Every asset is labelled shor-broken (public-key, must be replaced), grover-weakened (symmetric or hash, hardenable in place) or pqc-safe, and flagged for HNDL exposure. The same distinction drives the SAST remediation advice, which branches on primitive class: RSA and ECC get “migrate to ML-KEM or ML-DSA, with a hybrid construction during the transition”, while AES-128 and SHA-256 get “increase the key or digest size”. This is deliberate — advising a larger RSA key against a quantum adversary is worse than saying nothing, and any tool that conflates the two cases will do exactly that.
3 · The ranked migration backlog. Rather than a flat list, Xygeni scores each quantum-vulnerable asset 0–100 from quantum vulnerability, data longevity and sensitivity, network exposure, reachability and business value, and emits a ranked backlog. This is what turns “high-risk use cases by 2030” from a slogan into a work queue.
4 · The coverage map. Xygeni reports what it looked at and what it did not: source code, certificates, dependency attribution, private-key files and IaC configuration are enumerated as covered, partial or not scanned, with runtime and network traffic, TLS handshakes, HSM and KMS contents, compiled binaries and container-layer libraries named explicitly as blind spots. Auditors respond well to a tool that states its own limits; so, in our experience, do CISOs.
5 · Compliance evidence. The compliance engine evaluates the crypto inventory against six regimes and returns pass, partial or fail verdicts against their actual deadlines: NIST IR 8547, NSA CNSA 2.0, the EU PQC Roadmap, and the post-quantum subsets of PCI DSS 4.0, DORA and NIS2. This sits in the same compliance scanner as the CIS Software Supply Chain benchmark, OWASP SCVS and OpenSSF standards, so PQC posture reports through the same channel as the rest of your software supply chain compliance. Organizations whose binding deadline comes from elsewhere — ASD, CCCS, CCN — can work from the same evidence, since those roadmaps sit on the same 2030/2035 skeleton; only Australia’s end-2030 completion date needs to be tracked separately.
6 · Supply-chain readiness. Each dependency carries a post-quantum readiness attribute — does it support PQC, does it offer hybrid modes, does it have a published roadmap — so you can see which upstreams sit on your critical path, and produce a vendor readiness view for procurement.
Beyond the six: crypto-agility findings. Xygeni also flags the patterns that make the next migration a rewrite — hardcoded algorithm and curve choices, missing provider abstraction, pinned legacy cipher suites, non-negotiable protocol versions. Weak and quantum-vulnerable crypto is enforceable through the same policy layer as the rest of your findings, so a net-new Shor-broken algorithm can be caught in the pull request rather than in next year’s audit.
Key takeaways
- Find your earliest binding date before you plan anything. Most roadmaps converge on 2030 for high-risk and 2035 for the rest — but Australia expects the whole transition done by end-2030, and PCI DSS started asking for the inventory in 2025.
- Plan against the shape, not the jurisdiction. Discovery by 2026–2028, high-risk migration by 2030–2031, complete by 2035. Align once and you satisfy most of them; track the exceptions separately.
- Start with the inventory, because everyone asks for it first — the EU, Spain, Canada, Australia, Singapore’s MAS and PCI DSS all open with the same deliverable.
- Use CBOM as the format. The EU roadmap recommends it by name; US guidance on CBOM minimum elements is due around March 2027 and explicitly requires automated assessment.
- Never conflate Shor and Grover. Public-key must be replaced; symmetric and hash can be hardened in place. Remediation advice that mixes these up is worse than no advice.
- HNDL sets your real deadline. Data that must stay confidential past 2035 is exposed today. Prioritize key establishment — TLS, IKE, anything protecting data in transit — over signatures.
- Schedule by lead time, not only by risk. Key establishment is urgent but quick; firmware signing and PKI are not urgent but slow, and slow items have to start first. Anything you cannot migrate — old hardware, frozen third-party products — should be named this year, because replacement is the only remaining option and it needs a budget cycle.
- Record the use case, not just the algorithm. RSA protecting a TLS handshake and RSA signing firmware are two different projects, with different targets, deadlines and owners. An inventory that only lists algorithm names cannot drive a migration.
- Demand an honest coverage map. Any tool claiming complete cryptographic visibility from a source scan is overselling. What it cannot see matters to the auditor as much as what it can.
- Build for the second migration. FIPS 206 is not final, HQC is not standardized, and China and Korea are standardizing their own families. A multinational estate will hold more than one post-quantum algorithm set; crypto-agility findings are cheap now and expensive in 2031.
- Automate it or repeat it. A cryptographic inventory regenerated on every build is a control. A spreadsheet is a snapshot that starts drifting the day it is signed.
To read more
The full technical detail — what is discovered, how the quantum-risk classification and priority scoring work, what each compliance regime is evaluated against, and how to get the reports — is in the Xygeni documentation:
- Xygeni: “Quantum-Safe Compliance“. Xygeni Docs.
- Xygeni: “Generate a CBOM with the Xygeni CLI“. Xygeni Docs.
- Xygeni: “Supported compliance standards“. Xygeni Docs.
Standards and algorithms:
- NIST: “IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards“. November 2024.
- NIST: “FIPS 203 (ML-KEM)“, “FIPS 204 (ML-DSA)“, “FIPS 205 (SLH-DSA)“. August 2024.
- NIST: “IR 8545: Status Report on the Fourth Round of the NIST PQC Standardization Process“. March 2025.
- NIST: “SP 800-57 Part 1 Rev. 5: Recommendation for Key Management” — Table 2, comparable security strengths.
- NIST: “SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes” (LMS, HSS, XMSS, XMSS^MT). October 2020.
- IETF: “RFC 9794: Terminology for Post-Quantum Traditional Hybrid Schemes“. June 2025.
- Cloudflare: “State of the post-quantum Internet in 2025” and live adoption data on “Cloudflare Radar“.
- CycloneDX: “Cryptography Bill of Materials (CBOM)” and “CycloneDX v1.7 release“. October 2025.
National and regional roadmaps:
- ASD (Australia): “Planning for post-quantum cryptography“. September 2025.
- NIS Cooperation Group: “A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography“. June 2025.
- CCN (Spain): “CCN-TEC 009 / BP-37 — Recomendaciones para una transición postcuántica segura“. Julio 2026.
- European Commission: “Commission Recommendation (EU) 2024/1101” (11 April 2024) and “COM(2026) 13 — Proposal amending Directive (EU) 2022/2555 (NIS2)” (20 January 2026).
- NCSC (UK): “Timelines for migration to post-quantum cryptography“. March 2025.
- Canadian Centre for Cyber Security: “Roadmap for the migration to post-quantum cryptography for the Government of Canada (ITSM.40.001)“. June 2025.
- The White House: “Executive Order 14412 — Securing the Nation Against Advanced Cryptographic Attacks” (22 June 2026) and OMB “M-26-15” (24 June 2026).
- NSA: “Post-Quantum Cybersecurity Resources (CNSA 2.0)“.
- CRYPTREC (Japan): “CRYPTREC” — ML-KEM added to the Recommended Ciphers List, March 2026.
- MAS (Singapore): “Advisory on Addressing the Cybersecurity Risks Associated with Quantum“. February 2024.
- NZISM (New Zealand): “Preparation for Post-Quantum Cryptography“.
- ICCS (China): “Institute of Commercial Cryptography Standards” — next-generation commercial cryptographic algorithms program.
- ITI (Brazil): “ITI publica Instrução Normativa que incorpora algoritmos pós-quânticos à ICP-Brasil“. Janeiro 2026.
Sector and horizontal obligations:
- EU: “Directive (EU) 2022/2555 (NIS2)“; “Regulation (EU) 2022/2554 (DORA)“; “Commission Delegated Regulation (EU) 2024/1774 (DORA ICT risk-management RTS)“; “Regulation (EU) 2024/2847 (Cyber Resilience Act)“.
- PCI Security Standards Council: “Summary of Changes from PCI DSS v3.2.1 to v4.0” (requirement 12.3.3).
Background:
- Craig Gidney: “How to factor 2048 bit RSA integers with less than a million noisy qubits“. Google Quantum AI, May 2025.
- Michele Mosca: “Cybersecurity in an era with quantum computers: will we be ready?“. IACR ePrint 2015/1075.
