We use privacy-by-default, cookieless analytics.

Optional analytics cookies are used only if you accept them.

Read our Terms of Use and Privacy Policy.

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.

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

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
6

Cited legal and guidance references.

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

Use this page when a design review must decide whether a use case belongs under the classical algorithms in FIPS 186-5 or the algorithm in FIPS 204. Record the signature purpose, algorithm family, parameters 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 Standard for classical public-key signature systems. It covers signature generation and verification for RSA, ECDSA, and EdDSA. FIPS 186-5 took effect on February 3, 2023; its one-year transition ended on February 3, 2024, when FIPS 186-4 was withdrawn. DSA is no longer approved for signature generation, but it may verify signatures generated before February 3, 2024.

FIPS 204 is a separate post-quantum digital-signature standard for . It became effective on August 13, 2024. 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.

Both standards govern specified US federal signature systems and systems operated for agencies under contract, subject to their stated statutory scope; private and commercial organizations may adopt them voluntarily or by contract. The system owner identifies the governing instrument and signature purpose before the implementer selects an algorithm.

  • Use FIPS 186-5 rows for RSA, ECDSA, and EdDSA signature generation or verification.
  • Use FIPS 204 rows for 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 does not approve DSA for signature generation. It permits DSA verification only for signatures generated before February 3, 2024.
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 -44, ML-DSA-65, or ML-DSA-87; the pure ML-DSA or HashML-DSA variant; context string handling; approved randomness for hedged signing; and the exact public-key and signature length checks implemented by the verifier. FIPS 204 limits the context string to 255 bytes and uses the empty string by default.

  • 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.
  • 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: 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

FIPS 186-5 and FIPS 204 specify signature algorithms; implementation validation has a narrower boundary. FIPS 186-5 states that NIST developed a program to test implementations for conformance. FIPS 204 said NIST would develop an validation program, and current implementation claims should now be checked against the live validation listings and supported-test material rather than that forward-looking statement alone.

For module-level claims, use CMVP evidence separately from 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 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
Records the issued standard's statement that NIST would develop an ML-DSA validation program; current implementation status must be checked in the live CAVP sources.
NIST Cryptographic Algorithm Validation Program
Current official source for algorithm-validation scope, public listing fields, supported algorithm categories, and the Production ACVTS route to a listed validation.
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.

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 , document the approved randomness source for hedged signing or the explicit choice of the deterministic variant.
  • For 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

This template supports 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, , or HashML-DSA

Parameters | Key size, curve, 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 | 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

  • Keep one row per algorithm implementation and use case.
  • Write a gap statement when 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 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

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov
Referenced sections
  • Supports boundary, operational-environment, component-validation, and certificate-evidence fields in the review template.
"validation certificate serves as a benchmark"
NIST CAVP validation search
csrc.nist.gov
Referenced sections
  • Public lookup source for checking algorithm validation records before relying on a certificate number.
"Validation Number"
NIST Cryptographic Algorithm Validation Program
csrc.nist.gov
Referenced sections
  • Current official source for algorithm-validation scope, public listing fields, supported algorithm categories, and the Production ACVTS route to a listed validation.
NIST SP 800-89 digital signature assurances
doi.org
Referenced sections
  • Referenced by FIPS 186-5 and FIPS 204 for assurances beyond the signature algorithm, such as identity and private-key possession.
"Recommendation for Obtaining Assurances for Digital Signature Applications"
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 Algorithm Validation and ACVP Testing
How CAVP algorithm validation, the ACVP protocol, the ACVTS test system, and CMVP module validation fit together without overstating a FIPS claim.
CAVP Validation Evidence Workflow for FIPS Algorithms
Workflow for collecting CAVP validation evidence and ACVP/ACVTS test records: implementation identity, tested parameters, 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 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 evidence.
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 cited 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
Identify SHA-1 and SHA-2 in FIPS 180-4 and SHA-3 and SHAKE in FIPS 202, then check current-use status and CAVP/CMVP evidence separately.
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.
ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5
Compare ML-DSA and ECDSA for FIPS-aligned digital signature designs, including parameter choices, key handling, CAVP algorithm evidence, and CMVP module boundaries.
Post-quantum FIPS 203, 204, and 205: ML-KEM, ML-DSA, and SLH-DSA
An official source 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.