The NIST PQC Standards Are Here. Is Your Stack Ready?
NIST finalized its post-quantum cryptography standards in 2024. Here's what that means for your software and how to find out if you're exposed.
In August 2024, NIST officially published its first three post-quantum cryptography (PQC) standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205). A fourth, FN-DSA, is expected shortly. After years of evaluation, the quantum-resistant algorithm era has officially begun.
For most security engineers, the reaction is somewhere between "finally" and "now what?" The standards exist. The migration path is less clear.
Why RSA and ECC Are on the Clock
RSA, ECDSA, and ECDH (the algorithms securing the vast majority of TLS connections, code signing, and certificate infrastructure today) are all vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. Current estimates put cryptographically relevant quantum computers (CRQCs) somewhere between 5 and 15 years away, depending on who you ask.
That sounds comfortable until you factor in harvest now, decrypt later (HNDL) attacks. Adversaries are already collecting encrypted traffic today with the intent to decrypt it once quantum hardware matures. If your data has a sensitivity window longer than a decade (healthcare records, financial data, government communications) you're already in the exposure window.
What the Standards Actually Cover
The three finalized algorithms cover two use cases:
- Key encapsulation (KEM): ML-KEM replaces RSA and ECDH for key exchange. This is the most urgent migration because it directly addresses HNDL.
- Digital signatures: ML-DSA and SLH-DSA replace RSA and ECDSA for signing. Critical for code signing, certificate chains, and authentication.
Notably absent from the finalized set: a drop-in replacement for general asymmetric encryption. ML-KEM handles key exchange, but if you're using RSA for direct encryption (not just key wrapping), your migration path is more complex.
The Audit Problem
Before you can migrate, you need to know where you're using vulnerable algorithms. This is harder than it sounds. Cryptographic usage is scattered across:
- TLS configurations in web servers and load balancers
- Certificate chains (leaf, intermediate, root)
- Compiled binaries and libraries (OpenSSL, BoringSSL, NSS)
- Application code calling crypto APIs directly
- Third-party dependencies with their own crypto
Most organizations have no complete inventory. A manual audit of a medium-sized codebase takes weeks and is error-prone. Binary analysis is even harder because you're looking for algorithm patterns in compiled code without source.
What a Practical Assessment Looks Like
A thorough PQC readiness assessment covers three layers:
- Certificate analysis: Scan your certificate inventory for RSA key sizes, signature algorithms, and expiry timelines. Flag anything below RSA-3072 or using SHA-1.
- Binary analysis: Scan compiled artifacts for cryptographic imports, algorithm constants, and known-vulnerable library patterns. This catches what source scanning misses.
- Code scanning: Static analysis of source code for direct crypto API calls, hardcoded keys, and weak algorithm usage.
The output should be a prioritized risk inventory: not just a list of findings, but a scored assessment that accounts for algorithm strength, data sensitivity, and migration complexity.
Timeline Pressure Is Real
CISA, NSA, and NIST have all published migration guidance recommending organizations begin PQC transitions now. The NSA's CNSA 2.0 suite mandates PQC algorithms for national security systems by 2030. FedRAMP and other compliance frameworks are expected to follow.
For commercial software, the pressure is less regulatory and more competitive. Customers in regulated industries will start asking about your PQC posture before you expect them to.
Getting Started
The first step is visibility. You can't prioritize a migration you haven't mapped. Start with a cryptographic inventory across your certificates, binaries, and source code. Assign risk scores. Identify your highest-exposure assets: long-lived keys, sensitive data, and externally-facing services.
That inventory is exactly what Cerebion Rivet automates. It scans certificates, binaries, and code for quantum-vulnerable cryptography, scores findings on a 0-100 risk scale, and generates actionable reports you can hand to an engineering team or a compliance auditor.
Run your first quantum vulnerability scan
Cerebion Rivet scans certificates, binaries, and source code for post-quantum exposure in minutes.
Download Cerebion Rivet