NIST finalized two post-quantum digital signature standards in August 2024, and by August 2026 the choice between them has become a real engineering decision rather than a theoretical one. ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) are both quantum-resistant, both NIST-approved, and both already shipping in production systems at AWS, Google Cloud, Cloudflare, and OpenSSL. But they solve the signature problem in very different ways, and picking the wrong one for a given job means paying for size or speed you didn’t need to sacrifice.

This comparison breaks down the exact key sizes, signature sizes, benchmark numbers, and adoption data behind both algorithms, then walks through which one fits which workload. If you’re planning a migration off RSA or ECDSA before quantum computers make those schemes forgeable, this is the decision you’ll need to make first.

The stakes here are bigger than a typical algorithm swap. Signatures underpin software supply chains, PKI certificate authorities, firmware update mechanisms, and legal document validity. Get the choice wrong and you either burn latency and bandwidth you didn’t need to burn, or you pick a scheme that doesn’t hold up to the specific threat model your compliance team actually cares about. Neither ML-DSA nor SLH-DSA is objectively “better,” they’re built for different jobs, and this guide walks through the data so you can match the algorithm to the job instead of guessing.

What ML-DSA and SLH-DSA Actually Are

Both algorithms exist to replace RSA, ECDSA, and EdDSA, the signature schemes that secure software updates, TLS certificates, and code signing today. Those schemes rely on math problems (integer factorization and discrete logarithms) that a sufficiently powerful quantum computer running Shor’s algorithm could solve in hours. NIST spent roughly eight years running an open competition to find replacements, and in August 2024 it published FIPS 204 and FIPS 205 as final standards, with a status report on additional signature schemes still being finalized as recently as May 2026, according to NIST’s FIPS 204 publication.

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. During NIST’s evaluation it competed under the name CRYSTALS-Dilithium. Its security rests on the Module Learning With Errors (MLWE) problem, a lattice-based hard problem that’s been studied seriously since the late 1990s. In practice, ML-DSA behaves like a faster, more compact drop-in replacement for ECDSA, and NIST names it as the primary general-purpose recommendation for new deployments.

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm, known during evaluation as SPHINCS+. It skips lattice math entirely and builds its security guarantee purely from hash functions, the same primitives behind SHA-256 and password hashing. Hash-based cryptography has been scrutinized since the early 1990s, roughly a decade longer than lattice-based schemes have existed as a serious cryptographic tool. That extra scrutiny is the whole selling point of SLH-DSA: it’s the conservative fallback, not the fast option, per DigiCert’s breakdown of the NIST PQC algorithms.

Don’t Confuse Signatures With Key Exchange

A common mix-up worth clearing up before going further: ML-DSA and SLH-DSA are digital signature algorithms, not key exchange or encryption algorithms. They prove who sent a message and that it wasn’t altered. They don’t establish a shared secret for encrypting traffic, that’s a separate job handled by ML-KEM (FIPS 203), NIST’s post-quantum key encapsulation mechanism, standardized from the CRYSTALS-Kyber submission.

A full post-quantum TLS handshake typically uses both: ML-KEM to negotiate the session key, and ML-DSA (or a classical algorithm during a hybrid transition) to authenticate the certificate chain. Mixing these two categories up is one of the most common mistakes teams make when they first start planning a PQC migration, and it matters because the tradeoffs are different. ML-KEM’s public keys run around 1,184 bytes for the commonly used ML-KEM-768 parameter set, a different size profile from any ML-DSA or SLH-DSA variant. If your team is evaluating both key exchange and signatures at once, keep the two workstreams separate in your migration plan, they have different library dependencies, different NIST documents, and different rollout timelines.

How Lattice-Based and Hash-Based Signatures Work

ML-DSA’s security depends on the Closest Vector Problem in high-dimensional lattices. Picture graph paper extended into hundreds of dimensions: given a point near the lattice, finding the nearest actual lattice point is computationally hard for both classical and quantum computers. ML-DSA constructs a signature scheme where forging a valid signature requires solving that problem, and nobody has found an efficient way to do it, quantum or otherwise.

SLH-DSA takes a completely different route. It stacks three hash-based building blocks: WOTS+ (Winternitz One-Time Signatures), which signs a single message using hash chains; FORS (Forest of Random Subsets), a few-time signature scheme; and a hypertree structure that chains many WOTS+ instances together so one public key can authenticate an effectively unlimited number of signatures. The result depends on exactly one assumption, that SHA-256 or SHAKE256 behaves like a secure hash function. No lattice math, no number theory, just hashing.

