FAQGLOBALFIPS 186-5 signature evidence

FIPS 186-5 digital signatures How should teams use them in FIPS-approved algorithm decisions?

Q: Which signature algorithms does FIPS 186-5 support?

Use FIPS 186-5 when the decision is about digital signature generation or verification for RSA, ECDSA, deterministic ECDSA, EdDSA, or HashEdDSA. FIPS 186-5 became effective on February 3, 2023; its one-year transition ended when FIPS 186-4 was withdrawn on February 3, 2024. DSA is no longer approved for digital signature generation, although DSA may be used to verify signatures generated before the FIPS 186-5 implementation date. NIST has posted potential-update errata for FIPS 186-5, so implementation reviews should use the issued standard together with the current errata. The selection record should name the exact signature family, operation, parameters, key purpose, and approved hash or XOF relationship. For RSA, FIPS 186-5 permits signature generation or verification with modulus sizes at least 2048 bits, while CMVP implementation guidance explains how CAVP testing and Security Policy documentation handle sizes where CAVP testing is or is not available. Record whether the service performs signature generation, signature verification, or both. Separate RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, and legacy DSA verification decisions; do not collapse them into a generic signature claim. For RSA, document the modulus length, scheme such as RSASSA-PSS or RSASSA-PKCS1-v1.5, approved hash or XOF choice, and whether key generation is performed by the module.

Q: What FIPS 186-5 signature mistakes should teams avoid?

Do not reuse signature keys. FIPS 186-5 says digital signature key pairs must not be used for other purposes such as key establishment, and it repeats that RSA and ECDSA signature keys are signature-only. A key inventory should therefore show a signature-only purpose rather than a shared public-key bucket. Successful signature verification is not the whole validation decision. For ECDSA and EdDSA, verifiers also need domain-parameter assurance; verifiers need public-key validity, claimed-signatory identity, and possession assurance before accepting a signature as valid. Conformance to FIPS 186-5 also does not guarantee system security; the standard leaves implementation security and overall system assurance to the responsible implementer or authority. Do not use a signature key pair for key establishment, encryption, or other non-signature purposes. Do not claim DSA signature generation as approved under FIPS 186-5; limit DSA to the legacy verification context supported by the standard. Do not reuse a CAVP certificate across a different implementation, version, operating environment, parameter set, or module boundary without confirming the scope.

Use FIPS 186-5 to select and evidence approved signature algorithms, then keep the algorithm, key-use, operating-environment, and module-validation claims separate.

This FAQ focuses on RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification, CAVP certificates, and CMVP module boundaries.

Back to main artifact Review sources

Author

Sorena AI

Published

May 9, 2026

Updated

Jul 25, 2026

Questions

Structured answer sets in this page tree.

Primary sources

Cited legal and guidance references.

Publication metadata

Sorena AI

Published May 9, 2026

Updated Jul 25, 2026

Overview

Short answer: FIPS 186-5 is the standard for approved RSA, ECDSA, , EdDSA, and HashEdDSA use. It does not make every product using those names validated; teams still need implementation-specific evidence and, for FIPS 140-3 claims, module evidence.

Search this module

Find a question or answer quickly

3 of 3 questions

Question 1

Which signature algorithms does FIPS 186-5 support?

Use FIPS 186-5 when the decision is about generation or verification for RSA, ECDSA, , EdDSA, or HashEdDSA. FIPS 186-5 became effective on February 3, 2023; its one-year transition ended when FIPS 186-4 was withdrawn on February 3, 2024. is no longer approved for digital signature generation, although DSA may be used to verify signatures generated before the FIPS 186-5 implementation date. NIST has posted potential-update errata for FIPS 186-5, so implementation reviews should use the issued standard together with the current errata.

The selection record should name the exact signature family, operation, parameters, key purpose, and approved hash or XOF relationship. For RSA, FIPS 186-5 permits signature generation or verification with modulus sizes at least 2048 bits, while implementation guidance explains how testing and Security Policy documentation handle sizes where CAVP testing is or is not available.

