ML-DSA-44 vs ML-DSA-65 vs ML-DSA-87 for Enterprise PKI

Quick answer: ML-DSA-44, ML-DSA-65, and ML-DSA-87 are not interchangeable defaults; each maps to a different security category and a real size cost. ML-DSA-44 (Category 2, roughly matching 128-bit classical security) has the smallest footprint at 1,312-byte public keys and 2,420-byte signatures. ML-DSA-65 (Category 3) is the practical enterprise default at 1,952-byte public keys and 3,309-byte signatures. ML-DSA-87 (Category 5) is the largest at 2,592-byte public keys and 4,627-byte signatures, and is the parameter set CNSA 2.0 mandates for National Security Systems. The right choice depends on where in your PKI a certificate sits, root and intermediate CAs generally justify the larger size for a stronger security margin, while high-volume leaf certificates benefit more from the smaller footprint if your compliance requirements allow it.

“Just use ML-DSA” is not a complete answer once you actually configure a certification authority, since AD CS and every other PQC-capable CA platform ask which parameter set specifically. This guide compares the three by security level, size, performance, and where each one fits in a real certificate hierarchy.

Key Takeaways

• ML-DSA-44 is NIST Security Strength Category 2, ML-DSA-65 is Category 3, and ML-DSA-87 is Category 5, corresponding to progressively higher security margins against both classical and quantum attacks.
• Size scales directly with category: ML-DSA-44 signatures run 2,420 bytes, ML-DSA-65 signatures run 3,309 bytes, and ML-DSA-87 signatures run 4,627 bytes.
• ML-DSA-65 is the practical civilian default for most enterprise PKI, balancing a strong security margin against manageable certificate and chain size.
• CNSA 2.0 mandates ML-DSA-87 specifically for National Security Systems; the civilian defaults do not satisfy that requirement.
• Interoperability, not raw security margin, is often the deciding factor for leaf certificates, since larger signatures compound across every level of a certificate chain during validation.

The Three Parameter Sets, Side by Side

Property	ML-DSA-44	ML-DSA-65	ML-DSA-87
NIST security category	2 (~128-bit classical equivalent)	3 (~192-bit classical equivalent)	5 (~256-bit classical equivalent)
Public key size	1,312 bytes	1,952 bytes	2,592 bytes
Private key size	2,560 bytes	4,032 bytes	4,896 bytes
Signature size	2,420 bytes	3,309 bytes	4,627 bytes
Typical use	Constrained environments, high-volume signing where size matters most	General-purpose enterprise default	CNSA 2.0-regulated environments, highest-assurance root CAs

All three sets rest on the same underlying hardness assumptions, Module Learning With Errors and Module Short Integer Solution, so the choice is not about which one is fundamentally more trustworthy mathematically. It is about how much security margin above the current threat model you want, weighed against the real, compounding cost of larger keys and signatures.

Performance: Smaller Isn’t Always Faster in the Way You’d Expect

Signing and verification time scale with parameter set, but the difference between ML-DSA-44 and ML-DSA-87 is modest compared to the difference between ML-DSA and a hash-based scheme like SLH-DSA; ML-DSA as a family is fast enough for high-volume signing regardless of which parameter set you choose, which is a large part of why it is the practical default rather than SLH-DSA for most workloads. Where the size difference actually shows up operationally is not raw signing speed, it is downstream: larger signatures mean more bytes transmitted per TLS handshake, more bytes stored per certificate, and more bytes verified per certificate in a chain, effects that compound as chain depth increases rather than staying constant.

Mapping Parameter Sets to CA Tier

A practical, widely applicable pattern for enterprise hierarchies:

• Root CA: favor a higher parameter set (ML-DSA-65 or ML-DSA-87) since the root signs infrequently, its signature size does not compound across a high-volume issuance workload, and its long validity period justifies the strongest available margin.
• Issuing/intermediate CA: match the root’s parameter set, or use a slightly lower one if issuance volume is high and every certificate that CA signs inherits the size cost.
• High-volume leaf certificates (TLS, device identity, short-lived certs): the strongest argument for ML-DSA-44 or ML-DSA-65 over ML-DSA-87, since these certificates are issued in volume, often have short validity periods that limit the exposure window a lower category represents, and the size cost is paid on every single issuance and every single verification.
• Code signing and firmware: favor the higher end (ML-DSA-65 or ML-DSA-87), since these signatures often need to remain trustworthy for years and the artifact typically is not re-signed at high frequency.