There’s a related standard worth knowing here: LMS (NIST SP 800-208), also hash-based but stateful, meaning each signature consumes a leaf in a Merkle tree and the key has a hard cap on total signatures. SLH-DSA is stateless, so it behaves like a conventional signature key with no bookkeeping required. That convenience is a big reason SLH-DSA gets picked over LMS in most deployments, even though LMS produces smaller signatures.

NIST Security Levels, Explained

Both algorithms come in multiple parameter sets tied to NIST’s five security categories, though ML-DSA and SLH-DSA each only implement a subset of those levels. Category 1 corresponds roughly to the brute-force difficulty of breaking AES-128. Category 3 lines up with AES-192, and Category 5 with AES-256. ML-DSA-44 sits at Category 2 (close to Level 1 in practice), ML-DSA-65 at Category 3, and ML-DSA-87 at Category 5. SLH-DSA offers parameter sets at Categories 1, 3, and 5, each split further into “s” (small signature, slower signing) and “f” (fast signing, larger signature) variants.

Picking a security level isn’t just about picking the biggest number. Higher categories mean larger keys and signatures and slower operations, so most production deployments default to Category 3 (ML-DSA-65 or SLH-DSA-192s/f) unless there’s a specific compliance requirement pushing toward Category 5. Government and defense-adjacent systems handling top-secret-equivalent data are the main group that reaches for the top tier by default.

ML-DSA vs SLH-DSA: Full Specs Comparison

Here’s the direct side-by-side on the numbers that determine whether an algorithm fits your bandwidth, storage, and latency budget. Figures come from the final FIPS 204 and FIPS 205 specifications.

PropertyML-DSA (FIPS 204)SLH-DSA (FIPS 205)
Security basisModule-LWE lattice problemHash function security only
Public key size (128-bit level)1,312 bytes (ML-DSA-44)32 bytes (SLH-DSA-SHA2-128s)
Signature size (128-bit level)2,420 bytes (ML-DSA-44)7,856–17,088 bytes (128s/128f)
Public key size (192-bit level)1,952 bytes (ML-DSA-65)48 bytes (SLH-DSA-SHA2-192s)
Signature size (192-bit level)3,309 bytes (ML-DSA-65)16,224–35,664 bytes (192s/192f)
Public key size (256-bit level)2,592 bytes (ML-DSA-87)64 bytes (SLH-DSA-SHA2-256s)
Signature size (256-bit level)4,627 bytes (ML-DSA-87)29,792–49,856 bytes (256s/256f)
Private key size (128-bit level)2,560 bytes64–96 bytes (seed-based)
StatefulnessStatelessStateless
Underlying math age~25 years of scrutiny~30+ years of scrutiny
NIST standard numberFIPS 204FIPS 205
Competition-era nameCRYSTALS-DilithiumSPHINCS+
Standardization dateAugust 2024August 2024

The pattern is consistent at every security level: ML-DSA keeps signatures compact (2.4 KB to 4.6 KB) while SLH-DSA’s public keys stay tiny (32 to 64 bytes) but its signatures balloon to 7.8 KB on the low end and nearly 50 KB at the top security tier. Neither algorithm wins across every dimension, which is exactly why NIST standardized both instead of picking a single winner.

Benchmark Results: Signing and Verification Speed

Speed is where the two algorithms diverge hardest. Independent benchmark data pulled from vendor documentation and PQC deployment comparisons puts the gap in concrete terms.

AlgorithmApprox. Signing SpeedApprox. Verification SpeedSigning Ops/Sec
ML-DSA-65~0.5 ms~0.12 ms1,000–2,000/sec
SLH-DSA-SHA2-128f (fast)Several msSub-ms to low ms~100/sec
SLH-DSA-SHA2-128s (small)~8 ms~0.8 msUnder 10/sec
SLH-DSA SHAKE variants (small)Slowest tierModerateUnder 1/sec

