Artifact GuideGLOBALFIPS digital signatures

ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5

A focused comparison for teams choosing, implementing, or reviewing FIPS-aligned digital signature algorithms.

Use it to separate algorithm standards, parameter choices, CAVP evidence, and CMVP module validation scope.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
4

Structured answer sets in this page tree.

Primary sources
7

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

ML-DSA and ECDSA are both digital signature choices in the NIST FIPS ecosystem, but they are not interchangeable labels. FIPS 204 standardizes ML-DSA, a module-lattice-based post-quantum signature algorithm. FIPS 186-5 specifies ECDSA and other digital signature algorithms, with ECDSA depending on elliptic-curve domain parameters and per-message secret handling. A useful comparison records which algorithm is being claimed, which parameters are used, whether the implementation has CAVP evidence, and whether the surrounding cryptographic module is inside a CMVP validation boundary.

Side-by-side comparison

FIPS 204 ML-DSA vs ECDSA under FIPS 186-5

Compare the algorithm standard, parameters, key handling, validation evidence, and module boundary before reusing claims across ML-DSA and ECDSA.

Review all sources
First framework
FIPS 204 ML-DSA

Use this side when the signature claim is ML-DSA or HashML-DSA under FIPS 204, including ML-DSA-44, ML-DSA-65, or ML-DSA-87 parameter choices.

Second framework
ECDSA under FIPS 186-5

Use this side when the signature claim is ECDSA or deterministic ECDSA under FIPS 186-5, including the named curve/domain parameters and hash or XOF choices.

Comparison row 1

Standard scope

FIPS 204 ML-DSA

FIPS 204 specifies ML-DSA, including key generation, signature generation, signature verification, supporting algorithms, and approved ML-DSA parameter sets.

NIST FIPS 204 Module-Lattice-Based Digital Signature StandardSources 1
ECDSA under FIPS 186-5

FIPS 186-5 specifies ECDSA signature generation and verification as part of the Digital Signature Standard, with elliptic-curve domain parameters supplied through SP 800-186.

NIST FIPS 186-5 Digital Signature StandardSources 1
Operational implication

Start by naming the algorithm and standard. Do not use FIPS 204 to justify ECDSA claims or FIPS 186-5 to justify ML-DSA parameter-set claims.

NIST FIPS 204 Module-Lattice-Based Digital Signature StandardSources 1NIST FIPS 186-5 Digital Signature StandardSources 2
Comparison row 2

Covered actors

FIPS 204 ML-DSA

Federal agencies, contractors, and module vendors implementing ML-DSA under FIPS 204 for digital signature use cases requiring post-quantum algorithm compliance or NIST-approved lattice-based signing.

ECDSA under FIPS 186-5

Federal agencies, contractors, and module vendors implementing ECDSA under FIPS 186-5 for digital signature use cases that require classical elliptic-curve signature algorithms with approved domain parameters.

Operational implication

Match the actor role to the algorithm: use ML-DSA for post-quantum migration planning; use ECDSA for current approved digital signature operations.

Comparison row 3

Trigger

FIPS 204 ML-DSA

ML-DSA implementations should record whether the claim uses ML-DSA-44, ML-DSA-65, or ML-DSA-87 and whether the pure or pre-hash signing interface is used.

ECDSA under FIPS 186-5

ECDSA implementations should record the curve/domain parameters, hash or XOF, key-size security strength, and whether the signature process is randomized or deterministic.

Operational implication

Record whether the implementation trigger is post-quantum migration (ML-DSA) or current FIPS compliance (ECDSA) to choose the appropriate algorithm family.

Comparison row 4

Core obligations

FIPS 204 ML-DSA

ML-DSA key generation uses an approved random bit generator for the seed, with security-strength requirements that differ by parameter set.

ECDSA under FIPS 186-5

ECDSA requires the private key and per-message secret numbers to be protected; deterministic ECDSA derives the per-message secret from the message hash and private key through the specified process.

Operational implication

Protect key material and RBG dependencies for both algorithms; ML-DSA adds lattice-specific seed protections that ECDSA does not require.

Comparison row 5

Evidence

FIPS 204 ML-DSA

For ML-DSA, look for CAVP evidence that matches the implementation, FIPS 204 revision, parameter set, and function form being claimed.

ECDSA under FIPS 186-5

For ECDSA, look for CAVP evidence that matches ECDSA or deterministic ECDSA, the applicable curve/domain parameters, hash or XOF, implementation, and certificate status.

Operational implication

