Choose when the system is adopting the post-quantum signature algorithm in FIPS 204 and can support its larger keys and signatures, protocol identifiers, and validation path. Choose ECDSA when the controlling protocol or public-key infrastructure requires the elliptic-curve signature algorithm in FIPS 186-5. If pre-hashing is required, distinguish from pure ML-DSA; if predictable per-message secret generation is required, distinguish from randomized ECDSA. In every case, record the parameter set or curve, signature interface, implementation evidence, and FIPS 140-3 module boundary separately.
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 and ECDSA.
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.
FIPS 204 applies to federal signature systems operated by agencies or for them under contract when is selected. Private and commercial organizations may also adopt it.
FIPS 186-5 applies to federal signature systems operated by agencies or for them under contract when ECDSA is selected. Private and commercial organizations may also adopt it.
The standards identify approved algorithms; an agency requirement, contract, protocol profile, or risk decision determines which algorithm a particular system must use.
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 implementations should record the curve/domain parameters, hash or XOF, key-size security strength, and whether the signature process is randomized or deterministic.
Record the system requirement that drives the choice. Both algorithms are FIPS-approved signature options, while only is designed around a post-quantum security assumption.
key generation requires a fresh 256-bit seed from an approved RBG. The RBG must provide at least 128, 192, or 256 bits of security strength for ML-DSA-44, ML-DSA-65, or ML-DSA-87 respectively, with FIPS 204 recommending 192 bits for ML-DSA-44 to retain its category 2 claim.
ECDSA requires approved key generation and protection of the private key. Randomized ECDSA requires a new protected per-message secret number for every signature; derives that number from the message hash and private key through the specified HMAC_DRBG process.
Map every random input and secret to its generator, required strength, storage rule, and zeroization path. Do not assume deterministic signing removes the random-number requirement from key generation.
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.
FIPS 186-5 specifies and approves ECDSA, but it does not set a general ECDSA withdrawal date. Any migration schedule must be tied to later NIST transition guidance, an applicable system requirement, or a documented risk decision.
Treat FIPS 204 publication and matching CAVP evidence as separate facts; do not infer a universal ECDSA replacement date from either FIPS 204 or FIPS 186-5.
An 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.
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.
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.
Both algorithms use approved randomness for key generation, but their signing dependencies differ: may draw hedged per-signature randomness, randomized ECDSA draws a per-message secret number from an approved RBG, and derives that number from the message hash and private key.
Both algorithms can rely on FIPS-approved module assurance, but the evidence is different: 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.
Both algorithms require an approved RBG for key generation. can use a fresh hedging value for signing, while ECDSA uses a per-message secret number k generated either randomly or through the deterministic process.
Choose 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.
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.
Choose the algorithm whose standard, parameters, implementation, protocol support, and validation boundary match the actual system claim. A post-quantum-versus-legacy label does not establish those facts.
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.
FIPS 204 applies to federal signature systems operated by agencies or for them under contract when is selected. Private and commercial organizations may also adopt it.
ECDSA under FIPS 186-5
FIPS 186-5 applies to federal signature systems operated by agencies or for them under contract when ECDSA is selected. Private and commercial organizations may also adopt it.
Operational implication
The standards identify approved algorithms; an agency requirement, contract, protocol profile, or risk decision determines which algorithm a particular system must use.
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 the system requirement that drives the choice. Both algorithms are FIPS-approved signature options, while only is designed around a post-quantum security assumption.
key generation requires a fresh 256-bit seed from an approved RBG. The RBG must provide at least 128, 192, or 256 bits of security strength for ML-DSA-44, ML-DSA-65, or ML-DSA-87 respectively, with FIPS 204 recommending 192 bits for ML-DSA-44 to retain its category 2 claim.
ECDSA under FIPS 186-5
ECDSA requires approved key generation and protection of the private key. Randomized ECDSA requires a new protected per-message secret number for every signature; derives that number from the message hash and private key through the specified HMAC_DRBG process.
Operational implication
Map every random input and secret to its generator, required strength, storage rule, and zeroization path. Do not assume deterministic signing removes the random-number requirement from key generation.
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
FIPS 186-5 specifies and approves ECDSA, but it does not set a general ECDSA withdrawal date. Any migration schedule must be tied to later NIST transition guidance, an applicable system requirement, or a documented risk decision.
Operational implication
Treat FIPS 204 publication and matching CAVP evidence as separate facts; do not infer a universal ECDSA replacement date from either FIPS 204 or FIPS 186-5.
An 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.
Both algorithms use approved randomness for key generation, but their signing dependencies differ: may draw hedged per-signature randomness, randomized ECDSA draws a per-message secret number from an approved RBG, and derives that number from the message hash and private key.
ECDSA under FIPS 186-5
Both algorithms can rely on FIPS-approved module assurance, but the evidence is different: 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. can use a fresh hedging value for signing, while ECDSA uses a per-message secret number k generated either randomly or through the deterministic process.
Choose 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.
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.
Choose the algorithm whose standard, parameters, implementation, protocol support, and validation boundary match the actual system claim. A post-quantum-versus-legacy label does not establish those facts.
Choose FIPS 204 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 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 applicable NIST transition guidance, module revalidation cycles, or protocol changes affect either algorithm family; do not infer a withdrawal date from FIPS 204 alone.
FIPS 204 controls an algorithm claim. It defines key generation, signature generation, signature verification, and three approved parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87. Their claimed NIST security categories are 2, 3, and 5 respectively; those categories are not direct bit-security measurements.
FIPS 186-5 controls an ECDSA algorithm claim. It specifies randomized and signature generation and verification, points to SP 800-186 for recommended elliptic curves, and requires the hash or XOF strength and the strength associated with the curve order to meet the required signature-process strength.
Use FIPS 204 language for 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.
For , record the parameter set, whether the design uses ML-DSA or , whether signing is hedged or deterministic, and any context string. FIPS 204 limits the context string to 255 bytes. It generally prefers pure ML-DSA and recommends that a key pair be used for only one of ML-DSA or HashML-DSA.
For ECDSA, record the curve and domain parameters, hash or XOF, key-pair generation method, and per-message secret-number method. FIPS 186-5 requires ECDSA keys to be used only for ECDSA signatures. For randomized ECDSA, a new secret number k is generated for every signature; k, its inverse, and the private key must be protected from disclosure and modification.
-44, ML-DSA-65, and ML-DSA-87 have public-key sizes of 1,312, 1,952, and 2,592 bytes and signature sizes of 2,420, 3,309, and 4,627 bytes respectively; test protocol and storage limits with the selected set.
ECDSA depends on a specific elliptic-curve domain-parameter set and approved key generation. Randomized ECDSA also needs approved per-message random generation; derives k through the specified process.
For both algorithms, preserve the claim boundary: algorithm implementation, protocol use, key-management process, certificate profile, and cryptographic module are different review objects.
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.
Use the comparison to review an implementation and its migration evidence. 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 or FIPS 186-5 for ECDSA.
Record 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 .