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-approved cryptographic algorithm requirements

FIPS 203 ML-KEM vs RSA and ECDH

Compare ML-KEM, RSA, and ECDH as key-establishment choices without turning algorithm approval into an unsupported product-validation claim.

Based on FIPS 203, NIST SP 800-56A, NIST SP 800-56B, CAVP, and CMVP/FIPS 140-3 context. Use it as implementation guidance, not for legal interpretation.

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

Choose ML-KEM when the design requires the post-quantum in FIPS 203 and the protocol supports its keys, ciphertexts, shared secret, authentication model, and validation path. Keep ECDH or RSA key establishment when the controlling protocol, interoperability requirement, or validated module depends on an SP 800-56A or SP 800-56B scheme. These primitives are not drop-in substitutes: record the exact scheme, parameters, , protocol construction, CAVP evidence, and FIPS 140-3 module boundary.

Side-by-side comparison

FIPS 203 ML-KEM vs RSA and ECDH: what changes operationally?

This comparison helps decide which NIST source, parameter choices, validation records, and module-boundary evidence control an ML-KEM, RSA, or ECDH key-establishment claim.

Review all sources
First framework
FIPS 203 ML-KEM

ML-KEM is a FIPS 203 with three parameter sets and distinct KeyGen, encapsulation, and decapsulation evidence needs.

Second framework
RSA and ECDH key establishment

RSA and ECDH are classical key-establishment choices based on the SP 800-56 series, with scheme, parameter, KDF, and key-confirmation evidence that differs from ML-KEM.

Scope

FIPS 203 ML-KEM

Use FIPS 203 for ML-KEM algorithm behavior, including key generation, encapsulation, decapsulation, and the ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets.

RSA and ECDH key establishment

Use SP 800-56A for ECDH and other discrete-logarithm key-agreement schemes; use SP 800-56B for RSA key agreement or key transport based on integer factorization.

Operational implication

Identify whether the claim is KEM-based (ML-KEM), key-agreement-based (ECDH or RSA), or key-transport-based (RSA) before mapping to the applicable NIST publication.

Covered actors

FIPS 203 ML-KEM

FIPS 203 applies to federal systems that select ML-KEM for establishing a shared secret, including systems operated for agencies under contract. Private and commercial organizations may also adopt it.

RSA and ECDH key establishment

SP 800-56A and SP 800-56B specify approved classical schemes for systems that select ECDH, finite-field Diffie-Hellman, or RSA key establishment. The applicable contract or system policy determines who must follow them.

Operational implication

Do not infer a migration mandate from the actor's name. Identify the policy, contract, protocol, or risk decision that selects the scheme.

Key-establishment method

FIPS 203 ML-KEM

ML-KEM is a KEM: one party encapsulates to a public key and another decapsulates with the private key so both derive shared secret material under the conditions specified by FIPS 203.

RSA and ECDH key establishment

ECDH is pair-wise key agreement; RSA key establishment under SP 800-56B can be key agreement or key transport, with scheme-specific key-confirmation and assurance requirements.

Operational implication

Distinguish KEM encapsulation (ML-KEM) from pair-wise key agreement (ECDH) or key transport (RSA); the mechanism type determines which NIST publication governs.

Core obligations

FIPS 203 ML-KEM

Record the ML-KEM parameter set, supported operations, input checks, RBG strength, key and ciphertext sizes, and handling of the 32-byte shared secret for the implementation and operating environment being cited.

RSA and ECDH key establishment

Record the approved elliptic curve and domain parameters for ECDH, the RSA key size and scheme for RSA, plus the KDF, key-confirmation method, and protocol profile that bind the shared secret to the session.

Operational implication

The scheme name alone is insufficient. Preserve the parameters, operation, validation record, protocol binding, authentication method, and key-handling rules that make the implementation claim reproducible.

Evidence

FIPS 203 ML-KEM

ML-KEM evidence should identify the validation record for the implementation, version, algorithm capability, operating environment, and whether the tested capability covers the operation relied on.