Collect CAVP validation evidence matching the specific algorithm variant and parameter set; do not reuse ECDSA CAVP records for ML-DSA claims.

Comparison row 6

Timing

FIPS 204 ML-DSA

ML-DSA availability is tied to FIPS 204 publication and CAVP validation entry availability. Migration planning should account for protocol support, hybrid transition design, and NIST post-quantum migration guidance timelines.

ECDSA under FIPS 186-5

ECDSA remains approved under FIPS 186-5 with current validity unless NIST deprecation or SP 800-131A revision changes its status. Transition away from ECDSA is expected as post-quantum migration guidance matures.

Operational implication

Note that ML-DSA availability is tied to FIPS 204 publication and CAVP entry availability; ECDSA timelines are governed by FIPS 186-5.

Comparison row 7

Enforcement

FIPS 204 ML-DSA

An ML-DSA implementation may sit inside a FIPS 140-3 cryptographic module boundary, but the module certificate, security policy, approved mode, and listed algorithms determine the validated claim.

ECDSA under FIPS 186-5

An ECDSA implementation may also sit inside a FIPS 140-3 cryptographic module boundary, but the ECDSA certificate entry must still align with the module version and operational environment.

Operational implication

Both algorithms may sit inside a FIPS 140-3 module boundary; confirm that the module boundary claim covers the correct algorithm variant and parameter set.

Comparison row 8

Overlap

FIPS 204 ML-DSA

Both algorithms use approved randomness, but not in the same way: ML-DSA draws an approved RBG seed for key generation and may also draw hedged per-signature randomness, while ECDSA requires a fresh per-message secret number and protects it like private key material.

ECDSA under FIPS 186-5

Both algorithms can rely on FIPS-approved module assurance, but the evidence is different: ML-DSA claims should point to the ML-DSA parameter set and CAVP record, while ECDSA claims should point to the curve/domain parameters, the signature method, and the matching validation record.

Operational implication

Both algorithms require an approved RBG for key generation; the main difference is that ML-DSA can use a hedged signing seed, while ECDSA uses a per-message secret number k for each signature.

Comparison row 9

Practical decision rule

FIPS 204 ML-DSA

Choose ML-DSA when the design is intentionally adopting the FIPS 204 post-quantum signature algorithm and can support the chosen parameter set, implementation interface, and validation evidence.

NIST FIPS 204 Module-Lattice-Based Digital Signature StandardSources 1
ECDSA under FIPS 186-5

Choose ECDSA when the design needs a FIPS 186-5 elliptic-curve signature algorithm and can support the required curve/domain parameters, hash choices, key handling, and validation evidence.

NIST FIPS 186-5 Digital Signature StandardSources 1
Operational implication

Do not reduce the choice to post-quantum versus legacy. The defensible decision is the one whose algorithm standard, parameters, implementation, and validation boundary match the actual system claim.

NIST Cryptographic Algorithm Validation ProgramSources 1NIST Cryptographic Module Validation ProgramSources 2
Practical decision rule

Which algorithm standard to apply

  • Choose FIPS 204 ML-DSA when the design or procurement requirement specifically requires a NIST-approved post-quantum digital signature algorithm or lattice-based signing.
  • Choose FIPS 186-5 ECDSA when the controlling protocol profile, existing key infrastructure, or interoperability requirement depends on classical elliptic-curve signing with NIST-approved domain parameters.
  • Do not substitute ML-DSA and ECDSA evidence without verifying that the protocol, key size, parameter set, and CAVP validation record match the specific implementation in scope.
  • Review the algorithm choice after NIST SP 800-131A revisions, module recertification cycles, or protocol deprecation notices that affect either algorithm family.
NIST FIPS 204 Module-Lattice-Based Digital Signature Standard (ML-DSA)Sources 1NIST FIPS 186-5 Digital Signature Standard (DSS)Sources 2
Section 1

What is the direct standards difference?

FIPS 204 is the controlling source when the design claim is ML-DSA. It defines ML-DSA key generation, signature generation, signature verification, and approved parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87.

FIPS 186-5 is the controlling source when the design claim is ECDSA. It specifies ECDSA signature generation and verification, points implementers to SP 800-186 for recommended elliptic curves, and treats deterministic ECDSA as an approved variant.

  • Use FIPS 204 language for ML-DSA parameter-set and function-interface claims.
  • Use FIPS 186-5 language for ECDSA domain parameters, keys, per-message secret numbers, and verification assurances.
  • Do not describe an algorithm as FIPS 140-3 validated; FIPS 140-3 validation applies to cryptographic modules, while algorithm testing is separate evidence.
