What does FIPS 140-2 or FIPS 140-3 validation actually establish?

It establishes that a specific, named cryptographic module, a defined boundary of hardware, firmware, or software, was tested by an accredited Cryptographic and Security Testing Laboratory (CSTL) against the security requirements in the standard and that CMVP reviewed the submission and validated the module. The result is a certificate on the NIST Cryptographic Module Validation Program (CMVP) list naming the vendor, the module, the validated version, and the algorithms it implements. Validation is a property of that tested module and its certificate, not a general property of an algorithm, a product line, or a company. Lightbridge Cloud is an independent readiness advisor and does not issue or represent any FIPS validation itself.

Is "AES-256 encrypted" the same claim as "FIPS validated"?

No, and this is the most common confusion buyers run into. AES-256 is a cryptographic algorithm: the math for turning plaintext into ciphertext. A vendor can implement AES-256 correctly using a cryptographic library that was never submitted to CMVP for testing, and the data is still genuinely encrypted with that algorithm. FIPS validation additionally requires that the exact implementation, including key management, self-tests, and role-based controls, was tested by an accredited CSTL and reviewed and validated by CMVP. A marketing sentence that says only "AES-256 encryption" without naming a CMVP certificate number is describing the algorithm, not confirming a validated module.

What should we ask a cloud or software vendor to prove FIPS validation?

Ask for the specific CMVP certificate number, not a general statement such as "FIPS 140-3 compliant" or "uses FIPS-approved algorithms." "FIPS 140-3 compliant" is a vendor assertion, not evidence of CMVP validation. "FIPS-approved algorithms" is technically meaningful, but it does not establish module validation. A real answer names the certificate, the exact module and version validated, and the approved algorithms and modes it covers. Confirm that certificate is what is actually deployed in your environment, since a validation applies to a specific module boundary and version, and check whether it is Active, Historical, or revoked. Under CMVP policy, FIPS 140-2 modules move to Historical status after September 21, 2026; Historical modules may serve existing systems, while Active modules may serve new systems. Applicable procurements, agencies, or contracts may impose additional requirements. A vendor that cannot produce a certificate number, only marketing language, has not demonstrated FIPS validation.

Can a cloud provider be "FIPS compliant" without every service being FIPS validated?

Yes. A provider's broad "FIPS compliant" language does not prove that every service uses a validated module. Large cloud providers often operate specific regions, endpoints, or configurations, frequently labeled GovCloud, government, or FIPS endpoints, that route cryptographic operations through validated modules, while their standard commercial regions or default configurations may not. Using the provider generally does not automatically mean every workload inherits a validation. Confirm which specific endpoint, region, or configuration routes the relevant cryptographic operation through a validated module in its approved mode, and confirm the workload protecting CUI is actually deployed there, rather than assuming a provider-wide claim covers every service.

How does Lightbridge Cloud help with FIPS-validated cryptography for CUI?

Lightbridge Cloud is an independent readiness advisor. It is not a testing laboratory and does not issue or hold FIPS validations. The work is advisory: mapping NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 and related security requirements to the actual encryption modules a contractor's systems and vendors use, verifying CMVP certificate claims rather than accepting marketing language, and closing gaps as part of broader DFARS, NIST SP 800-171, and CMMC readiness. See the CMMC compliance readiness service for how this fits the full assessment path.

SK Written by Sarika Krishnan with Robert LabardeeSenior Program Manager and Founder and CEO

Last updated August 2026.

FIPS 140-2 and 140-3 Validated Cryptography

Lightbridge Cloud is an independent readiness advisor. FIPS 140-2 and FIPS 140-3 are federal standards for cryptographic-module security. Cryptographic and Security Testing Laboratories (CSTLs) test modules, and CMVP validates them. For contracts invoking DFARS 252.204-7012, CMMC Level 2, or applicable requirements, NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 requires FIPS-validated cryptography when used to protect the confidentiality of CUI. “AES-256 encrypted” alone does not establish validation.