Three sources converge on the same conclusion. The EJBCA Keymaster technical brief on stateless PQC signatures, Google Cloud’s Cloud KMS algorithm documentation, and independent deployment-planning benchmarks all show ML-DSA signing in well under a millisecond while SLH-DSA’s small-signature variants take single-digit milliseconds per signature, an order of magnitude slower. Verification tells a similar story, though the gap narrows: ML-DSA verification stays under 0.2 ms while SLH-DSA verification typically lands under 1 ms, fast enough for most systems even though it’s noticeably behind ML-DSA.

The practical takeaway: for anything signing or verifying at scale, thousands of TLS handshakes per second, high-volume API gateways, CI/CD pipelines cutting hundreds of releases a day, ML-DSA’s speed advantage is not a rounding error. It’s the difference between an algorithm that fits your latency budget and one that doesn’t.

Real-World Adoption: Who’s Shipping What in 2026

Post-quantum signatures moved from standards documents to production infrastructure faster than most of the industry expected. Here’s where things stand as of August 2026, with five concrete deployments worth knowing:

  • AWS KMS added ML-DSA support with the ML_DSA_44, ML_DSA_65, and ML_DSA_87 key specs, documented in AWS’s asymmetric key specs guide. Customers can now request an ML-DSA key the same way they’d request an RSA or ECDSA one, through the standard KMS API. AWS CloudHSM does not yet support ML-DSA, only KMS does, which matters if your architecture depends on dedicated HSM tenancy rather than the shared KMS service.
  • Google Cloud KMS shipped ML-DSA-65 and SLH-DSA-SHA2-128s in public preview, giving developers a direct choice between the fast lattice option and the conservative hash-based one inside the same service, without needing a third-party library. Preview status means it’s not yet backed by Google’s standard production SLA, so most teams are treating it as a place to prototype and benchmark rather than a place to put a customer-facing signing key today.
  • Cloudflare now accepts ML-DSA post-quantum certificates on its edge-to-origin path, covering Authenticated Origin Pulls and its Custom Origin Trust Store, per Cloudflare’s post-quantum signatures blog post. This is one of the first large-scale, internet-facing deployments of ML-DSA outside of a lab or preview environment, and it’s specifically scoped to origin authentication rather than the full TLS handshake.
  • OpenSSL has supported both ML-DSA and SLH-DSA since version 3.5.0, released in April 2025, according to the official OpenSSL 3.5 release notes. Because OpenSSL underpins a huge share of TLS implementations across web servers, load balancers, and custom applications, this single release did more to unlock real-world PQC signature adoption than any individual cloud provider’s announcement.
  • Open Quantum Safe (liboqs), the widely-used open-source library that many vendors build on for PQC prototyping, ships reference implementations of both algorithms, tracked at openquantumsafe.org. It’s become the de facto reference point vendors use to validate their own ML-DSA and SLH-DSA implementations against, since it tracks the NIST specifications closely and updates quickly when NIST publishes clarifications.

Notice the pattern: every major cloud KMS and edge provider that has shipped PQC signature support so far has prioritized ML-DSA first, with SLH-DSA following as a secondary option or still in preview. That mirrors NIST’s own guidance, treat ML-DSA as the default and SLH-DSA as the deliberate exception for cases that specifically call for it. Certificate authorities and browser vendors are the group to watch next; once a major browser starts accepting ML-DSA-signed leaf certificates by default, that’s the signal that PQC signatures have crossed from “available” to “expected.”

Generating and Testing Keys With OpenSSL

Since OpenSSL 3.5.0 supports both algorithms natively, testing them locally doesn’t require pulling in a separate PQC library. Here’s how to generate a key pair and sign a file with each algorithm from the command line.

# Generate an ML-DSA-65 key pair
openssl genpkey -algorithm ML-DSA-65 -out mldsa65_private.pem
openssl pkey -in mldsa65_private.pem -pubout -out mldsa65_public.pem

# Sign a file with ML-DSA-65
openssl pkeyutl -sign -inkey mldsa65_private.pem -in message.txt -out message.sig

# Verify the signature
openssl pkeyutl -verify -pubin -inkey mldsa65_public.pem -in message.txt -sigfile message.sig
# Generate an SLH-DSA-SHA2-128s key pair
openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slhdsa128s_private.pem
openssl pkey -in slhdsa128s_private.pem -pubout -out slhdsa128s_public.pem

# Sign and verify follow the same pkeyutl commands as ML-DSA above,
# just note the signature file will be roughly 3x larger

