Artifact GuideGLOBALFIPS cryptographic algorithms

AES requirements under FIPS 197

Use this guide to keep AES claims tied to the FIPS 197 block cipher, its approved key sizes, and the separate evidence needed for modes, implementations, and modules.

Grounded in NIST source material. Use it as implementation guidance, not for legal interpretation.

Back to main artifactReview sources
Author
Sorena AI
Published
May 9, 2026
Updated
May 9, 2026
Sections
5

Structured answer sets in this page tree.

Primary sources
4

Cited legal and guidance references.

Publication metadata
Sorena AI
Published May 9, 2026
Updated May 9, 2026
Overview

FIPS 197 specifies the Advanced Encryption Standard as a FIPS-approved symmetric block cipher for protecting electronic data. It does not, by itself, validate a product, approve every AES mode, or prove that a cryptographic module is FIPS 140-3 validated. Use this page to separate those claims before writing design notes, audit evidence, or procurement language.

Section 1

What FIPS 197 actually covers

FIPS 197 defines AES as a symmetric block cipher. The standard specifies AES-128, AES-192, and AES-256, each with a 128-bit block size; the suffix names the key length. Other Rijndael block sizes or key lengths are outside the AES configurations adopted by FIPS 197.

Treat FIPS 197 as the algorithm specification, not as a complete encryption design. The standard says the algorithm may be implemented in software, firmware, hardware, or combinations of them, and it points teams to NIST-recommended modes of operation for services such as confidentiality and authentication.

  • Record whether the implementation uses AES-128, AES-192, or AES-256.
  • Record that the AES block size is 128 bits for the FIPS 197 configurations.
  • Do not describe non-standard Rijndael configurations as AES under FIPS 197.
  • Keep mode-of-operation decisions separate from the AES block cipher selection.
Sources for this answer
NIST FIPS 197-upd1 Advanced Encryption Standard
Supports the AES algorithm scope, the three approved AES key sizes, the 128-bit block size, and the May 2023 update identifier.
NIST block cipher modes project
FIPS 197 points readers to NIST block-cipher mode resources for services built around a block cipher.
Section 2

Claims that need a separate source

A correct AES implementation is not the same thing as a validated cryptographic module. FIPS 140-3 is the module security standard, and CMVP validation applies to a defined cryptographic module boundary, security level, operating environment, services, self-tests, lifecycle evidence, and approved security functions.

Procurement language should therefore avoid shortcuts such as "FIPS 197 certified product" or "AES means FIPS validated." Safer wording names the algorithm, the mode, the cryptographic module or library, and any relevant CMVP or CAVP evidence separately.

  • Use FIPS 197 to support the AES algorithm claim.
  • Use a NIST-recommended mode source for CBC, GCM, XTS, KW, or other mode-specific claims.
  • Use CMVP module records for FIPS 140-3 module validation claims.
  • Use CAVP certificate evidence only for the tested algorithm implementation and parameters it actually covers.
Sources for this answer
NIST FIPS 140-3 security requirements for cryptographic modules
Supports the distinction between an approved AES algorithm and validation of a complete cryptographic module.
CMVP Implementation Guidance for FIPS 140-3
Supports treating CAVP testing, approved services, algorithm parameters, and module certificate evidence as scoped validation artifacts.
Section 3

Evidence to keep for an AES design review

The useful evidence is narrow and technical. A reviewer should be able to see which AES configuration is used, why the selected mode is appropriate for the service, where keys are generated and protected, and whether the claim is algorithm-level, mode-level, or module-level.

For implementation changes, treat the evidence as versioned. A library upgrade, hardware acceleration change, operating-environment change, module boundary change, or mode change can make older test or certificate evidence too broad for the current release.

  • AES configuration: AES-128, AES-192, or AES-256, with the implementation or library version.
  • Mode record: selected NIST-recommended mode, initialization or nonce requirements, authentication-tag handling where relevant, and prohibited modes if the policy excludes them.
  • Boundary record: the product, service, module, platform, or operating environment covered by the claim.
  • Validation record: CMVP module certificate or CAVP algorithm certificate numbers when those are being asserted.
  • Change record: release notes and review sign-off for cryptographic library, firmware, accelerator, platform, or configuration changes.
