> 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 repository, 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 your software uses — algorithms, protocols, certificates and key material — from source code, from application configuration and from infrastructure-as-code, 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 | Status | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | | **Source code** | Algorithms, protocols and certificate loads observed in your code (AST analysis). | covered | | **Certificate files** | X.509 certificates on disk (PEM/DER/PKCS#12/JKS). | covered | | **Private keys** | Private-key material in the repository / configuration — *presence and location only; key bytes are never captured.* | covered | | **Application configuration** | Cryptography a framework or server takes from its configuration rather than from code — an SSH daemon's key-exchange, cipher and MAC lists, a JWT signing algorithm, a TLS protocol floor or cipher list, a key-store reference, a password-hash work factor. | partial | | **IaC configuration** | Cryptography an infrastructure template declares: a minimum TLS version, a named load-balancer security policy and the cipher suites it enables, a managed certificate, a KMS or key-vault key spec. | partial | | **Dependency attribution** | The implementing library behind a detected asset (e.g. BouncyCastle, OpenSSL). | partial | 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`. Discovery from keys, certificates, configuration and infrastructure never captures secret material — only that a key, certificate or setting exists, and where. A configured value that is not a literal (an environment placeholder, a template variable resolved at apply time) is skipped rather than guessed, which is why these channels report as *partial*. {% 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-file cbom.json` | | Check a PQC compliance standard | `xygeni compliance -s nist_pqc_transition --cbom-file 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 -s nist_pqc_transition` | {% hint style="info" %} With `xygeni scan --cbom` the inventory phase discovers the cryptography once and the compliance phase reuses it — the inventory is not computed twice, and no intermediate file is needed. Add `--cbom-file ` if you also want the CycloneDX document on disk. 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.