Sources for this answer
NIST FIPS 204 Module-Lattice-Based Digital Signature Standard
Defines ML-DSA and its approved parameter sets.
NIST FIPS 186-5 Digital Signature Standard
Specifies ECDSA and other approved digital signature algorithms.
NIST FIPS 140-3 security requirements for cryptographic modules
Separates module validation from algorithm-standard conformance.
Section 2

Implementation facts to capture before choosing

For ML-DSA, record the parameter set and whether the design uses the pure or pre-hash form, because FIPS 204 ties API structure, random inputs, and CAVP-oriented testing interfaces to those functions.

For ECDSA, record the curve/domain parameters, hash or XOF choice, key-pair generation method, and per-message secret-number method. FIPS 186-5 requires ECDSA keys to be used only for ECDSA signatures and requires protection of the private key and per-message secret material.

  • ML-DSA-44, ML-DSA-65, and ML-DSA-87 are distinct parameter-set choices, not marketing tiers.
  • ECDSA depends on a specific elliptic-curve domain-parameter set and on approved random generation unless deterministic ECDSA is used.
  • For both algorithms, preserve the claim boundary: algorithm implementation, protocol use, key-management process, certificate profile, and cryptographic module are different review objects.
Sources for this answer
NIST FIPS 204 Module-Lattice-Based Digital Signature Standard
Lists ML-DSA-44, ML-DSA-65, and ML-DSA-87 and describes CAVP-oriented interfaces.
NIST FIPS 186-5 Digital Signature Standard
Defines ECDSA key, domain-parameter, and per-message secret-number requirements.
Section 3

Validation evidence that should not be overstated

CAVP evidence can support a claim that a specific algorithm implementation was tested for conformance to the relevant algorithm standard. It does not by itself prove that a product, service, protocol stack, or deployment boundary is a validated cryptographic module.

CMVP evidence is about a cryptographic module validated to FIPS 140-3 and its approved mode, security policy, certificate scope, and listed algorithm certificates. A customer or independent review should therefore ask for both the algorithm evidence and the module certificate when the public claim depends on validated-module use.

  • Check CAVP entries for the exact algorithm, revision, parameter set or mode, implementation name, vendor, and certificate status.
  • Check CMVP entries for the module name, version, operational environment, security level, approved-mode caveats, and linked algorithm certificates.
  • Write public or customer-facing claims as scoped facts, for example: an implementation has CAVP evidence, or a named module is CMVP validated for a listed configuration.
Sources for this answer
NIST Cryptographic Algorithm Validation Program
Public program source for algorithm validation certificate evidence.
NIST Cryptographic Module Validation Program
Public program source for cryptographic module validation scope.
NIST FIPS 140-3 security requirements for cryptographic modules
Grounds CMVP module validation and approved security-function framing.
Recommended next step

Review ML-DSA and ECDSA claims

Use the comparison to align algorithm choices, parameter records, CAVP evidence, and CMVP module boundaries before publishing or reusing a FIPS claim.

Assessment workflow
Open Assessment Autopilot for FIPS evidence

Convert signature-algorithm claims into scoped evidence requests and review tasks.

Explore next step
Research workflow
Research FIPS source questions

Resolve parameter, validation, and module-boundary questions against cited NIST sources.

Explore next step
Talk to Sorena
Talk through implementation

Review the signature choice, evidence boundary, and customer-facing claim language with Sorena.

Explore next step
Section 4

Review checklist for ML-DSA vs ECDSA

Use the comparison as an implementation review, not as a generic migration scorecard. The review should identify the exact signature function in use and the evidence needed for the claim being made.

  • Name the signing use case: firmware signing, document signing, certificate issuance, protocol authentication, code signing, or another concrete signature flow.
  • Record the controlling standard: FIPS 204 for ML-DSA or FIPS 186-5 for ECDSA.
  • Record ML-DSA parameter set or ECDSA curve/domain parameters, plus hash, XOF, random-bit generation, and key-use assumptions.
  • Check whether CAVP evidence exists for the implementation and whether the evidence matches the claimed algorithm and parameter choices.
  • Check whether the product claim needs a CMVP-validated module and whether the certificate scope covers the shipped version and operating environment.
  • Avoid shortcuts such as calling an algorithm certificate a validated product or treating a legacy ECDSA certificate as evidence for ML-DSA.
