Cryptographic Discovery: Find Where Crypto Lives
A practitioner guide to cryptographic discovery and building a CBOM — how to find where crypto is used across your estate before the quantum migration starts.
Every conversation about post-quantum cryptography eventually hits the same wall: where is crypto even used in our estate? NIST finalised the post-quantum standards in August 2024 — FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — and the strategic destination is clear. But you cannot replace algorithms you cannot see. Cryptographic discovery is the unglamorous, foundational work that determines whether your migration is a managed programme or a five-year fire drill.
At CC Conceptualise we have run this discovery work for regulated European enterprises, and the pattern is consistent: organisations are confident they know their crypto, and they are almost always wrong. Cryptography hides in places nobody owns.
TL;DR / Key takeaways
- You cannot migrate what you cannot see. A complete cryptographic inventory — a CBOM — is the prerequisite for any post-quantum migration.
- Discovery alone takes 12–24 months for a large enterprise, and full migration takes 5–15 years. Starting now is what makes 2027–2030 deadlines achievable.
- No single tool finds everything. Layer source/binary scanning, network/TLS scanning, certificate enumeration, and dependency analysis.
- Prioritise by data lifetime, not just algorithm. Harvest-now-decrypt-later means long-lived confidential data is already at risk today.
- A CBOM is structured and reusable. Produce it in CycloneDX, wire it into CI/CD, and treat crypto-agility as the end state.
Why "where is crypto used" is the hardest question
Cryptography is not a system you can point to. It is a property woven through almost everything: TLS on every endpoint, signing keys in CI/CD pipelines, encryption at rest in databases and object storage, JWT and SAML token signing, VPN and SSH, code-signing certificates, hardware roots of trust, payment HSMs, and a long tail of third-party products that embed crypto you never configured.
The harvest-now-decrypt-later threat reframes urgency. An adversary capturing encrypted traffic today can store it and decrypt it once a cryptographically relevant quantum computer exists. So the question is not only what algorithm protects this data but how long must this data stay confidential. A session token that expires in an hour is uninteresting. Genomic data, M&A documents, state secrets, and 30-year mortgage records are already exposed.
This is why discovery is a 12–24 month exercise for large organisations — and why the realistic end-to-end migration runs 5–15 years. The hard part is rarely the new algorithm; SymCrypt added ML-KEM and ML-DSA in late 2024, and Azure Key Vault and Managed HSM PQC support is tracking through 2026. The hard part is finding everything that needs to change.
What a cryptographic inventory must capture
A useful inventory is not a spreadsheet of "we use AES." Each cryptographic asset should record enough context to drive prioritisation and remediation:
| Attribute | Why it matters |
|---|---|
| Algorithm and mode | Identifies quantum-vulnerable primitives (RSA, ECC, classic DH) versus symmetric/hash that mainly need larger sizes |
| Key size / parameters | Distinguishes "rotate" from "replace"; drives effort estimates |
| Protocol & version | TLS 1.2 vs 1.3, IKE, SSH — where negotiation can be hardened first |
| Library & version | Tells you whether a fix is a config change or a vendor upgrade |
| Owning system & team | Without an owner, nothing gets remediated |
| Data sensitivity & confidentiality lifetime | The harvest-now-decrypt-later prioritisation axis |
| Configurability | Hard-coded crypto is a migration blocker; configurable crypto is crypto-agility-ready |
The natural artefact for this is a cryptographic bill of materials (CBOM). CycloneDX extended its SBOM standard with a cryptography component type, so a CBOM is machine-readable, diffable, and producible in the same pipeline as your existing SBOM. That reuse matters: a static document goes stale within a sprint, whereas a generated CBOM stays current.
A layered discovery approach
No single technique sees the whole estate. We run four discovery workstreams in parallel, then reconcile the findings.
1. Source and binary scanning
Scan source code and compiled artefacts for cryptographic API calls, hard-coded algorithm identifiers, and embedded keys or certificates. This catches the crypto your developers wrote — including the dangerous hard-coded cases that block agility. Feed results directly into the CBOM at build time.
2. Network and TLS scanning
Active and passive network scanning reveals what is actually negotiated in transit: TLS versions, cipher suites, certificate chains, SSH and VPN parameters. This is often where reality diverges most sharply from documentation — legacy protocols survive in forgotten corners.
3. Certificate and key store enumeration
Enumerate every PKI, certificate authority, Azure Key Vault, Managed HSM, and on-prem HSM. Map issuance, expiry, key types, and usage. Long-lived signing keys and code-signing certificates deserve early attention because their compromise has the widest blast radius.
4. Library and dependency analysis
Analyse dependency manifests and transitive dependencies to surface crypto libraries you inherit but never chose. This is where third-party and open-source crypto hides, and where a vendor's migration timeline becomes your constraint.
Classifying and prioritising what you find
Discovery produces a large, noisy dataset. The value is in ruthless prioritisation. We score each asset on three axes:
- Quantum exposure — is the primitive directly broken by a quantum computer (RSA, ECC, DH) or merely weakened (symmetric, hashes)?
- Confidentiality lifetime — how long must the protected data stay secret? This is the harvest-now-decrypt-later axis.
- Remediation difficulty — is the crypto configurable, or hard-coded and entangled with business logic?
The intersection of high quantum exposure, long data lifetime, and external exposure is your first wave: public-facing TLS protecting long-lived sensitive data, and long-lived signing keys. Hard-coded crypto with no clear owner is your structural debt — it will not be fixed in this migration cycle without deliberate investment.
| Priority | Profile | Typical action |
|---|---|---|
| Wave 1 | Long-lived confidential data over public TLS; long-lived signing keys | Plan hybrid/PQC enablement first; tighten protocols now |
| Wave 2 | Internal services with sensitive data, configurable crypto | Schedule into normal upgrade cycles |
| Wave 3 | Short-lived tokens, ephemeral sessions | Lower urgency; address opportunistically |
| Structural | Hard-coded crypto, unowned third-party crypto | Fund refactoring toward crypto-agility |
From inventory to crypto-agility
A one-off inventory is worth far less than a living one. The estate changes every sprint; a CBOM produced once is wrong within weeks. The goal is to make CBOM generation part of CI/CD and asset onboarding, so the inventory is continuously regenerated and drift is visible.
This is also where discovery connects to the wider programme. The inventory feeds directly into your crypto-agility roadmap, which sequences the migration; into platform-specific work such as Azure Key Vault post-quantum migration; and into the architectural decisions covered in our guide to ML-KEM and ML-DSA for architects. Discovery without a destination is just an audit; the destination is crypto-agility — the ability to swap cryptographic primitives without re-architecting systems.
The regulatory clock reinforces the timeline. NSA's CNSA 2.0 requires quantum-safe algorithms for new national-security systems from January 2027, with full migration across 2030–2035, and the hyperscalers — Google, Cloudflare, AWS, Microsoft — are targeting roughly 2029 internally. None of those targets are reachable for an enterprise that has not yet found where its crypto lives.
Common pitfalls we see
- Treating discovery as a tooling purchase. A scanner is necessary but not sufficient; reconciliation and ownership are the hard parts.
- Inventorying algorithms but not data lifetime. Without the confidentiality-lifetime lens, you cannot prioritise against harvest-now-decrypt-later.
- Ignoring third-party and embedded crypto. Vendor and appliance crypto is often the longest pole in the tent because you do not control its timeline.
- Producing a static document. If the CBOM is not regenerated in your pipelines, it is decoration.
Where to start
Begin narrow and prove the pipeline: pick one high-value, externally exposed system, run all four discovery workstreams against it, and produce a CBOM you trust. That proof point exposes your tooling gaps cheaply and gives leadership a concrete artefact to fund the wider programme.
Cryptographic discovery is genuinely difficult, but it is finite and it is the work that makes everything downstream possible. If you would like a partner who has built these inventories for regulated European enterprises, our Zero Trust and cybersecurity team can help you scope and run the discovery phase — and connect it to a credible crypto-agility roadmap.
FAQ
What is cryptographic discovery?
Cryptographic discovery is the process of finding and cataloguing every place cryptography is used across an organisation — algorithms, key sizes, protocols, certificates, libraries, and the systems and data they protect. It is the foundational step before any post-quantum migration, because you cannot replace algorithms you cannot see. For large enterprises, discovery alone typically takes 12 to 24 months.
What is a CBOM (cryptographic bill of materials)?
A CBOM is a structured, machine-readable inventory of all cryptographic assets in a system — the cryptographic equivalent of a software bill of materials (SBOM). It records algorithms, key lengths, certificate metadata, library versions, and the dependencies between them. CycloneDX extended its SBOM standard with a cryptography component type, so a CBOM can be produced in the same format and pipeline as your SBOM.
Why do I need a crypto inventory before post-quantum migration?
NIST finalised the post-quantum standards (FIPS 203, 204, 205) in August 2024, but you cannot migrate to ML-KEM or ML-DSA without first knowing where your current algorithms live. The inventory tells you what to prioritise against the harvest-now-decrypt-later threat, where crypto is hard-coded versus configurable, and which systems block crypto-agility. Skipping discovery means migrating blind.
How do I find where cryptography is used in my estate?
Combine several techniques: static source and binary scanning for crypto API calls, network and TLS scanning for protocols and cipher suites in transit, certificate and key store enumeration (PKI, Key Vault, HSM), and dependency analysis of libraries. No single tool finds everything, so layering passive and active methods is essential. CC Conceptualise typically runs four parallel discovery workstreams to avoid blind spots.
How long does cryptographic discovery take?
For a large enterprise, building a reasonably complete crypto inventory takes 12 to 24 months because cryptography is embedded in code, configuration, third-party products, hardware, and partner integrations. The realistic end-to-end post-quantum migration takes 5 to 15 years. Starting discovery now is what makes the later deadlines (CNSA 2.0 from 2027, hyperscaler targets around 2029) achievable.
What is harvest-now-decrypt-later and why does it change discovery priorities?
Harvest-now-decrypt-later is an attack where an adversary captures encrypted data today and stores it to decrypt once a cryptographically relevant quantum computer exists. It means data with a long confidentiality lifetime — health records, state secrets, intellectual property, long-lived keys — is already at risk in transit and at rest. Discovery should therefore tag each asset with its data sensitivity and required confidentiality lifetime, not just its algorithm.
Topics