How to Implement Post-Quantum Cryptography

Key Takeaways

~ NIST finalised three post-quantum standards in August 2024: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA as a hash-based backup. In March 2025, NIST selected HQC as a code-based backup KEM under NIST IR 8545. A fourth signature standard, FN-DSA (FIPS 206), is expected between late 2026 and early 2027. The operative compliance baseline today is FIPS 203, 204 and 205.
~ A correct PQC implementation is not just algorithm selection. It requires constant-time code, side-channel resistance, and semantic understanding of where each algorithm belongs in the stack.
~ Hybrid deployment, running classical and post-quantum algorithms in parallel, is the standard migration pattern: it preserves interoperability while closing harvest-now-decrypt-later exposure immediately.

Post-quantum cryptography has moved from standardisation to implementation. With NIST FIPS 203, 204, and 205 finalised in August 2024, enterprises now have vetted, government-approved algorithms to deploy. The question is no longer which algorithms to use. It is how to implement them correctly, in the right order, without introducing the vulnerabilities that a naïve migration creates.

What Is Post-Quantum Cryptography?

Post-quantum cryptography is a family of mathematical algorithms designed to remain secure against attacks from both classical and quantum computers. Unlike quantum cryptography, which uses the physical behaviour of particles, PQC runs on existing classical infrastructure through software updates, library changes, and configuration. Its security derives from mathematical problems, primarily lattice-based and hash-based constructions, that have no known efficient quantum solution. The urgency of implementation comes from harvest now, decrypt later attacks: adversaries are already collecting encrypted data today to decrypt once quantum hardware matures.

NIST Algorithms to Implement: ML-KEM, ML-DSA, SLH-DSA

NIST's three finalised standards solve different problems and belong in different parts of the stack.

ML-KEM (FIPS 203) is the key encapsulation mechanism that replaces RSA and ECDH key exchange. It secures the key agreement layer of TLS, IPsec, and similar protocols. ML-KEM-768 is the standard deployment target; ML-KEM-1024 applies where higher security margins are required, such as for classified systems under CNSA 2.0.

ML-DSA (FIPS 204) replaces RSA and ECDSA for digital signatures. It applies to certificate signing, code signing, and any authentication flow that depends on verifiable identity assertions. Built on Module Learning With Errors over structured lattices, it is faster than its predecessor candidates while maintaining strong security margins.

SLH-DSA (FIPS 205) is a stateless hash-based signature scheme. It rests on a structurally independent mathematical foundation from ML-DSA, making it the appropriate backup if lattice assumptions are ever weakened. It is slower and produces larger signatures, so it is reserved for long-lived signing keys and scenarios where conservative security is the priority over performance.

HQC (selected March 2025, NIST IR 8545) is a code-based key encapsulation mechanism chosen as a backup to ML-KEM. Because HQC rests on a different mathematical foundation from lattice-based schemes, a future break in structured lattice assumptions would leave HQC unaffected. Its standard is still being drafted, with finalisation expected in 2027. It is a roadmap item, not a production deliverable.

FN-DSA (FIPS 206, in development) is derived from the FALCON submission and based on NTRU lattices rather than Module-LWE. It produces compact signatures of roughly 1 kilobyte compared to several kilobytes for ML-DSA, making it attractive for bandwidth-constrained environments such as IoT and certificate chains. Its implementation complexity is higher: the signing path requires careful constant-time handling of floating-point arithmetic. Finalisation is expected between late 2026 and early 2027.

On 28 July 2026, NIST confirmed that an AI model discovered a vulnerability in HAWK, a lattice-based signature candidate under consideration. HAWK was withdrawn. This finding does not affect ML-KEM, ML-DSA, or SLH-DSA, which rely on different mathematical foundations and remain ready for implementation.

Knowing which algorithms to deploy is only half the work. The sequence in which you implement them, and the rigour you apply at each stage, determines whether the migration holds. Here is the practical path.

Step 1: Build a Cryptographic Inventory

Implementation without visibility is guesswork. The first step is a Cryptographic Bill of Materials (CBOM): a complete map of every algorithm, key, certificate, and protocol in use across the estate. TLS endpoints, VPN gateways, PKI hierarchies, HSMs, code-signing pipelines, and every third-party platform must be covered. Most organisations find three to five times more cryptographic dependencies than initial estimates. A stale or partial inventory is functionally the same as no inventory.