Sources for this answer
NIST FIPS 197-upd1 Advanced Encryption Standard
Supports recording the AES configuration and separating the block cipher from surrounding protocol or mode choices.
CMVP Implementation Guidance for FIPS 140-3
Supports reviewing approved services by algorithm parameters, including key sizes and modes used by the approved service.
Recommended next step

Operationalize AES FIPS 197

Use this AES FIPS 197 guidance to separate algorithm selection, mode approval, certificate evidence, and FIPS 140-3 module scope before audit or procurement review.

Assessment workflow
Open Assessment Autopilot for AES evidence

Convert AES configuration, mode, boundary, and validation questions into accountable review tasks.

Explore next step
Research workflow
Research FIPS cryptography source questions

Use cited NIST source material to resolve AES scope, mode, CAVP, and CMVP evidence questions before implementation.

Explore next step
Talk to Sorena
Talk through implementation

Review AES claims, certificate scope, evidence gaps, and the next compliance actions with Sorena.

Explore next step
Section 4

AES FIPS 197 checklist

Use this checklist before publishing an AES claim, accepting supplier evidence, or responding to an audit question. Each item should be answered with a named source, record, or certificate rather than a general statement that AES is approved.

  • Name the AES key size and confirm it is one of AES-128, AES-192, or AES-256.
  • Name the mode of operation and cite the NIST mode source or internal policy that approves it for the use case.
  • State whether the claim is about the algorithm, a tested implementation, or a FIPS 140-3 validated module.
  • Attach certificate evidence only when the certificate scope, version, platform, mode, and key size match the release being reviewed.
  • Rewrite public or procurement copy that implies FIPS 197 alone validates a product, service, module, or cloud environment.
Sources for this answer
NIST FIPS 197-upd1 Advanced Encryption Standard
Supports the checklist items for AES key-size and block-cipher scope.
NIST FIPS 140-3 security requirements for cryptographic modules
Supports the checklist distinction between an AES algorithm claim and a validated cryptographic module claim.
Section 5

Common AES claim mistakes

Most AES FIPS 197 errors are claim-boundary errors. The fix is to name exactly what was selected, tested, or validated, and to remove any wording that lets readers infer broader assurance than the source supports.

  • Do not call AES modes, protocols, products, or modules FIPS 197-approved unless the source actually covers that layer.
  • Do not cite a CAVP algorithm certificate as proof that the whole product is FIPS 140-3 validated.
  • Do not reuse certificate evidence after a platform, operating environment, module boundary, mode, or key-size change without checking scope.
  • Do not bury exceptions in marketing language; say which releases, environments, and features are outside the AES or validation claim.
Sources for this answer
NIST FIPS 197-upd1 Advanced Encryption Standard
Supports limiting AES claims to the FIPS 197 algorithm specification and its adopted configurations.
CMVP Implementation Guidance for FIPS 140-3
Supports checking algorithm parameters and approved-service scope before relying on validation evidence.
Primary sources

References and citations

NIST block cipher modes project
csrc.nist.gov
Referenced sections
  • FIPS 197 points readers to NIST block-cipher mode resources for services built around a block cipher.
"Block cipher modes of operation"
Related guides

Explore more topics

CAVP and ACVP validation evidence for FIPS algorithms
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
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
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 grounding.
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 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.
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 validation certificates for cryptographic algorithms
How to read CAVP algorithm validation certificates and CMVP module validation certificates without overstating FIPS-approved cryptographic algorithm claims.
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.
How FIPS 180-4 and FIPS 202 Hash Functions Fit FIPS Algorithm Approval
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
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
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
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
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.
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.