To find quantum-vulnerable cryptography, search four places: source code for algorithm names and library calls, configuration for allowed key exchanges and signature types, certificates and key stores for key types, and dependencies for crypto libraries. Record each finding with an owner and a data lifetime. Grep alone will miss hidden uses.
What you are looking for
NIST's draft transition report names the quantum-vulnerable families: finite-field DH, elliptic curve DH, RSA key establishment, and the ECDSA, EdDSA and RSA signature algorithms. Search for each family under the names tools use.
Step 1: source code
Search for algorithm strings and API calls. Typical terms:
grep -rniE "rsa|ecdsa|ecdh|ed25519|x25519|secp256|prime256|diffie|dsa_" \
--include="*.py" --include="*.js" --include="*.ts" --include="*.go" \
--include="*.java" --include="*.rs" --include="*.cs" .
Also search for JWT algorithm names such as RS256, ES256 and EdDSA, and for key generation calls in your language's crypto library.
Step 2: configuration and infrastructure
- Web servers and proxies: allowed TLS key exchange groups and signature algorithms.
- SSH configs: KexAlgorithms, HostKeyAlgorithms and key types in authorized keys.
- VPN and tunnel configs.
- Cloud key management: which keys are RSA or elliptic curve, and what they wrap.
- Infrastructure as code: key and certificate resources.
grep -rniE "KexAlgorithms|HostKeyAlgorithms|ssl_ecdh_curve|ssl_ciphers|ecdsa|rsa" \
--include="*.conf" --include="*.yaml" --include="*.yml" --include="*.tf" .
Step 3: certificates and keys
Export your certificate inventory and note the public key type and size. Check internal certificate authorities and their root keys, since those have the longest lives. Do not forget device and code signing certificates.
Step 4: dependencies
Your code may never name RSA, but a library does. Use an SBOM or dependency scan to list cryptographic libraries and versions, including transitive ones. Safeguard's SBOM and dependency scanning does this for supported ecosystems, and the free scan at gold.safeguard.sh/scan is a quick start.
Step 5: record what you find
For each hit, capture:
- Location and owner.
- Algorithm and key size.
- Purpose: key exchange, signature, or key wrapping.
- Data lifetime.
- Whether you can change it or a vendor controls it.
What grep will miss
- Algorithms chosen at runtime by negotiation.
- Cryptography inside binaries, firmware and managed services.
- Hard-coded OIDs and byte strings.
Add runtime checks: log the negotiated TLS group and signature algorithm for a sample of connections, and review it.
Run the search on a schedule, not once. Add it to CI as a report, not a blocker at first, and track the count of hits over time. A falling count is a simple progress metric you can show to leadership. Pair it with a short note on what changed each quarter, so the number has context and a reader can tell a real migration from a search pattern that stopped matching.
Quick check
Is X25519 a hit in this search?
Yes. It is an elliptic curve scheme, which falls in the quantum-vulnerable key agreement group, so record it like any other.
Will AES show up as a finding?
It can appear in your search, but NIST says AES at 128, 192 or 256 bits can continue to be used, so it is low priority for quantum reasons.
Sources
Last reviewed: 19 October 2026.
