The March 2027 deadline for CBOM standards isn't your problem. Your problem is finding every certificate, key, and algorithm buried in your infrastructure before quantum computers break your encryption. CISA and NIST will hand you a data model. They won't hand you a discovery plan.
This checklist focuses on the cryptographic inventory work you can start now, before the standard drops. If you've watched SBOM adoption stumble, you know why: 78% of organizations started programs, but only 9% achieved automated implementation. The gap wasn't the standard. It was the discovery.
Prerequisites
Before you start cataloging cryptographic assets, confirm you have:
Executive sponsorship with budget authority. Cryptographic discovery touches every system. You'll need access to production environments, legacy code repositories, and vendor documentation. That requires sign-off from someone who can override territorial objections.
Cross-functional access. Your team needs read access to application code, infrastructure configs, certificate stores, key management systems, HSMs, and vendor integration documentation. Map who owns what before you start asking for inventory data.
A flexible data schema. Don't wait for the final CBOM specification to begin. Build your inventory in a format you can map to the official schema later. Track: algorithm name, key length, certificate expiration, system location, business criticality, and vendor dependency status.
Good: A spreadsheet or database that captures algorithm details with enough metadata to answer "where is this used and what breaks if we change it?"
Cryptographic Asset Inventory Checklist
1. Identify all TLS/SSL certificates across your infrastructure.
Start with your external-facing systems, then move to internal services. Don't limit yourself to web servers. Payment gateways, API endpoints, and inter-service communication all use certificates.
Check: Load balancers, reverse proxies, application servers, database connections, message queues, and third-party integrations.
Good: A living inventory showing certificate location, issuing CA, expiration date, key algorithm (RSA-2048, ECDSA P-256), and which business services depend on it. You can generate alerts 90 days before expiration and identify which certificates use quantum-vulnerable algorithms.
2. Catalog cryptographic libraries in your application code.
Run Software Composition Analysis against your codebase to identify OpenSSL, BouncyCastle, libsodium, and other crypto libraries. Note the version. Legacy versions often default to deprecated algorithms.
This isn't the same as an SBOM. You're looking specifically for cryptographic dependencies and how your code calls them.
Good: You know which applications use which crypto libraries, what algorithms they invoke, and whether those libraries support post-quantum algorithms in current or planned versions.
3. Document key management infrastructure.
Map every system that generates, stores, or uses cryptographic keys. This includes HSMs, cloud KMS services, key vaults, and any custom key management code.
For each system, record: what types of keys it manages (KEKs, DEKs, signing keys), rotation schedules, access controls, and whether it supports algorithm agility.
Good: You can answer "if we need to migrate from RSA-2048 to a post-quantum algorithm, which systems need hardware upgrades and which can handle it in software?"
4. Inventory signing and verification processes.
Identify everywhere your organization signs data: code signing, document signing, transaction signing, API request signing, firmware signing.
For each process, document the algorithm, key storage location, and what would break if you changed the signature scheme.
Good: A matrix showing signing use cases, current algorithms, business impact of downtime, and migration complexity rating (low/medium/high).
5. Map vendor and third-party cryptographic dependencies.
List every vendor integration that involves cryptography: payment processors, identity providers, cloud services, SaaS platforms.
For critical vendors, request their cryptographic roadmap. When will they support post-quantum algorithms? Do they provide CBOMs for their services?
Good: You've identified which vendors are quantum-ready, which are planning migration, and which represent risk because they haven't published a timeline. You have contractual language requiring cryptographic transparency in future renewals.
6. Locate legacy and embedded cryptography.
Check systems that haven't been updated in years: mainframe connections, industrial control systems, legacy payment terminals, archived applications still processing transactions.
These often use hardcoded algorithms with no upgrade path.
Good: You know which legacy systems use quantum-vulnerable cryptography, whether they're business-critical, and what your options are (upgrade, replace, or accept risk with compensating controls).
7. Test algorithm agility in critical systems.
Pick three high-value systems and attempt to change their cryptographic algorithm without code changes. Can you swap RSA for ECDSA by updating configuration? Or does the algorithm choice live in compiled code?
This reveals how painful migration will actually be.
Good: You've documented which systems support algorithm agility through configuration and which require code changes, testing, and redeployment.
8. Document compliance and regulatory constraints.
Identify where regulations mandate specific algorithms. PCI DSS requires strong cryptography for cardholder data. Some jurisdictions restrict which algorithms you can use for digital signatures.
Note where post-quantum migration might conflict with current compliance requirements.
Good: You know which systems operate under regulatory constraints and have a plan to engage with your QSA or regulators before migrating algorithms.
Common Mistakes
Waiting for the final CBOM specification. The standard will define data fields, not discovery methods. Start inventorying now with a flexible schema.
Treating this as a point-in-time audit. Cryptographic assets change constantly. Certificates expire, libraries get updated, new services launch. Build continuous discovery, not a static report.
Ignoring vendor dependencies. You don't control third-party cryptography, but you depend on it. If your payment processor isn't quantum-ready, your inventory is incomplete.
Assuming cloud providers will handle everything. Cloud KMS services will support post-quantum algorithms, but your application code still needs to invoke them correctly. Migration isn't automatic.
Skipping the "what breaks" analysis. Knowing where you use RSA-2048 matters less than knowing what happens when you change it. Test dependencies before Q-Day forces your hand.
Next Steps
Start discovery in your highest-risk environment: wherever you process payment card data, authenticate users, or sign transactions. These systems face the most regulatory pressure and the highest cost of failure.
Build your inventory with enough detail to support migration planning. Algorithm name alone isn't enough. You need location, business criticality, vendor dependency, and migration complexity.
The U.S. government will deliver a CBOM standard by March 2027. By then, you should already know what's in your environment. The checklist they publish will help you format the data you've already collected.
Discovery is local work. The standard just gives you a common language to describe what you found.
