Scope
This guide tackles the challenge of discovering and inventorying cryptographic assets in payment environments, especially as post-quantum cryptography becomes a requirement. It's designed for teams managing cardholder data environments, key management infrastructure, and cryptographic controls under PCI DSS 4.0 or similar frameworks.
You won't find a step-by-step CBOM template here. The U.S. executive order from June 22 gives CISA and NIST until March 2027 to define what belongs in a cryptography bill of materials, but that deadline only covers the data model. Discovery, finding every certificate, every legacy algorithm, every HSM configuration buried in systems you haven't touched in years, is your problem to solve.
Key Concepts and Definitions
Cryptography Bill of Materials (CBOM): An inventory of cryptographic algorithms, protocols, certificates, and keys used across your infrastructure. Unlike a software bill of materials, which catalogs components, a CBOM catalogs the cryptographic primitives those components rely on.
Post-Quantum Cryptography (PQC): Algorithms designed to resist attacks from quantum computers. NIST has standardized several PQC algorithms, and organizations are expected to transition before Q-Day, the point when quantum computers can break current public-key cryptography.
Q-Day Readiness: The state of having identified quantum-vulnerable cryptographic assets and having a migration plan in place. For payment processors, this includes everything from TLS configurations to key encryption keys protecting cardholder data.
Discovery vs. Inventory: Discovery involves scanning systems, analyzing configurations, and identifying cryptographic primitives. Inventory is the structured record of what you've found. You can't maintain an accurate inventory without repeatable discovery.
Requirements Breakdown
While federal agencies define the "what," your team must solve the "how." Here's what you're actually inventorying:
Cryptographic Algorithms in Use
- Symmetric encryption (AES-256, 3DES still running in legacy HSMs)
- Asymmetric encryption (RSA-2048, RSA-4096, ECC)
- Hash functions (SHA-256, SHA-3, MD5 in certificate chains)
- Key derivation functions (PBKDF2, HKDF per NIST SP 800-108)
Certificates and Key Material
- TLS certificates protecting payment page endpoints
- Code signing certificates for application integrity
- Key encryption keys (KEKs) in your HSM hierarchy
- Data encryption keys (DEKs) protecting stored PANs
- Certificate expiration dates and issuing authorities
Cryptographic Protocols
- TLS versions across payment gateways and acquirer connections
- SSH configurations on CDE administration systems
- IPsec tunnels between segmented network zones
- API authentication mechanisms (JWT signatures, OAuth flows)
Implementation Context
- Where the algorithm runs (HSM, application layer, database TDE)
- What data it protects (PAN at rest, PAN in transit, session tokens)
- Whether it's vendor-controlled or internally managed
- Compliance dependencies (PCI DSS Requirement 4.2.1, FIPS 140-3 validation)
Implementation Guidance
Start with Critical Payment Flows
Don't attempt a comprehensive enterprise scan on day one. Map your payment authorization flow first: customer browser to payment page, payment page to gateway, gateway to processor. Document every TLS handshake, every tokenization call, every key unwrap operation. This gives you a working model before you scale.
Use Existing Compliance Artifacts
Your PCI DSS 4.0 documentation already identifies systems that store, process, or transmit cardholder data. Your network segmentation testing (Requirement 1.3) identifies connection points. Your key management procedures (Requirement 3.6) list KEKs and rotation schedules. These aren't complete cryptographic inventories, but they're better starting points than a blank spreadsheet.
Address the Supplier Visibility Problem
ENISA's 2026 survey found that 40% of organizations never receive SBOMs from software suppliers, and 60% report data quality issues when they do. Expect the same problem with CBOMs. Your payment gateway vendor might document their API's TLS requirements, but they won't tell you what cryptographic libraries their proprietary tokenization engine uses internally.
Build your procurement language now. Require vendors to disclose cryptographic dependencies in RFP responses. For critical payment infrastructure, make CBOM delivery a contractual obligation with update frequency tied to major releases.
Automate Discovery Where You Control the Stack
For internally managed systems, automated scanning works:
- TLS configuration scanners (testssl.sh, sslyze) for web endpoints
- Certificate inventory tools for expiration tracking
- Configuration management databases that track cryptographic parameters
- HSM audit logs that reveal active key usage patterns
For vendor-managed SaaS components in your payment flow, you're dependent on what they'll share.
Align with NIST Standards Early
Organizations that align with NIST's post-quantum algorithms now aren't doing it because Washington mandated it. They're doing it because NIST standards represent the most mature reference available. That doesn't guarantee long-term alignment, but it gives you a head start when regulatory requirements formalize.
Common Pitfalls
Treating CBOM as a One-Time Audit
Your cryptographic inventory is stale the moment you deploy new code, rotate a certificate, or patch a library. If you're not updating your CBOM with every change control ticket that touches encryption, you're maintaining documentation, not an operational inventory.
Ignoring Legacy Algorithm Persistence
3DES is deprecated, but it's still running in HSMs that were validated under FIPS 140-2 and haven't been replaced. MD5 is cryptographically broken, but it appears in certificate chain signatures you don't control. Your CBOM must capture what's actually deployed, not what your architecture diagrams say should be deployed.
Underestimating Discovery Costs
Finding every cryptographic primitive in a payment environment with decades-old infrastructure isn't a scripting exercise. It requires application source code review, vendor interviews, HSM configuration analysis, and testing in isolated environments. Budget accordingly.
Waiting for Perfect Standardization
The March 2027 deadline covers the data model. It doesn't solve your discovery problem, and it won't make your vendors more transparent. Start building your inventory now with a flexible schema you can map to the final standard later.
Quick Reference Table
| Asset Type | Discovery Method | Update Frequency | Compliance Link |
|---|---|---|---|
| TLS certificates (CDE endpoints) | Automated scan + manual verification | Weekly | PCI DSS 4.2.1 |
| HSM key hierarchy (KEKs) | HSM audit logs + key ceremony records | Per rotation event | PCI DSS 3.6.1 |
| Application-layer encryption | Source code analysis + dependency scan | Per release | PCI DSS 3.5.1 |
| Database TDE configurations | Database config review | Quarterly | PCI DSS 3.4.1 |
| API authentication (JWT, OAuth) | API gateway logs + spec review | Per API version | Internal policy |
| Vendor cryptographic dependencies | Contractual disclosure + attestation | Annually or per major release | Vendor management |
The U.S. government will deliver a checklist. What it won't deliver is a discovery process that works in your environment, with your legacy constraints, and your vendor relationships. That work belongs to whoever owns the infrastructure. Start now.
