Artifact GuideGLOBALFIPS cryptographic algorithms

FIPS digital signatures FIPS 186-5 and FIPS 204

A focused guide to choosing and evidencing classical and post-quantum FIPS digital-signature algorithms without overstating implementation validation.

Grounded in NIST FIPS 186-5, NIST FIPS 204, CMVP implementation guidance, and public CAVP lookup sources.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

May 9, 2026

Sections

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated May 9, 2026

Overview

Use this page when a design review needs to decide whether a signature use case belongs under FIPS 186-5 classical signature algorithms or FIPS 204 ML-DSA. The useful output is a narrow record: signature purpose, algorithm family, parameter or key choices, approved supporting functions, key-use limits, implementation evidence, and any gap between algorithm approval and product or module validation.

Section 1

Separate the classical and post-quantum signature standards

FIPS 186-5 is the Digital Signature Standard for classical public-key signature systems. It covers signature generation and verification for algorithms such as RSA, ECDSA, and EdDSA, and it superseded FIPS 186-4 after the transition period described in the standard.

FIPS 204 is a separate post-quantum digital-signature standard for ML-DSA. It says ML-DSA can be used in place of other digital-signature schemes specified in NIST FIPS publications and Special Publications, including FIPS 186-5, but it does not make every existing signature protocol or product automatically validated.

Use FIPS 186-5 rows for RSA, ECDSA, and EdDSA signature generation or verification.
Use FIPS 204 rows for ML-DSA key generation, signing, verification, and HashML-DSA variants.
Record whether the use case is signing, verification, certificate validation, software update signing, document signing, or protocol authentication.
Keep DSA separate: FIPS 186-5 no longer approves DSA for digital-signature generation, though it allows verification of signatures generated before the implementation date.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports the FIPS 186-5 scope, federal applicability, FIPS 186-4 transition, RSA/ECDSA/EdDSA context, and DSA generation limit.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports ML-DSA as the FIPS 204 post-quantum digital-signature scheme and its relationship to FIPS 186-5.

Section 2

Record the signature decision fields

A signature decision is incomplete if it only names a standard. For FIPS 186-5, capture the algorithm family, key size or curve, hash or XOF dependency, key-pair generation method, public-key assurance, private-key possession evidence, and whether the module performs the whole operation or a tested component such as a signature primitive.

For FIPS 204, capture the ML-DSA parameter set, pure ML-DSA or HashML-DSA variant, context string handling, approved randomness source for hedged signing, and the exact public-key and signature length checks implemented by the verifier.

Classical field set: RSA, ECDSA, or EdDSA; key size or curve; hash or XOF; key-generation source; sign and verify operations; and certificate or module boundary.
ML-DSA field set: parameter set, key-generation path, pure or pre-hash variant, context string, hedged or deterministic signing behavior, and verification input checks.
Assurance field set: public-key validity, identity binding, private-key possession, and any relying-party or PKI process outside the algorithm itself.
Evidence field set: CAVP certificate when available, CMVP module certificate when relevant, Security Policy service name, tested operational environment, and unresolved gap statement.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports approved hash dependencies, key-pair use limits, and the distinction between mathematical verification and broader signature validation assurances.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports the ML-DSA parameter-set, signing, verification, HashML-DSA, randomness, and input-length review fields.

NIST SP 800-89 digital signature assurances

Referenced by FIPS 186-5 and FIPS 204 for assurances beyond the signature algorithm, such as identity and private-key possession.

Section 3

Use validation evidence without turning it into a product claim

NIST standards approve algorithms; validation evidence has a narrower boundary. FIPS 186-5 states that NIST has developed a validation program to test implementations for conformance to the algorithms in the standard. FIPS 204 states that NIST will develop a validation program for the ML-DSA algorithm.

For module-level claims, use CMVP evidence separately from CAVP evidence. The FIPS 140-3 implementation guidance says a CAVP algorithm certificate states the algorithm implementation name, version, and tested operational environment, while a CMVP certificate states the validated cryptographic module name, version, and tested operational environment.

Do not call a product FIPS 140-3 validated only because its signature algorithm appears in a FIPS standard.
Do not reuse an algorithm certificate across a different operating system, processor size, accelerator path, module boundary, or library version without matching evidence.
For FIPS 186-5 component validation, distinguish full signature generation from RSASP1 or ECDSA component tests that assume a precomputed digest.
For FIPS 204, record whether ML-DSA validation evidence exists for the implementation before using certificate language in customer or audit material.