Running both commands side by side on the same file is a quick way to see the size difference for yourself, check the byte size of message.sig after each run and you’ll see the ML-DSA output land around 3.3 KB while the SLH-DSA output comes in around 7.8 KB for the 128s parameter set, matching the published FIPS 205 numbers.

Pricing: What It Costs to Deploy Either Algorithm

Neither algorithm currently carries an extra fee on top of standard signing infrastructure costs. Cloud KMS providers have folded PQC signature operations into their existing pricing models rather than introducing a quantum-safe surcharge. That said, the underlying compute and storage costs still shift because of signature size differences, so “free” isn’t quite the whole story.

ProviderML-DSA PricingSLH-DSA PricingNotes
AWS KMSStandard asymmetric key/API pricing, no PQC surchargeNot yet available (CloudHSM unsupported)Billed per key-version and per API call like existing key specs
Google Cloud KMSStandard active key-version hourly rateStandard active key-version hourly rate (preview)No separate PQC line item found on Cloud KMS pricing page
Azure Key VaultNot yet listed as supportedNot yet listed as supportedStandard flat transaction and HSM-pool pricing applies if added
OpenSSL / liboqs (self-hosted)Free, open sourceFree, open sourceOnly cost is compute and bandwidth for larger SLH-DSA signatures
Cloudflare (origin certs)Included in existing plans supporting Custom Origin Trust StoreNot yet supported for origin signingNo additional charge reported for ML-DSA cert support

The real cost driver isn’t the per-operation fee, it’s bandwidth and storage. If you’re signing millions of records a day, SLH-DSA’s 7 KB to 50 KB signatures versus ML-DSA’s 2.4 KB to 4.6 KB signatures translate directly into higher egress and storage bills at scale, even when the per-signature API call costs the same on paper. A rough back-of-envelope example: signing 10 million records a day with ML-DSA-65 adds roughly 33 GB of signature data daily, while the same workload on SLH-DSA-SHA2-128s adds roughly 78 GB, more than double, before accounting for the larger public keys stored alongside them. At cloud storage and egress rates, that gap adds up to a real monthly line item once you’re operating at that volume.

Self-hosting through OpenSSL or liboqs remains the lowest-cost path for teams that already run their own PKI infrastructure, since both libraries are open source with no licensing fee attached to either algorithm. The tradeoff is that you take on the operational burden of key management, HSM integration, and monitoring yourself rather than paying a managed KMS to handle it, which is a cost calculation that depends more on your team’s existing infrastructure than on the algorithm choice itself.

Why NIST Standardized Both Instead of Picking One

If ML-DSA is faster and smaller, the obvious question is why bother with SLH-DSA at all. The answer is algorithmic diversity, a principle cryptographers take seriously after watching supposedly solid schemes get broken over the decades.

Every cryptographic algorithm is a bet that a particular math problem stays hard. ML-DSA bets on lattice problems. If a breakthrough, classical or quantum, ever makes lattice problems tractable, every system relying solely on ML-DSA becomes vulnerable at once. SLH-DSA bets on an entirely separate assumption: that hash functions stay one-way. A lattice breakthrough wouldn’t touch it. By standardizing both from different mathematical families, NIST built in a fallback that fails independently of the primary choice, so organizations can lean on ML-DSA for everyday signing while keeping SLH-DSA in reserve for their longest-lived or most sensitive signatures.

This isn’t a hypothetical exercise. Cryptographic history includes several algorithms that looked solid for years before a cryptanalysis breakthrough weakened or broke them, MD5 and SHA-1 both went from industry-standard hash functions to deprecated within a decade of researchers publishing practical collision attacks. Lattice-based cryptography is younger than hash-based cryptography by roughly a decade of serious academic study, so NIST’s decision to standardize a structurally independent backup reflects lessons learned from watching earlier “safe” algorithms fail. It’s a form of portfolio diversification applied to cryptography: don’t put the entire internet’s signature infrastructure behind a single mathematical bet, however well-studied that bet currently looks.

