A grounded comparison for choosing, procuring, and evidencing SHA-2 and SHA-3 hash functions in FIPS-sensitive systems.
Use it to separate algorithm approval, CAVP evidence, protocol compatibility, and FIPS 140-3 module claims.
Structured answer sets in this page tree.
Cited legal and guidance references.
SHA-2 and SHA-3 are both NIST-standardized hash families, but they are not interchangeable labels. FIPS 180-4 defines SHA-1 and the SHA-2 family, while FIPS 202 defines SHA-3 hash functions and SHAKE extendable-output functions. For real programs, the decision is usually less about which family is newer and more about which function the protocol, product boundary, customer requirement, or validation evidence actually supports.
Use this comparison to decide whether the work is algorithm selection, validation evidence, protocol compatibility, procurement wording, or FIPS 140-3 module assurance.
Use FIPS 180-4 for SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256 decisions, while handling SHA-1 as a legacy-sensitive case.
Use FIPS 202 for SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, and SHAKE256 decisions.
| Dimension | FIPS 180-4 SHA-2 | FIPS 202 SHA-3 | Operational implication |
|---|---|---|---|
| Function scope | FIPS 180-4 defines SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. | FIPS 202 defines SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus SHAKE128 and SHAKE256 extendable-output functions. | Do not compare only the family names. Record the exact function and output length before making a design, validation, or procurement claim. |
| Covered actors | Federal agencies, contractors, and cryptographic module vendors selecting SHA-2 family functions under FIPS 180-4 for digital signatures, HMACs, key derivation, or other secure-hash use cases requiring NIST-approved algorithms. | Federal agencies, contractors, and module vendors selecting SHA-3 or SHAKE functions under FIPS 202 for designs where a SHA-3 or extendable-output function is required by a protocol, procurement specification, or NIST guidance document. | Map the actor role to the algorithm family: SHA-2 actors satisfy FIPS 180-4; SHA-3/SHAKE actors satisfy FIPS 202; both may appear in the same module. |
| Trigger | SHA-2 is still common where TLS profiles, digital signatures, certificate ecosystems, firmware tooling, or customer controls name SHA-256 or SHA-384. | SHA-3 or SHAKE fits better where a new design, protocol, or standard explicitly allows FIPS 202 functions and validated implementations are available. | Use SHA-2 where protocol profiles, certificate ecosystems, or firmware require it; switch to SHA-3 only when the standard or design explicitly allows FIPS 202. |
| Core obligations | FIPS 180-4 can satisfy the secure-hash requirement for Federal applications when a FIPS 180-4 function is the appropriate function. | FIPS 202 can satisfy the same secure-hash requirement when a SHA-3 or SHAKE function is appropriate. | Confirm that the selected function is approved for the use case; SHA-2 and SHA-3 are both approved but interoperability constraints may limit substitution. |
| Evidence | A SHA-2 implementation claim should point to NIST validation evidence for the tested implementation, not only to FIPS 180-4. | A SHA-3 or SHAKE implementation claim should point to CAVP validation evidence for the tested function implementation, not only to FIPS 202. | Point to the CAVP validation record for the specific function and implementation; SHA-2 and SHA-3 records are separate and cannot be reused across families. |
| Timing | Keep SHA-2 when it is approved for the use case, supported by current validation evidence, and required by the protocol or customer environment. | Do not switch to SHA-3 just to modernize a label if the surrounding protocol, certificate profile, module certificate, or customer requirement does not support it. | Keep the existing algorithm if it is approved, validated, and supported by the current protocol profile; do not modernize labels without functional justification. |
| Enforcement | A SHA-2 CAVP validation confirms that the specific SHA-224, SHA-256, SHA-384, or SHA-512 implementation produces correct outputs for the tested function. For a FIPS 140-3 module claim, the module security policy must name the validated SHA-2 function, the implementation must sit inside the defined cryptographic boundary, and the module certificate must list the algorithm under approved services. | A SHA-3 or SHAKE CAVP validation covers the specific SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or SHAKE256 implementation tested. For a FIPS 140-3 module claim using SHAKE, the module security policy must specify the output length constraints, because FIPS 202 CAVP entries are separate from FIPS 180-4 entries and cannot be substituted for each other in the module certificate's approved algorithm list. | Check that the CAVP validation covers the specific function, variant, and operating mode being claimed; SHA-2 and SHA-3 validation entries are not interchangeable. |
| Overlap | SHA-2 and SHA-3 are both NIST-approved secure-hash algorithm families, both listed in SP 800-57 key-management guidance, and both subject to CAVP validation requirements for federal cryptographic modules. | Algorithm validation for SHA-2 and SHA-3 uses the same CAVP submission process and does not, by itself, constitute a FIPS 140-3 module validation. Procurement evidence for either family should distinguish algorithm validation records from module validation certificates. | Treat SP 800-131A algorithm status and CAVP submission process as shared controls; both SHA-2 and SHA-3 follow the same validation framework. |
| Decision rule | For SHA-2, ask for the exact function, implementation version, validation entry, operating environment, and any FIPS 140-3 module boundary that uses it. | For SHA-3 or SHAKE, ask the same questions and include the selected SHAKE output length if an XOF is used. | Ask for the exact function, implementation version, validation entry, and operating mode for either family; SHAKE output length is an additional required field for SHA-3. |
FIPS 180-4 defines SHA-1 and the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
FIPS 202 defines SHA3-224, SHA3-256, SHA3-384, SHA3-512, plus SHAKE128 and SHAKE256 extendable-output functions.
Do not compare only the family names. Record the exact function and output length before making a design, validation, or procurement claim.
Federal agencies, contractors, and cryptographic module vendors selecting SHA-2 family functions under FIPS 180-4 for digital signatures, HMACs, key derivation, or other secure-hash use cases requiring NIST-approved algorithms.
Federal agencies, contractors, and module vendors selecting SHA-3 or SHAKE functions under FIPS 202 for designs where a SHA-3 or extendable-output function is required by a protocol, procurement specification, or NIST guidance document.
Map the actor role to the algorithm family: SHA-2 actors satisfy FIPS 180-4; SHA-3/SHAKE actors satisfy FIPS 202; both may appear in the same module.
SHA-2 is still common where TLS profiles, digital signatures, certificate ecosystems, firmware tooling, or customer controls name SHA-256 or SHA-384.
SHA-3 or SHAKE fits better where a new design, protocol, or standard explicitly allows FIPS 202 functions and validated implementations are available.
Use SHA-2 where protocol profiles, certificate ecosystems, or firmware require it; switch to SHA-3 only when the standard or design explicitly allows FIPS 202.
FIPS 180-4 can satisfy the secure-hash requirement for Federal applications when a FIPS 180-4 function is the appropriate function.
FIPS 202 can satisfy the same secure-hash requirement when a SHA-3 or SHAKE function is appropriate.
Confirm that the selected function is approved for the use case; SHA-2 and SHA-3 are both approved but interoperability constraints may limit substitution.
A SHA-2 implementation claim should point to NIST validation evidence for the tested implementation, not only to FIPS 180-4.
A SHA-3 or SHAKE implementation claim should point to CAVP validation evidence for the tested function implementation, not only to FIPS 202.
Point to the CAVP validation record for the specific function and implementation; SHA-2 and SHA-3 records are separate and cannot be reused across families.
Keep SHA-2 when it is approved for the use case, supported by current validation evidence, and required by the protocol or customer environment.
Do not switch to SHA-3 just to modernize a label if the surrounding protocol, certificate profile, module certificate, or customer requirement does not support it.
Keep the existing algorithm if it is approved, validated, and supported by the current protocol profile; do not modernize labels without functional justification.
A SHA-2 CAVP validation confirms that the specific SHA-224, SHA-256, SHA-384, or SHA-512 implementation produces correct outputs for the tested function. For a FIPS 140-3 module claim, the module security policy must name the validated SHA-2 function, the implementation must sit inside the defined cryptographic boundary, and the module certificate must list the algorithm under approved services.
A SHA-3 or SHAKE CAVP validation covers the specific SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, or SHAKE256 implementation tested. For a FIPS 140-3 module claim using SHAKE, the module security policy must specify the output length constraints, because FIPS 202 CAVP entries are separate from FIPS 180-4 entries and cannot be substituted for each other in the module certificate's approved algorithm list.
Check that the CAVP validation covers the specific function, variant, and operating mode being claimed; SHA-2 and SHA-3 validation entries are not interchangeable.
SHA-2 and SHA-3 are both NIST-approved secure-hash algorithm families, both listed in SP 800-57 key-management guidance, and both subject to CAVP validation requirements for federal cryptographic modules.
Algorithm validation for SHA-2 and SHA-3 uses the same CAVP submission process and does not, by itself, constitute a FIPS 140-3 module validation. Procurement evidence for either family should distinguish algorithm validation records from module validation certificates.
Treat SP 800-131A algorithm status and CAVP submission process as shared controls; both SHA-2 and SHA-3 follow the same validation framework.
For SHA-2, ask for the exact function, implementation version, validation entry, operating environment, and any FIPS 140-3 module boundary that uses it.
For SHA-3 or SHAKE, ask the same questions and include the selected SHAKE output length if an XOF is used.
Ask for the exact function, implementation version, validation entry, and operating mode for either family; SHAKE output length is an additional required field for SHA-3.
Start by naming the exact function: SHA-256 is not the same claim as SHA-512/256, SHA3-256, or SHAKE256 with a chosen output length. The hash family, output length, implementation version, operational environment, and consuming protocol all affect the evidence a reviewer can rely on.
FIPS 180-4 says either FIPS 180-4 or FIPS 202 must be implemented wherever a secure hash algorithm is required for Federal applications. That does not mean every SHA-2 deployment should be replaced by SHA-3. It means the team must use an approved hash function that fits the surrounding standard, protocol, validation, and assurance claim.
Use this comparison to turn hash choices into validation checks, procurement questions, and release-review evidence instead of broad FIPS claims.
Convert SHA-2 and SHA-3 decisions into accountable evidence requests, validation checks, and review milestones.
Use cited source material to resolve algorithm, validation, procurement, and module-boundary questions before implementation.
Review scope, evidence, owners, and the next cryptographic assurance actions with Sorena.
A FIPS 180-4 or FIPS 202 citation supports the algorithm family and function definition. It does not by itself prove that a product, library, cloud service, HSM, firmware image, or software module is validated for a buyer's configuration.
For implementation evidence, look for CAVP or ACVP algorithm validation details and, where a product makes a FIPS 140-3 claim, the CMVP module certificate and Security Policy. The useful evidence links the exact implementation and operational environment to the hash function being claimed.
SHA-3 supplements SHA-2; it is not a universal drop-in replacement for every deployed use. FIPS 202 says SHA-3 hash functions can be alternatives to SHA-2 functions, but the surrounding protocol or certificate profile still decides whether that alternative is allowed.
For many deployed systems, SHA-256 or SHA-384 remains the practical answer because TLS profiles, signature formats, certificate ecosystems, firmware update tooling, or customer controls already specify those functions. A SHA-3 migration is stronger when it is tied to a new architecture, a specific standard that supports it, or a validated implementation already available in the product boundary.
Procurement language should ask for the evidence behind the claim, not just whether a supplier uses SHA-2 or SHA-3. A useful answer names the hash function, implementation, version, operating environment, validation reference, module boundary, approved-mode status, and any protocol that constrains the choice.
Be especially careful with broad statements such as "FIPS compliant hashing" or "SHA-3 ready." Those phrases are not enough for audit or customer assurance unless they are tied to a source-linked standard and implementation-specific validation evidence.
Use this checklist when a design review, customer answer, supplier review, or audit file depends on SHA-2 vs SHA-3. The goal is a record that stands on its own without asking a later reviewer to reconstruct the cryptographic boundary from memory.
"validation-search"
"the tested operational environment"
"Security Requirements for Cryptographic Modules"