RSA has signed the internet’s certificates for three decades. ML-DSA, finalized by NIST in August 2024, is the algorithm built to take over once quantum computers make RSA’s math solvable in practice. The catch is that ML-DSA signatures run 5 to 18 times larger than RSA’s, and that single fact is reshaping how banks, cloud providers, and certificate authorities plan their next five years of infrastructure spending.

This comparison walks through the actual numbers: signature and key sizes straight from the FIPS 204 specification, benchmark ranges from liboqs and Cloudflare’s own testing, the CNSA 2.0 deadlines federal contractors are already tracking, and which companies have shipped ML-DSA support into production in 2025 and 2026. By the end you’ll know exactly which algorithm to deploy where, and when.

None of this is hypothetical anymore. OpenSSL shipped native ML-DSA support over a year ago, the major cloud key management services already let you choose it, and a hard regulatory deadline for U.S. national security systems arrives on January 1, 2027. The question for most engineering teams in October 2026 isn’t whether ML-DSA matters, it’s which systems need it first and which can safely wait.

Why RSA’s Clock Is Running Out

RSA signatures rely on the difficulty of factoring the product of two large prime numbers. That problem has held up against classical computers for over 40 years. It does not hold up against Shor’s algorithm running on a sufficiently large, fault-tolerant quantum computer, which can factor an RSA modulus in polynomial time rather than the exponential time classical computers need.

No quantum computer today can factor RSA-2048 at a cryptographically relevant scale. Published estimates for what it would take vary widely, ranging from hundreds to thousands of logical qubits, which translates to potentially millions of physical qubits once error correction overhead is factored in. There is no single agreed “RSA break date,” and serious estimates keep shifting as quantum hardware architecture evolves.

The more pressing issue isn’t a future break, it’s a present one: harvest now, decrypt later. An attacker can record encrypted traffic today and sit on it until a capable quantum computer exists, then decrypt everything retroactively. Signatures carry a related but distinct risk. Once quantum attacks become practical, an adversary could forge RSA signatures on certificates, code-signing packages, and authentication tokens that were never meant to be verified decades into the future. That’s precisely the gap ML-DSA was built to close.

What Is ML-DSA, and Why Did NIST Pick It?

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. NIST finalized it as FIPS 204 on August 13, 2024, alongside ML-KEM (FIPS 203, for key exchange) and SLH-DSA (FIPS 205, a hash-based backup signature scheme). Before standardization, ML-DSA competed and won under its original research name, CRYSTALS-Dilithium.

Instead of factoring large numbers, ML-DSA’s security rests on the hardness of certain lattice problems, specifically finding short vectors in high-dimensional structured lattices. That math is believed to resist both classical and quantum attacks, including Shor’s algorithm, which has no known way to solve lattice problems efficiently.

FIPS 204 defines three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The numbers refer to internal lattice dimension parameters, not key or signature sizes, so don’t read them as byte counts. Each set maps to one of NIST’s five security categories, and picking the right one is the first real decision any team migrating off RSA has to make.

RSA vs ML-DSA: The Core Specs Table

Here’s the side-by-side breakdown, pulling exact figures from the FIPS 204 specification and NIST’s published security category mapping.

PropertyRSA-2048RSA-3072RSA-4096ML-DSA-44ML-DSA-65ML-DSA-87
Hard problemInteger factorizationInteger factorizationInteger factorizationModule lattice (MLWE/MSIS)Module lattice (MLWE/MSIS)Module lattice (MLWE/MSIS)
NIST standardFIPS 186-5FIPS 186-5FIPS 186-5FIPS 204FIPS 204FIPS 204
StandardizedLong-standing, current revision 2023Long-standing, current revision 2023Long-standing, current revision 2023August 13, 2024August 13, 2024August 13, 2024
NIST security category~Category 1-equivalent~Category 1/2-equivalent~Category 3-equivalentCategory 2Category 3Category 5
Public key size~294-450 bytes~422-550 bytes~550-800 bytes1,312 bytes1,952 bytes2,592 bytes
Private key size~1,190-1,700 bytes~1,768-2,500 bytes~2,348-3,400 bytes2,560 bytes4,032 bytes4,896 bytes
Signature size256 bytes384 bytes512 bytes2,420 bytes3,309 bytes4,627 bytes
Quantum resistantNoNoNoYes (per current analysis)Yes (per current analysis)Yes (per current analysis)
Signing cost profileModerate, grows with modulusSlower than RSA-2048Slowest of the threeCompetitive with RSA signingSlightly higher than ML-DSA-44Highest of the three
Verification cost profileVery fastFastFast but slower than RSA-2048Fast, more work than RSAModerateMost compute-intensive
Native OpenSSL supportSince inceptionSince inceptionSince inceptionOpenSSL 3.5.0+OpenSSL 3.5.0+OpenSSL 3.5.0+
Typical 2026 roleLegacy TLS, backward compatibilityHigher-assurance legacy useHigh-assurance legacy useLower-assurance PQC migrationDefault PQC signature choiceCNSA 2.0 / national security systems