5 Use Cases Where ML-DSA Is the Right Call

  1. High-volume TLS and API gateways. Any system handling thousands of connections per second needs signing and verification that stays under a millisecond. ML-DSA’s sub-millisecond performance keeps it out of the latency budget entirely.
  2. Code signing pipelines. CI/CD systems cutting hundreds of builds or releases a day benefit from ML-DSA’s speed and its 2.4 KB to 4.6 KB signature footprint, which doesn’t bloat build artifacts.
  3. IoT and cellular-connected devices. When every signature travels over a metered or bandwidth-constrained link, ML-DSA’s compact signatures cost far less than SLH-DSA’s 7 KB-plus payloads.
  4. Database and audit-log signing at scale. Systems signing millions of records need the per-signature storage cost to stay low; ML-DSA keeps that cost roughly 3x to 10x lower than SLH-DSA depending on security level.
  5. Any deployment defaulting to NIST guidance. Compliance frameworks that reference NIST PQC standards without further specification will point to ML-DSA as the primary recommendation, making it the safer default for audits.

5 Use Cases Where SLH-DSA Is the Right Call

  1. Decades-long document validity. Legal records, property deeds, and archival medical records that must verify correctly 30 to 50 years from now benefit from SLH-DSA’s reliance on hash functions with a longer track record of scrutiny.
  2. Hedging against a lattice breakthrough. Organizations whose threat models specifically account for future weaknesses in lattice cryptography can deploy SLH-DSA as an independent fallback, not because ML-DSA is currently broken, but because algorithm diversity is cheap insurance.
  3. Regulatory algorithm-diversity requirements. Some compliance regimes require signatures from two distinct mathematical families. Pairing SLH-DSA with ML-DSA satisfies that requirement directly.
  4. Firmware and large software image signing. When you’re already shipping a 200 MB firmware image or installer, an extra 8 KB to 50 KB signature is noise. Size stops mattering once the payload dwarfs the signature.
  5. Constrained devices needing tiny public keys. SLH-DSA’s 32 to 64 byte public keys are the smallest of any NIST post-quantum signature scheme, useful when keys must be embedded in long-cached certificates or burned into limited device memory.

What Happens if You Wait to Migrate

Signatures don’t carry the same urgency as encryption. Encrypted traffic captured today can be stored and decrypted later once a capable quantum computer exists, the “harvest now, decrypt later” scenario security teams have warned about for years. A signature, by contrast, only needs to resist forgery at the moment it’s verified, not years in advance. That’s an important distinction, and it’s why signature migration timelines have moved more slowly than key-exchange migration timelines industry-wide.

But the calculus changes for anything that needs to verify correctly far into the future. A firmware image signed today with RSA that a device will still be checking against in 2040 is exactly the kind of asset that needs post-quantum protection now, because by the time a quantum computer capable of breaking RSA exists, that signature will already be embedded in deployed hardware you may not be able to easily patch. The same logic applies to legal documents, long-term archival records, and any code-signing key with a validity period stretching past the mid-2030s, which is the rough window analysts cite for when cryptographically relevant quantum computers could plausibly emerge.

Industry migration guidance discussed through 2026 generally frames the full transition window as stretching toward 2030 to 2035, giving teams time to plan deliberately rather than rush a signature scheme change under pressure. The organizations moving fastest right now are the ones with the longest-lived signing artifacts: certificate authorities, firmware vendors, and government agencies with statutory records-retention requirements.

Migration Guide: Moving From RSA/ECDSA to Post-Quantum Signatures

Migrating signature infrastructure is slower and riskier than migrating encryption, because signatures often need to verify against archives that stretch back years. Here’s a practical sequence for planning the transition.

  1. Inventory every signing operation. Map out TLS certificates, code signing keys, firmware signing, document signing, and internal service-to-service authentication. You can’t migrate what you haven’t cataloged.
  2. Classify by lifetime and volume. Split workloads into high-volume/short-lived (candidates for ML-DSA) versus low-volume/long-lived (candidates for SLH-DSA or a hybrid approach).
  3. Start with hybrid signatures where possible. Many TLS and PKI implementations support dual-signing with both a classical algorithm (RSA/ECDSA) and a post-quantum one during the transition, so a verifier that doesn’t yet understand PQC still validates the classical signature.
  4. Test library support first. Confirm your TLS stack, HSM, and signing libraries support FIPS 204/205 before touching production. OpenSSL 3.5.0+ and liboqs both support both algorithms today.
  5. Pilot on a low-risk system. Internal service authentication or a staging environment is a safer first deployment than customer-facing TLS or a public code-signing key.
  6. Update key management and rotation procedures. Larger key and signature sizes affect storage, logging, and monitoring systems that assumed RSA-2048 or P-256 signature sizes; audit those assumptions before rollout.
  7. Roll out ML-DSA first for high-traffic paths. Given the speed and size advantage, most organizations should default new high-volume signing to ML-DSA before considering SLH-DSA for special cases.
  8. Reserve SLH-DSA for the specific long-lived or diversity-mandated cases identified in step 2. Don’t deploy it everywhere by default; use it deliberately where its conservative guarantee earns its size and speed cost.
  9. Plan for algorithm agility going forward. Build signing infrastructure that can swap algorithms without a full re-architecture, since NIST’s post-quantum signature evaluation pipeline (including the additional digital signature schemes report finalized in May 2026) is still active.