CMMC readiness DFARS and NIST 800-171

"AES-256 encrypted" describes an algorithm. FIPS validation confirms a tested module.

These two claims get treated as interchangeable in vendor marketing, and they are not. One names the math. The other names a specific, tested implementation of that math, with a certificate to show for it. A defense contractor evaluating a vendor for CUI workloads needs to know which claim is actually being made.

AES-256 is an algorithm

The Advanced Encryption Standard with a 256-bit key is a cryptographic algorithm published by NIST. It describes math: how to transform plaintext into ciphertext and back. Naming the algorithm says nothing about how it was implemented, whether that implementation was tested, or whether it handles keys correctly.

FIPS 140-2/140-3 validation covers a tested module

A FIPS validation applies to a specific cryptographic module: a defined boundary of hardware, firmware, or software that implements one or more approved algorithms (AES-256 among them) plus the surrounding requirements for key management, self-tests, roles, and physical or logical protection. An accredited Cryptographic and Security Testing Laboratory (CSTL) tests that exact module and submits its results to CMVP. CMVP, jointly run by NIST and the Canadian Centre for Cyber Security, reviews the submission and validates the module, issuing a certificate when the requirements are met.

Why the gap matters in practice

A vendor can build a product that uses AES-256 correctly in the algorithmic sense while running it through an off-the-shelf or custom cryptographic library that has never been submitted for CMVP testing. The data is genuinely encrypted with a strong algorithm. It is not FIPS validated, because validation is a property of the tested module and its certificate, not of the algorithm name in the marketing copy.

CMVP is the program. The validated modules list is the proof.

The Cryptographic Module Validation Program, run jointly by NIST and the Canadian Centre for Cyber Security, is the mechanism behind every FIPS 140-2 and FIPS 140-3 certificate. An accredited, organizationally independent Cryptographic and Security Testing Laboratory (CSTL) tests a specific module against the standard's requirements: approved algorithms, key management, self-tests on startup and during operation, roles and services, with authentication as required by the claimed security level (mandatory at Security Level 2 and above, but not at Level 1), and physical or logical protection of the module boundary. The laboratory submits its results to CMVP, which reviews the submission and validates the module.

When CMVP validates a module, it publishes a certificate on its validated modules list naming the vendor, the exact module and version tested, and the algorithms and modes it covers. That list, not a vendor's own compliance page, is the authoritative record. A phrase such as "FIPS 140-3 compliant" is a vendor assertion, not evidence of CMVP validation. "FIPS-approved algorithms" has technical meaning, but it does not establish module validation. If a vendor cannot point to a certificate number on that list, its FIPS validation claim has not been demonstrated.

Lightbridge Cloud is an independent readiness advisor. It is not a testing laboratory and does not perform or hold CMVP validations. This guide describes the program as NIST publishes it, and any specific certificate status should be confirmed directly on the CMVP list, since it changes over time.

FIPS 140-2 is being phased out. FIPS 140-3 is the current standard.

Both standards define requirements for validated cryptographic modules, but they are not the same generation, and knowing which one a certificate belongs to changes how much weight to put on it.

FIPS 140-1 (1994) and FIPS 140-2 (2001)

FIPS 140-2 has been the working standard for two decades and underlies most cryptographic modules validated to date. NIST set September 22, 2021 as the general cutoff for new FIPS 140-2 submissions. Approved grandfathered submissions could be accepted through March 31, 2022, and April 1, 2022 marked the cutoff for new FIPS 140-2 validation submissions; CMVP could still issue certificates afterward for submissions accepted before that cutoff. Existing modules may remain usable under applicable CMVP transition policy or an agency risk determination.

FIPS 140-3 (effective September 22, 2019)

FIPS 140-3 adopts ISO/IEC 19790 as its technical requirements and ISO/IEC 24759 for test methods, aligning the US federal standard with the international one. FIPS 140-3 became effective on September 22, 2019, and CMVP began accepting FIPS 140-3 submissions on September 22, 2020. It is the standard open for new module submissions, and CMVP policy moves FIPS 140-2 modules to Historical status after September 21, 2026.

