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.

WorkflowGLOBALFIPS cryptographic algorithms

FIPS approved algorithm selector workflow

A practical way to choose approved cryptographic algorithms by service type, standard, parameter set, module boundary, and validation evidence.

Use it to structure engineering and assurance review. Do not treat algorithm approval as proof that a module, product, protocol, or deployment is FIPS 140-3 validated.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
Oct 15, 2026
5 sections11 primary sources
Overview

Choose the cryptographic service first, then the governing FIPS or NIST publication, algorithm or scheme, mode, parameter set, and supporting functions. The cited FIPS publications control covered U.S. federal systems and are available for private and commercial adoption; a protocol profile, agency rule, contract, or application standard may narrow the allowed choice. After selection, verify the implementation through the Cryptographic Algorithm Validation Program (). When the claim concerns a validated cryptographic module, also verify the separate Cryptographic Module Validation Program () certificate, public Security Policy, operational environment, module boundary, and approved-service indicator. An approved algorithm standard does not validate a product, protocol, deployment, or module.

Section 1

Start with the cryptographic service, not the algorithm name

The system or product owner names the service the module or product will provide: encryption, hashing, digital signature, key establishment, key derivation, message authentication, random bit generation, or a protocol component. The cryptographic engineer records the exact algorithm, mode, parameter set, and dependencies. The assurance reviewer matches that design to and evidence. The service determines which FIPS or NIST publication applies and what evidence can support the resulting claim.

Keep the claim narrow. AES in FIPS 197 specifies a block cipher with AES-128, AES-192, and AES-256, but the standard also says AES is used with a FIPS-approved or NIST-recommended mode of operation. A hash decision should point to FIPS 180-4 or FIPS 202. Signature decisions should distinguish FIPS 186-5, FIPS 204 ML-DSA, FIPS 205 SLH-DSA, and any application-level assurance requirements. Key-encapsulation decisions should identify the FIPS 203 ML-KEM parameter set.

  • Write one selector row per service, not one row per library or vendor package.
  • Record the source standard, algorithm family, mode or variant, parameter set, and intended security service.
  • Flag anything that is only a component or subroutine, such as K-PKE inside ML-KEM or WOTS+, XMSS, FORS, and hypertree components inside SLH-DSA.
  • Keep algorithm and module claims separate. A record supports the listed algorithm implementation and operational environment. A module-level claim also needs the applicable certificate, Security Policy, module boundary, tested environment, approved services, and usage conditions.
Section 2

Selection checklist for common FIPS algorithm choices

This checklist is the first pass before library or vendor selection. It is intentionally limited to claims supported by the standards; implementation status and validated use still need separate evidence.

  • Symmetric encryption: FIPS 197 plus the applicable mode recommendation. Record: AES-128, AES-192, or AES-256, mode, IV or nonce handling, key management path. Evidence: algorithm certificate, module Security Policy, mode documentation.
  • Hashing or digest support: FIPS 180-4 or FIPS 202. Record: SHA-2 or SHA-3/SHAKE function, digest length, whether it is standalone or used inside another algorithm. Evidence: certificate or module evidence for the function actually used.
  • Classical signatures: FIPS 186-5. Record: RSA, ECDSA, or EdDSA use, key size or curve, hash function, key-generation assurance. Evidence: Signature algorithm validation and public/private key assurance evidence.
  • Post-quantum KEM: FIPS 203. Record: ML-KEM-512, ML-KEM-768, or ML-KEM-1024, input checking, key handling, encapsulation or decapsulation use. Evidence: Parameter-set decision, implementation validation status, module boundary.
  • Post-quantum signatures: FIPS 204 or FIPS 205. Record: ML-DSA or SLH-DSA, parameter set, pure or pre-hash variant where relevant. Evidence: Signature validation evidence and approved hash or XOF evidence when pre-hashing is used.
  • Message authentication: FIPS 198-1 or the applicable NIST mode recommendation. Record: HMAC or an approved block-cipher-based MAC, underlying hash or cipher, tag length, key handling. Evidence: entry for the exact MAC and parameters plus module evidence when a module claim is made.
  • Key derivation or protocol KDF: Applicable NIST recommendation or protocol-KDF reference recognized by guidance. Record: KDF family, inputs, output length, protocol context, and whether use is component-limited. Evidence: or Component Validation List (CVL) entry, usage restriction, Security Policy mapping, and protocol context.
  • Random bit generation: SP 800-90A and applicable entropy-source requirements. Record: Deterministic random bit generator (DRBG) construction, security strength, entropy source, personalization or nonce handling, reseed behavior. Evidence: DRBG validation entry plus module entropy and Security Policy evidence.
  • Treat the selector as a control input, not a certificate substitute.
  • When the standard says NIST will develop or provides validation-program information, check the live and records before making an implementation claim.
  • For pre-hash signature variants, record the approved hash function or XOF used to create the digest.
  • For PQC choices, record why the selected parameter set fits the application rather than copying the strongest available option into every service.