RSA key sizes above are approximate because the byte count depends heavily on encoding: raw modulus and exponent, PKCS#1 DER, PKCS#8 DER, and PEM (which adds roughly a third more size through Base64 wrapping) all produce different numbers for the “same” key. ML-DSA’s figures, by contrast, are fixed exactly in FIPS 204 Table 2, which is part of why lattice-based schemes are easier to benchmark consistently.

Signature and Key Sizes: The Byte-for-Byte Gap

The headline number in any RSA vs ML-DSA conversation is the signature size gap. An RSA-2048 signature fits in 256 bytes. Swap it for ML-DSA-44 and that same signature balloons to 2,420 bytes, a 9.5x increase. Move up to ML-DSA-87, the parameter set CNSA 2.0 targets for national security systems, and a single signature hits 4,627 bytes, roughly 18 times the size of the RSA-2048 signature it replaces.

Public keys follow the same pattern, though less dramatically. ML-DSA-44’s 1,312-byte public key already exceeds the largest commonly encoded RSA-4096 public key. Private keys show the widest spread: ML-DSA-87’s 4,896-byte private key runs comparable to a PKCS#8-encoded RSA-4096 private key, so the private-key overhead is less painful than the signature overhead.

That asymmetry matters because signatures get transmitted over the wire on every single TLS handshake, every code-signing verification, and every document check. Private keys mostly sit on disk or inside an HSM and never leave. The practical cost of migrating to ML-DSA shows up almost entirely in network and storage overhead tied to signatures and public keys, not in private-key storage.

Benchmark Results: Signing and Verification Speed

Raw speed tells a more forgiving story than size does. Benchmarks from the Open Quantum Safe project’s liboqs library, cross-referenced against Cloudflare’s own post-quantum signature testing and independent measurements published by systemshardening.com, converge on a consistent pattern even though exact throughput numbers swing with CPU model, compiler flags, and whether AVX2 or AVX-512 vectorization is enabled.

AlgorithmSigning throughput (ops/sec, representative range)Verification throughput (ops/sec, representative range)Observed pattern
RSA-2048~10,000-50,000~50,000-200,000Verification is dramatically faster than signing
RSA-3072~3,000-15,000~30,000-100,000Signing cost climbs fast with modulus size
RSA-4096~1,000-5,000~10,000-50,000Slowest signing of the group tested
ML-DSA-44~10,000-40,000~8,000-30,000Often competitive with, or faster than, RSA signing
ML-DSA-65~7,000-25,000~6,000-20,000Moderate drop versus ML-DSA-44
ML-DSA-87~5,000-20,000~4,000-15,000Highest compute cost of the lattice family

The pattern worth remembering: RSA’s verification step is its biggest advantage, often an order of magnitude faster than its own signing step, which is exactly why RSA has dominated TLS server certificates for so long (clients verify far more often than servers sign). ML-DSA’s signing and verification costs sit much closer together, which changes the performance calculus for services that sign constantly, like code-signing pipelines or high-frequency API authentication, where ML-DSA’s more balanced profile can actually come out ahead despite the larger output.

Treat every number in that table as a range, not a constant. liboqs results should always be reported with the library version, compiler, and CPU model attached, because a benchmark showing 20,000 operations per second on one machine and 2,000 on another isn’t a contradiction, it’s two different hardware and implementation configurations.

What Bigger Signatures Actually Cost: Bandwidth, TLS, and Storage

