Artifact GuideGLOBALSecure hash evidence

FIPS 180-4 and FIPS 202 secure hash guidance

A practical guide for selecting SHA-2, SHA-3, or SHAKE functions and keeping the evidence clean for CAVP, ACVP, and FIPS 140-3 reviews.

Use it to separate algorithm conformance from module validation, protocol requirements, procurement wording, and internal migration policy.

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, validation package, procurement clause, or customer assurance request asks which FIPS secure hash algorithm is being used and how that claim is evidenced. FIPS 180-4 covers SHA-1 and the SHA-2 family, while FIPS 202 adds SHA-3 hash functions and SHAKE extendable-output functions. The implementation decision is not complete until the team can show the algorithm, parameters, tested implementation, operational environment, consuming protocol, and module boundary behind the claim.

Section 1

Start with the hash function family and use case

Treat the page title as a selection problem, not a blanket approval statement. FIPS 180-4 specifies SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. FIPS 202 specifies SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256.

For new designs, record the consuming use case before selecting the primitive. A hash used inside a digital signature, HMAC, KDF, pseudorandom bit generation process, firmware integrity check, certificate profile, or protocol transcript may inherit extra requirements from that higher-level standard. A FIPS-listed hash alone does not prove the surrounding product or protocol is approved.

Use FIPS 180-4 when the requirement calls for SHA-2 or an existing SHA-1/SHA-2 interface that must be evidenced against the Secure Hash Standard.
Use FIPS 202 when the design needs SHA-3 family diversity, SHA3 fixed-length hashes, or SHAKE output that is explicitly allowed by the consuming NIST publication or protocol.
Avoid treating SHAKE128 or SHAKE256 as ordinary hash-function drop-ins. FIPS 202 approves them as XOFs and says approved uses are specified in NIST Special Publications.
If SHA-1 remains in scope, document the exact legacy dependency and the external rule that still permits it. Do not let a FIPS 180-4 citation become a default approval for new collision-sensitive designs.

Sources for this answer

NIST FIPS 180-4 Secure Hash Standard

Identifies the SHA-1 and SHA-2 algorithms covered by the Secure Hash Standard.

NIST FIPS 202 SHA-3 Standard

Identifies SHA-3 hash functions and SHAKE extendable-output functions.

Section 2

Keep algorithm validation separate from module validation

For assurance and procurement, split the claim into two layers. The hash algorithm implementation can have CAVP or ACVP evidence, but the cryptographic module that exposes the service is validated under CMVP to FIPS 140-3. A supplier should not use an algorithm certificate by itself as proof that the product, module boundary, operational environment, or approved mode is validated.

The evidence package should name the algorithm certificate, implementation version, tested operational environment, module certificate, approved service, and the exact product build that consumes the hash. If the algorithm implementation changes during integration, or if the operational environment differs from the tested environment, the existing algorithm evidence may not carry forward without retesting or validation review.

Record CAVP or ACVP evidence for the actual SHA-2, SHA-3, or SHAKE implementation and parameter set used by the release.
Record CMVP evidence separately for the FIPS 140-3 module, including certificate number, module version, tested operating environment, approved mode, and Security Policy reference.
Check whether the hash operation is provided by the module itself, a bound module, or an embedded validated module, because the boundary changes what can be claimed.
Do not write procurement language that says a product is FIPS validated when only an algorithm implementation has been tested.

Sources for this answer

NIST FIPS 140-3 Implementation Guidance

Grounding for distinguishing CAVP algorithm certificates from CMVP module certificates and tested operational environments.

NIST FIPS 140-3 security requirements for cryptographic modules

Grounding for FIPS 140-3 as the module-security standard, not a standalone hash algorithm certificate.

Section 3

Decision checklist for SHA-2, SHA-3, and SHAKE

The practical choice is usually driven by the consuming standard and the assurance story. SHA-256 and SHA-384 often appear because protocols and signature schemes already specify them. SHA-3 may be a better fit when the design needs NIST-approved hash diversity based on different design principles. SHAKE is useful only when a variable-length output is allowed and the caller fixes the output length and security target.

Write the decision record so a reviewer can reproduce the reasoning without hidden context. The record should state the function name, digest or output length, input domain, consuming construction, security-strength target, validation evidence, and migration trigger.