Interoperability Requirements

Every relying party validating a certificate needs to support the specific ML-DSA parameter set it was issued under, not just “ML-DSA” as a general capability. A validator built and tested against ML-DSA-65 does not automatically handle ML-DSA-87 correctly without its own explicit support and testing, since the parameter sets differ in key and signature size, not just security level. Before standardizing on a parameter set organization-wide, confirm the specific relying parties in your environment, browsers, internal applications, embedded devices, actually support that exact parameter set, not a general “ML-DSA support” claim from a vendor.

What We’d Actually Recommend

Default to ML-DSA-65 for most enterprise PKI unless a specific regulatory requirement or use case argues otherwise; it is the balance point most current guidance and platform defaults converge on. Move to ML-DSA-87 specifically where CNSA 2.0 applies, or where a root CA’s long validity period and low signing frequency justify the strongest available margin regardless of regulatory requirement. Consider ML-DSA-44 specifically for high-volume, short-lived leaf certificates where the compounding size cost across millions of issuances outweighs the security margin difference, provided your specific compliance posture permits Category 2. Confirm relying-party support for your chosen parameter set explicitly before standardizing, rather than assuming general ML-DSA support covers every parameter set.

How Encryption Consulting Can Help

Choosing the right ML-DSA parameter set per CA tier depends on an accurate picture of your certificate volumes, chain depths, and relying-party capabilities, exactly the inventory our CBOM Secure platform builds, mapping every certificate to its issuing tier and volume so the parameter set decision is made against real data.

Our PQC Advisory Services apply the CA-tier mapping in this guide to your specific hierarchy, sequencing parameter set decisions against regulatory requirements and relying-party readiness. Where certificate issuance is involved, CertSecure Manager issues and manages certificates across different ML-DSA parameter sets by tier from a single policy plane, so the root-versus-leaf distinction becomes a policy setting rather than separate tooling.

One Algorithm, Three Real Decisions

ML-DSA-44, 65, and 87 are the same algorithm at three different security margins, and treating them as interchangeable is where PKI teams get their first PQC configuration wrong. The right default for most enterprise PKI is ML-DSA-65, with ML-DSA-87 reserved for CNSA 2.0 environments and long-lived root signatures, and ML-DSA-44 worth considering specifically for high-volume, short-lived leaf certificates where the size cost compounds fastest. Getting this mapping right by CA tier, not applying one parameter set everywhere, is what keeps certificate and chain sizes manageable as the migration scales.

Frequently Asked Questions

Which ML-DSA parameter set should most enterprises use by default?

ML-DSA-65, Category 3, is the practical default for most enterprise PKI, balancing a strong security margin with manageable certificate and chain size. Deviate from it specifically where a regulatory requirement like CNSA 2.0 or a specific high-volume use case argues for a different parameter set.

Does ML-DSA-87 provide meaningfully stronger security than ML-DSA-65?

Yes, at NIST Category 5 versus Category 3, ML-DSA-87 provides a materially higher security margin, which is why CNSA 2.0 mandates it for National Security Systems. That margin comes at the cost of roughly 33 percent larger signatures and public keys compared to ML-DSA-65.

Can a validator built for ML-DSA-65 automatically verify an ML-DSA-87 signature?

Not automatically. Each parameter set differs in key and signature size and needs explicit support and testing in the validating application or library. Confirm your specific relying parties support the exact parameter set you plan to issue under, not general “ML-DSA support.”

Why would a root CA use a different parameter set than its leaf certificates?

A root CA signs infrequently and has a long validity period, so a larger, higher-security parameter set costs little in aggregate. High-volume leaf certificates are issued and verified far more often, so their size cost compounds faster, making a smaller parameter set an attractive trade-off where compliance requirements allow it.

Is ML-DSA-44 less secure than ML-DSA-65 in a way that matters practically?

ML-DSA-44 provides Category 2 security, roughly equivalent to 128-bit classical security, which remains strong for most use cases but sits below Category 3. Whether that difference matters depends on your specific risk tolerance, regulatory requirements, and how long the certificate needs to remain trustworthy.