Signature size differences stop being academic the moment you multiply them across millions of daily connections. A TLS 1.3 CertificateVerify message carrying an ML-DSA-87 signature runs roughly 4.6 KB for the signature payload alone, before certificate data and handshake framing are even counted. A full certificate chain signed end-to-end with ML-DSA-65 can add 10 KB or more compared to an equivalent RSA or ECDSA chain.

Migration cost factorRSA-2048 baselineML-DSA-65 impactML-DSA-87 impactRelative cost
Added signature bytes per handshake0 (baseline, 256 B)+3,053 bytes+4,371 bytesHigh
Extra bandwidth at 1M handshakes/day0 GB~3 GB/day~4 GB/dayMedium
Extra bandwidth at 10M handshakes/day0 GB~30 GB/day~40 GB/dayMedium-High
Library upgrade requirementNone (already supported)OpenSSL 3.5.0+ or oqs-providerOpenSSL 3.5.0+ or oqs-providerOne-time, low cost
HSM/KMS compatibilityUniversalAWS KMS, Google Cloud KMS support itAWS KMS, Google Cloud KMS support itLow, if on major clouds
Public CA certificate availabilityUniversalLimited, expanding through 2026-2027Limited, expanding through 2026-2027High until PKI catches up
Legacy parser/appliance updatesNone neededMay need updates for oversized ASN.1 fieldsMay need updates for oversized ASN.1 fieldsMedium, infrastructure-dependent

None of the major cloud key management services charge extra per signature algorithm today. AWS KMS and Google Cloud KMS both bill ML-DSA signing the same way they bill any other asymmetric signing operation, through their standard per-API-call pricing. The real cost of this migration isn’t a line item on a cloud bill, it’s engineering time spent on library upgrades, infrastructure that chokes on oversized ASN.1 fields, and certificate-chain bloat that quietly eats into bandwidth budgets at scale.

NIST Security Levels, Explained in Plain Terms

NIST defines five security categories for post-quantum algorithms, each pegged to the computational effort required to break a reference classical algorithm. ML-DSA-44 sits at Category 2, roughly equivalent to the effort needed to find a SHA-256 collision. ML-DSA-65 sits at Category 3, comparable to breaking AES-192 by brute force. ML-DSA-87 sits at Category 5, comparable to breaking AES-256.

In practice, most organizations land on ML-DSA-65 as the default choice, the same way RSA-2048 became the default rather than RSA-4096 for years: it balances security margin against size and performance cost. ML-DSA-87 gets reserved for cases where regulation demands it, principally CNSA 2.0 compliance for U.S. national security systems, or where an organization wants maximum long-term margin for data or signatures that need to stay trustworthy for decades.

CNSA 2.0 and Government Migration Deadlines

The NSA’s Commercial National Security Algorithm Suite 2.0 is the single clearest deadline driving ML-DSA adoption in 2026, even though it technically applies only to National Security Systems rather than every commercial entity in the country.

  • January 1, 2027: all new National Security System acquisitions must use CNSA 2.0-compliant algorithms, which for signatures means ML-DSA-87.
  • Through 2030: organizations are expected to have active migration planning and procurement underway, phasing out classical algorithms in new deployments.
  • By 2033: CNSA 2.0 calls for exclusive use of the new suite across applicable systems, subject to NSA implementation guidance.

CNSA 2.0 also requires post-quantum key establishment via ML-KEM, not just post-quantum signatures, so contractors touching both encryption and signing infrastructure are dealing with a two-front migration. The deadlines don’t bind ordinary commercial companies or civilian agencies by statute, but defense contractors, their suppliers, and anyone selling into that procurement chain are already building ML-DSA-87 support into 2026 and 2027 product roadmaps regardless of whether a specific contract requires it yet.

Running in parallel, the CA/Browser Forum has been shortening public TLS certificate validity on its own separate timeline: maximum validity dropped to 200 days on March 15, 2026, is scheduled to fall to 100 days on March 15, 2027, and down to 47 days by March 15, 2029. That schedule isn’t an ML-DSA mandate, but shorter-lived certificates push every CA toward heavier automation, which happens to make a future switch to post-quantum signatures operationally easier once public PKI support arrives.

Real-World Adoption: Who’s Already Shipping ML-DSA