RSA and ECDH key establishment

RSA and ECDH evidence should identify their own validation records and must not be reused as proof that an ML-KEM implementation has been tested.

Operational implication

Collect validation evidence for the specific algorithm variant and parameter set; ML-KEM CAVP records cannot substitute for RSA/ECDH records and vice versa.

Transition considerations

FIPS 203 ML-KEM

Adding ML-KEM can require protocol support, hybrid or transition design, parameter-set selection, new validation evidence, and new customer-facing wording.

RSA and ECDH key establishment

Keeping RSA or ECDH can be justified by interoperability, existing protocol profiles, certificate ecosystems, or validation timing, but the reason should be recorded rather than implied.

Operational implication

Justify the timing decision: ML-KEM requires post-quantum migration planning; RSA/ECDH can be justified by interoperability and existing protocol profiles.

Module validation and claim checks

FIPS 203 ML-KEM

If ML-KEM is part of a FIPS 140-3 claim, confirm that the implementation is inside the validated cryptographic module boundary and is described consistently in the module security policy and approved services.

RSA and ECDH key establishment

For RSA or ECDH, confirm the same boundary, certificate, security policy, operating environment, and approved-mode conditions before relying on a product-level FIPS statement.

Operational implication

Confirm the FIPS 140-3 module boundary covers the correct algorithm; ML-KEM and RSA/ECDH boundary requirements are similar but parameter sets differ.

Overlap

FIPS 203 ML-KEM

ML-KEM and RSA/ECDH implementations may both sit inside a FIPS 140-3 cryptographic module boundary, but each scheme needs matching algorithm-validation evidence and Security Policy treatment.

RSA and ECDH key establishment

FIPS 203 specifies ML-KEM; SP 800-56A and SP 800-56B govern the cited classical schemes. FIPS 203 does not itself set a withdrawal date for RSA or ECDH. A hybrid design may require separate evidence for the post-quantum and classical components within the same module boundary.

Operational implication

If one module boundary is meant to cover both ML-KEM and RSA/ECDH, verify that the certificate, security policy, and validation records name each algorithm and operating environment explicitly; otherwise split the claim into separate scheme-specific evidence trails.

Practical decision rule

FIPS 203 ML-KEM

Use ML-KEM when the design, procurement, or transition plan specifically requires FIPS 203 post-quantum key encapsulation and the implementation evidence supports the claim.

RSA and ECDH key establishment

Use RSA or ECDH language when the controlling protocol profile, legacy interoperability requirement, module certificate, or procurement clause is actually written around SP 800-56A or SP 800-56B schemes.

Operational implication

Do not collapse the three options into one checklist; make a scheme-by-scheme decision record with separate source, parameter, validation, and module-boundary fields.

Practical decision rule

How to choose the controlling claim

  • Choose FIPS 203 when the claim is about ML-KEM algorithm behavior, parameter sets, or post-quantum key encapsulation.
  • Choose SP 800-56A or SP 800-56B when the claim is about classical ECDH or RSA key-establishment schemes.
  • Choose CAVP evidence when the claim is about a tested algorithm implementation, and CMVP evidence when the claim is about a validated cryptographic module.
  • Escalate the wording when marketing, procurement, or security documentation says FIPS compliant without naming the algorithm validation, module certificate, and approved-mode basis.
Section 1

What changes when ML-KEM enters an RSA or ECDH design?

FIPS 203 standardizes ML-KEM key generation, encapsulation, decapsulation, and three approved parameter sets: ML-KEM-512, ML-KEM-768, and ML-KEM-1024. They target NIST security categories 1, 3, and 5. RSA and ECDH key-establishment work is based on the SP 800-56 series instead: SP 800-56B for integer-factorization schemes, including RSA, and SP 800-56A for discrete-logarithm schemes, including elliptic-curve Diffie-Hellman.