Section 3

Evidence checks before calling a service approved

After a candidate algorithm is selected, verify whether the implementation evidence matches the exact service. FIPS 140-3 Implementation Guidance states that addresses testing of approved security functions and approved sensitive security parameter generation and establishment methods referenced by the SP 800-140 series.

A algorithm certificate is not a FIPS 140-3 module certificate. The guidance says an algorithm certificate identifies the validated algorithm implementation and tested operational environment. When that certificate is bound into a module undergoing FIPS 140-3 testing, the CAVP-tested environment must be identical to, or fully included in, the module's test environment under the guidance's stated rules. Do not apply that binding rule as a blanket claim that every unlisted product environment is validated.

  • Match the certificate to the algorithm implementation name, version, processor or accelerator path, and operational environment.
  • Match the module claim to the cryptographic boundary, service list, approved and non-approved service separation, and Security Policy.
  • For approved-mode claims, verify the service indicator and the rule that non-approved security functions are not used in .
  • For protocol claims, check the component list instead of assuming a protocol version makes each KDF, MAC, cipher, or signature use approved.
Recommended next step

Build a FIPS algorithm selection record

Use the selector output to assign evidence owners, identify validation gaps, and keep algorithm claims aligned with module boundaries and certificates.

Assessment workflow
Open Assessment Autopilot for FIPS algorithm evidence

Convert selector rows into owners, evidence requests, gap statements, and review checkpoints.

Explore next step
Research workflow
Research FIPS source questions

Use official FIPS and CMVP material to resolve algorithm, parameter-set, and validation-evidence questions.

Explore next step
Talk to Sorena
Talk through FIPS algorithm selection

Review service scope, algorithm choices, validation evidence, and boundary caveats with Sorena.

Explore next step
Section 4

Decision gates for the selector workflow

Gate 1: Is the service in scope? Name the exact cryptographic service and reject selector rows that only name a broad product feature such as secure storage or secure transport.

Gate 2: Is the source family correct? Choose the FIPS or NIST source that covers the service: AES, secure hash, digital signature, key encapsulation, KDF, MAC, random bit generation, or protocol component.

Gate 3: Are the mode, parameter set, and supporting functions specified? Record AES mode, hash or XOF, signature parameter set, KEM parameter set, approved RBG dependency, and pre-hash details where relevant.

Gate 4: Does evidence match the implementation? Compare records, certificate and Security Policy text, service indicators, operational environment, hardware acceleration path, and module boundary.

Gate 5: What claim is allowed? Choose one bounded outcome: rejected because the service or governing source is unclear; selected at design level but missing implementation evidence; matched to a named -tested implementation; or matched to a named -validated module whose approved service is used under its Security Policy conditions. Record the owner, covered boundary, allowed wording, open evidence, and changes that reopen the decision.

  • Stop the workflow when the use case cannot be tied to a specific service and source standard.
  • Do not approve a selector row that lacks parameter-set detail for ML-KEM, ML-DSA, or SLH-DSA.
  • Do not carry a vendor certificate into a different module, platform, accelerator path, or operating environment without matching evidence.
  • Do not use the selector to make export, procurement acceptance, or customer compliance guarantees; it only documents the algorithm and evidence decision.
Section 5

Selector record template

Copy these fields into the design review or assurance record for each cryptographic service. Leave a field blank only if the reviewer has explicitly marked it not applicable and explained why.

  • Service: Encryption, digest, signature generation, signature verification, KEM encapsulation, KEM decapsulation, KDF, MAC, DRBG, or protocol component.
  • Source: FIPS or NIST publication and section or table used for the selection.
  • Algorithm choice: Family, mode or variant, parameter set, key size, curve, hash, XOF, or supporting function.
  • Implementation evidence: certificate, certificate, Security Policy entry, test result, or gap statement.
  • Boundary: Module, operational environment, library version, accelerator path, platform, and calling service.
  • Allowed claim: Exact wording the team can use internally or externally, with any caveat.
  • Change trigger: Library update, compiler/platform change, accelerator change, parameter-set change, protocol change, module boundary change, or certificate-status change.
  • Use a gap statement when validation evidence is not available instead of weakening the wording to imply approval.
  • Record negative decisions, especially non-approved algorithms kept only for interoperability or no-security-claimed use.
  • Tie every external claim to a source URL and an evidence artifact rather than to the selector workflow itself.
  • Review the selector record before release, customer questionnaires, audits, procurements, and module-validation submissions, and reopen it after an algorithm, mode, parameter set, library, compiler, processor path, operational environment, protocol, module boundary, Security Policy, or certificate-status change.
Primary sources

References and citations

