Cryptographic Discovery and the CBOM — Quantum-Safe: Readiness Assessment

The first hard part of becoming quantum-safe is not replacing algorithms. It is finding them. Cryptography is rarely kept in one tidy place. It is written into application code, loaded through libraries, negotiated by live network protocols, stored in certificates, configured in cloud services, and hidden inside products you bought years ago. A Cryptographic Bill of Materials, or CBOM, turns that scattered reality into an inventory you can act on.

Start with the hiding places

Cryptographic discovery is the work of finding every place an organization uses cryptography. That sounds simple until you follow how systems are actually built. An application may call a modern library in one function, use an old hard-coded algorithm in another, and rely on a vendor appliance for part of the same business process.

A useful search pattern is to look in six places: source code and application dependencies; certificates and keys; live network protocols; data-at-rest systems such as databases, backups, and file stores; bought products and managed services; and firmware or embedded devices in the supply chain.

Network protocols deserve special care because what is configured is not always what is used. Transport Layer Security (TLS), Virtual Private Networks (VPNs), and Secure Shell (SSH) negotiate cryptographic choices at connection time. The real answer may be on the wire, not in the design document.

📌

The practical rule. If a system protects data, proves identity, signs code, or establishes a secure connection, it belongs in discovery.

Cryptography hides across code, certificates, traffic, stored data, and firmware.

Use several discovery methods, not one

No single scanner can find all cryptography. Source-code scanning can find direct algorithm calls, hard-coded keys, and old dependencies, but it will not see what a network gateway negotiates with a trading partner. A certificate inventory can list public-key algorithms and expiry dates, but it will not explain how a backup product encrypts archives internally.

Good discovery triangulates. Scan the code. Inspect dependency manifests. Inventory certificate stores and key stores. Passively monitor production traffic to observe negotiated protocols and cipher suites. Query cloud configuration for keys, policies, and managed-service encryption settings. Ask vendors for written evidence of what they use today and how they plan to support post-quantum cryptography, often shortened to PQC.

Passive monitoring is especially valuable because it gives ground truth without changing production behavior. It can reveal legacy clients, fallback settings, and protocol versions that nobody remembers enabling.

Use source-code and dependency scanning to find algorithms called directly by applications.
Use certificate and key inventories to map the public-key infrastructure, or PKI, estate.
Use passive network monitoring to see what TLS, VPN, and SSH sessions actually negotiate.
Use cloud queries to inspect Key Management Service (KMS) keys, managed encryption settings, and TLS policies.
Use vendor questionnaires when the cryptography is inside a product or service you do not control.

No single scanner sees everything, so combine four complementary methods.

Build the CBOM record around decisions

A CBOM is not just a list of algorithms. It is an operational record that connects cryptography to ownership, risk, and migration work. Each entry should tell a reader what cryptography is used, where it is used, what it protects, who owns it, and why it matters.

At a minimum, record the algorithm, key size or parameter set, purpose, system or component, owner, data sensitivity, data shelf life, dependency source, current migration status, and last-verified date. Data shelf life means how long the protected information must remain confidential. It is one of the most important fields because it turns a technical inventory into a risk signal.

For example, Rivest-Shamir-Adleman (RSA) and Elliptic-Curve Cryptography (ECC) are public-key methods that are vulnerable to a sufficiently capable future quantum computer. Advanced Encryption Standard with 256-bit keys, often written as AES-256, is not broken in the same way by known quantum algorithms and remains a strong symmetric encryption choice. A CBOM entry should make that distinction visible without forcing every decision maker to be a cryptographer.

Algorithm and key size or parameter set: shows whether the cryptography is likely to need replacement.
Purpose: separates key exchange, digital signatures, code signing, authentication, and data-at-rest encryption.
System owner: identifies who can approve, fund, and execute the change.
Data sensitivity and shelf life: shows how much harm a future decryption event could cause.
Dependency source: distinguishes owned code, open-source libraries, vendor products, firmware, and managed services.
Migration status: records whether the item is not started, being tested, using a hybrid approach, or complete.
Last-verified date: prevents old evidence from being silently trusted.

✅

A useful test. A CBOM entry is complete when it helps someone decide what to fix, who must fix it, and how soon it matters.

Public-key methods are quantum-vulnerable while symmetric AES-256 stays strong.

Treat standards as exchange formats, not magic

Organizations already use Software Bills of Materials, or SBOMs, to describe the components inside software. A CBOM applies the same inventory idea to cryptography. The point is not paperwork for its own sake. The point is to make cryptographic facts portable across tools, teams, suppliers, and audits.

CycloneDX is an open bill-of-materials standard that includes support for cryptographic bill-of-materials data. When tools can emit CBOM information in a common format, discovery becomes less dependent on spreadsheets and personal knowledge. That matters because a large environment may have thousands of certificates, services, libraries, containers, devices, and cloud resources.

Standards do not remove the need for judgment. A generated CBOM fragment may describe an algorithm correctly but omit business context such as data shelf life or system ownership. Automated output is a starting point. The mature inventory combines machine-collected facts with human-owned risk information.

📌

Automation helps scope. Use standard formats where possible so CBOM data can move between build systems, asset tools, risk registers, and supplier evidence.

Keep the inventory alive

A CBOM that is created once and filed away quickly becomes misleading. Certificates rotate. Applications ship new dependencies. Cloud services change policies. Vendors patch products. New devices appear on the network. In a live environment, cryptographic inventory has to be maintained as a feed, not preserved as a photograph.