ML-KEM always produces a 32-byte shared secret. Its encapsulation-key, decapsulation-key, and ciphertext sizes are 800/1,632/768 bytes for ML-KEM-512, 1,184/2,400/1,088 bytes for ML-KEM-768, and 1,568/3,168/1,568 bytes for ML-KEM-1024. Test those sizes against handshake limits, key containers, hardware interfaces, logs, and packet fragmentation before choosing a set.

ML-KEM decapsulation uses : a correctly sized but internally invalid ciphertext does not produce a distinct invalid-ciphertext result. The surrounding authenticated protocol must establish peer identity and any required . Avoid exposing internal validity through errors, timing, or fallback behavior.

  • Treat ML-KEM as a FIPS 203 KEM decision, not as a drop-in synonym for all existing key agreement.
  • Treat ECDH as an SP 800-56A discrete-logarithm key-agreement decision tied to approved curves, roles, and domain parameters.
  • Treat RSA key establishment as an SP 800-56B integer-factorization decision tied to RSA key-pair generation, key agreement or key transport, and key-confirmation choices.
  • For ML-KEM, use an approved RBG with at least 128, 192, or 256 bits of security strength for ML-KEM-512, ML-KEM-768, or ML-KEM-1024 respectively, and generate fresh randomness for every KeyGen and Encaps invocation.
  • Keep the algorithm evidence separate from the module-validation evidence until the FIPS 140-3 certificate boundary and approved mode are confirmed.
Section 2

Key-establishment decision rules for ML-KEM, RSA, and ECDH

Start with the source that governs the implemented primitive. Use FIPS 203 for ML-KEM parameter-set and algorithm-behavior claims; use SP 800-56A for ECDH-style pair-wise key agreement; use SP 800-56B for RSA key agreement or key transport. FIPS 203 permits its 256-bit output to be used directly as a shared secret key under the stated conditions. If the application derives further keys, it must use an approved method such as one specified in SP 800-108 or SP 800-56C.

Avoid claims that a primitive is FIPS validated by itself. CAVP evidence supports an algorithm implementation, while CMVP evidence supports a cryptographic module. A product, service, protocol, or library claim should say which certificate, validation entry, module version, operating environment, and approved-mode statement the team is relying on.

  • For ML-KEM, record ML-KEM-512, ML-KEM-768, or ML-KEM-1024 and whether the evidence covers KeyGen, encapsulation, decapsulation, or the applicable combined capability.
  • For ECDH, record the SP 800-56A scheme, approved elliptic curve and domain parameters, party role, key-confirmation choice, and KDF context.
  • For RSA, record the SP 800-56B scheme, key size, key agreement or key transport use, key-confirmation choice, and KDF or wrapping context.
  • For FIPS 140-3 claims, connect the algorithm evidence to the specific module certificate, security policy, operational environment, and approved mode.
Section 3

Evidence to keep for a FIPS-facing comparison

Produce a separate evidence record for each implementation. Tie the source, algorithm identifier, parameter choice, implementation version, operational environment, protocol use case, CAVP validation status, and CMVP module status together.

When CAVP evidence exists, verify that the validation entry matches the algorithm implementation and operating environment being used. When a FIPS 140-3 claim exists, verify the module certificate and security policy rather than assuming every algorithm in a product inherits the module's approved-mode claim.

  • Source: FIPS 203, SP 800-56A, or SP 800-56B section or publication that governs the implemented scheme.
  • Algorithm evidence: CAVP validation entry, algorithm capability, implementation name, version, vendor, and operating environment.
  • Module evidence: CMVP certificate, module name and version, security policy, approved services, and approved-mode conditions.
  • Protocol evidence: TLS, SSH, CMS, VPN, or application profile showing how the shared secret is derived, confirmed, and consumed.
  • Change trigger: reassess when parameter sets, curves, RSA key sizes, KDFs, protocol profiles, module boundaries, or operating environments change.
Recommended next step

Document ML-KEM, RSA, and ECDH decisions

Use the comparison to produce a cited record of schemes, parameters, validation evidence, module boundaries, and customer-facing wording.