What this means for a buyer today

A currently active FIPS 140-2 certificate is not automatically a red flag. Under CMVP policy, FIPS 140-2 modules move to Historical status after September 21, 2026. Historical modules may serve existing systems, while Active modules may serve new systems; an applicable procurement, agency, or contract may impose additional requirements. A revoked module is different: its validation is no longer valid. Check the certificate status on the CMVP list rather than assuming a validation is current because a vendor once mentioned it. New procurements should increasingly expect FIPS 140-3.

Sunset dates, transition periods, and historical-list rules are set by NIST and CMVP policy and are revised periodically. Verify current cutoffs against NIST's own publications before relying on a specific date.

NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 is where this stops being theoretical.

In NIST SP 800-171 Rev. 2, requirement 3.13.11, in the System and Communications Protection family, requires employing FIPS-validated cryptography when it is used to protect the confidentiality of CUI. CMMC Level 2 uses the corresponding SC.L2-3.13.11 requirement. These obligations become binding through an applicable contract or agreement, such as one invoking DFARS 252.204-7012 or CMMC Level 2, and do not apply universally to every defense contractor. They do not independently require FIPS validation for every other use of cryptography inside a protected environment or every CUI-adjacent workload. That requirement is the reason a generic encryption claim is not enough. The module doing the encrypting must have a CMVP validation whose status and permitted use fit the applicable policy or contract.

NIST SP 800-171 Rev. 2 has 110 requirements across 14 families. NIST SP 800-171 Rev. 3 supersedes Rev. 2, has 17 families, and labels 03.13.11 "Cryptographic Protection." Rev. 3 uses organization-defined cryptography, and its discussion recommends rather than categorically requires FIPS validation. Our guide to DFARS 252.204-7012 and NIST SP 800-171 covers the full set of security requirements, the SPRS self-assessment, and how the standard ladders up to CMMC. During a CMMC Level 2 self-assessment or C3PAO assessment, an assessor looking at SC.L2-3.13.11 will expect evidence tied to an actual CMVP certificate, not a sentence describing an algorithm.

Key custody is a related but distinct question: even a validated module needs a defensible answer to who holds the keys. See our guide on BYOK vs HYOK encryption for that side of the picture.

What to verify before trusting a vendor's FIPS claim.

A short verification checklist closes most of the gap between a marketing sentence and an assessment-ready answer.

Ask for the CMVP certificate number

Ask for the specific certificate number on the NIST CMVP validated modules list. A statement such as "FIPS 140-3 compliant" is a vendor assertion, not evidence that CMVP has validated the module. "FIPS-approved algorithms" has technical meaning, but it does not establish module validation. A real certificate names the module, the vendor, the validated version, and the approved algorithms and modes it covers.

Confirm the certificate covers what is actually deployed

A validation applies to an exact module version and configuration, sometimes down to a specific operational environment. A certificate for an older version of a product, or for a component the vendor no longer ships in the way it was tested, does not carry forward automatically. Ask whether the deployed version matches the certificate.

Check whether the module is on the active or historical list

CMVP maintains Active and Historical lists. Historical entries can include certificates that have expired, been superseded, or moved under transition policy. Under CMVP policy, FIPS 140-2 modules move to Historical status after September 21, 2026. Historical modules may serve existing systems, while Active modules may serve new systems; applicable procurements, agencies, or contracts may impose additional requirements. A revoked module is different: its validation is no longer valid.

Distinguish the module boundary from the whole product

A validated cryptographic module is often a narrow component (a library, a chip, an operating system kernel crypto provider) embedded inside a much larger product. Confirm that the specific encryption operation protecting CUI, at rest and in transit, actually runs through the validated module boundary rather than a different code path in the same product.

Lightbridge Cloud verifies vendor cryptography claims as an independent advisor.

