> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-products/quantum-safe-compliance.md). # 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. {% hint style="info" %} 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*. {% endhint %} ## 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. | Regime | What it requires | Timeline | | ----------------------------------------------- | ----------------------------------------------------------------------------------------- | ---------------------------------------------- | | **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 | {% hint style="info" %} 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). {% endhint %} ## 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. {% hint style="info" %} See [Generate a CBOM with the Xygeni CLI](/xygeni-scanner-cli/xygeni-cli-overview/generate-cbom-with-the-xygeni-cli.md) for how to produce the CBOM, and the [Inventory](/xygeni-products/application-security-posture-management-aspm/inventory.md) panels for browsing the discovered crypto assets. {% endhint %} ### 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). {% hint style="info" %} The post-quantum standards are listed alongside the others in [Supported compliance standards](/xygeni-products/compliance/compliance-scanner/supported-compliance-standards.md), and results appear on the [SSCS Compliance](/xygeni-products/compliance.md) page. {% endhint %} ### 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: | Factor | Effect on 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. {% hint style="info" %} 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. {% endhint %} ### 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: | Channel | What it finds | | -------------------------- | -------------------------------------------------------------------------------------------------------------------- | | **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. {% hint style="info" %} 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. {% endhint %} ## Getting the results All of the above come from the Xygeni scanner. The most common invocations: | Goal | Command | | ---------------------------------------- | ----------------------------------------------------------- | | 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` | {% hint style="info" %} With `xygeni scan --cbom ` 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](/xygeni-scanner-cli/xygeni-cli-overview/xygeni-scanner-reference.md) for the full set of post-quantum options. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.xygeni.io/xygeni-products/quantum-safe-compliance.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.