Cryptographic Security
Cryptographic Bill
of Materials
Every algorithm has an expiration date. Every certificate has a shelf life. Every key has an adversary.
A C-BOM is how you find out what you have — before a quantum computer finds it for you.
C-BOM
POST-QUANTUM
CRYPTO-AGILITY
FIPS 203/204/205
HARVEST-NOW-DECRYPT-LATER
What Is a Cryptographic Bill of Materials?
A Cryptographic Bill of Materials (C-BOM) is a comprehensive, structured inventory of every cryptographic algorithm, protocol, key, certificate, library, and cipher suite deployed across an organisation's systems. It answers the questions that attackers — and quantum computers — are already asking: What cryptographic assumptions protect your data? What is the weakest link? What breaks first?
Unlike a standard software bill of materials (SBOM), a C-BOM focuses specifically on the cryptographic foundations of security — the layer that quantum computing directly attacks. A C-BOM maps not just what algorithms are deployed, but their age, their quantum vulnerability, their data protection scope, and when they require migration.
The core insight is stark: you cannot manage what you cannot measure. Without a complete cryptographic inventory, organisations have no baseline from which to plan post-quantum migration, no visibility into where harvest-now-decrypt-later attacks have the highest value, and no understanding of their cryptographic technical debt.
The Y2Q Position: A C-BOM is not a one-time compliance exercise. It is a living asset that becomes increasingly critical as the quantum timeline compresses. Organisations that do not begin now will face emergency migration — the worst possible context for getting cryptography right.
What Goes Into a Complete C-BOM?
A complete C-BOM documents every cryptographic component across the full stack:
- Symmetric algorithms — AES (128/192/256), ChaCha20, DES (legacy), 3DES, RC4; mode of operation (GCM, CBC, CTR)
- Asymmetric algorithms — RSA (all key sizes), ECDSA, ECDH, DH; key length, curve name, usage purpose
- Hash functions — SHA-256, SHA-384, SHA-512, SHA-3, MD5 (legacy), SHA-1 (deprecated); where each is used and why
- Key derivation functions — PBKDF2, Argon2, bcrypt, scrypt; iteration counts and salt management
- Protocols and cipher suites — TLS versions and configured cipher suites, SSH algorithm negotiation, VPN configurations
- Certificates — X.509 certificate inventory, expiration dates, signing algorithms, certificate authority chains
- Key management infrastructure — Generation, storage (HSM, software, cloud KMS), rotation schedules, retirement procedures
- Cryptographic libraries — OpenSSL, BoringSSL, NSS, libsodium, Bouncy Castle; versions and known CVEs
- Post-quantum migration status — Which components are migrated, in planning, or unaddressed
- Data classifications and lifetimes — What data each algorithm protects and for how long confidentiality is required
Crypto-Agility: The Architecture Requirement
A C-BOM is not useful if the systems it inventories cannot be changed. Crypto-agility — the ability to swap cryptographic algorithms without redesigning entire systems — is the architectural property that makes a C-BOM actionable.
Crypto-agility requires:
- Algorithm abstraction — Cryptographic operations are encapsulated behind interfaces; implementations are swappable without touching application logic
- Parallel protocol support — New algorithms (ML-KEM, ML-DSA) can be deployed alongside legacy ones during transition windows
- Migration planning — Defined processes for deprecating old algorithms and adopting new ones on documented timelines
- Performance impact assessment — Post-quantum algorithms have different performance characteristics; latency and throughput must be re-evaluated
- Hybrid key exchange — Combining classical and post-quantum algorithms during transition ensures protection against both attack classes
Without crypto-agility, discovery via C-BOM produces a list of problems with no path to resolution. NIST's Migration to Post-Quantum Project at the NCCoE specifically prioritises identifying and fixing crypto-rigid systems before the 2035 deadline.
C-BOM and the Quantum Risk Intersection
The quantum risk in a C-BOM inventory is not uniform. Prioritisation depends on the intersection of algorithm vulnerability and data lifetime:
- Long-lifetime sensitive data + quantum-vulnerable algorithm = Critical — State secrets, medical records, legal documents, intellectual property. These are harvest targets today. Replace encryption immediately or accept that eventual exposure is certain.
- Short-lifetime data + quantum-vulnerable algorithm = Medium — Transient session data, ephemeral tokens. The confidentiality window may close before quantum computers are available — but this depends on timelines that are accelerating.
- Long-lifetime data + quantum-safe algorithm = Low — If you have already migrated to AES-256, ML-KEM, or ML-DSA, the long-term risk is substantially reduced.
- Digital signatures + quantum-vulnerable algorithm = High — Signatures validated in the future (legal documents, software updates, certificates) lose integrity if the signing algorithm is quantum-broken. Non-repudiation and authenticity fail.
The Harvest-Now-Decrypt-Later Problem: For confidentiality, the threat exists NOW. Adversaries do not need quantum computers to collect data — only to store it. Your C-BOM must identify data with multi-year confidentiality requirements and flag it for immediate encryption upgrade, regardless of when quantum computers actually arrive.
C-BOM as Compliance and Governance Infrastructure
C-BOM is increasingly required by or directly referenced in regulatory frameworks:
- NIST IR 8547 and PQC Migration — Explicitly recommends cryptographic inventory as the foundation of post-quantum migration planning. Without a C-BOM, compliance with the 2035 deadline is not achievable in a structured way.
- NIST Cybersecurity Framework (CSF 2.0) — The IDENTIFY function requires asset inventory including cryptographic assets.
- PCI-DSS v4.0 — Requires documented cryptographic protocols for payment card data protection and management of cryptographic key lifecycles.
- HIPAA — Mandates encryption standards for protected health information, requiring knowledge of what algorithms are deployed.
- EU Cyber Resilience Act — Emerging requirements around software and hardware cybersecurity will increasingly drive C-BOM-style inventories.
- NSA CNSA 2.0 — NSA's Commercial National Security Algorithm Suite 2.0 mandates post-quantum algorithms for National Security Systems and sets migration timelines.
C-BOM as a Living System
A C-BOM that is not continuously maintained becomes a liability. Systems change. Dependencies are updated. New CVEs are published. Quantum timelines compress. An outdated C-BOM creates false confidence.
Maintaining a living C-BOM requires:
- Integration with development and deployment pipelines — cryptographic changes trigger automatic C-BOM updates
- Automated discovery tooling — scanners that identify cryptographic usage across codebases, configurations, and network traffic
- Regular review cycles — at minimum quarterly; more frequently for high-risk environments
- Change ownership — defined accountability for each cryptographic component and its migration status
- Incident trigger integration — cryptographic vulnerability disclosures automatically cross-referenced with the inventory
The Y2Q C-BOM Tool provides the version control, audit logging, and automated assessment infrastructure required to keep a C-BOM alive and actionable across organisational time horizons.
Honest Note: A C-BOM is not a solution to quantum risk. It is a prerequisite for developing one. Without knowing what you have, you cannot plan what to change. The tool makes the inventory manageable — the migration decisions remain yours.