Lightbridge Cloud is an independent, vendor-neutral readiness advisor. It supports FIPS-validated cryptography readiness as part of broader NIST SP 800-171 and CMMC work: mapping NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 and related security requirements to the actual modules a contractor's platforms and vendors run, requesting and checking CMVP certificate numbers rather than accepting compliance language at face value, and closing gaps where a deployed configuration does not match what a certificate actually covers.

Lightbridge Cloud does not perform CMVP testing, does not issue FIPS validations, and makes no organization-level FIPS claim. It accepts no vendor kickbacks and carries no reseller quotas, so a recommendation to use one platform's endpoint over another is based on evidence that the endpoint routes the relevant operation through a validated module in its approved mode, rather than on a partner incentive. For the full readiness path, see CMMC compliance readiness and the DFARS and NIST 800-171 guide.

This guide is general information, not legal or audit advice. FIPS 140-2, FIPS 140-3, CMVP policy, and NIST SP 800-171 security-requirement text and numbering change over time. Verify any specific certificate, sunset date, or security requirement against the official source, including NIST, CMVP, and acquisition.gov, and consult qualified counsel or an authorized C3PAO for your situation. Any product or platform names mentioned are trademarks of their respective owners; Lightbridge Cloud is independent and is not affiliated with, endorsed by, or a partner tier of any vendor.

FIPS 140-2 and 140-3: frequently asked questions