For digital signatures, record the signature standard or certificate profile that constrains the hash choice and digest length.
For HMAC, record the selected hash function and confirm whether the consuming implementation has the required validation evidence.
For KDF or pseudorandom bit generation use, cite the higher-level NIST publication or protocol that permits the selected SHA-2, SHA-3, or SHAKE construction.
For file, firmware, or software integrity checks, tie the hash to the FIPS 140-3 service and avoid implying that a bare digest proves authenticity without a validated signature, MAC, or approved integrity mechanism where one is required.

Sources for this answer

NIST FIPS 180-4 Secure Hash Standard

Supports SHA-2 family digest lengths and the use of secure hashes with signatures, MACs, and random bit generation.

NIST FIPS 202 SHA-3 Standard

Supports SHA-3 as a supplement to SHA-1 and SHA-2, and SHAKE as an extendable-output function.

Recommended next step

Operationalize FIPS 180-4 and FIPS 202 decisions

Use the hash selection, validation, module-boundary, and change-control notes as a shared evidence checklist before publishing a FIPS claim.

Assessment workflow

Open Assessment Autopilot for FIPS hash evidence

Convert SHA-2, SHA-3, and SHAKE decisions into accountable evidence tasks and review checkpoints.

Explore next step

Research workflow

Research FIPS source questions

Resolve hash-family, CAVP, ACVP, and FIPS 140-3 boundary questions before implementation.

Explore next step

Talk to Sorena

Talk through FIPS hash implementation

Review the selected hash functions, validation evidence, module boundaries, and change triggers with Sorena.

Explore next step

Section 4

Evidence to keep with the implementation

A useful hash evidence pack is more than a source citation. It should connect the standard to the actual implementation, validation certificate, module boundary, service name, and change-control record. This is what prevents an auditor or customer from having to guess whether the hash claim applies to the shipped build.

For FIPS 140-3 contexts, the evidence should also show whether the service runs in approved mode and whether the module Security Policy lists the hash algorithm or integrity mechanism in the relevant service table. If the hash comes through a bound or embedded module, keep the referenced module name, certificate number, version, and used functionality explicit.

Algorithm evidence: CAVP or ACVP certificate identifier, implementation name, implementation version, tested operating environment, and algorithm mode or parameter set.
Module evidence: CMVP certificate, module version, Security Policy, approved-service mapping, and operational environment.
Design evidence: why SHA-2, SHA-3, or SHAKE was selected, which output length is used, and which consuming protocol or construction requires it.
Change evidence: trigger retesting or review when the hash implementation, compiler, processor, operating environment, cryptographic boundary, or consuming protocol changes.

Sources for this answer

NIST FIPS 140-3 Implementation Guidance

Supports evidence requirements for algorithm certificate binding, implementation version, and operational environment.

NIST FIPS 140-3 security requirements for cryptographic modules

Supports approved security functions and the module-level assurance boundary.

Section 5

Common mistakes in secure hash claims

Most hash mistakes are evidence mistakes: the implementation may use a NIST-standardized primitive, but the public claim overstates what was validated. Keep the wording narrow enough that it survives procurement review, FIPS 140-3 validation review, and later migration work.

Do not say SHA-3 is a mandatory replacement for SHA-2. FIPS 202 says SHA-3 supplements the FIPS 180-4 hash functions and provides design diversity.
Do not call SHAKE128 or SHAKE256 a hash function in approval language. Treat them as XOFs and cite the higher-level rule that permits the intended use.
Do not use a CAVP certificate from one operating environment to support a different module environment without checking the FIPS 140-3 binding rules.
Do not hide SHA-1 behind a generic Secure Hash Standard reference; name the function and the legacy or protocol reason it remains present.
Do not imply that hashing alone provides authenticity. Pair integrity claims with the signature, MAC, approved integrity technique, or module service that actually provides the assurance.

Sources for this answer

NIST FIPS 202 SHA-3 Standard

Supports the distinction between SHA-3 hash functions and SHAKE XOF approval language.

NIST FIPS 140-3 Implementation Guidance

Supports caution around operational environment and algorithm-certificate binding.

Primary sources