ML-DSA moved from paper standard to shipping product faster than most post-quantum algorithms, largely because OpenSSL 3.5.0, released April 8, 2025 as a long-term-support build, brought native ML-KEM, ML-DSA, and SLH-DSA support into the default provider with no external patch required. That single release did more to accelerate real-world ML-DSA adoption than any individual vendor announcement, since it removed the biggest practical barrier, needing a non-standard library or a hand-rolled patch, in one stroke.

  • Cloudflare has deployed ML-DSA support on its edge-to-origin path, covering Authenticated Origin Pulls and its Custom Origin Trust Store, rolled out across Free, Pro, and Business tiers. Separately, Cloudflare’s hybrid ML-KEM key exchange protected roughly 43% of human-generated connections as of mid-September 2025, a share that kept climbing through 2026.
  • AWS KMS added ML-DSA signing support across all three parameter sets (ML-DSA-44, -65, -87) in 2025, confirmed still active as of August 2026, billed through its standard asymmetric signing pricing.
  • Google Cloud KMS now offers ML-DSA as a selectable signing option that customers opt into explicitly rather than something enabled by default.
  • Microsoft has built ML-KEM and ML-DSA into its SymCrypt cryptographic library, with support rolling out across parts of the Azure and Windows ecosystem.
  • Oracle launched Java 27 with Oracle Jipher 20, a FIPS 140-3 validated OpenSSL-based module supporting both ML-KEM and ML-DSA, announced in September 2026.
  • Ubuntu 26.10 ships on OpenSSL 4.0 with ML-KEM, ML-DSA, and SLH-DSA available out of the box, and makes hybrid post-quantum key exchange the default preference.
  • Red Hat’s RHEL 10 includes preliminary pure ML-DSA support as a technology preview, built against the IETF’s draft-ietf-lamps-dilithium-certificates specification, which is still evolving.

Worth separating clearly: Apple’s PQ3 messaging protocol and Signal’s PQXDH both lean on ML-KEM-style key establishment for forward secrecy, not ML-DSA signatures. That’s a meaningful distinction. ML-KEM protects the confidentiality of session keys, while ML-DSA protects signatures, certificates, and authentication. A messaging app going post-quantum on encryption says nothing about whether it has also gone post-quantum on signing, and conflating the two overstates how far signature migration has actually progressed industry-wide.

Public, browser-trusted ML-DSA certificates for ordinary websites remain the holdup. IETF published RFC 9881 in October 2025, defining how to carry ML-DSA keys and signatures inside X.509 certificates, but broad public issuance by major commercial certificate authorities, with full browser and operating system trust, is still expected in late 2026 or 2027 rather than available today.

Hybrid Signatures: Running Both Algorithms at Once

Because public PKI trust for pure ML-DSA certificates hasn’t fully arrived, most 2026 production deployments lean on hybrid signatures: pairing a classical algorithm with ML-DSA so verification only succeeds when both components validate, or structuring a single certificate to carry both signatures. Common pairings include ECDSA P-256 with ML-DSA-44, ECDSA P-384 with ML-DSA-65, and RSA-3072 or RSA-4096 with ML-DSA-65 or ML-DSA-87.

Hybrid mode buys algorithm diversity and backward compatibility with systems that don’t understand ML-DSA yet, at the cost of larger certificates, more verification work, and more complex certificate-management logic (do you require both signatures to validate, or accept either one?). Hybrid key exchange is considerably more mature in TLS today than hybrid signature authentication, which is why most 2026 deployments you’ll find in production use classical signatures paired with hybrid ML-KEM key exchange, reserving full ML-DSA signing for internal PKI, code signing, and systems where the operator controls both ends of the trust relationship.

Policy decisions around hybrid validation turn out to matter more than the cryptography itself. A strict “both must validate” policy maximizes security margin but means a bug or key-management failure in either algorithm breaks the whole chain. A looser “either is sufficient” policy keeps systems running if one algorithm fails, but only provides the security level of whichever algorithm an attacker chooses to target. Most production deployments documented so far lean toward requiring both, accepting the operational risk in exchange for not quietly downgrading security the moment one algorithm hits a snag.

Generating Keys: What Changes in Your Code