Sources for this answer

CMVP Implementation Guidance for FIPS 140-3

Supports the difference between CAVP algorithm certificates, CMVP module certificates, tested operational environments, and component validation restrictions.

NIST CAVP validation search

Public lookup source for checking algorithm validation records before relying on a certificate number.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports treating ML-DSA validation as implementation evidence that must be checked separately from algorithm approval.

Recommended next step

Build a FIPS signature decision record

Use the FIPS 186-5 or FIPS 204 decision to assign owners, request validation evidence, document key-use limits, and keep signature claims aligned with module boundaries.

Assessment workflow

Open Assessment Autopilot for signature evidence

Convert signature decisions into owners, evidence requests, validation gaps, and release review checkpoints.

Explore next step

Research workflow

Research FIPS signature source questions

Use official NIST material to resolve algorithm, parameter-set, assurance, and validation-evidence questions.

Explore next step

Talk to Sorena

Talk through FIPS 186-5 and FIPS 204 signatures

Review signature scope, algorithm choices, key-use limits, validation evidence, and post-quantum migration caveats with Sorena.

Explore next step

Section 4

Check key use, hash use, and malformed input handling

The highest-risk implementation errors are usually around use boundaries. FIPS 186-5 advises that digital-signature key pairs shall not be used for other purposes, and the FIPS 140-3 implementation guidance gives an RSA example where a non-approved signature algorithm sharing the same key as an approved RSA signature algorithm is prohibited.

ML-DSA has different implementation checks from RSA or ECDSA. FIPS 204 describes hedged signing by default, an optional deterministic variant, public-key and signature length checks, and verification behavior that returns false when public-key or signature lengths differ from the specified lengths.

Keep signing keys dedicated to signature use and document any rejected attempt to reuse them for key establishment, encryption, or non-approved signature services.
For FIPS 186-5, verify that the hash function or XOF used with the signature algorithm is approved for the use case.
For ML-DSA, document the approved randomness source for hedged signing or the explicit choice of the deterministic variant.
For ML-DSA verification, test malformed public-key and signature encodings and length mismatches as negative cases.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports dedicated digital-signature key-pair use and approved hash-function dependencies.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports ML-DSA hedged signing, deterministic signing, verification input checks, and malformed input handling.

CMVP Implementation Guidance for FIPS 140-3

Supports the warning that non-approved algorithms must not share keys or CSPs used by approved signature algorithms.

Section 5

Signature review template

Use this template for each signature use case instead of writing a broad assurance statement.

Use case | Required entry

Signature service | Generation, verification, validation, certificate issuance, software signing, document signing, protocol authentication, or stored-data integrity

Standard | FIPS 186-5 or FIPS 204

Algorithm | RSA, ECDSA, EdDSA, ML-DSA, or HashML-DSA

Parameters | Key size, curve, ML-DSA parameter set, hash or XOF, context string, and randomness mode

Key-use rule | Dedicated signature key, owner, storage boundary, and prohibited reuse

Assurance path | Public-key validity, identity binding, private-key possession, certificate or relying-party checks

Evidence | CAVP record, CMVP certificate and Security Policy if applicable, test output, negative tests, or explicit validation gap

Allowed wording | The exact internal or external claim, with boundary and caveat

Use one row per algorithm implementation and use case.
Write a gap statement when CAVP or CMVP evidence is unavailable rather than weakening language to imply validation.
Reopen the record after changes to algorithm parameters, signing library, platform, processor, accelerator, module boundary, certificate status, or signature protocol.
Keep post-quantum migration notes in the ML-DSA row; do not treat ML-DSA as a drop-in claim until the protocol, key formats, relying parties, and validation evidence are reviewed.

Sources for this answer

NIST FIPS 186-5 Digital Signature Standard

Supports using FIPS 186-5 as the source for classical signature algorithm and key-use decisions.

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard

Supports recording ML-DSA parameter, variant, verification, and migration decisions separately from FIPS 186-5 rows.

CMVP Implementation Guidance for FIPS 140-3

Supports boundary, operational-environment, component-validation, and certificate-evidence fields in the review template.

Primary sources