What does FIPS 140-2 or FIPS 140-3 validation actually establish?: It establishes that a specific, named cryptographic module, a defined boundary of hardware, firmware, or software, was tested by an accredited Cryptographic and Security Testing Laboratory (CSTL) against the security requirements in the standard and that CMVP reviewed the submission and validated the module. The result is a certificate on the NIST Cryptographic Module Validation Program (CMVP) list naming the vendor, the module, the validated version, and the algorithms it implements. Validation is a property of that tested module and its certificate, not a general property of an algorithm, a product line, or a company. Lightbridge Cloud is an independent readiness advisor and does not issue or represent any FIPS validation itself.
Is "AES-256 encrypted" the same claim as "FIPS validated"?: No, and this is the most common confusion buyers run into. AES-256 is a cryptographic algorithm: the math for turning plaintext into ciphertext. A vendor can implement AES-256 correctly using a cryptographic library that was never submitted to CMVP for testing, and the data is still genuinely encrypted with that algorithm. FIPS validation additionally requires that the exact implementation, including key management, self-tests, and role-based controls, was tested by an accredited CSTL and reviewed and validated by CMVP. A marketing sentence that says only "AES-256 encryption" without naming a CMVP certificate number is describing the algorithm, not confirming a validated module.
Does NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 require FIPS-validated cryptography?: In NIST SP 800-171 Rev. 2, requirement 3.13.11 requires employing FIPS-validated cryptography when it is used to protect the confidentiality of CUI. CMMC Level 2 uses the corresponding SC.L2-3.13.11 requirement. These obligations apply when incorporated through an applicable contract or agreement, such as DFARS 252.204-7012, CMMC Level 2, or another contractual requirement, not universally to every defense contractor. They do not independently require FIPS validation for every other use of cryptography inside a protected environment or every CUI-adjacent workload. NIST SP 800-171 Rev. 3 supersedes Rev. 2 and uses 03.13.11, "Cryptographic Protection." Rev. 3 uses organization-defined cryptography, and its discussion recommends rather than categorically requires FIPS validation. In practice, the specific module doing the encrypting or decrypting needs a CMVP validation whose status and permitted use fit the applicable policy or contract. Under CMVP policy, FIPS 140-2 modules move to Historical status after September 21, 2026; Historical modules may serve existing systems, while Active modules may serve new systems. Applicable procurements, agencies, or contracts may impose additional requirements, while a revoked validation is no longer valid. Lightbridge Cloud helps contractors map this requirement to actual vendor and platform choices as an independent readiness advisor.
What is the difference between FIPS 140-2 and FIPS 140-3?: FIPS 140-2, published in 2001, has been the working standard for most validated modules for two decades. Its general cutoff for new submissions was September 22, 2021. Approved grandfathered submissions could be accepted through March 31, 2022, and April 1, 2022 marked the cutoff for new FIPS 140-2 validation submissions; CMVP could still issue certificates afterward for submissions accepted before that cutoff. FIPS 140-3 became effective on September 22, 2019, and CMVP began accepting FIPS 140-3 submissions on September 22, 2020. It is the standard open for new module submissions and adopts ISO/IEC 19790 and ISO/IEC 24759 as its technical basis. CMVP policy moves FIPS 140-2 modules to Historical status after September 21, 2026. Historical modules may serve existing systems, while Active modules may serve new systems; applicable procurements, agencies, or contracts may impose additional requirements. A revoked module is not valid. Confirm certificate status and permitted use on the CMVP list.
What should we ask a cloud or software vendor to prove FIPS validation?: Ask for the specific CMVP certificate number, not a general statement such as "FIPS 140-3 compliant" or "uses FIPS-approved algorithms." "FIPS 140-3 compliant" is a vendor assertion, not evidence of CMVP validation. "FIPS-approved algorithms" is technically meaningful, but it does not establish module validation. A real answer names the certificate, the exact module and version validated, and the approved algorithms and modes it covers. Confirm that certificate is what is actually deployed in your environment, since a validation applies to a specific module boundary and version, and check whether it is Active, Historical, or revoked. Under CMVP policy, FIPS 140-2 modules move to Historical status after September 21, 2026; Historical modules may serve existing systems, while Active modules may serve new systems. Applicable procurements, agencies, or contracts may impose additional requirements. A vendor that cannot produce a certificate number, only marketing language, has not demonstrated FIPS validation.
Can a cloud provider be "FIPS compliant" without every service being FIPS validated?: Yes. A provider's broad "FIPS compliant" language does not prove that every service uses a validated module. Large cloud providers often operate specific regions, endpoints, or configurations, frequently labeled GovCloud, government, or FIPS endpoints, that route cryptographic operations through validated modules, while their standard commercial regions or default configurations may not. Using the provider generally does not automatically mean every workload inherits a validation. Confirm which specific endpoint, region, or configuration routes the relevant cryptographic operation through a validated module in its approved mode, and confirm the workload protecting CUI is actually deployed there, rather than assuming a provider-wide claim covers every service.
Where is the authoritative source for validated modules?: The NIST Cryptographic Module Validation Program (CMVP) maintains the validated modules list and is run jointly by NIST and the Canadian Centre for Cyber Security. CMVP is the authoritative source for a module's FIPS 140-2 or FIPS 140-3 validation record and certificate status. Under CMVP policy, Historical modules may serve existing systems, while Active modules may serve new systems; an applicable procurement, agency, or contract may impose additional requirements. A historical listing does not by itself answer whether your use is allowed, so resolve any applicable agency risk determination or other use restriction. A revoked module's validation is no longer valid. Vendor documentation and sales materials are not authoritative on their own; treat any FIPS claim as a pointer to verify against the CMVP list itself.
How does Lightbridge Cloud help with FIPS-validated cryptography for CUI?: Lightbridge Cloud is an independent readiness advisor. It is not a testing laboratory and does not issue or hold FIPS validations. The work is advisory: mapping NIST SP 800-171 Rev. 2 requirement 3.13.11 / CMMC SC.L2-3.13.11 and related security requirements to the actual encryption modules a contractor's systems and vendors use, verifying CMVP certificate claims rather than accepting marketing language, and closing gaps as part of broader DFARS, NIST SP 800-171, and CMMC readiness. See the CMMC compliance readiness service for how this fits the full assessment path.

From an algorithm claim to a verified certificate.

When the question shifts from what a vendor says to what actually satisfies 3.13.11, Lightbridge Cloud runs a vendor-neutral review of your cryptography posture and the evidence behind it.

Talk to a compliance advisor See CMMC readiness