Every migration decision you make has a performance dimension. Choosing between ML-KEM and SLH-DSA is not just a security question, it's a question about how much bandwidth you have, how much memory your device can spare, and how many operations per second your infrastructure needs to sustain.
This lesson is deliberately non-mathematical. You do not need to understand lattice problems or hash-based constructions to use these numbers well. What you need is a working model of three things:
The bottom line before you start: ML-KEM is fast and efficient, the easiest drop-in for most environments. ML-DSA has larger signatures than what you're replacing but acceptable performance. SLH-DSA is slower and larger but the most conservative security choice. IoT and constrained devices face the hardest tradeoffs of all three. By the end of this lesson you'll be able to explain why each of those statements is true.
Select each algorithm to see its performance characteristics, key sizes, and what that means in practice. All figures are representative benchmarks on modern server hardware; performance varies by implementation and platform.
ML-KEM is the replacement for RSA and ECDH key exchange. It is the algorithm you will encounter most often in TLS, VPNs, and secure messaging. Its performance profile is the most favorable of the three NIST standards, fast key generation, fast encapsulation, fast decapsulation.
Migration implication: ML-KEM keys are roughly 12–25× larger than ECDH keys. For most server-to-server TLS, this adds negligible overhead, a few kilobytes in a handshake. For IoT devices with 32KB of RAM and constrained radio bandwidth, this size difference is a genuine engineering problem that requires careful selection of the right parameter set.
ML-DSA is the replacement for ECDSA and RSA signatures. It is used wherever you need to sign data, code signing, certificate issuance, document authentication, TLS certificate chains. Its performance is good, but its key and signature sizes are meaningfully larger than what ECDSA produces, and this creates real considerations for PKI deployments.
The PKI certificate chain implication: A standard TLS certificate chain has 2–3 certificates. If each certificate's signature grows from 72 bytes to ~3,300 bytes, the total handshake data increases substantially. Modern TLS implementations handle this, but embedded systems, IoT clients, and bandwidth-constrained networks feel the difference. Certificate transparency logs and OCSP responses also grow, which affects CA infrastructure planning.
SLH-DSA is the conservative backup. Where ML-DSA is built on lattice mathematics (a newer construction), SLH-DSA is built on hash functions, one of the most thoroughly studied and trusted foundations in cryptography. If you're skeptical of lattice-based security or operating in an environment where long-term conservatism is required, SLH-DSA is the answer. The tradeoff is real: it is slower to sign and its signatures are significantly larger.
What makes SLH-DSA unusual: Its public key is tiny (32–64 bytes, smaller than ECDSA) but its signatures are enormous by comparison. The signing operation is also slow because it requires many hash computations. Verification is relatively fast. This profile makes SLH-DSA well-suited for use cases where you sign rarely, verify often, and trust matters more than efficiency, for example, firmware signing on critical infrastructure or long-term document archival where you need cryptographic conservatism over decades.
The slow signing speed eliminates SLH-DSA from most high-throughput scenarios. Its appropriate use cases are those where the signing event happens infrequently but the trust requirement is extremely high:
This table summarizes the key performance dimensions across all three standards and their classical predecessors. Use it as a reference for migration planning conversations.
| Algorithm | Operation speed | Key / cert size | Signature size | Best use case |
|---|---|---|---|---|
| ECDH P-256 Classical — being replaced |
Very fast | Very small (64 B) | N/A (KEM) | Key exchange |
| ML-KEM-768 FIPS 203 — recommended |
Very fast | Larger (~1.2 KB) | N/A (KEM) | TLS, VPN, messaging key exchange |
| ECDSA P-256 Classical — being replaced |
Very fast | Very small (64 B) | 72 bytes | Certificates, code signing |
| ML-DSA-65 FIPS 204 — recommended |
Fast | Larger (~2 KB) | ~3.3 KB | TLS certificates, code signing, PKI |
| SLH-DSA-128s FIPS 205 — conservative |
Slow (signing) | Tiny key (32 B) | ~7–50 KB | Root CA signing, firmware, archival |
The hardest performance tradeoffs in PQC migration are not in your data centers, they're in the devices that live at the edge of your network and have been running on hardware designed for classical cryptography. Select a device category to see what the PQC migration challenge looks like for that environment.
IoT sensors and microcontrollers face the most acute PQC challenge. A typical ARM Cortex-M0+ running a TLS stack has 32–64 KB of RAM. ML-KEM-768 alone requires ~2 KB of working memory for a key exchange operation, feasible on better-resourced microcontrollers, but tight. ML-DSA signatures (~3.3 KB each) plus the certificate chain overhead can exceed available working memory on the smallest devices entirely.
The practical options: (1) move PQC processing off-device to a gateway that handles cryptographic operations on behalf of a cluster of sensors, (2) use ML-KEM-512 (smaller parameter set, lower security level but still quantum-safe), or (3) accept that some legacy endpoints cannot be migrated without hardware replacement. Hardware replacement cycles for IoT are often 10–15 years, this is a procurement decision that needs to start now.
Smart cards and hardware tokens (PIV cards, FIDO2 keys, banking tokens) have the most constrained environment of all. Classic smart card hardware was designed for RSA-2048 operations. Many cannot run ML-KEM or ML-DSA at all without a firmware or hardware upgrade, the CPU is too slow and the RAM too limited for lattice-based operations.
NIST and card manufacturers are actively working on this. Some modern smart card chips have hardware accelerators that can handle ML-KEM. But the installed base, millions of government PIV cards, banking tokens, and identity credentials, represents a replacement cycle measured in years and billions of dollars. This is the reason smart card migration is listed as a separate and explicitly flagged category in Unit 4's hardware migration checklist.
Hardware security modules are in a better position than most constrained devices, but migration is not trivial. HSMs are purpose-built cryptographic hardware, they are fast, but they run firmware that must explicitly support each algorithm. An HSM that does not have ML-KEM or ML-DSA in its firmware cannot perform those operations, regardless of how powerful the underlying hardware is.
The good news: major HSM vendors (Thales, Entrust, Utimaco, AWS CloudHSM) have announced or begun shipping PQC firmware updates. The migration path is a firmware update and re-enrollment process, not a hardware replacement. The risk: firmware updates require testing, change management, and re-certification in regulated environments. Plan for 6–12 months of lead time in environments where HSMs are in regulatory scope.
Embedded systems in industrial control and SCADA environments combine the worst of all categories: constrained hardware, long replacement cycles, air-gapped update processes, and safety-critical operation that makes downtime nearly impossible. A PLC running DNSSEC or TLS-secured communications with 10-year-old firmware may have no path to PQC without physical replacement.
The migration strategy here is rarely direct. Most organizations planning OT (operational technology) PQC migration use a combination of: (1) gateway devices that provide a PQC-secured perimeter while the inner OT network continues running legacy protocols, (2) network segmentation to isolate OT from the public internet until hardware renewal is feasible, and (3) extended vendor support agreements to ensure security updates continue until replacement is funded. This environment is the strongest argument for starting your CBOM now, you need years of lead time.
Answer two questions about a deployment scenario to get an algorithm recommendation with reasoning.
Algorithm selection guide
Select both options to see your recommendationPerformance benchmarking is a topic that comes up constantly in PKIC working group conversations, both in the PQC WG and the TCWG. Being able to say "ML-DSA signatures are roughly 45× larger than ECDSA, which creates real considerations for certificate transparency log infrastructure and bandwidth-constrained clients" is a contribution to that conversation, not just background knowledge.
If you're exploring a Web3 or decentralized PKI angle (covered in Lesson 5.8), note that the performance profile applies there too. Blockchain-based identity systems that rely on cryptographic signatures face the same ML-DSA size tradeoffs as traditional PKI, and many current decentralized identity implementations have not yet addressed this.
For most SMBs, the practical performance question is simple: will PQC make my systems slower or more expensive to run? The honest answer for most server-based infrastructure is: slightly, at the margins, and probably not noticeably. ML-KEM and ML-DSA on modern server hardware run in microseconds.
Where SMBs feel performance differences is in bandwidth and certificate chain size, if you're running a web application on a thin hosting plan with tight bandwidth limits, or operating over satellite or low-bandwidth links, the larger certificate chain sizes are worth knowing about in advance. Ask your hosting provider and CDN whether they support hybrid TLS and how they handle larger certificate objects.
The most operationally important performance insight in this lesson is the constrained device problem. When you're building your migration priority list, systems that sit behind a gateway (where the gateway handles PQC and the internal systems speak classical protocols) are much easier to migrate than endpoint devices that must perform cryptographic operations themselves.
Use this framing when you present migration timelines: "These 40 servers migrate in Phase 1 because they can run ML-KEM and ML-DSA natively. These 200 IoT sensors migrate in Phase 3 because they require either gateway mediation or hardware replacement, and we need procurement approval to fund that." That kind of phased, performance-aware framing is exactly what a CISO or CFO needs to approve a realistic plan.