Post-Quantum CBOM Generator
Scan a JSON dependency list for post-quantum cryptography readiness and receive a PQC migration roadmap aligned with NIST timelines.
Post-Quantum CBOM Generator
Map cryptographic asset risks and generate CycloneDX v1.6 exports.
Asset Inventory
CBOM Standard (2026): Post-Quantum Cryptography migration mandated under NIS2 requires a Cryptographic Bill of Materials (CBOM). RSA/ECC assets with data shelf-life exceeding 10 years are flagged as "Critical Risk" due to "Harvest Now, Decrypt Later" threats.
Enter cryptographic assets and click "Generate" to start the vault audit.
What a Cryptographic Bill of Materials Is and Why Regulators Now Require It
A Cryptographic Bill of Materials is a structured inventory of every cryptographic algorithm, key, certificate, and protocol in use across a software system or infrastructure stack. The concept extends the Software Bill of Materials — already mandated by US Executive Order 14028 for federal software suppliers — into the cryptographic layer specifically. Where a standard SBOM lists components and their versions, a CBOM goes further by identifying which cryptographic primitives each component relies on, what key sizes and modes are used, and where those algorithms appear in data flows. The need for CBOM has accelerated because of the post-quantum timeline. NIST finalised three post-quantum cryptography standards in August 2024 — FIPS 203 (ML-KEM, lattice-based key encapsulation), FIPS 204 (ML-DSA, lattice-based digital signatures), and FIPS 205 (SLH-DSA, hash-based signatures) — and has set a deprecation target for RSA and elliptic curve algorithms by 2030. The EU NIS2 Directive, which became enforceable in October 2024, requires essential and important entities to implement measures addressing cryptographic risks as part of their information security management obligations. A CBOM is the foundational document for demonstrating that an organisation knows where vulnerable algorithms exist before it can credibly claim to be managing the migration risk.
How the Tool Classifies Each Algorithm Against NIST FIPS 203, 204, and 205
The tool processes your component list and maps each identified cryptographic algorithm to one of four classification tiers. Quantum-Safe algorithms are those standardised or approved by NIST for post-quantum use: ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and AES-256 in symmetric contexts, which retains its security margin against quantum attacks due to Grover's algorithm only halving effective key size. Quantum-Vulnerable algorithms are those whose security relies on the integer factorisation or discrete logarithm problems that Shor's algorithm solves in polynomial time on a cryptographically relevant quantum computer: RSA at all key sizes, ECDH, ECDSA, and finite-field Diffie-Hellman. These are classified as requiring migration before the 2030 deprecation target. Hybrid algorithms — combinations of a classical and a post-quantum primitive in the same operation — are classified as Transitional, providing quantum resistance while maintaining backwards compatibility during the migration window. Unknown or unrecognised algorithm strings are flagged for manual review rather than assigned a classification, because misclassifying an algorithm is more dangerous than leaving it flagged. The output follows the CycloneDX v1.6 CBOM schema, which is the OASIS standard format for cryptographic inventory exchange and is accepted by compliance frameworks including FedRAMP and the US National Cybersecurity Strategy implementation guidance.
The Harvest Now, Decrypt Later Threat and Why Migration Cannot Wait Until Quantum Computers Arrive
Harvest Now, Decrypt Later is an active threat strategy in which adversaries intercept and store encrypted network traffic today with the intention of decrypting it retrospectively once a cryptographically relevant quantum computer becomes available. This makes the post-quantum migration timeline a present-day risk rather than a future one. Data encrypted today with RSA-2048 or ECDH will remain ciphertext until a sufficiently powerful quantum computer exists — estimates for cryptographically relevant quantum computers range from 2030 to 2040 from NIST, NSC, and UK NCSC threat assessments. But for data with a long confidentiality requirement — medical records with multi-decade retention, intellectual property, national security communications, long-term financial contracts — the data must be protected with quantum-resistant algorithms now, because by the time a quantum computer exists it will be too late to re-encrypt already-harvested ciphertext. The intelligence community has assessed that nation-state adversaries are already conducting Harvest Now, Decrypt Later collection against high-value targets. NIST's timeline recommendation is that organisations with data sensitivity horizons beyond 2030 should begin migration to FIPS 203 key encapsulation immediately for data in transit. A CBOM is the prerequisite — you cannot prioritise migration of the highest-risk data flows without first knowing which of your systems use RSA or ECDH for data with long confidentiality requirements.
Frequently Asked Questions
Commonly Asked Questions
- What is the difference between ML-KEM, ML-DSA, and SLH-DSA?
- ML-KEM (FIPS 203) is a key encapsulation mechanism — it establishes a shared secret between two parties and replaces RSA and ECDH in key exchange and TLS handshake contexts. ML-DSA (FIPS 204) is a digital signature algorithm — it replaces ECDSA and RSA signatures for authentication, code signing, and certificate issuance. SLH-DSA (FIPS 205) is a stateless hash-based signature scheme — it provides a conservative signature alternative whose security relies only on hash function properties rather than lattice mathematics, making it suitable for long-lived signatures such as firmware signing where the verification infrastructure may outlast the algorithm's operational period. All three are standardised for immediate use. ML-KEM is the most urgently needed because it addresses Harvest Now, Decrypt Later for data in transit.
- Does AES-256 need to be replaced for post-quantum security?
- No. Symmetric encryption algorithms including AES are affected by Grover's algorithm, which provides a quadratic speedup for brute-force key search — effectively halving the security level. AES-128 provides 64-bit effective security against a quantum adversary, which is insufficient. AES-256 provides 128-bit effective security against a quantum adversary, which NIST considers adequate. AES-256 does not require replacement and is classified as Quantum-Safe by this tool. If your system uses AES-128, migration to AES-256 is recommended as part of the post-quantum remediation programme.
- What is CycloneDX v1.6 and why is it the output format?
- CycloneDX is an OASIS open standard for bill of materials documents covering software, hardware, and cryptographic components. Version 1.6 introduced the cryptographic asset component type, allowing CBOM data — algorithm name, key size, protocol context, and certificate metadata — to be expressed in a machine-readable format that integrates with SBOM tooling, vulnerability scanners, and compliance automation platforms. Using CycloneDX v1.6 output means your CBOM can be ingested by tools like OWASP Dependency Track, accepted by FedRAMP automated assessment platforms, and cross-referenced with the NIST National Vulnerability Database for cryptographic weakness identifiers (CWE-327 and related entries).
- When must RSA and ECDH be deprecated under US federal guidance?
- NIST IR 8547 (initial public draft, 2024) and NSA CNSA 2.0 guidance specify that RSA and ECDH must not be used in new systems after 2026 and must be fully replaced in existing systems by 2030 for most federal and defence applications. CNSA 2.0 specifically mandates ML-KEM for key establishment and ML-DSA for authentication in national security systems with immediate effect for new acquisitions. For commercial organisations outside the federal context, there is no single mandated deadline, but NIST's general guidance is that organisations should target completion of migration for internet-facing systems before 2030 given the Harvest Now, Decrypt Later threat.
- What should I do with algorithms flagged as Unknown by this tool?
- Unknown flags indicate algorithm strings the tool did not recognise — either because of non-standard naming conventions, proprietary algorithm identifiers, or abbreviated references without version context. For each Unknown entry: first, resolve the full algorithm name from the component's documentation or source code. Second, determine whether it maps to a known NIST-evaluated algorithm or a proprietary primitive. Third, if proprietary, obtain the vendor's post-quantum roadmap and security assessment. Unknown entries should not be left unresolved in a CBOM submitted for compliance purposes — regulators and auditors treat unclassified cryptographic assets as an inventory gap rather than a low-risk finding.
- Is a hybrid classical-plus-post-quantum approach sufficient for compliance?
- Hybrid key exchange — combining X25519 with ML-KEM-768, for example — is the IETF-recommended transition approach and is supported in TLS 1.3 via RFC 8446 extension mechanisms. NIST considers hybrid schemes acceptable during the transition period and they satisfy NIS2 risk management obligations for data in transit. However, hybrid approaches add handshake overhead and increase implementation complexity, and they are a transitional measure rather than a final state. Systems using hybrid schemes should have a documented timeline for completing migration to pure post-quantum algorithms. This tool classifies hybrid implementations as Transitional rather than Quantum-Safe for this reason.
- How does this tool differ from running a dependency scanner like Dependabot or Snyk?
- Dependabot and Snyk identify outdated or CVE-affected library versions — they flag that your OpenSSL version has a known vulnerability, for example, but they do not tell you which cryptographic algorithms your application is invoking through that library or whether those algorithms are quantum-vulnerable. A CBOM analysis operates at the algorithm layer rather than the library version layer. It answers: even if your OpenSSL is fully patched, are you calling RSA-2048 key exchange through it? That question requires either static analysis of cryptographic API calls or a structured manual inventory — which is what this tool is designed to support.