For developers, the practical difference between RSA and ML-DSA key generation is smaller than the size numbers might suggest. On OpenSSL 3.5 or later, both algorithms go through the same generic EVP key-generation API, just with a different algorithm name passed in. There’s no separate exotic toolchain to learn for the common case.

# Generate an RSA-3072 key pair (classical, pre-existing workflow)
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa3072.key

# Generate an ML-DSA-65 key pair (requires OpenSSL 3.5.0 or later)
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key

# Sign a file with each key
openssl pkeyutl -sign -inkey rsa3072.key -in message.txt -out rsa.sig
openssl pkeyutl -sign -inkey mldsa65.key -in message.txt -out mldsa.sig

# Compare signature sizes directly
ls -l rsa.sig mldsa.sig

Run that last comparison yourself and the size gap stops being an abstract table and becomes a visible 384-byte file sitting next to a 3,309-byte one. That’s the entire migration story in miniature: same workflow, same command structure, dramatically different output size. Teams running custom C or Rust cryptography code rather than shelling out to the OpenSSL CLI will call the equivalent EVP_PKEY_CTX_new_from_name function with "ML-DSA-65" as the algorithm identifier, followed by the standard EVP_PKEY_keygen_init and EVP_PKEY_keygen calls already used for every other EVP-based algorithm in the library.

Migration Guide: Eight Steps From RSA to ML-DSA

Moving a real production system off RSA signatures is not a weekend project. Here’s a sequence that works whether you’re migrating a single service or an entire PKI.

  1. Inventory every signature touchpoint. TLS certificates, code-signing keys, JWT signing, SSH host keys, VPN authentication, document signing, firmware update verification. Most teams underestimate this list by half.
  2. Upgrade your cryptographic stack. OpenSSL 3.5.0 or later gives you native ML-DSA support with no external provider. Older stacks can bridge through liboqs and the oqs-provider plugin, though oqs-provider now disables its own ML-DSA implementation automatically when it detects native OpenSSL 3.5+ support underneath it.
  3. Choose parameter sets deliberately. ML-DSA-44 for lower-assurance or size-constrained use cases, ML-DSA-65 as the sensible default for most services, ML-DSA-87 only where CNSA 2.0 or an explicit high-assurance requirement demands it.
  4. Start with hybrid signing, not pure ML-DSA. Pair ML-DSA with your existing RSA or ECDSA signature until public trust stores, CAs, and client software catch up.
  5. Benchmark on your actual hardware. Vendor-published throughput numbers assume specific CPUs, compilers, and vector instruction sets. Run liboqs benchmarks on your own production-equivalent machines before committing to a parameter set.
  6. Audit size-sensitive infrastructure. Load balancers, legacy ASN.1 parsers, certificate transparency log submissions, and OCSP responders may choke on or silently truncate oversized certificate fields built for 256-byte RSA signatures, not 4.6 KB ML-DSA ones.
  7. Coordinate with your certificate authority. Ask directly about hybrid or ML-DSA certificate timelines rather than assuming availability. DigiCert and AWS Private CA have both signaled production paths, but confirm what’s actually issuable for your specific use case today.
  8. Set a recurring crypto-agility checkpoint. Re-evaluate your migration status against CNSA 2.0’s January 2027, 2030, and 2033 milestones, or your organization’s internal PQC deadline, rather than treating this as a one-time project with a finish line.

Five Use Cases: Picking the Right Algorithm for the Job

Public-facing TLS web servers today. Stick with RSA or ECDSA server certificates paired with hybrid ML-KEM key exchange for confidentiality. Pure ML-DSA certificates aren’t broadly trusted by browsers yet, and chasing them early just adds handshake overhead with no compatibility payoff.

Defense contractors and National Security Systems. Move to ML-DSA-87 now, not in 2027. The CNSA 2.0 deadline for new acquisitions lands January 1, 2027, and procurement, testing, and certification cycles eat months you don’t want to lose waiting.

Code signing and software supply chains. Dual-sign firmware, OS updates, and software packages with both a classical signature and ML-DSA today. Signed artifacts can stay in circulation for years, and that’s exactly the kind of long-lived signature an adversary could target once quantum attacks become feasible.

