What is a CBOM, and why does the EU want one by the end of 2026?
A CBOM (Cryptographic Bill of Materials) is a machine-readable inventory of every cryptographic asset your systems use: algorithms, key lengths, certificates, protocols and libraries. The EU coordinated post-quantum roadmap treats this inventory as the first milestone, with reporting pointing to end-2026 for critical systems. Treat the exact dates as provisional and verify them against primary EU sources.
- ▸Where a CBOM lives. CycloneDX 1.6 extends the SBOM format with a cryptographic-assets component type covering algorithm, certificate, protocol and related-crypto-material. A CBOM is effectively an SBOM specialized for cryptography.
- ▸The EU driver. Commission Recommendation (EU) 2024/1101 and the NIS Cooperation Group post-quantum roadmap push member states and critical-infrastructure operators toward inventory-first transition planning. Exact deadlines differ between documents and are still moving.
- ▸Why inventory comes first. You cannot migrate what you cannot see, and most cryptography hides inside TLS terminators, VPNs, PKI, code signing, databases, HSMs, firmware and third-party SaaS.
Which of my systems are actually broken by a quantum computer?
Public-key cryptography is the casualty. A large fault-tolerant quantum computer running Shor's algorithm breaks RSA, Diffie-Hellman and elliptic-curve schemes (ECDH and ECDSA), the backbone of TLS, VPNs, PKI and code signing. Symmetric cryptography such as AES and hash functions such as SHA-2 are only weakened by Grover's algorithm and survive by increasing key sizes.
- ▸Asymmetric means replace. RSA-2048, ECDSA P-256, ECDH and classic Diffie-Hellman all need post-quantum replacements: ML-KEM for key exchange and ML-DSA or SLH-DSA for signatures.
- ▸Symmetric means upsize. Move AES-128 to AES-256 and prefer SHA-384 or SHA-512 for long-lived integrity. Grover's algorithm gives only a quadratic speedup, so doubling key length restores the margin.
- ▸No quantum computer breaks this today. No cryptographically relevant quantum computer (CRQC) exists publicly, but migration takes years, which is precisely the problem.
What is harvest-now-decrypt-later, and how do I triage for it?
Harvest-now-decrypt-later (HNDL) is the threat where adversaries record encrypted traffic and stored ciphertext today, then decrypt it once a quantum computer arrives. Triage with Mosca's inequality: if your data's required secrecy lifetime plus your migration time exceeds the time until a quantum computer, that data is already exposed. Prioritize long-lived secrets.
- ▸Mosca's inequality: if X (how long data must stay secret) plus Y (migration time) is greater than Z (time to a CRQC), you must act now.
- ▸High-shelf-life data first: health and biometric records, state secrets, intellectual property, root CA private keys and long-term contracts, anything with a 10-to-25-year confidentiality horizon.
- ▸Ephemeral data is lower priority: a session token that expires within the hour is not a realistic HNDL target and should not crowd out your migration budget.
- ▸A deeper treatment lives in Harvest Now, Decrypt Later: Your 2026 Post-Quantum Migration Plan.
How do I build a cryptographic inventory that is not a spreadsheet graveyard?
Automate discovery, then keep the inventory as code. Combine source scanning, dependency and binary analysis, network and TLS scanning, and certificate discovery, then emit a CycloneDX CBOM you regenerate in CI. A static spreadsheet rots within a sprint; a generated CBOM tracks reality and feeds the crypto-agility work that follows.
- ▸Tooling: OWASP CBOMkit and the sonar-cryptography plugin for source scanning; testssl.sh or sslscan for negotiated suites; certificate inventory from your CA, ACME and Certificate Transparency logs; dependency scanners for library versions such as OpenSSL, BoringSSL and Bouncy Castle.
- ▸Record per asset: algorithm, key length, purpose, protocol, owning service, data sensitivity and rotation path.
- ▸Keep it continuous: regenerate the CBOM on every build, diff it, and alert whenever new RSA or ECC usage appears.
- ▸The SBOM foundations are covered in The Software Supply Chain in 2026: SBOMs, Provenance, and the CRA Reckoning.
What is ML-KEM, and how do I turn on hybrid TLS safely?
ML-KEM (FIPS 203, derived from CRYSTALS-Kyber) is NIST's standardized key-encapsulation mechanism for quantum-safe key exchange. The safe deployment path is hybrid: pair it with a classical curve so you are never worse off than today. In TLS 1.3 that means the X25519MLKEM768 group, already default in major browsers and CDNs.
- ▸Why hybrid. If ML-KEM has an implementation flaw, the classical X25519 half still protects you; if a quantum computer later breaks X25519, the ML-KEM half holds. France's ANSSI and Germany's BSI both favor hybrid for the transition.
- ▸How to enable it. OpenSSL 3.5 ships ML-KEM and the X25519MLKEM768 hybrid group; enable it at your TLS terminator, whether that is a load balancer, reverse proxy or CDN. Cloudflare, AWS and current browsers already negotiate it.
- ▸Mind the handshake size. ML-KEM public keys and ciphertexts add roughly one to two kilobytes to the TLS handshake, so test latency-sensitive and constrained embedded clients; for most web traffic the added round-trip overhead is negligible.
- ▸Signatures come next. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) cover authentication, but post-quantum certificate chains are still maturing, so plan them separately from key exchange.
What about code signing, firmware, and long-lived signatures?
Signatures that must stay valid for years, such as firmware, secure boot, software updates and document signing, need special care because you cannot easily re-sign deployed artifacts. Use hash-based signatures: stateless SLH-DSA (FIPS 205) where operational simplicity matters, or stateful LMS and XMSS (NIST SP 800-208) for firmware with disciplined state management.
- ▸Long device lifecycles. Firmware and secure boot outlive most servers, so a forged future update is a real HNDL-style risk; hash-based signatures rest on conservative security assumptions.
- ▸Stateful schemes are unforgiving. LMS and XMSS require never reusing a one-time key; a single state-management error collapses the security, so many teams prefer stateless SLH-DSA despite larger signatures.
- ▸Plan the PKI. Dual-sign with classical and post-quantum algorithms during transition, pilot ML-DSA chains, and track your vendor CA support. See Provenance You Can Prove: SLSA, Sigstore, and Policy-as-Code CI/CD.
What does a realistic PQC migration checklist look like before end-2026?
Aim to finish discovery and start hybrid pilots by end-2026, not to be fully post-quantum. A defensible position is a complete cryptographic inventory, HNDL triage done, a crypto-agility refactor underway, hybrid TLS live on external endpoints, and vendor roadmaps collected. Full migration realistically extends toward 2030 to 2035.
- ▸1. Inventory: generate a CBOM across code, infrastructure, certificates, firmware and third parties.
- ▸2. Triage: apply Mosca's inequality and rank systems by data shelf life.
- ▸3. Crypto-agility: abstract algorithms behind interfaces and remove hardcoded RSA and ECC, as detailed in Crypto-Agility by Design: Engineering for the Post-Quantum Era.
- ▸4. Hybrid TLS: enable X25519MLKEM768 on external endpoints and, where feasible, the internal service mesh.
- ▸5. Signatures and PKI: pilot ML-DSA and plan SLH-DSA or LMS for firmware and updates.
- ▸6. Vendors: require CBOMs and post-quantum timelines in procurement and contracts.
- ▸7. Governance: align to the NIST IR 8547 draft (deprecating RSA and ECC toward 2035) and NSA CNSA 2.0, and verify EU deadlines against primary sources.
How TuniCyberLabs helps
We run post-quantum migration as an evidence-producing engineering program. TuniCyberLabs generates your first CBOM, triages HNDL exposure with Mosca's inequality, refactors for crypto-agility, and enables hybrid TLS such as X25519MLKEM768 without breaking clients. We serve the EU and North Africa, with engineering delivered from Tunisia and standards-aligned documentation your auditors and customers will accept.
To scope a cryptographic inventory and a realistic PQC roadmap, explore our security services.