Sources for this answer
NIST FIPS 204 Module-Lattice-Based Digital Signature Standard
Grounds ML-DSA parameter and implementation checks.
NIST FIPS 186-5 Digital Signature Standard
Grounds ECDSA parameter, key, and verification checks.
Primary sources

References and citations

NIST FIPS 186-5 Digital Signature Standard (DSS)
nvlpubs.nist.gov
Referenced sections
  • Primary source for ECDSA algorithm specification, domain parameters, key generation, signature generation, and verification under FIPS.
"Digital Signature Standard"
Related guides

Explore more topics

AES FIPS 197 requirements and evidence
AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.
CAVP and ACVP validation evidence for FIPS algorithms
How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.
CAVP Validation Evidence Workflow for FIPS Algorithms
Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records.
FIPS 180-4 and FIPS 202 secure hash guidance
Choose and evidence SHA-2, SHA-3, and SHAKE use under FIPS 180-4, FIPS 202, CAVP validation, and FIPS 140-3 module claims.
FIPS 186-5 and FIPS 204 digital signatures
Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.
FIPS 203 ML-KEM vs RSA and ECDH key establishment
Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding.
FIPS 203, 204, and 205 Post-Quantum Algorithms
FAQ on how FIPS 203 ML-KEM, FIPS 204 ML-DSA, and FIPS 205 SLH-DSA fit FIPS-approved cryptographic algorithm planning, implementation evidence, and validation checks.
FIPS Algorithm Procurement Evidence FAQ
What procurement teams should collect before accepting FIPS algorithm or module claims: CAVP certificates, CMVP module status, security policy scope, and supplier change triggers.
FIPS approved algorithm selector workflow
A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.
FIPS approved mode procurement: certificates, boundaries, and evidence
Procurement guidance for FIPS approved mode claims: how to check CMVP certificates, CAVP evidence, module boundaries, tested environments, and supplier evidence before purchase.
FIPS crypto transition and deprecation tracker
Track FIPS algorithm transitions, withdrawn guidance, CAVP evidence, CMVP module impact, procurement triggers, and approved-mode caveats without overstating validation status.
FIPS cryptographic algorithm selector
Choose between FIPS algorithm standards for AES, SHA-2, SHA-3, digital signatures, ML-KEM, ML-DSA, and SLH-DSA without overstating validation scope.
FIPS KDF and MAC coverage for validated modules
Map FIPS 140-3 KDF and MAC coverage to approved security functions, CAVP evidence, self-tests, service indicators, and module security policy entries.
FIPS Key Management Mapping for Algorithms and SSP Evidence
Map FIPS 140-3 key management requirements to approved algorithms, SSP establishment methods, CAVP evidence, module boundaries, and key-use records.
FIPS Procurement Evidence Review Workflow: CAVP, CMVP, Approved Mode
Review FIPS crypto procurement evidence by separating CAVP algorithm certificates from CMVP module certificates, Security Policy scope, approved mode, operating environment, change impact, and retention records.
FIPS validation certificates for cryptographic algorithms
How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
FIPS-approved cryptographic algorithms FAQ
Answers to common FIPS algorithm questions: approved security functions, CAVP validation, CMVP module scope, AES modes, SHA-2, SHA-3, signatures, and post-quantum algorithms.
How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval
Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.
How FIPS 186-5 Signature Algorithms Fit FIPS Approval
Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.
Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA
A grounded guide to the three NIST post-quantum FIPS standards: when ML-KEM, ML-DSA, and SLH-DSA apply, what evidence to keep, and how CAVP and CMVP claims differ.
Post-Quantum Migration for FIPS Cryptography
Plan post-quantum migration for FIPS cryptography by separating ML-KEM key establishment, ML-DSA and SLH-DSA signatures, CAVP algorithm evidence, and CMVP module validation boundaries.
Post-Quantum Migration Tracker for FIPS 203, 204, and 205
Track post-quantum cryptography migration evidence for FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, CAVP algorithm certificates, and CMVP module boundaries.
SHA-2 vs SHA-3 under FIPS 180-4 and FIPS 202
Compare SHA-2 and SHA-3 for FIPS use: approved functions, validation evidence, compatibility, procurement checks, and when migration is not required.
TLS use-case mapping for FIPS algorithm evidence
Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.
What does FIPS 197 AES mean for FIPS-approved algorithms?
FIPS 197 defines AES as a FIPS-approved block cipher, but AES use alone is not the same as CAVP algorithm testing or FIPS 140-3 module validation.