Assessment workflow
Open Assessment Autopilot for FIPS algorithm evidence

Convert ML-KEM, RSA, and ECDH choices into owners, evidence requests, validation checks, and release gates.

Explore next step
Research workflow
Research FIPS key-establishment source questions

Resolve source, parameter, validation, and module-boundary questions before public or procurement claims are written.

Explore next step
Talk to Sorena
Talk through implementation

Review the scheme choices, evidence gaps, and FIPS-facing wording with Sorena.

Explore next step
Section 4

Migration planning without overclaiming post-quantum coverage

ML-KEM is designed for post-quantum key establishment, while RSA and ECDH are classical public-key mechanisms. That does not make every ML-KEM integration automatically production-ready, FIPS 140-3 validated, protocol-approved, or suitable for every relying party. The migration plan still needs protocol support, hybrid or transition design, algorithm validation, module validation, performance testing, and customer acceptance evidence.

When a system keeps RSA or ECDH during migration, document why: interoperability, certificate ecosystem constraints, protocol profile limits, customer requirements, or staged module-validation timing. When it adds ML-KEM, document the target parameter set, validation path, fallback behavior, and how the shared secret is combined or consumed.

  • Do not describe ML-KEM as a signature replacement; keep it scoped to key encapsulation and key establishment.
  • Do not describe RSA and ECDH as deprecated unless the specific procurement clause, protocol profile, transition table, or assessor rule says so.
  • If a hybrid design is used, record exactly how ML-KEM output is combined with classical key-establishment output and which source governs that construction.
  • Use CAVP and CMVP records to support validation claims, not marketing descriptions of algorithm support.
Section 5

Implementation checklist for ML-KEM vs RSA and ECDH

Treat this checklist as the release or evidence gate for a product-level decision. Each item should be answerable from a source, a validation record, a module security policy, a protocol profile, or an engineering artifact.

  • Name the controlling source for each scheme: FIPS 203 for ML-KEM, SP 800-56A for ECDH, and SP 800-56B for RSA key establishment.
  • Record the parameter set, curve, group, RSA key size, KDF, key-confirmation behavior, and protocol profile used by the implementation.
  • Check CAVP validation evidence for the exact implementation, algorithm capability, version, and operating environment being cited.
  • Check CMVP evidence before making a FIPS 140-3 module or approved-mode claim; cite the module certificate and security policy, not only the algorithm name.
  • Document migration exceptions, fallback behavior, hybrid design choices, and customer-facing wording so post-quantum support is not overstated.
Section 6

Common mistakes to avoid when handling ML-KEM vs RSA and ECDH

Most failures come from collapsing three different questions into one sentence: whether the algorithm is specified by NIST, whether an implementation has algorithm validation evidence, and whether a product uses that implementation inside a validated module's approved mode.

  • Do not cite post-quantum signature standards for this comparison unless the page is also making a separate digital-signature claim.
  • Do not call ML-KEM a replacement for RSA signatures or ECDSA; it is a .
  • Do not reuse an ECDH or RSA CAVP entry for ML-KEM evidence; each algorithm capability and operating environment needs its own support.
  • Do not claim a product is FIPS 140-3 validated from a CAVP algorithm validation alone.
  • Do not hide unsupported transition claims behind phrases such as quantum safe, FIPS ready, or compliant without naming the source and evidence.
Primary sources

References and citations

NIST FIPS 203 ML-KEM standard
csrc.nist.gov8 citations
Referenced sections
  • Primary source for ML-KEM algorithm behavior, parameter sets, and post-quantum key-encapsulation scope.
  • Defines ML-KEM, its parameter sets, and its key-generation, encapsulation, and decapsulation scope.
  • Supports the ML-KEM side of the decision and the three named parameter sets.
