If you've been following NIST's post-quantum cryptography standardization process, you already know the threat is real. In August 2024, NIST finalized the first three PQC standards: ML-KEM (CRYSTALS-Kyber), ML-DSA (CRYSTALS-Dilithium), and SLH-DSA (SPHINCS+).

But here's the problem most engineering teams face: they don't know what cryptography is actually running in their codebase.

Why this matters now

The "harvest now, decrypt later" attack is already happening. Nation-state actors are collecting encrypted traffic today, betting they'll be able to decrypt it once quantum computers are powerful enough. For data that needs to stay confidential for 5+ years, this is not a future problem.

CNSA 2.0 (NSA's Commercial National Security Algorithm Suite) has set deadlines:

• Software and firmware: migrate by 2025
• Networking equipment: migrate by 2026
• General purpose systems: migrate by 2030

What algorithms are actually at risk

These are the algorithms that quantum computers will break using Shor's algorithm:

These are weakened but not broken by Grover's algorithm:

AES-256 and SHA-256 remain safe against known quantum attacks.

How to find cryptographic risk in your code

The naive approach is grepping for algorithm names. This misses a lot.

# This will miss most real-world usage
grep -r "RSA" ./src

Real cryptographic usage hides in:

• Library imports (from cryptography.hazmat.primitives.asymmetric import rsa)
• Configuration files (ssl_protocols TLSv1 TLSv1.1)
• Certificate handling code
• JWT libraries using RS256 or ES256 signing
• SSH key generation
• TLS configuration in web servers

A proper scan needs to understand context, not just pattern match.

What a real scan looks like

I built CipherAhead to solve this. Here's what scanning the Apache HTTPD repository surfaces:

• 57 findings across the codebase
• 6 critical issues including Diffie-Hellman key exchange and TLS 1.0 support
• Specific file and line references for each finding
• Remediation mapped to NIST PQC standards

For example, in modules/ssl/ssl_engine_init.c:

// Line 122 - CRITICAL
DH_generate_key(dh); DH_compute_key(shared_secret, peer_pub_key, dh);
// Fix: migrate to X25519 or ML-KEM post-quantum key exchange

And in the same file:

// Line 910 - HIGH
SSL_CTX_set_min_proto_version(ctx, TLS1_VERSION);
// Fix: require TLS 1.3 as minimum

A scan across popular open source projects

After scanning 97 real-world projects, here's what the data shows:

• 9,869 total findings
• 39 critical risk findings
• 42 high risk findings
• Only Angular scored 0 (fully PQC-safe in its own code)
• Apache Tomcat: 152 findings, 15 critical
• Bitcoin Core: 190 findings, 4 critical
• Classical cryptography still dominates across the ecosystem

Where to start in your own codebase

1. Inventory first: list every library that handles cryptography
2. Focus on data in transit: TLS configurations, API authentication
3. Focus on data at rest: encryption keys, certificate management
4. Check JWT signing algorithms: RS256 and ES256 are vulnerable, switch to EdDSA as an intermediate step
5. Audit SSH keys: RSA keys should be replaced with Ed25519

The migration path

For each vulnerable algorithm, NIST recommends:

• Key exchange: migrate to ML-KEM (CRYSTALS-Kyber)
• Digital signatures: migrate to ML-DSA (CRYSTALS-Dilithium) or SLH-DSA
• Symmetric encryption: upgrade AES-128 to AES-256
• Hashing: move from MD5/SHA-1 to SHA-256 or SHA-3

Most major libraries already support these. OpenSSL 3.x, BouncyCastle, and libsodium have PQC implementations available.

Try it on your own repo

You can scan any public GitHub repository or web URL at cipherahead.com for free. No install required.

The goal isn't to panic — most production systems have years before quantum computers become a real threat. But cryptographic migrations take time, and understanding your current exposure is the first step.

If you found this useful or have questions about PQC migration, drop a comment below.