Here is a small experiment. Take a service you own, and grep it for the algorithms you think it uses:
$ grep -rn "AES" demo/
$ echo $?
1
Exit code 1: no matches. Now run a real crypto scan over the same directory:
PQLens 0.7.0 — scanned demo
4 crypto asset(s), 4 occurrence(s)
BROKEN / deprecated: 2
QUANTUM-VULNERABLE: 2
STATUS ALGORITHM LIBRARY LOCATION
broken SHA-1 node/crypto demo/app/sign.js:4
broken MD5 python/hashlib demo/app/tokens.py:5
quantum-vulnerable ECDSA node/crypto demo/app/sign.js:3
quantum-vulnerable RSA-2048 python/cryptography demo/app/tokens.py:8
The grep found nothing because you were looking for the crypto you chose. The scanner found the crypto that is actually there — including an MD5 and a SHA-1 nobody would have volunteered in a meeting. This is the whole problem in miniature: the hard part of a cryptographic inventory is not migration, it is discovery. You cannot plan to replace what you cannot see.
The ten places it hides
Cryptography does not live in one file called crypto. It is smeared across your stack, and each layer needs a different way of looking. Here is the full list, with the kind of thing each one turns up.
1. Your source code. The obvious one, and still not obvious: the interesting findings are the API calls with a bad parameter — RSA.generate(1024), a createHash('sha1') — not the string "AES". You need to understand the call, not match a keyword. How the code scan works →
2. Your dependencies. Most of the cryptography you ship, you never wrote. A transitive dependency four levels down that bundles an old TLS stack is in your artifact whether or not your code touches it.
3. Config and IaC. Your nginx config declares which cipher suites the server will accept — including the TLS 1.0 floor someone set in 2015. Your Terraform declares the key spec it will mint on the next apply. This is the crypto of the future, written down today.
4. Certificates on disk. PEM and DER files with key algorithms, signature hashes, and the occasional SHA-1 signature that should have died years ago.
5. Keystores. Java services and load balancers keep their real certificates inside .jks and .p12 containers, which are opaque to a filesystem scan. That is where the surprises accumulate. Opening keystores →
6. TLS endpoints. What your servers negotiate, as opposed to what they'll accept. Here's a live scan of one well-run endpoint:
● cloudflare.com:443 TLS 1.3 TLS_AES_128_GCM_SHA256 KEX=X25519MLKEM768 [hybrid PQC ✓]
cert: CN=cloudflare.com expires 2026-10-06 (84d)
quantum-vulnerable ECDSA-256 Elliptic-curve DSA is broken by Shor's algorithm.
pqc-ready X25519MLKEM768 Hybrid post-quantum key exchange.
Note the honesty of the finding: the key exchange is already hybrid post-quantum, but the certificate is still classical ECDSA. Both facts belong in the inventory. Scanning TLS →
7. SSH host keys. Long-lived production cryptography, generated when the box was provisioned and never looked at again. Readable pre-authentication, so no credentials required.
8. JWKS. Your entire authentication layer trusts the keys in one JSON document. Most teams have never once looked at what is in it.
9. Cloud KMS and ACM. The keys and certificates that never touch a filesystem, so no file scan will ever find them. For a PCI-scoped shop running on AWS, the customer master keys are the inventory. Scanning AWS →
10. Vendor appliances and SaaS. The crypto you don't operate but depend on — which is why inventory tools that can point at a public JWKS or TLS endpoint let you cover third parties too.
Why this is the good news
If the problem were migration, it would be genuinely hard: rewriting protocols, coordinating across teams, testing interoperability. But the problem in front of almost everyone is one step earlier and far more tractable. Discovery is a scan, not a project. You can run it this afternoon, and the output is a list — which is exactly the artifact PCI DSS 12.3.3 and ISO 27001 A.8.24 ask for, and the first thing every post-quantum deadline requires before anything else.
None of this leaves your machine. The scans above ran locally against local files and public endpoints; nothing about your code or config is uploaded anywhere.
The uncomfortable part is that most organisations have never looked, so the first scan is always a little embarrassing. That is not a reason to avoid it. It is the reason to do it before someone else does it for you.