Common Migration Mistakes to Avoid

Teams moving off RSA and ECDSA tend to trip over the same handful of issues. Knowing them ahead of time saves a lot of rework.

The biggest one is assuming signature sizes don’t matter because “bandwidth is cheap.” That assumption holds for a single TLS handshake, but breaks down fast at scale. A service issuing a million SLH-DSA-signed audit records a day adds gigabytes of extra storage and transfer compared to the same workload on ML-DSA, and that cost compounds every day the system runs. Model the actual volume before picking an algorithm, not just the per-operation cost in isolation.

The second common mistake is hardcoding signature and key size assumptions into logging, monitoring, or database schemas. Systems built around RSA-2048 or ECDSA P-256 often have fixed-width fields or buffer sizes tuned to those algorithms. ML-DSA and SLH-DSA both produce larger artifacts, and SLH-DSA’s largest variants can exceed 49 KB, which will overflow fields sized for classical signatures. Audit those assumptions during the inventory step, not after a production outage.

The third mistake is skipping the hybrid transition period entirely. Jumping straight to PQC-only signatures cuts off any client or verifier that hasn’t updated yet, which is a real risk if you don’t control every endpoint that verifies your signatures. Dual-signing with a classical and a post-quantum algorithm during the transition avoids breaking compatibility while still building real-world PQC deployment experience.

Finally, teams sometimes treat this as a one-time swap rather than an ongoing capability. NIST’s signature standardization work is still active, evidenced by the status report on additional digital signature schemes finalized in May 2026, so the algorithm landscape isn’t frozen. Building signing infrastructure with algorithm agility in mind, where swapping the underlying scheme doesn’t require a full re-architecture, pays off the next time NIST adds or revises a recommendation.

Pros and Cons: ML-DSA

ProsCons
Fast signing and verification (sub-millisecond)Security rests on a mathematical family with less historical scrutiny than hashing
Compact signatures (2.4–4.6 KB)Larger than classical ECDSA signatures, so bandwidth impact isn’t zero
NIST’s primary general-purpose recommendationA future lattice cryptanalysis breakthrough would be a single point of failure
Broadest current vendor support (AWS KMS, Cloudflare, OpenSSL)Newer to production hardening than hash-based schemes

Pros and Cons: SLH-DSA

ProsCons
Security rests on hash functions with 30+ years of scrutinySignatures are 3x to 20x larger than ML-DSA’s
Smallest public keys of any NIST PQC signature scheme (32–64 bytes)Signing is an order of magnitude slower than ML-DSA
Stateless, unlike the related LMS standardFewer production deployments and less vendor support as of mid-2026
Fails independently of any lattice cryptography breakthroughNot practical for high-volume, low-latency signing paths

The Verdict: Which Should You Use?

For the large majority of deployments, ML-DSA is the right default. It’s faster by roughly an order of magnitude, its signatures run 3x to 20x smaller depending on security level, and it already has the broadest vendor support across AWS KMS, Google Cloud KMS, Cloudflare, and OpenSSL. NIST names it the primary general-purpose standard, and compliance frameworks that reference NIST PQC guidance without further detail will expect it by default.

SLH-DSA earns its place in a narrower set of scenarios: signatures that need to hold up for decades, systems where regulatory rules demand algorithm diversity across mathematical families, or organizations that want an explicit hedge against the (currently unrealized) risk of a lattice cryptography breakthrough. Treat it as a deliberate second signature, not a replacement for ML-DSA in everyday operations.