CMVP Implementation Guidance for FIPS 140-3
csrc.nist.gov5 citations
Referenced sections
  • Program guidance for algorithm certificates, operational-environment matching, approved security service indicators, and approved-mode separation.
  • Provides the approved-mode conditions and usage limits for algorithm components, protocol KDFs, SP 800-108 KDFs, random bit generation, MACs, and sensitive security parameter establishment within a FIPS 140-3 module.
  • Supports the distinction between CAVP algorithm testing, operational environments, approved-mode indicators, and FIPS 140-3 module evidence.
Show 2 more
  • Supports approved-mode separation and service indicator review.
  • Supports boundary, operational-environment, approved-service, and non-approved-service evidence checks.
"Cryptographic algorithm implementations are tested and validated under the Cryptographic Algorithm Validation Program (CAVP)."
More quoted passages
"Non-approved security functions shall not be used in the approved mode of operation"
"algorithm validation certificate states the name and version number"
NIST CAVP validation search
csrc.nist.gov3 citations
Referenced sections
  • Public source for checking validation numbers, vendors, implementations, product types, algorithm coverage, and validation dates before making an implementation claim.
  • Public source to look up a validation number, vendor, implementation, product type, included algorithms, and validation date before relying on supplier evidence.
  • Public source for confirming the validation number, implementation, vendor, algorithm coverage, product type, and validation date recorded in selector evidence.
NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard
doi.org3 citations
Referenced sections
  • Primary source for ML-KEM and its approved parameter sets.
  • Supports ML-KEM service scope and approved parameter-set selection.
  • Supports the need to select an ML-KEM parameter set and avoid standalone K-PKE claims.
"Module-Lattice-Based Key-Encapsulation Mechanism"
More quoted passages
"ML-KEM-512, ML-KEM-768, and ML-KEM-1024"
"K-PKE is not approved for use in a stand-alone fashion."
NIST FIPS 205 Stateless Hash-Based Digital Signature Standard
doi.org3 citations
Referenced sections
  • Primary source for SLH-DSA, approved parameter sets, and component-use limits.
  • Supports SLH-DSA scope, parameter-set approval, and the distinction between SLH-DSA and its components.
  • Supports recording approved SLH-DSA parameter sets and component-use limitations.
"Stateless Hash-Based Digital Signature Standard"
More quoted passages
"This standard specifies several parameter sets for SLH-DSA that are approved for use."
"WOTS+, XMSS, FORS, and hypertree signature schemes are not approved"
NIST Cryptographic Algorithm Validation Program
csrc.nist.gov2 citations
Referenced sections
  • Official explanation of CAVP scope, validation-list fields, ACVTS production testing, supported algorithm categories, and the boundary between algorithm and module validation.
  • Explains CAVP validation scope, public-listing fields, ACVTS Production testing, and the boundary between algorithm and module validation.
"validation testing of Approved (i.e., FIPS-approved and NIST-recommended) cryptographic algorithms"
NIST FIPS 180-4 Secure Hash Standard
doi.org2 citations
Referenced sections
  • Primary source for SHA-1 and SHA-2 secure hash algorithms and federal secure-hash applicability.
  • Supports SHA-1, SHA-2 family names, and federal secure-hash applicability alongside FIPS 202.
"Secure Hash Standard"
More quoted passages
"Either this Standard or Federal Information Processing Standard (FIPS) 202 must be implemented"
NIST FIPS 186-5 Digital Signature Standard
doi.org2 citations
Referenced sections
  • Primary source for classical digital-signature algorithm selection and assurance context.
  • Supports classical digital-signature scope and validation-program distinction.
"Digital Signature Standard"
More quoted passages
"specifies a suite of algorithms that can be used to generate a digital signature"
NIST FIPS 197-upd1 Advanced Encryption Standard
doi.org2 citations
Referenced sections
  • Primary source for AES scope, AES key sizes, block size, and approved or recommended mode dependency.
  • Supports AES scope, key sizes, 128-bit block size, and the need to use AES with an approved or recommended mode.
"Advanced Encryption Standard (AES)"
More quoted passages
"shall be used in conjunction with a FIPS-approved or NIST-recommended mode of operation"
NIST FIPS 202 SHA-3 Standard
doi.org2 citations
Referenced sections
  • Primary source for SHA-3 hash functions and SHAKE extendable-output functions.
  • Supports SHA-3 and SHAKE choices when the service needs a hash or extendable-output function.
"SHA-3 Standard"
More quoted passages
"The SHA-3 family consists of four cryptographic hash functions"
NIST FIPS 204 Module-Lattice-Based Digital Signature Standard
doi.org2 citations
Referenced sections
  • Primary source for ML-DSA algorithm and parameter-set selection.
  • Supports ML-DSA as an approved post-quantum digital-signature algorithm and parameter-set family.
"Module-Lattice-Based Digital Signature Standard"
More quoted passages
"This standard specifies several parameter sets for ML-DSA that are approved for use."

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 186-5 and FIPS 204 digital signatures

Compare FIPS 186-5 classical digital signatures with FIPS 204 ML-DSA, including scope, algorithm choices, key-use limits, and validation evidence boundaries.

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.

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.