FIPS-approved cryptographic algorithms FAQ

The FIPS publications on this page are U.S. federal standards. Their applicability clauses govern federal departments and agencies, with stated statutory exceptions, and can also reach systems operated for an agency under contract. A contract, acquisition rule, agency policy, authorization requirement, or another jurisdiction's policy may make the same standards relevant outside a federal system.

Private and commercial organizations may adopt these standards voluntarily, but the appearance of FIPS in a customer questionnaire does not establish the required scope. Before selecting algorithms or requesting certificates, identify the governing contract or policy, the information being protected, whether the requirement concerns an approved algorithm or a validated module, and whether the system is new or already deployed.

For this topic, call an algorithm or technique FIPS-approved only when the current FIPS 140-3 approved-security-function sources identify that exact algorithm, mode, parameter set, and use as approved. Being described somewhere in a FIPS or NIST publication is not enough: the same source set can also document disallowed functions, legacy-only verification or decryption, component algorithms that are not approved on their own, and transition rules. Approval at that layer is still not blanket approval of every product, protocol, cloud service, library build, or configuration that mentions the algorithm.

A useful algorithm record should name the standard, the algorithm family, the exact mode or parameter set, the intended use, and the evidence source. For example, AES is a FIPS-approved block cipher, but FIPS 197 also says AES is used with a FIPS-approved or NIST-recommended mode of operation.

No. CAVP validation is evidence that a specific cryptographic algorithm implementation passed algorithm testing. CMVP validation is about a cryptographic module meeting FIPS 140-3 requirements for a defined module boundary, tested operational environment, roles, services, self-tests, security policy, and other module requirements.

In a procurement or audit file, keep these artifacts separate. A CAVP certificate can support the algorithm implementation evidence for a module, but it does not by itself prove that the delivered product is a FIPS 140-3 validated cryptographic module or that the product is operating in approved mode.

Be careful. FIPS 140-3 implementation guidance says the FIPS 140-3 and SP 800-140 series do not address protocols as protocols. The approved-mode question is whether the module uses approved or allowed cryptographic algorithms and schemes, such as AES, ECDSA, KDFs, key-agreement schemes, or key-transport schemes, in the way permitted for the module's approved services.

For protocol claims, write the evidence around the cryptographic functions actually used by the module. For example, a TLS claim may require checking the KDF, cipher suite components, key agreement, certificate signature algorithms, random bit generation, and whether those services are listed as approved services in the module Security Policy.

Use the algorithm standard for the primitive, then check current-use status, CAVP evidence for the implementation, and CMVP evidence for the module. FIPS 197 covers AES; FIPS 180-4 specifies SHA-1 and the SHA-2 family; FIPS 202 covers SHA-3 hash functions and SHAKE extendable-output functions; FIPS 186-5 approves RSA, ECDSA, deterministic ECDSA, EdDSA, and HashEdDSA for signature generation and verification while retaining DSA only for verification of signatures generated before its implementation date.

A claim such as AES, SHA, or FIPS signatures is not enough. The record should identify the mode or scheme, key length or digest length, approved use, implementation validation, and whether the module's approved services actually call that implementation.

Treat FIPS 203, FIPS 204, and FIPS 205 as algorithm standards, not automatic product approvals. FIPS 203 specifies ML-KEM for key establishment; FIPS 204 specifies ML-DSA for digital signatures; FIPS 205 specifies SLH-DSA for stateless hash-based digital signatures. Each claim still needs implementation evidence, parameter-set choices, module boundary evidence, and approved-mode treatment where FIPS 140-3 validation is relevant.

For migration planning, do not state that a system is post-quantum compliant because a roadmap names ML-KEM or ML-DSA. The evidence record should identify which algorithm standard is used, which parameter set is selected, where the algorithm runs, how keys or signatures are generated, and what CAVP or CMVP evidence is available for the implementation and module. NIST's publication pages list potential-update errata for FIPS 203 and FIPS 204; the FIPS 203 planning note is dated November 17, 2025, and the latest FIPS 204 note is dated February 23, 2026. Check those pages and errata alongside the issued standards.

Sometimes, but the distinction is narrow. CMVP guidance says non-approved security functions cannot be used in approved mode. It also recognizes that a non-approved cryptographic algorithm may appear in approved mode only when it is not used as a security function, does not meet FIPS 140-3 requirements, and is clearly documented as providing no claimed security.

This matters for libraries, diagnostics, interoperability code, and internal obfuscation. If a non-approved algorithm is exposed as encryption, key agreement, key transport, message authentication, digest generation, signature generation, signature verification, or another security function, it should not be treated as harmless just because the module also contains approved algorithms.

Keep evidence that lets another reviewer reconstruct the claim without relying on marketing shorthand. The packet should show the algorithm standard, the implementation validation evidence, the module validation evidence if a module claim is made, and the product or service configuration that uses the approved service.

For customer-facing or procurement language, the minimum useful file is the exact claim text, the source standard, any CAVP certificate references, the CMVP certificate and Security Policy when applicable, the module version and operational environment, and the owner who approved the wording.