---
title: "FIPS approved algorithm selector workflow"
canonical_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow"
source_url: "https://www.sorena.io/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow"
author: "Sorena AI"
description: "A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims."
published_at: "2026-05-09"
updated_at: "2026-05-09"
keywords:
  - "FIPS approved algorithms"
  - "CAVP certificate"
  - "FIPS 140-3 approved mode"
  - "AES FIPS 197"
  - "FIPS 203"
  - "FIPS 204"
  - "FIPS algorithms"
  - "CAVP"
  - "FIPS 140-3"
  - "AES"
  - "post-quantum cryptography"
---
**[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform

[Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io)

---

# FIPS approved algorithm selector workflow

A source-linked workflow for selecting FIPS and NIST-approved cryptographic algorithms without overstating module validation, CAVP evidence, or approved-mode claims.

*Workflow* *GLOBAL* *FIPS 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.

Use this workflow when a design review needs to decide which FIPS or NIST-approved cryptographic algorithm family fits a specific service. It separates the algorithm question from adjacent questions about modes of operation, parameter sets, CAVP testing, cryptographic module validation, approved-mode indicators, and deployment boundary.

## Start with the cryptographic service, not the algorithm name

The selector starts by naming the service the module or product will provide: encryption, hashing, digital signature, key establishment, key derivation, random bit generation support, or protocol component. That service determines which FIPS or NIST recommendation is relevant and which evidence can support the 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.
- Do not describe an implementation as validated unless the evidence names the relevant CAVP certificate, CMVP certificate, operational environment, and module boundary.

Sources for this answer:

- [NIST FIPS 197-upd1 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Supports AES scope, key sizes, 128-bit block size, and the need to use AES with an approved or recommended mode.
- [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Supports SHA-1, SHA-2 family names, and federal secure-hash applicability alongside FIPS 202.
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports ML-KEM service scope and approved parameter-set selection.

## Selector table for common FIPS algorithm choices

Use this table as 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.

Service | Candidate source | Decision detail to record | Evidence to request

Symmetric encryption | FIPS 197 plus the applicable mode recommendation | AES-128, AES-192, or AES-256, mode, IV or nonce handling, key management path | CAVP algorithm certificate, module Security Policy, mode documentation

Hashing or digest support | FIPS 180-4 or FIPS 202 | SHA-2 or SHA-3/SHAKE function, digest length, whether it is standalone or used inside another algorithm | CAVP certificate or module evidence for the function actually used

Classical signatures | FIPS 186-5 | RSA, ECDSA, or EdDSA use, key size or curve, hash function, key-generation assurance | Signature algorithm validation and public/private key assurance evidence

Post-quantum KEM | FIPS 203 | ML-KEM-512, ML-KEM-768, or ML-KEM-1024, input checking, key handling, encapsulation or decapsulation use | Parameter-set decision, implementation validation status, module boundary

Post-quantum signatures | FIPS 204 or FIPS 205 | ML-DSA or SLH-DSA, parameter set, pure or pre-hash variant where relevant | Signature validation evidence and approved hash or XOF evidence when pre-hashing is used

- 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 CAVP and CMVP 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.

Sources for this answer:

- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Supports classical digital-signature scope and validation-program distinction.
- [NIST FIPS 204 Module-Lattice-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Supports ML-DSA as an approved post-quantum digital-signature algorithm and parameter-set family.
- [NIST FIPS 205 Stateless Hash-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports SLH-DSA scope, parameter-set approval, and the distinction between SLH-DSA and its components.

*Recommended next step*

*Placement: after selector workflow*

## Build a defensible 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.

- [Open Assessment Autopilot for FIPS algorithm evidence](/solutions/assessment.md): Convert selector rows into owners, evidence requests, gap statements, and review checkpoints.
- [Research FIPS source questions](/solutions/research-copilot.md): Use official FIPS and CMVP material to resolve algorithm, parameter-set, and validation-evidence questions.
- [Talk through FIPS algorithm selection](/contact.md): Review service scope, algorithm choices, validation evidence, and boundary caveats with Sorena.

## 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 CAVP addresses testing of approved security functions and approved sensitive security parameter generation and establishment methods referenced by the SP 800-140 series.

A CAVP algorithm certificate is still not the same thing as a FIPS 140-3 module certificate. The IG states that an algorithm validation certificate identifies the validated algorithm implementation and tested operational environment. It also states that the tested operational environment must be identical to, or fully included in, the cryptographic module environment being tested, subject to the stated rules.

- 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 approved mode.
- For protocol claims, check the component list instead of assuming a protocol version makes each KDF, MAC, cipher, or signature use approved.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports the distinction between CAVP algorithm testing, operational environments, approved-mode indicators, and FIPS 140-3 module evidence.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source to look up algorithm validation records before relying on a certificate number.
- [NIST FIPS 140-3 security requirements for cryptographic modules](https://doi.org/10.6028/NIST.FIPS.140-3?ref=sorena.io) - Primary FIPS 140-3 source for module-level security requirements; use with CMVP guidance for approved-mode evidence.

## 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 CAVP records, CMVP certificate and Security Policy text, service indicators, operational environment, hardware acceleration path, and module boundary.

Gate 5: What claim is allowed? The final row should say what is selected, what is validated or not yet validated, which boundary the evidence covers, and what change would 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.

Sources for this answer:

- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Supports SHA-3 and SHAKE choices when the service needs a hash or extendable-output function.
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Supports the need to select an ML-KEM parameter set and avoid standalone K-PKE claims.
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports approved-mode separation and service indicator review.

## 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.

Field | Required entry

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 | CAVP certificate, CMVP 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, and module-validation submissions.

Sources for this answer:

- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Supports boundary, operational-environment, approved-service, and non-approved-service evidence checks.
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source for confirming algorithm certificate records used in selector evidence.
- [NIST FIPS 205 Stateless Hash-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Supports recording approved SLH-DSA parameter sets and component-use limitations.

## Primary sources

- [NIST FIPS 197-upd1 Advanced Encryption Standard](https://doi.org/10.6028/NIST.FIPS.197-upd1?ref=sorena.io) - Primary source for AES scope, AES key sizes, block size, and approved or recommended mode dependency.
  - Quote: "Advanced Encryption Standard (AES)"
- [NIST FIPS 180-4 Secure Hash Standard](https://doi.org/10.6028/NIST.FIPS.180-4?ref=sorena.io) - Primary source for SHA-1 and SHA-2 secure hash algorithms and federal secure-hash applicability.
  - Quote: "Secure Hash Standard"
- [NIST FIPS 202 SHA-3 Standard](https://doi.org/10.6028/NIST.FIPS.202?ref=sorena.io) - Primary source for SHA-3 hash functions and SHAKE extendable-output functions.
  - Quote: "SHA-3 Standard"
- [NIST FIPS 186-5 Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.186-5?ref=sorena.io) - Primary source for classical digital-signature algorithm selection and assurance context.
  - Quote: "Digital Signature Standard"
- [NIST FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard](https://doi.org/10.6028/NIST.FIPS.203?ref=sorena.io) - Primary source for ML-KEM and its approved parameter sets.
  - Quote: "Module-Lattice-Based Key-Encapsulation Mechanism"
- [NIST FIPS 204 Module-Lattice-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.204?ref=sorena.io) - Primary source for ML-DSA algorithm and parameter-set selection.
  - Quote: "Module-Lattice-Based Digital Signature Standard"
- [NIST FIPS 205 Stateless Hash-Based Digital Signature Standard](https://doi.org/10.6028/NIST.FIPS.205?ref=sorena.io) - Primary source for SLH-DSA, approved parameter sets, and component-use limits.
  - Quote: "Stateless Hash-Based Digital Signature Standard"
- [CMVP Implementation Guidance for FIPS 140-3](https://csrc.nist.gov/csrc/media/Projects/cryptographic-module-validation-program/documents/FIPS%20140-3/FIPS%20140-3%20IG.pdf?ref=sorena.io) - Program guidance for algorithm certificates, operational-environment matching, approved security service indicators, and approved-mode separation.
  - Quote: "CAVP addresses the testing of Approved Security Functions"
- [NIST CAVP validation search](https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?ref=sorena.io) - Public source for checking algorithm validation records before making an implementation claim.
  - Quote: "validation-search"

## Related Topic Guides

- [AES FIPS 197 requirements and evidence](/artifacts/global/fips-crypto-algorithms/aes-fips-197.md): AES FIPS 197 guidance for identifying supported key sizes, separating the block cipher from modes of operation, and avoiding unsupported FIPS validation claims.
- [CAVP and ACVP validation evidence for FIPS algorithms](/artifacts/global/fips-crypto-algorithms/cavp-and-acvp-validation.md): How to read CAVP algorithm certificates, ACVTS/ACVP test coverage, CMVP module validation, and FIPS 140-3 procurement evidence without overstating the claim.
- [CAVP Validation Evidence Workflow for FIPS Algorithms](/artifacts/global/fips-crypto-algorithms/cavp-validation-evidence-workflow.md): Workflow for collecting CAVP and ACVP evidence: algorithm certificates, implementation names, tested parameters, operating environments, and CMVP handoff records.
- [FIPS 180-4 and FIPS 202 secure hash guidance](/artifacts/global/fips-crypto-algorithms/secure-hash-fips-180-4-and-fips-202.md): 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](/artifacts/global/fips-crypto-algorithms/digital-signatures-fips-186-5-and-fips-204.md): 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](/artifacts/global/fips-crypto-algorithms/ml-kem-vs-rsa-and-ecdh.md): Compare FIPS 203 ML-KEM with RSA and ECDH key-establishment schemes using NIST SP 800-56A, SP 800-56B, CAVP, and CMVP grounding.
- [FIPS 203, 204, and 205 Post-Quantum Algorithms](/artifacts/global/fips-crypto-algorithms/faq/fips-203-204-and-205-post-quantum-algorithms.md): 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](/artifacts/global/fips-crypto-algorithms/faq/procurement-evidence.md): 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 approved mode procurement: certificates, boundaries, and evidence](/artifacts/global/fips-crypto-algorithms/approved-mode-procurement.md): 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](/artifacts/global/fips-crypto-algorithms/transition-and-deprecation-tracker.md): 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](/artifacts/global/fips-crypto-algorithms/algorithm-selector.md): 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](/artifacts/global/fips-crypto-algorithms/kdf-and-mac-coverage.md): 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](/artifacts/global/fips-crypto-algorithms/key-management-mapping.md): 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](/artifacts/global/fips-crypto-algorithms/procurement-evidence-review-workflow.md): 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 validation certificates for cryptographic algorithms](/artifacts/global/fips-crypto-algorithms/faq/validation-certificates.md): How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
- [FIPS-approved cryptographic algorithms FAQ](/artifacts/global/fips-crypto-algorithms/faq.md): 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.
- [How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-180-4-and-fips-202-hash-functions.md): Use FIPS 180-4 for SHA-1 and SHA-2 hash algorithms, FIPS 202 for SHA-3 and SHAKE functions, and CAVP/CMVP evidence without treating a hash certificate as module validation.
- [How FIPS 186-5 Signature Algorithms Fit FIPS Approval](/artifacts/global/fips-crypto-algorithms/faq/fips-186-5-signatures.md): Use FIPS 186-5 for RSA, ECDSA, deterministic ECDSA, EdDSA, HashEdDSA, DSA verification limits, approved hashes, and CAVP/CMVP evidence boundaries.
- [ML-DSA vs ECDSA under FIPS 204 and FIPS 186-5](/artifacts/global/fips-crypto-algorithms/ml-dsa-vs-ecdsa.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-fips-203-204-205.md): A grounded 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration.md): 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](/artifacts/global/fips-crypto-algorithms/post-quantum-migration-tracker.md): 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](/artifacts/global/fips-crypto-algorithms/sha-2-vs-sha-3.md): 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](/artifacts/global/fips-crypto-algorithms/tls-use-case-mapping.md): Map TLS uses to FIPS algorithm, CAVP, CMVP, approved-mode, certificate-authority, and evidence checks without overstating protocol validation claims.
- [What does FIPS 197 AES mean for FIPS-approved algorithms?](/artifacts/global/fips-crypto-algorithms/faq/fips-197-aes.md): 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.


---

[Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us)

(c) 2026 Sorena AB (559573-7338). All rights reserved.

Source: https://www.sorena.io/artifacts/global/fips-crypto-algorithms/approved-algorithm-selector-workflow