The pragmatic path most teams are taking in 2026: deploy ML-DSA as the default across TLS, code signing, and API authentication, and layer SLH-DSA in specifically for archival signatures, firmware, or wherever a compliance requirement calls for a second, independent mathematical basis. Neither algorithm needs to be a permanent commitment; both are designed to be swappable as vendor support matures and as NIST’s ongoing evaluation work, including the additional signature schemes still under review, produces further guidance. Building that flexibility into your signing infrastructure now is worth more than getting the initial algorithm choice perfectly optimized, since the PQC landscape is still moving.

Frequently Asked Questions

Is ML-DSA the same as Dilithium?

Yes. ML-DSA is the standardized name for the algorithm that competed in NIST’s evaluation process as CRYSTALS-Dilithium. The underlying design is the same; ML-DSA is simply its final, standardized form under FIPS 204, published in August 2024 after NIST’s multi-year public evaluation. If you see “Dilithium” referenced in older documentation or libraries, it’s describing the same algorithm now formally called ML-DSA.

Is SLH-DSA the same as SPHINCS+?

Yes. SLH-DSA is the standardized version of SPHINCS+, published as FIPS 205. Both names refer to the same stateless, hash-based signature scheme, though NIST made minor parameter adjustments during standardization, so implementations should target the final FIPS 205 specification rather than pre-standardization SPHINCS+ code.

What’s the difference between ML-DSA/SLH-DSA and ML-KEM?

ML-KEM (FIPS 203) is a key encapsulation mechanism used for establishing shared encryption keys, while ML-DSA and SLH-DSA are signature algorithms used for authentication and integrity. They solve different problems and are typically deployed together in a full post-quantum TLS stack: ML-KEM negotiates the session key, and a signature algorithm authenticates the certificate chain.

How much bigger is the CPU and bandwidth overhead of switching to these algorithms?

For ML-DSA, the overhead is modest: signatures land in the 2.4 KB to 4.6 KB range, several times larger than a typical ECDSA P-256 signature (about 64-72 bytes) but still small in absolute terms, and signing/verification stays sub-millisecond. For SLH-DSA, the overhead is substantial: signatures run from roughly 7.8 KB up to nearly 50 KB, and signing throughput drops to double or single digits per second on the smaller-signature “s” variants. Size the impact against your actual request volume before choosing.

Can I use both ML-DSA and SLH-DSA at the same time?

Yes, and many organizations planning for algorithm diversity do exactly that, using ML-DSA for high-volume, latency-sensitive signing and SLH-DSA for long-lived or highly sensitive signatures where an independent mathematical basis is worth the extra size and speed cost.

Does switching to ML-DSA or SLH-DSA break compatibility with existing RSA or ECDSA systems?

Not if you use a hybrid approach. Many TLS and PKI implementations support dual-signing with both a classical algorithm and a post-quantum one during the transition period, so systems that don’t yet understand PQC signatures can still validate the classical signature while newer systems validate the post-quantum one.

Which cloud providers support ML-DSA and SLH-DSA today?

As of August 2026, AWS KMS supports ML-DSA (ML_DSA_44, ML_DSA_65, ML_DSA_87). Google Cloud KMS supports both ML-DSA-65 and SLH-DSA-SHA2-128s in public preview. Cloudflare accepts ML-DSA certificates on its edge-to-origin path. Azure Key Vault has not yet published support for either algorithm.

Why are SLH-DSA signatures so much bigger than ML-DSA’s?

SLH-DSA builds signatures out of a hypertree of hash-based one-time and few-time signature schemes (WOTS+ and FORS), which requires including many hash values to prove authenticity. ML-DSA’s lattice-based construction achieves the same guarantee with a much more compact mathematical structure, which is why its signatures stay under 5 KB across all security levels.

Do I need to migrate to post-quantum signatures right now?

For most organizations, planning and piloting now makes sense given that industry migration timelines discussed in 2026 stretch toward 2030–2035 for full transition. Signatures don’t carry the same “harvest now, decrypt later” urgency as encryption, but systems producing long-lived signatures (decades-long document validity) benefit from starting the transition earlier rather than later.

Is ML-DSA or SLH-DSA more resistant to quantum computers?

Both are designed to resist attacks from quantum computers running Shor’s algorithm, which is what makes RSA and ECDSA vulnerable. Neither is “more” quantum-resistant in a meaningful sense; the difference between them is which classical mathematical assumption underlies that resistance (lattice problems for ML-DSA, hash functions for SLH-DSA), not the degree of quantum safety itself.