NIST Post-Quantum Standards Explained: KEMs and Signatures – What’s Here, What’s Coming

Last updated on September 21st, 2026 at 08:07 am

Today, quantum computers don’t break encryption. Nonetheless, the protocols and certificates being issued currently may still be used when they do. And that is the unpleasant reality: NIST took almost ten years to host one of the most high-traffic cryptography contests in history – and that is why the standards that the agency published in 2024 are significant to firmware engineers and enterprise architects alike.

This paper dissects the NIST PQC process, describes what the actual difference between KEMs and signatures really is, and discusses the real-life limitations that you will bump into when attempting to realize these algorithms in practice—no deep math required.

What NIST Actually Did and Why It Took So Long

The Competition in Brief

In 2016, NIST already launched an open call for post-quantum cryptography algorithms. The concept was simple: identify alternatives to RSA and elliptic-curve cryptography that would resist both classical and quantum attacks. Research teams worldwide submitted applications, with 69 in the first round alone.

After numerous public publications, cryptanalyses, and civil commentary, NIST published its first completed standards in August 2024. Three algorithms completed the race:

• ML-KEM (FIPS 203) – a key encapsulation system on the problem of the Module-Lattice.
• ML-DSA(FIPS 204) is a lattice-based digital signature scheme.
• SLH-DSA (FIPS 205) – a hash-based signature scheme, a scheme that is slower and has weak

security behavior. Two additional ones remain under consideration: FN-DSA (a compact lattice signature scheme, Falcon) and HQC (a code-based KEM backup to ML-KEM). The process is not complete; it is taking a new level.

These algorithms are being developed as drop-in algorithms to insert into protocols already dependent on RSA and ECC: TLS, VPNs, secure email, code signing, X.509 certificates, and S/MIME. Critical infrastructure has no choice in transitioning; it is not a matter of choice, but a matter of when.

NIST Post-Quantum Standards Explained: KEMs and Signatures Are Not the Same Problem

Here, much early publicity is confused. KEMs and signatures address different issues, and replacing them requires understanding each role in your protocol stack.

What a KEM Does

A Key Encapsulation Mechanism handles key establishment: the handshake stage where two parties agree on a shared secret without transmitting it directly over the wire. In classical cryptography, this is tackled with RSA key transport or ECDH key exchange.

ML-KEM replaces that. One party generates a public/private key pair. The other party uses the public key to encapsulate a randomly generated shared secret and produce ciphertext; the first party decrypts with its secret key to recover the same secret. Neither party transmits the secret.

It appears in TLS 1.3 key exchange, TCPsec/IKEv2, SSH, and any protocol that negotiates session keys.

What a Signature Scheme Does

Signatures manage authentication and integrity – demonstrating that a message, certificate, or code worked its way out of who it claims it originated from and that it has not undergone an integrity violation. RSA-PKCS1 and ECDSA currently fill this role.

ML-DSA and SLH-DSA are replacing these. A signer prepares a signature for a message using their private key. It can be verified by anybody having the corresponding public key. The underlying math is completely different from RSA, though the protocol flow of protocols such as X.509 and S/MIME can be cleanly mapped.

Where you will find it: Code signing pipeline, TLS certificate chains, document signing, firmware authentication, and secure boot.

Why Both Matter Together

A connection like TLS includes both a KEM (to set the session key) and signatures (to verify the server certificate’s authenticity). Migrating one but not the other leaves half the chain vulnerable. This is one reason Post-Quantum Cryptography Migration planning is more complicated than changing a cipher suite setting.

The Trade-Offs Nobody Warned You About

I have read enough migration documentation to tell you this in a nutshell: on paper, the numbers look good, good, but once you test with real stacks, things start to go wrong. Here’s what actually shows up.

Key and Ciphertext Sizes

This is the nearest contention center. Compare these rough figures:

ML-KEM is manageable. Signatures manually generated by ML-DSA are about 13 times larger than ECDSA counterparts. The size cost of SLH-DSA signatures is enormous – that security assumption that is conservative and based on hash is actually expensive.

In TLS handshakes, these longer signature and certificate chains add latency. In limited protocols with regular-sized messages (DTLS, CoAP, Zigbee), they can shatter it completely. This is where I, in experience, found lab testing to begin to diverge markedly from theoretical expectations.

CPU and Memory Overhead

Lattice is also computationally expensive compared to ECC on devices without hardware support. ML-KEM and ML-DSA scale relatively well on current server hardware. NXP’s post-quantum whitepaper reports readable performance on Cortex-A class processors with AVX2 optimization.

The image is displayed on lockup devices. Microcontrollers with 64 KB of RAM, no FPU, and no hardware crypto acceleration have real issues. SLH-DSA signatures are large and require storage and bandwidth, which many embedded systems lack. I observed this especially through papers aimed at upgrading pipelines in IoT firmware updates – the decision that simply updating the signature scheme is sufficient fails quickly.

Hybrid Designs: The Transition Bridge