Record whether the service performs signature generation, signature verification, or both.
Separate RSA, ECDSA, , EdDSA, HashEdDSA, and legacy verification decisions; do not collapse them into a generic signature claim.
For RSA, document the modulus length, scheme such as RSASSA-PSS or RSASSA-PKCS1-v1.5, approved hash or XOF choice, and whether key generation is performed by the module.

Citations

NIST FIPS 186-5 Digital Signature Standard

Defines the approved digital signature standard and states that DSA is no longer approved for signature generation.

NIST FIPS 186-5 publication and potential-update errata

Official publication status and potential-update errata for the issued FIPS 186-5 standard.

NIST FIPS 140-3 Implementation Guidance

Clarifies RSA signature parameter sizes, CAVP testing expectations, and Security Policy documentation for FIPS 140-3 module submissions.

Question 2

What evidence should support a FIPS 186-5 signature claim?

A useful evidence package starts with the standard citation but does not stop there. Keep the FIPS 186-5 algorithm decision, the algorithm-validation record, and the module claim as separate records that are linked only when the implementation name, version, parameters, and operating environment match.

For a check, capture the implementation name and version, vendor, certificate or validation-search entry, algorithm and mode, parameter set or modulus size, and tested operating environment. For a check, tie the signature service to the cryptographic module boundary, approved-mode service list, Security Policy, and any bound or embedded module caveats.

Use evidence to support the tested algorithm implementation, not to claim that the whole product or module is FIPS 140-3 validated.
Use evidence to support module validation, approved-mode operation, module boundary, and approved-service claims.
Refresh the evidence when the implementation version, operating environment, module boundary, processor acceleration path, key-generation path, or approved-service listing changes.

Citations

NIST CAVP validation search

Public search source for checking algorithm validation entries for signature implementations, modes, parameters, and environments.

NIST Cryptographic Module Validation Program

Program source for cryptographic module validation, which is distinct from algorithm implementation testing.

NIST FIPS 140-3 Implementation Guidance

Explains that CAVP algorithm certificates identify implementation details and tested operational environments for module submissions.

Recommended next step

Separate algorithm selection, CAVP evidence, and CMVP module claims

This FAQ helps review signature algorithm choices, key-use boundaries, operating environments, approved-mode services, and validation evidence before relying on a FIPS claim.

Assessment workflow

Check the signature boundary

Review whether signature algorithms, keys, parameters, and module claims point to the right validation records.

Explore next step

Research workflow

Resolve a scoped FIPS question

Compare FIPS 186-5 requirements, CAVP evidence, and CMVP evidence when a signature claim depends on implementation details.

Explore next step

Talk to Sorena

Talk through implementation

Review the product boundary, signature services, operating environment, and validation evidence in scope.

Explore next step

Question 3

What FIPS 186-5 signature mistakes should teams avoid?

Do not reuse signature keys. FIPS 186-5 says key pairs must not be used for other purposes such as key establishment, and it repeats that RSA and ECDSA signature keys are signature-only. A key inventory should therefore show a signature-only purpose rather than a shared public-key bucket.

Successful signature verification is not the whole validation decision. For ECDSA and EdDSA, verifiers also need domain-parameter assurance; verifiers need public-key validity, claimed-signatory identity, and possession assurance before accepting a signature as valid. Conformance to FIPS 186-5 also does not guarantee system security; the standard leaves implementation security and overall system assurance to the responsible implementer or authority.

Do not use a signature key pair for key establishment, encryption, or other non-signature purposes.
Do not claim signature generation as approved under FIPS 186-5; limit DSA to the legacy verification context supported by the standard.
Do not reuse a certificate across a different implementation, version, operating environment, parameter set, or module boundary without confirming the scope.

Citations

NIST FIPS 186-5 Digital Signature Standard

Supports key-purpose separation, assurance checks before accepting signatures as valid, and the limits of conformance claims.

NIST FIPS 140-3 Implementation Guidance

Clarifies that approved-service indicators may depend on the signature algorithm, hash algorithm, and key size used by the service.

Primary sources