The best approach is to automate where the environment allows it. Owned code can be scanned in continuous integration, or CI, pipelines each time software is built. Certificate stores and passive network observations can refresh on a schedule. Cloud configurations can be queried by policy tools. Vendor products, firmware, and embedded devices may still need manual attestation, but those entries should carry a last-verified date and a named owner.

This is where discovery and crypto-agility reinforce each other. Crypto-agility is the ability to change cryptographic algorithms, parameters, libraries, or providers without rebuilding the whole system from scratch. Systems that are easier to change are usually easier to inventory, and systems that are easier to inventory are safer to change.

Handle vendors and unknowns honestly

Bought products are often the hardest part of cryptographic discovery because the cryptography may be buried inside a closed appliance, managed service, software-as-a-service platform, or device firmware. You may not be able to inspect the implementation directly. That does not make it out of scope. It makes evidence management more important.

Ask suppliers for current cryptographic details, a PQC roadmap, support timelines, and any CBOM or CycloneDX export they can provide. Ask for answers in writing. If a supplier cannot or will not disclose the relevant information, record the dependency as unknown in the CBOM and raise it as a risk item. A blank field hides the problem; an explicit unknown makes it governable.

Contract renewal and procurement are leverage points. Future purchases should require cryptographic transparency, update commitments, and a credible post-quantum migration plan. Existing suppliers should be grouped by criticality, data sensitivity, and replacement difficulty.

⚠️

Unknown is a status. When a supplier will not disclose cryptographic details, mark the item unknown, assign an owner, and track the risk rather than pretending it is absent.

Use the CBOM to make real decisions

The CBOM earns its value when it changes decisions. A security architect may use it to choose which TLS endpoints need testing first. An application owner may use it to budget library upgrades. A procurement leader may use it to decide which vendors need contractual commitments. An executive may use it to understand how much exposure sits in systems that cannot be patched quickly.

Priority is not based only on whether an algorithm is quantum-vulnerable. It also depends on what the cryptography protects, how long that data must stay secret, whether the system is externally exposed, whether the component can be updated, and whether there is a business deadline such as a certificate authority transition or platform end-of-life.

The most urgent cases are often the ones where long-lived sensitive data is protected by quantum-vulnerable public-key cryptography and is exposed to harvest-now, decrypt-later risk. That phrase describes an attack pattern where encrypted data is copied today and decrypted in the future if the relevant cryptography becomes breakable.

What must be migrated first because the protected data has a long shelf life?
Which systems can be fixed through configuration and which require code changes?
Which vendor dependencies need written commitments before renewal?
Which embedded or Internet of Things (IoT) devices need isolation, replacement, or accepted risk?
Which teams own the highest-risk entries and have funding to act?

Long-lived sensitive data on exposed vulnerable crypto is the most urgent case.

Avoid the common traps

The most common mistake is trusting documentation more than evidence. Architecture diagrams, old standards pages, and vendor brochures may all be out of date. Production traffic, current certificates, actual build dependencies, and signed supplier statements are stronger evidence.

Another mistake is stopping at the easy boundary: owned applications. Quantum-safe migration also depends on certificate authorities, hardware security modules, identity platforms, network devices, firmware, third-party software, and operational tools. Anything that signs, encrypts, authenticates, or exchanges keys can affect the migration.

The final trap is recording cryptography without urgency. An entry that says RSA-2048 is useful. An entry that says RSA-2048 protects regulated archive data that must remain confidential for 25 years, is owned by a named platform team, depends on a vendor library, and has no migration date is far more useful.

Do not treat the CBOM as a one-time assessment artifact.
Do not omit firmware, appliances, and vendor-managed services because they are difficult to inspect.
Do not leave undisclosed vendor cryptography as a blank field.
Do not record algorithms without purpose, owner, sensitivity, and shelf life.
Do not assume a system can migrate quickly until you know who controls the code, configuration, certificates, and dependencies.

⚠️

Flying blind. Without a current CBOM, a quantum-safe migration becomes guesswork dressed up as planning.

Key takeaways

Cryptographic discovery must cover code, certificates, network protocols, data stores, bought products, and firmware.
No single tool is complete; combine scanning, inventories, passive monitoring, cloud queries, and vendor evidence.
A useful CBOM records not only algorithms, but also purpose, owner, sensitivity, data shelf life, dependency source, status, and last verification.
CycloneDX can help exchange CBOM data, but business context still needs human ownership.
Unknown vendor cryptography should be recorded as an explicit risk, not left blank.
A living CBOM turns quantum-safe migration from a vague concern into a prioritized, owned plan.

Glossary

Cryptographic discovery: The process of finding and recording every place an organization uses cryptography.
Cryptographic Bill of Materials (CBOM): A living inventory of cryptographic algorithms, keys, purposes, owners, dependencies, and risk context.
Software Bill of Materials (SBOM): An inventory of software components, often used to understand dependencies and supply-chain exposure.
CycloneDX: An open bill-of-materials standard that can represent software and cryptographic inventory data.
Public-Key Infrastructure (PKI): The systems, certificates, keys, policies, and authorities used to manage digital identity and trust.
Transport Layer Security (TLS): A protocol that protects network connections by negotiating encryption, authentication, and integrity settings.
Post-Quantum Cryptography (PQC): Cryptographic algorithms designed to resist attacks from both classical computers and future cryptographically relevant quantum computers.
Data shelf life: The length of time protected data must remain confidential or trustworthy.
Crypto-agility: The ability to change cryptographic algorithms, parameters, libraries, or providers without redesigning an entire system.