Quantum-Safe Compliance & CBOM
Xygeni helps you discover the cryptography in your software, assess its post-quantum readiness, and demonstrate compliance with the emerging post-quantum transition mandates — from a single scan of your source code, with no change to how your applications are built.
This capability is driven by normative requirements. The sections below first explain what regulators and standards bodies now require, then how Xygeni helps you meet each requirement.
Why post-quantum cryptography matters
Most of today's public-key cryptography — RSA, elliptic-curve schemes (ECDSA, EdDSA, ECDH), Diffie-Hellman and DSA — is broken by Shor's algorithm running on a sufficiently large quantum computer. Unlike a weak key, this cannot be fixed by choosing a larger key size: the algorithms themselves must be replaced.
The threat is not only in the future. In a "harvest now, decrypt later" attack, an adversary records encrypted traffic today and decrypts it once a cryptographically-relevant quantum computer exists — so any data that must stay confidential for years is already at risk.
In 2024 NIST finalized the first post-quantum standards — ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures — and the industry transition is now underway. Symmetric cryptography (AES) and hashes (SHA-2/3) are only weakened by quantum attacks (Grover's algorithm) and are hardened simply by using larger sizes (AES-256, SHA-384+); this section focuses on the public-key algorithms that must migrate.
The normative requirements driving the transition
Several mandates now require organizations to inventory their cryptography and migrate away from quantum-vulnerable algorithms on a defined timeline. These requirements are the driver for the capabilities described below.
NIST IR 8547 — Transition to PQC Standards
Retire quantum-vulnerable public-key cryptography
Deprecated 2030, disallowed after 2035
NSA CNSA 2.0 (national security systems)
Migrate to pure post-quantum algorithms (hybrid not approved)
Default by 2030, exclusive by 2033
EU PQC Roadmap (Coordinated Implementation)
Governance & cryptographic inventory, then migrate high-risk and all systems
2026 / 2030 / 2035
PCI DSS 4.0 (req. 12.3.3)
Maintain a documented cryptographic cipher-suite inventory and review it (crypto-agility)
No fixed PQC date
DORA (Art. 9)
ICT cryptographic controls and a key-management/encryption policy
No fixed PQC date
NIS2 (Art. 21)
Policies on the use of cryptography and encryption
No fixed PQC date
The first three regimes set explicit deadlines. PCI DSS 4.0, DORA and NIS2 impose a cryptographic-inventory and agility obligation but publish no post-quantum date — Xygeni treats them accordingly (see Demonstrate compliance — PQC standards below).
How Xygeni helps you meet them
1. Know your cryptography — the CBOM
Every requirement starts with the same prerequisite: you cannot migrate what you have not inventoried. Xygeni discovers the cryptographic assets used in your source code — algorithms, protocols, certificates and key material — and produces a Cryptographic Bill of Materials (CBOM) in CycloneDX 1.6, classifying each algorithm by quantum risk (shor-broken, grover-weakened, pqc-safe) and flagging harvest-now-decrypt-later exposure.
The discovered crypto assets also appear as first-class assets in the Inventory panels of the Xygeni platform.
See Generate a CBOM with the Xygeni CLI for how to produce the CBOM, and the Inventory panels for browsing the discovered crypto assets.
2. Demonstrate compliance — PQC standards
Xygeni maps your cryptographic inventory to the mandates above as compliance standards, producing an auditable pass / partial / fail verdict against each regime's timeline:
NIST IR 8547, NSA CNSA 2.0 and the EU PQC Roadmap are evaluated against their concrete 2030 / 2033 / 2035 deadlines.
PCI DSS 4.0, DORA and NIS2 enforce the cryptographic-inventory obligation as a hard control, and surface quantum-vulnerable cryptography as advisory migration debt — Xygeni does not assert a deadline that the regulation itself does not state.
Each standard checks two things: that a cryptographic inventory exists, and that no quantum-vulnerable cryptography remains in use relative to the applicable timeline (prioritising harvest-now-decrypt-later assets).
The post-quantum standards are listed alongside the others in Supported compliance standards, and results appear on the SSCS Compliance page.
3. Assess your supply chain — PQC readiness
Beyond your own code, Xygeni assesses the post-quantum readiness of your dependencies: for each cryptographic upstream it reports whether the library is post-quantum ready, partially ready, has a roadmap, or blocks your migration. This produces a procurement-facing report that answers "which of my upstreams stand in the way of going quantum-safe?"
4. Prioritize the migration — ranked backlog
A flat list of quantum-vulnerable algorithms doesn't tell you where to start. Xygeni scores each one and produces a ranked migration backlog, so you migrate the highest-risk assets first — directly supporting the EU "prioritize high-risk by 2030" expectation.
Each asset gets a 0–100 priority score, computed transparently as a base set by its quantum risk, multiplied by factors that each default to neutral — a missing signal never inflates or zeroes the score:
Quantum vulnerability
Shor-broken public-key (RSA/ECDSA/DH) sets a high base; Grover-weakened symmetric/hash a lower one. Post-quantum-safe algorithms are not ranked.
Harvest-now-decrypt-later (HNDL)
The differentiator — data encrypted today is decryptable once a quantum computer exists, so HNDL assets are boosted.
Exposure
Network-exposed cryptography (e.g. TLS) is boosted.
Reachability
Cryptography used in application code is boosted; test/build-only code is deprioritized.
Sensitivity
The project business_value (CRITICAL / HIGH / MEDIUM / LOW) scales the score.
Assets are banded critical (≥ 80), high (≥ 60), medium (≥ 35) or low, and every entry carries a one-line rationale plus its NIST IR 8547 / EU deadline — so the ranking is never a black box.
Generate the backlog with xygeni inventory --pqc-backlog backlog.md. Exposure and reachability currently use scanner-side proxies and are refined as richer signals become available.
5. Know what you can — and cannot — see — the coverage map
An inventory is only trustworthy to an auditor if its blind spots are stated. Alongside the CBOM, Xygeni produces a coverage map: for each discovery channel it reports the status and how many cryptographic assets it found, and it lists — explicitly — the cryptography it does not see.
Xygeni discovers cryptography from more than your source code:
Source code
Algorithms, protocols and certificate loads observed in your code (AST analysis).
Certificate files
X.509 certificates on disk (PEM/DER/PKCS#12/JKS).
Dependency attribution
The implementing library behind a detected asset (e.g. BouncyCastle, OpenSSL).
Private keys
Private-key material in the repository / configuration — presence and location only; key bytes are never captured.
IaC configuration
TLS settings in infrastructure-as-code (e.g. a declared minimum TLS version).
Each channel is marked covered (scanned in full), partial (scanned with known limits) or not-scanned. The report then names the deliberate blind spots — runtime/dynamically-selected crypto, network & TLS handshakes, keys in HSM/KMS, cryptography inside compiled binaries and container base-image layers, and crypto reachable only through transitive dependencies — so the inventory is never mistaken for exhaustive.
Generate the coverage map with xygeni inventory --crypto-coverage coverage.md. Private-key and IaC discovery never capture secret material — only that a key or TLS setting exists, and where.
Getting the results
All of the above come from the Xygeni scanner. The most common invocations:
Produce a CBOM (crypto inventory)
xygeni inventory --cbom cbom.json
Check a PQC compliance standard
xygeni compliance -s nist_pqc_transition --cbom cbom.json
Supply-chain readiness report
xygeni deps --pqc-readiness pqc-readiness.md
Ranked migration backlog
xygeni inventory --pqc-backlog backlog.md
Discovery coverage map
xygeni inventory --crypto-coverage coverage.md
Inventory and compliance in one pass
xygeni scan --cbom cbom.json -s nist_pqc_transition
With xygeni scan --cbom <file> the inventory phase emits the CBOM once and the compliance phase reuses it — the cryptographic inventory is not computed twice. See the Xygeni Scanner Reference for the full set of post-quantum options.
Last updated