Internal enterprise PKI and device identity. This is the lowest-friction place to adopt ML-DSA early. You control both ends of the trust relationship, major clouds already support it through AWS KMS, Google Cloud KMS, and Microsoft’s SymCrypt, and there’s no public browser trust store to wait on.

Bandwidth-constrained IoT, embedded, and satellite links. Think twice before adopting ML-DSA here. A 4.6 KB signature is a real tax on a narrowband or metered link. Stay on RSA or ECDSA where the threat model allows it, or evaluate SLH-DSA and other compact alternatives designed with constrained environments in mind.

Long-term document and legal signing. Contracts, notarized records, and archival signatures meant to remain verifiable for decades should move to ML-DSA or hybrid signing now. The whole point of post-quantum signatures is protecting things that need to outlive the classical-cryptography era, and a signature on a 30-year lease is a textbook case.

Where SLH-DSA and Hybrid Classical Schemes Still Fit

ML-DSA isn’t the only post-quantum signature NIST standardized, and treating it as the sole option undersells the choice teams actually face. SLH-DSA (FIPS 205, formerly SPHINCS+) relies purely on hash functions rather than lattice math, which makes it a useful backup if lattice-based cryptanalysis ever advances further than expected. The tradeoff runs the other direction from ML-DSA’s: SLH-DSA signatures are considerably larger, often tens of kilobytes, and signing is noticeably slower, so it gets reserved for high-assurance backup roles rather than everyday TLS or API authentication.

Then there’s FN-DSA (FIPS 204’s sibling standard built on the Falcon design), which produces smaller signatures than ML-DSA but comes with a narrower, harder-to-implement signing process that has kept adoption slower. For most teams outside specialized high-assurance or space-constrained deployments, the practical decision tree still starts and ends with ML-DSA: it has the widest library support, the clearest adoption signal from Cloudflare, AWS, Google, and Microsoft, and the most mature tooling as of October 2026.

None of this changes the core RSA-versus-ML-DSA comparison, but it matters for teams evaluating whether ML-DSA alone covers their entire signature strategy. A defense-in-depth posture, the kind national security systems and long-term archival signers increasingly favor, pairs ML-DSA as the primary post-quantum signature with SLH-DSA as a structurally independent fallback, so a weakness in one mathematical approach doesn’t take down both signatures at once.

Pros and Cons

RSA

  • Signatures as small as 256 bytes, minimal bandwidth and storage overhead
  • Universal support across every browser, OS, library, and appliance built in the last 20 years
  • Verification is extremely fast, often an order of magnitude faster than signing
  • Decades of cryptanalysis and real-world battle-testing
  • Not quantum resistant, vulnerable in principle to Shor’s algorithm once capable hardware exists
  • Signing cost rises sharply as key size grows toward RSA-4096
  • Carries long-term liability for anything that needs to stay trustworthy past the 2030s

ML-DSA

  • Standardized by NIST (FIPS 204) and designed to resist quantum attacks
  • Signing speed is competitive with, and sometimes faster than, RSA’s
  • Already supported natively in OpenSSL 3.5+, AWS KMS, Google Cloud KMS, and Microsoft SymCrypt
  • More balanced signing-to-verification performance ratio than RSA
  • Signatures run 9x to 18x larger than RSA-2048’s, straining bandwidth and legacy parsers
  • Public, browser-trusted certificates aren’t broadly available yet
  • Newer algorithm with less cumulative real-world cryptanalytic scrutiny than RSA

What Practitioners Are Saying

David Adrian, a cryptography engineer at Cloudflare, put the current state of the field plainly: “ML-DSA is the most viable general purpose post-quantum signature scheme standardized today” (source). That’s a notable statement given Cloudflare runs some of the busiest TLS infrastructure on the internet and has direct visibility into what actually holds up under production load.

Cloudflare’s security team has been similarly direct about the lack of alternatives in the near term: “Luckily, the solution is already available: migrate to ML-KEM encryption and ML-DSA signatures, which are designed to be resistant to quantum attack” (source). The framing matters: this isn’t presented as a perfect fix, but as the available fix given where NIST standardization has landed.

Oracle’s own database documentation is blunt about the intended trajectory: “ML-DSA is intended to replace RSA and ECDSA” (source), a line that shows up in enterprise vendor documentation precisely because customers are asking vendors what their post-quantum roadmap looks like.