Show 5 more
  • Supports post-quantum ML-KEM scope and prevents treating ML-KEM as a signature standard.
  • Source for ML-KEM implementation and parameter-set checks.
  • Source for limiting ML-KEM claims to key encapsulation and its specified parameter sets.
  • Primary source for the ML-KEM side of the decision rule.
  • Primary source for ML-KEM decisions.
"Module-Lattice-Based Key-Encapsulation Mechanism Standard"
More quoted passages
"This standard specifies a key-encapsulation mechanism called ML-KEM."
"ML-KEM-512, ML-KEM-768, and ML-KEM-1024"
"key-encapsulation mechanism"
"three parameter sets"
"key generation, encapsulation, and decapsulation"
"ML-KEM"
NIST SP 800-56A Rev. 3 discrete-logarithm key establishment
csrc.nist.gov7 citations
Referenced sections
  • Primary source for ECDH and other discrete-logarithm pair-wise key-establishment schemes.
  • Primary source for ECDH and other pair-wise key-establishment schemes based on discrete logarithm cryptography.
  • Supports ECDH scheme and parameter decisions.
Show 4 more
  • Supports migration comparisons that retain classical elliptic-curve key agreement.
  • Source for ECDH and other discrete-logarithm key-establishment checks.
  • Primary source for ECDH-side decision records.
  • Primary source for ECDH key-establishment decisions.
"Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography"
More quoted passages
"Using Discrete Logarithm Cryptography"
"Pair-Wise Key-Establishment Schemes"
"Pair-Wise Key-Establishment"
"SP 800-56A Rev. 3"
"Discrete Logarithm Cryptography"
NIST SP 800-56B Rev. 2 integer-factorization key establishment
csrc.nist.gov7 citations
Referenced sections
  • Primary source for RSA key-establishment schemes based on integer factorization cryptography.
  • Primary source for RSA-based pair-wise key-establishment schemes.
  • Supports RSA key-establishment decisions and key-confirmation context.
Show 4 more
  • Supports migration comparisons that retain classical RSA key agreement or transport.
  • Source for RSA key-establishment checks.
  • Primary source for RSA-side decision records.
  • Primary source for RSA key-establishment decisions.
"Recommendation for Pair-Wise Key-Establishment Using Integer Factorization Cryptography"
More quoted passages
"in particular, RSA"
"key-agreement and key transport schemes"
"Integer Factorization Cryptography"
"key-establishment schemes using integer factorization"
"SP 800-56B Rev. 2"
NIST CAVP overview
csrc.nist.gov6 citations
Referenced sections
  • Supports algorithm-validation evidence and the distinction between CAVP evidence and CMVP module validation.
  • Explains that algorithm validation tests approved algorithms and is a prerequisite for cryptographic module validation.
  • Explains how CAVP records identify vendor, implementation, operating environment, validation date, and algorithm details.
Show 3 more
  • Source for the distinction between algorithm validation and module validation evidence.
  • Source for separating algorithm validation from cryptographic module validation claims.
  • Source for algorithm-validation evidence rules.
"Cryptographic Algorithm Validation Program"
More quoted passages
"validation testing of Approved"
"vendor, implementation, operational environment"
"prerequisite of cryptographic module validation"
"algorithm validation is a prerequisite"
"cryptographic algorithm validation process"
NIST CMVP validated modules search
csrc.nist.gov6 citations
Referenced sections
  • Supports checking whether a FIPS-facing product claim maps to a validated cryptographic module record.
  • Official source for checking whether a cryptographic module has been validated to FIPS 140-1, FIPS 140-2, or FIPS 140-3.
  • Public source for matching a product claim to a specific validated cryptographic module record.
Show 3 more
  • Source for checking validated module records before using product-level FIPS wording.
  • Use module records to support product-level FIPS wording.
  • Source for module-validation evidence checks.
"official validation information"
More quoted passages
"validated modules search"
"tested and validated"
"FIPS 140-3"
NIST CAVP validation search
csrc.nist.gov
Referenced sections
  • Public validation-search source for checking algorithm records before citing validation evidence.
"Cryptographic Algorithm Validation Program"

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

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.