Read this first
The hunt targets the public-key algorithms Shor's algorithm breaks — RSA, finite-field Diffie–Hellman, and elliptic-curve schemes (ECDH, ECDSA, EdDSA). No single detection method sees all of it: static analysis reads source, network scanning reads live traffic, certificate discovery reads your PKI, and each misses what the others catch. A clean scan means the rules that ran found nothing — not that no vulnerable crypto exists. Coverage, not tool output, is the metric that matters.
Before you can migrate anything, you have to know where the quantum-vulnerable cryptography is. That sounds like a search problem with a single right tool, but it is not: the same algorithm shows up as an API call in source, a transitive dependency in an SBOM, a negotiated group on a TLS handshake, and a signature on a certificate — and no one method observes all four. Effective discovery means running several methods and reconciling what they find.
What counts as quantum-vulnerable
The target is narrow and specific: the asymmetric algorithms broken by Shor's algorithm. That means RSA, finite-field Diffie–Hellman, and the elliptic-curve family — ECDH for key exchange, ECDSA and EdDSA for signatures. These are the schemes a cryptographically-relevant quantum computer defeats outright.
Symmetric cryptography is not the target of this hunt. AES at 128 bits or more and hash functions in the SHA-2 and SHA-3 families remain secure against known quantum attacks at adequate sizes; Grover's algorithm weakens them only modestly. Flagging every AES call as "quantum-vulnerable" buries the findings that matter under noise. Hunt the public-key algorithms; note the symmetric ones for context, not for remediation.
The detection methods
Each method sees a different slice of the estate, and the slices only partly overlap:
- **Source-code and static analysis** — scan for crypto API calls and hardcoded primitives (`RSA.generate`, named curves, key sizes). Findings can be emitted as SARIF so they flow into the same review surface as other code scanning.
- **Dependency and SBOM analysis** — identify the libraries that *implement* RSA and ECC, including transitive dependencies your own code never names directly.
- **Network and TLS scanning** — observe the key-exchange groups actually negotiated and the certificate signature algorithms presented on live connections. This catches what is running, not what is written.
- **Certificate and key-store discovery** — enumerate RSA and ECDSA certificates, their key sizes, and their expiry dates across your PKI and load balancers.
- **Binary and protocol analysis** — recover crypto from compiled artifacts and proprietary protocols where no source is available.
- **HSM and keystore configuration review** — read the algorithms and key hierarchies configured in hardware modules and secret stores.
Their blind spots
Every method leaves gaps, and honest discovery is mostly a matter of knowing where they are. Static analysis misses algorithms chosen at runtime from configuration or negotiated dynamically — the source shows a variable, not a curve. Embedded systems, firmware, and network appliances often expose neither source nor a scannable surface. Third-party SaaS and managed services run crypto you cannot scan at all. Code paths reached only under specific runtime conditions never appear in a static pass. And data-at-rest key hierarchies — the KEK-wrapping-DEK chains behind stored data — are invisible to both source and network scanning.
A clean static scan is not an all-clear
"No findings" from a source scan means the rules that ran matched nothing in the code they could see — not that no vulnerable crypto exists. Config-driven algorithms, runtime-only paths, vendored binaries, and third-party services all sit outside its view. The real question is never "what did the tool report?" but "what fraction of the estate did any tool actually look at?" Combine static, dynamic, and network discovery, because any single method leaves a systematic gap.
Consolidating findings
Discovery only pays off when the results from every method are normalized into one place. Raw output — SARIF from the scanners, TLS group names from the network sweep, certificate metadata from PKI discovery — arrives in incompatible shapes. Reconcile it into a single machine-readable CBOM: one record per cryptographic asset, tagging algorithm, key size, location, and the method that found it. That inventory is what feeds prioritization — sequencing remediation by data shelf life and exposure — and it is the artifact a cryptographic inventory is ultimately built to produce.
How quantakrypto helps
We run the full sweep rather than a single scanner — static analysis, dependency and SBOM review, network and TLS scanning, certificate discovery, and keystore review — precisely because each method covers the others' blind spots. Our audit normalizes every finding into one CBOM you can trust as a coverage baseline, not just a list of hits, and hands it to a migration plan that replaces vulnerable key exchange with standards such as ML-KEM. Start with discovery: you cannot migrate what you have not found, and you cannot trust a finding of "nothing" you never measured.