Every system you run has cryptographic dependencies you’ve never inventoried. When quantum computers break RSA, you’ll need that inventory yesterday.
You know exactly which open-source libraries your application depends on. You have an SBOM. You scan for CVEs weekly. You patch critical vulnerabilities within 48 hours.
Now tell me: which cryptographic algorithms does your system use? All of them. Not just the ones you explicitly chose — the ones buried in your TLS configuration, your JWT library, your database connection strings, your certificate chain, your key derivation functions, your random number generators.
Most architects can’t answer that question. And that’s a problem, because every RSA key, every ECDH exchange, every SHA-256 hash in your system has an expiration date. It’s called Q-Day — the day a cryptographically relevant quantum computer can break these algorithms in polynomial time.
The timeline is debatable. The preparation isn’t. You need a Cryptographic Bill of Materials before you need a migration plan. You can’t migrate what you haven’t inventoried.
Part 5 of The Quantum-Centric Architect. In Part 4, we ran our first quantum circuit. Now we turn to the defensive side: understanding and cataloging your quantum exposure.
What Is a Cryptographic Bill of Materials?
A CBOM is a complete inventory of every cryptographic algorithm, protocol, key, and certificate used across your systems. An SBOM for cryptography — a machine-readable catalog that answers:
- Which algorithms are in use (RSA-2048, AES-256, SHA-256, ECDH P-256)?
- Where are they used (TLS termination, data-at-rest, token signing, API auth)?
- What key sizes and parameters are configured?
- Which libraries implement the cryptography?
- What’s the certificate chain and expiration timeline?
- Which data is protected by quantum-vulnerable algorithms?
- How long must that data remain confidential?
Why this matters now: Nation-state adversaries are executing “harvest now, decrypt later” campaigns — capturing encrypted traffic today, banking on decrypting it when quantum computers mature. If your data needs to remain confidential for 10+ years, your quantum exposure window is already open.
The Harvest Now, Decrypt Later Threat
This isn’t theoretical. Intelligence agencies have publicly acknowledged the strategy. The math is simple:
Shelf life of your secrets (how long data must stay confidential):
- Healthcare records: 50+ years (HIPAA)
- Financial data: 7–25 years (regulatory)
- Trade secrets: indefinite
- Government classified: 25–75 years
- Personal data: lifetime of the individual
Time to quantum threat (estimates vary):
- Optimistic: 10–15 years
- Consensus: 15–20 years
- Conservative: 25+ years
If shelf life > time to quantum threat, you’re already exposed.
A medical record encrypted today with RSA-2048 and captured by an adversary will be readable when quantum computers mature — potentially while the patient is still alive. That’s not a future problem. That’s a present vulnerability with a delayed exploit.
The Five Layers of Cryptographic Exposure
Most architects think about cryptography at one or two layers. Quantum exposure exists at all five.
Layer 1: Transport (TLS/mTLS)
Every HTTPS connection negotiates a cipher suite. Your TLS configuration determines which key exchange, authentication, and encryption algorithms are used.
What to inventory:
- TLS versions supported (1.2, 1.3)
- Cipher suites enabled and their priority order
- Key exchange algorithms (RSA, ECDHE, DHE)
- Certificate key types and sizes (RSA-2048, ECDSA P-256)
- Certificate chain depth and root CA algorithms
Quantum-vulnerable components:
- RSA key exchange (broken by Shor’s algorithm)
- ECDHE key exchange (broken by Shor’s algorithm)
- RSA certificate signatures (broken by Shor’s algorithm)
Quantum-safe components:
- AES-256 symmetric encryption (Grover’s reduces to 128-bit — still safe)
- SHA-256 in HMAC mode (reduced but adequate)
The catch: Even if your symmetric encryption is safe, the key exchange that established the session key is not. Captured TLS sessions can be decrypted once the ephemeral key exchange is broken.
Layer 2: Data at Rest
Databases, file systems, backups, archives — everything stored uses cryptography.
What to inventory:
- Encryption algorithms for storage (AES-256-GCM, AES-256-CBC)
- Key management system and key wrapping algorithms
- Key derivation functions (PBKDF2, Argon2, scrypt)
- Database-level encryption (TDE algorithms)
- Backup encryption and key escrow
Quantum exposure: Symmetric encryption (AES-256) is largely safe. But key wrapping often uses RSA or ECDH. If your KMS wraps data keys with RSA-2048, the data keys are quantum-vulnerable even if the data encryption itself isn’t.
Layer 3: Identity and Authentication
Tokens, certificates, signatures — the trust infrastructure.
What to inventory:
- JWT signing algorithms (RS256, ES256, PS256)
- OAuth/OIDC token encryption
- SAML assertion signatures
- Code signing certificates
- API key derivation methods
- mTLS client certificate algorithms
Quantum exposure: Nearly all identity infrastructure relies on asymmetric cryptography. JWT signed with RS256 can be forged once RSA is broken. Certificate-based authentication becomes meaningless. Code signatures can be spoofed.
Layer 4: Application-Level Cryptography
Custom encryption, hashing, digital signatures within application logic.
What to inventory:
- Password hashing algorithms (bcrypt, Argon2, PBKDF2)
- Application-level encryption (field-level, envelope encryption)
- Digital signatures for business logic (document signing, audit trails)
- Random number generation sources
- Cryptographic protocol implementations
Quantum exposure: Password hashes using SHA-256 get a quadratic speedup from Grover’s algorithm — reducing effective security from 256-bit to 128-bit. Still adequate, but worth noting. RSA-based document signatures are fully vulnerable.
Layer 5: Third-Party and Supply Chain
Dependencies, APIs, cloud services — cryptography you don’t control.
What to inventory:
- Cloud provider encryption defaults (AWS KMS, Azure Key Vault algorithms)
- Third-party API authentication mechanisms
- Payment processor cryptographic requirements
- Partner integration encryption standards
- SaaS platform security configurations
Quantum exposure: You inherit the quantum vulnerability of every third party. If your payment processor uses RSA-2048 for transaction encryption, your payment data is quantum-vulnerable regardless of your own cryptographic choices.
Building Your CBOM: A Practical Approach
Step 1: Automated Discovery
Start with what you can find automatically.
# Scan TLS configurations across your infrastructure
nmap --script ssl-enum-ciphers -p 443 your-domain.com
# Inventory certificates
openssl s_client -connect your-domain.com:443 2>/dev/null | \
openssl x509 -noout -text | grep -E "(Algorithm|Public-Key)"
# Scan code for cryptographic library usage
grep -rn "from cryptography\|import crypto\|require('crypto')" ./src/
# Check JWT configurations
grep -rn "RS256\|RS384\|RS512\|ES256\|PS256" ./src/
Tools for automated CBOM generation:
- IBM Quantum Safe Explorer: Scans Java/.NET applications for crypto usage
- Cryptosense Analyzer: Enterprise crypto discovery and risk assessment
- NIST’s Crypto Discovery Tool: Open-source scanning for quantum-vulnerable algorithms
- Custom scripts: grep-based discovery for your specific stack
Step 2: Manual Inventory of Hidden Crypto
Automated tools miss cryptography that’s:
- Configured at infrastructure level (load balancer TLS settings)
- Embedded in third-party services (cloud KMS defaults)
- Implicit in protocol choices (database wire protocol encryption)
- Hidden in dependency trees (transitive crypto library usage)
Walk through each system boundary and ask: “What cryptography protects data crossing this boundary?”
Step 3: Risk Classification
Not all quantum exposure is equal. Classify by:
https://medium.com/media/abdad02b014755baa98c195cce14bac0/hrefStep 4: Dependency Mapping
For each quantum-vulnerable component, map:
- What depends on it (upstream consumers)
- What it depends on (downstream providers)
- Migration complexity (can you change it independently?)
- Fallback options (what happens if you disable it?)
This dependency map becomes your migration sequencing guide.
The CBOM Format
Structure your CBOM as machine-readable data:
{
"system": "payment-service",
"components": [
{
"id": "tls-ingress",
"layer": "transport",
"algorithm": "ECDHE-RSA-AES256-GCM-SHA384",
"key_exchange": "ECDHE",
"authentication": "RSA-2048",
"encryption": "AES-256-GCM",
"quantum_vulnerable": true,
"vulnerability": "key_exchange_and_authentication",
"data_sensitivity": "financial_transactions",
"confidentiality_requirement_years": 25,
"risk_level": "critical",
"migration_complexity": "medium",
"dependencies": ["load-balancer-config", "certificate-authority"]
}
]
}Crypto Agility: The Architecture That Makes Migration Possible
A CBOM is useless without the ability to act on it. Crypto agility is the architectural property that allows you to swap cryptographic algorithms without rewriting your application.
Principles:
- Abstract cryptographic operations behind interfaces — never call algorithm-specific APIs directly
- Externalize algorithm selection to configuration — not hardcoded in source
- Support algorithm negotiation in protocols — allow gradual migration
- Maintain backward compatibility during transitions — old and new must coexist
- Automate certificate rotation — manual rotation won’t scale during migration
The test: Can you change your JWT signing algorithm from RS256 to a post-quantum algorithm by changing a configuration value? If the answer is “no, that requires code changes across 47 services,” you have a crypto agility problem.
Key Takeaways:
- A Cryptographic Bill of Materials (CBOM) is the prerequisite for any quantum migration — you can’t migrate what you haven’t inventoried
- Quantum exposure exists at five layers: transport, data at rest, identity, application-level, and third-party/supply chain
- “Harvest now, decrypt later” is an active threat — if your data’s shelf life exceeds time-to-quantum, you’re already exposed
- Key wrapping with RSA makes even AES-256 encrypted data quantum-vulnerable through the key management layer
- Crypto agility — the ability to swap algorithms via configuration — is the architectural property that makes migration feasible
- Risk classification by data confidentiality timeline determines your migration urgency
Action Items:
- Run automated crypto discovery against your production infrastructure (TLS configs, JWT algorithms, KMS settings)
- Inventory your third-party dependencies’ cryptographic choices — you inherit their quantum vulnerability
- Classify your data by confidentiality requirement timeline and map it against quantum threat estimates
- Audit your key management system — check if key wrapping uses quantum-vulnerable asymmetric algorithms
- Test your crypto agility: can you change your JWT signing algorithm without code changes across services?
- Start your CBOM in machine-readable format (JSON/YAML) and assign ownership for each cryptographic component
Tools and Resources
CBOM Discovery:
- IBM Quantum Safe Explorer: Enterprise crypto scanning for Java/.NET
- Cryptosense Analyzer: Automated cryptographic risk assessment
- NIST Crypto Discovery Tool: Open-source quantum-vulnerable algorithm scanning
Standards and Frameworks:
- NIST SP 800–208: Post-Quantum Cryptography standardization
- CISA Post-Quantum Guidance: Federal migration planning resources
- X.509 Certificate Inventory Tools: Open-source cert chain analysis
Quantum Threat Assessment:
- Global Risk Institute Quantum Threat Timeline: Annual expert survey on Q-Day estimates
- Quantum Economic Development Consortium (QED-C): Industry readiness resources
What’s Next
You now have the framework for understanding your quantum exposure. Part 6 covers Post-Quantum Cryptography in Practice — the specific algorithms (ML-KEM, ML-DSA, SLH-DSA) that NIST has standardized, how they perform, and the practical migration playbook for moving from quantum-vulnerable to quantum-safe.
Coming up:
- Post-Quantum Cryptography in Practice
- The Quantum Control Plane
- The Quantum Price Tag
- Quantum Machine Learning Pipelines
Series Navigation
Previous Article: Run Your First Quantum Circuit: A Hands-On Guide (Part 4)
Next Article: Post-Quantum Cryptography in Practice (Part 6 — Coming soon!)
This is Part 5 of The Quantum-Centric Architect series. Read Part 0: Why Architects Need to Think About Quantum Now to start from the beginning.
Daniel Stauffer is an Enterprise Architect specializing in quantum-safe architecture and post-quantum cryptography migration strategy. He writes about emerging technology risk at @the-architect-ds.
#QuantumComputing #Cybersecurity #PostQuantumCryptography #SoftwareArchitecture #RiskManagement
The Cryptographic Bill of Materials: Auditing Your Quantum Exposure was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
