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 lookup sources.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections6 primary sources
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.
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.
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.
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.
Section 5

Signature review template

This template supports each signature use case instead of writing a broad assurance statement.

  • 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 record 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.
Primary sources

References and citations

NIST FIPS 204 Module-Lattice-Based Digital Signature Standard
doi.org6 citations
Referenced sections
  • Primary source for ML-DSA, parameter sets, pure and pre-hash variants, hedged signing, verification checks, and post-quantum signature positioning.
  • Supports ML-DSA as the FIPS 204 post-quantum digital-signature scheme and its relationship to FIPS 186-5.
  • Supports the ML-DSA parameter-set, signing, verification, HashML-DSA, randomness, and input-length review fields.
Show 3 more
  • 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.
  • Supports ML-DSA hedged signing, deterministic signing, verification input checks, and malformed input handling.
  • Supports recording ML-DSA parameter, variant, verification, and migration decisions separately from FIPS 186-5 rows.
"Module-Lattice-Based Digital Signature Standard"
More quoted passages
"ML-DSA can be used in place of other digital signature schemes"
"This standard specifies several parameter sets for ML-DSA"
"NIST will develop a validation program"
"shall return false whenever the length"
"ML-DSA is believed to be secure"
NIST FIPS 186-5 Digital Signature Standard
doi.org5 citations
Referenced sections
  • Primary source for FIPS 186-5 classical signature scope, RSA/ECDSA/EdDSA decisions, approved supporting functions, DSA transition limits, and digital-signature key-use restrictions.
  • Supports the FIPS 186-5 scope, federal applicability, FIPS 186-4 transition, RSA/ECDSA/EdDSA context, and DSA generation limit.
  • Supports approved hash dependencies, key-pair use limits, and the distinction between mathematical verification and broader signature validation assurances.
Show 2 more
  • Supports dedicated digital-signature key-pair use and approved hash-function dependencies.
  • Supports using FIPS 186-5 as the source for classical signature algorithm and key-use decisions.
"Digital Signature Standard"
More quoted passages
"This standard specifies a suite of algorithms"
"Agencies are advised that digital signature key pairs shall not be used for other purposes."
"shall employ cryptographic algorithms"
"Signature generation uses a private key"
CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov4 citations
Referenced sections
  • Program guidance for separating CAVP algorithm certificates from CMVP module certificates, matching tested operational environments, and limiting component-validation claims.
  • Supports the difference between CAVP algorithm certificates, CMVP module certificates, tested operational environments, and component validation restrictions.
  • Supports the warning that non-approved algorithms must not share keys or CSPs used by approved signature algorithms.
Show 1 more
  • Supports boundary, operational-environment, component-validation, and certificate-evidence fields in the review template.
"Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program (CAVP)."
More quoted passages
"Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program"
"shall not share the same key or CSP"
"validation certificate serves as a benchmark"
NIST CAVP validation search
csrc.nist.gov2 citations
Referenced sections
  • Public lookup source for checking algorithm validation records before making implementation-specific certificate claims.
  • Public lookup source for checking algorithm validation records before relying on a certificate number.
"Validation Number"
NIST SP 800-89 digital signature assurances
doi.org2 citations
Referenced sections
  • Referenced assurance source for identity, public-key validity, and private-key possession questions that sit outside the signature algorithm math.
  • 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"
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.

Related guides

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

Show all related guides (25)

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

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.

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 validation certificates for cryptographic algorithms

How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.

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.

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.