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.

Artifact GuideGLOBALFIPS cryptographic algorithms

AES requirements under FIPS 197

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

Based on 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
Jul 25, 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 Jul 25, 2026
Overview

FIPS 197 specifies 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 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 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. The standard became effective on May 26, 2002. NIST's May 9, 2023 update added diagrams and editorial improvements but made no technical change to the algorithm.

FIPS 197 applies to information systems used or operated by US federal agencies, contractors, or other organizations on an agency's behalf. A private organization may adopt it voluntarily or through a contract or policy. The system owner should record which instrument makes FIPS 197 relevant; the algorithm name alone does not create a universal legal duty.

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 shall be used with a FIPS-approved or NIST-recommended mode of operation. The separate mode or protocol specification controls matters such as initialization values or nonces, padding, authentication tags, error handling, and whether the construction provides confidentiality, authentication, or both.

  • Record whether the implementation uses -128, AES-192, or AES-256.
  • Record that the block size is 128 bits for the FIPS 197 configurations.
  • Do not describe non-standard Rijndael configurations as under FIPS 197.
  • Keep mode-of-operation decisions separate from the block cipher selection; AES-256 names a key size, not an authenticated-encryption construction.
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 implementation is not the same thing as a validated cryptographic module. 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 " means FIPS validated." Safer wording names the algorithm, the mode, the cryptographic module or library, and any relevant CMVP or evidence separately.

  • Use FIPS 197 to support the algorithm claim.
  • Use a NIST-recommended mode source for CBC, GCM, XTS, KW, or other mode-specific claims.
  • Use CMVP module records for module validation claims.
  • Use 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

Keep the evidence narrow and technical. The product or system owner records the required service and allowed claim; the implementer records the configuration, mode, key handling, library or hardware path, and release; the assessor or buyer checks that evidence against any and CMVP records. The completed review should show why the selected mode fits the service 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. The key size alone cannot answer whether the mode, nonce construction, tag length, key lifecycle, or protocol profile is acceptable.

  • 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 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

This AES FIPS 197 guidance helps 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

Review this checklist before publishing an 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 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 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 FIPS 197 errors cross claim boundaries. Name what was selected, tested, or validated, and remove wording that implies broader assurance than the source supports.

  • Do not call modes, protocols, products, or modules FIPS 197-approved unless the source actually covers that layer.
  • Do not cite a algorithm certificate as proof that the whole product is 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 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.
"modes of operation"
Related guides

Explore more topics

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