Since confidence in new algorithms is developed gradually, in most realistic applications, hybrid schemes will be employed – classic algorithms are executed simultaneously with post-quantum algorithms. An example is X25519 + ML-KEM-768, which can be trusted to be classically secure now and quantum-secure later.

In some cases, this doubles the material and adds handshake complexity. However, it is the suggested practice during the transition period, especially where long-lived certificates and infrastructure are involved. NIST’s migration guidance specifically focuses on hybrid operation.

What’s Still Being Evaluated and Why It Matters

FN-DSA (Falcon)

Produces much smaller signatures than ML-DSA, but its signature-verification algorithm requires floating-point numbers, which are difficult to execute reliably and safely across hardware. Side-channel resistance is harder to ensure. It is still slowly heading toward standardization as FIPS 206, though deployment guidance has just begun to keep pace.

HQC – The Backup KEM

Another mathematical family that is not a lattice, but is a code-based algorithm, is HQC (Hamming Quasi-Cyclic). It is being standardized, specifically as a hedge: if a breakthrough in lattice cryptanalysis ever undermines ML-KEM, HQC offers an independent fallback. It has larger key sizes than ML-KEM but serves as portfolio insurance rather than a default selection.

Deployment Reality: What Architects and Engineers Are Actually Facing

Protocol-Level Integration

The IETF has been developing hybrid key exchange for TLS 1.3, and browser vendors have already started testing ML-KEM on real traffic. In 2023, Chrome and Cloudflare also completed preliminary Kyber engines (the initial name of ML-KEM). They were not experiments, but large-scale production traffic tests.

In the case of the majority of enterprise stacks, the realistic way is as follows:

• Inventory – listing of RSA/ECC implementation by your certificate authority, TLS termination gateways, VPN gateways, and signing infrastructure.
• Evaluate – determine which systems can have software updates versus those systems that have to be replaced.
• Test – test ML-KEM and ML-DSA with your protocols in a laboratory setup. And hybrid first. In hybrid mode, install classical and PQC before switching over.
• Monitor– observe interoperability malfunctions with third-party systems that are not yet migrated.

This structured lab migration in enterprise and government settings is exactly what the NCCoE (National Cybersecurity Center of Excellence) is implementing. The data from their project outputs will be a valuable real-world reference.

The Embedded and IoT Problem

The hardest category is that of constrained devices. The firmware signing key shipped in a machine today may still be required to check signatures in 2035. Unless the bootloader of that device can accept the size of ML-DSA signatures or even has the RAM to generate the key using ML-KEM, the migration path may mandate hardware replacement, rather than a software one.

That is why IoT Post-Quantum Cryptography Migration planning cannot wait until quantum computers can do it. It must begin now, during product design. I’ve observed that any device manufacturer viewing this as a future problem is already accruing technical debt.

Governance and Crypto-Agility

Crypto-agility, or the capability to change cryptographic algorithms without redesigning the entire system, is a common theme across all serious migration roadmaps, including those TNO has published so far. Systems hard-coded with RSA-2048 in their design, rather than treating the algorithm as a configuration parameter, will have to be completely rewritten to upgrade.

This is a design issue and not a cryptography issue. Any company that develops crypto-agile systems today will incur significantly lower costs and time for algorithm transitions.

The Standards Timeline: Where Things Stand Right Now

Last History and Present Situation. The three finalized standards can be implemented today. FN-DSA and HQC will be followed, but planning must not be deferred.

Two External Resources Worth Bookmarking

Two sources I consider to be truly helpful to any person creating implementation plans or writing about this space are:

1. The official page of the PQC project at NIST. Reference material for the FIPS documents, draft standards, and migration directions. Use the NIST Post-Quantum Cryptography project as a bookmark for algorithm specifications and official schedules.
   Propositions: NIST Post-Quantum Cryptography Standards.
2. PQC Migration Project of NCCoE. The National Cybersecurity Center of Excellence is releasing enterprise-level migration counseling. The projects page of their PQC migration (real-world testing, interoperability findings, and deployment) is discussed on their migration project page. Anchor text: NCCoE Post-Quantum Cryptography Migration Project.

What This All Means – My Take

The finalization of NIST 2024 was not the end of the post-quantum story. It was the starting gun.
The algorithms are ready. The actual work- inventorying systems, testing performance on real hardware, updating certificate infrastructure, retraining teams, etc. is only underway. KEMs and signatures aren’t comparable tools for different jobs, and treating them the same will create real integration issues.

Organizations that transition readily are the ones that already test ML-KEM in their own TLS stacks, specify crypto-agile architectures in new products, and read the NCCoE lab documents.

In my experience, organizations scramble when they have to meet a real deadline and wait for a final migration guide before starting any work. Start with a KEM. Test an ML-KEM-768 hybrid (TLS) based. Quantify the difference in handshake size. That one experiment can teach you everything you need from the white paper.

Pranay Sai Aduvala

I’m a technology writer passionate about AI and digital marketing. I create engaging and useful content that bridges the gap between complex technology concepts and digital technologies. My writing makes the process easy and engaging. I encourage participation I continue to research innovation and technology. Let’s connect and talk technology!