And NIST’s own FIPS 204 standard describes its scope in characteristically understated terms: “This standard specifies ML-DSA, a set of algorithms that can be used to generate and verify digital signatures” (source). The understatement belies just how much engineering work sits behind that single sentence.

The Verdict: Which One Should You Actually Deploy?

Neither algorithm wins outright, because they’re not really competing for the same job anymore. RSA remains the pragmatic default for anything that needs universal compatibility today: public TLS certificates, legacy device authentication, and systems where a 256-byte signature matters more than quantum resistance. It is not going away in 2026 or 2027, and treating it as already obsolete would be premature given how much of the internet’s trust infrastructure still depends on it working everywhere, instantly.

ML-DSA is the correct choice wherever long-term signature validity matters more than bandwidth efficiency, and wherever a regulatory clock is already running. That means CNSA 2.0-bound government and defense systems should be migrating to ML-DSA-87 now, not waiting for the January 2027 deadline to force the issue. It means code-signing pipelines and software supply chains should dual-sign with hybrid RSA-plus-ML-DSA today, because a firmware image signed in 2026 might still be running in 2036. And it means internal enterprise PKI, where you control both ends of the trust chain, is the easiest and lowest-risk place to start building operational experience with the new algorithm before public trust infrastructure forces your hand.

The one certainty: the 256-byte RSA signature’s three-decade run as the internet’s default is ending, just not overnight, and not everywhere at once. Teams that treat this as a binary switch, flip the day RSA stops working, will find themselves scrambling. Teams that treat it as a staged migration, hybrid now, selective pure ML-DSA where it makes sense, full cutover once public PKI catches up, will barely notice the transition happen.

Frequently Asked Questions

Is RSA broken right now?

No. No existing quantum computer can factor RSA-2048 at a scale that threatens real-world deployments. The risk is forward-looking: harvest-now-decrypt-later for encrypted data, and a future forgery risk for long-lived signatures, not an active break today.

Why is ML-DSA’s signature so much bigger than RSA’s?

Lattice-based signature schemes fundamentally require more data to encode the mathematical proof that makes forgery hard. RSA compresses its proof into a single modular exponentiation result, while ML-DSA encodes multiple polynomial vectors, which is inherently larger regardless of implementation quality.

Can I use ML-DSA with my current certificate authority?

It depends on the CA and your use case. Private and enterprise CAs can issue ML-DSA certificates today using OpenSSL 3.5+ or AWS Private CA. Broad public, browser-trusted ML-DSA certificate issuance is still expected in late 2026 or 2027, pending CA/Browser Forum baseline requirement updates.

What’s the difference between ML-DSA-44, ML-DSA-65, and ML-DSA-87?

They’re three parameter sets mapping to NIST security categories 2, 3, and 5 respectively, with ML-DSA-65 as the commonly recommended default and ML-DSA-87 reserved for high-assurance or CNSA 2.0-mandated deployments.

Does switching to ML-DSA cost more money?

Cloud KMS providers like AWS and Google Cloud bill ML-DSA signing the same as any other asymmetric signing operation, so there’s no direct per-signature price increase. The real cost shows up as engineering time for library upgrades, infrastructure updates for oversized fields, and additional bandwidth from larger certificates and handshakes at scale.

Is ML-DSA the same thing as Dilithium?

Yes. CRYSTALS-Dilithium was the algorithm’s name during NIST’s evaluation process. ML-DSA is the official standardized name under FIPS 204, finalized August 13, 2024.

Should small businesses worry about this migration yet?

Not urgently, unless you’re in a regulated industry, handle long-lived signed artifacts, or sell into government supply chains. Most small businesses can wait for public CA support and mainstream library defaults to mature before touching production signing infrastructure.

What should I do if my hardware security module doesn’t support ML-DSA?

Check with your HSM vendor for a firmware or software update roadmap, since major vendors have been adding support following the FIPS 204 finalization. In the meantime, AWS KMS and Google Cloud KMS both offer managed ML-DSA signing if you need production capability sooner than your on-premises HSM vendor can deliver it. For regulated environments where keys can’t leave a validated hardware boundary, ask your vendor specifically about FIPS 140-3 validation status for ML-DSA, since algorithm support and formal validation often ship on separate timelines.