Step 2: Vulnerable Algorithms to Find and Replace

The inventory should flag every instance of: RSA, ECC (ECDH, ECDSA, Ed25519), Diffie-Hellman, DSA, and any classical key agreement protocol. Symmetric algorithms like AES-256 are unaffected by Shor's algorithm and do not require replacement. Grover's algorithm gives at most a quadratic speedup on brute-force search, leaving AES-256 with roughly 128-bit effective strength, which remains sound. The migration scope is asymmetric cryptography only: key exchange, digital signatures, and public-key encryption.

Step 3: Implementation Vulnerabilities: Getting It Right

Selecting the correct algorithm is necessary but not sufficient. PQC implementations introduce a category of vulnerability that classical migration did not: side-channel attacks that exploit timing, power consumption, and memory access patterns rather than mathematical weaknesses.

In late 2023, researchers discovered KyberSlash: timing attacks affecting multiple implementations of Kyber KEM (the predecessor to ML-KEM) that exploited non-constant-time arithmetic during decapsulation. An attacker with precise timing measurements could recover a private key across many decryption operations on the same key. The vulnerability was patched, but the incident established a principle that every PQC implementation team must internalise: algorithmic security is insufficient if the implementation leaks through timing, power, or memory access patterns.

Correct implementation requires constant-time code: no secret-dependent branches, no secret-dependent memory accesses, no operations whose duration varies with the value of a secret. This applies to every platform, embedded systems and server-grade hardware alike.

Step 4: Why Remediation Needs Semantic Depth

A common failure mode in PQC migration is syntactic replacement: swapping an RSA call for an ML-KEM call without understanding the semantic difference between them. RSA can encrypt application data directly. ML-KEM is a key encapsulation mechanism: it establishes a shared symmetric key, which is then used with AES-256-GCM to encrypt the actual data. Replacing RSA with ML-KEM without understanding this distinction produces a broken implementation that appears to work but does not.

Similarly, ML-DSA and SLH-DSA are signature algorithms, not encryption algorithms. Using a signature scheme where encryption is required, or vice versa, is a semantic error that no linter will catch and that breaks security guarantees silently. Implementation must be driven by cryptographic understanding, not mechanical substitution.

Step 5: Hybrid Deployment and Crypto-Agility

The standard implementation pattern for 2026 is hybrid deployment: running classical and post-quantum algorithms simultaneously so that a session is protected unless both fail. In TLS 1.3, this is standardized as X25519MLKEM768, combining X25519 and ML-KEM-768 key agreement with the session key derived from both. The same principle applies to IKEv2 under RFC 9370 and MACsec at Layer 2.

Hybrid deployment serves two purposes. It preserves interoperability with clients and infrastructure not yet migrated to PQC. And it closes harvest now, decrypt later exposure immediately on migrated connections, because an adversary who has collected that traffic cannot decrypt it without breaking both the classical and post-quantum components.

Crypto-agility is what sustains this over time: abstracting algorithm selection behind configurable interfaces so that moving from hybrid to pure post-quantum, or from ML-KEM to HQC if standards evolve, is a configuration change rather than a code rewrite. The QKMS governs key lifecycle across both classical and post-quantum algorithms under one control plane, with QRNG supplying physics-based entropy as the root of trust beneath every key generated.

Step 6: Strengthening the Foundations: Ongoing

Implementation is not a point-in-time event. The CBOM must be maintained as infrastructure evolves. Vendor PQC roadmaps must be tracked through contract renewals. HSM firmware must be verified for native ML-KEM and ML-DSA support, and certification status must be checked rather than assumed. Certificate automation must be in place ahead of the CA/Browser Forum's 47-day TLS validity window arriving by March 2029. And incident response playbooks must include cryptographic algorithm failure as an explicit scenario, so that when a vulnerability is disclosed, the response is measured in hours rather than weeks.

The gap between a correct algorithm and a correct implementation is where most PQC programmes will fail.

See how QNu Labs approaches implementation from root of trust to key lifecycle.