FIPS 140-3 Validated Cryptography: What FedRAMP Requires

FedRAMP requires that every place your system uses cryptography to protect federal data, you use a cryptographic module that has been validated by NIST's Cryptographic Module Validation Program (CMVP) — not merely a module that claims to use approved algorithms. The current standard is FIPS 140-3. FIPS 140-2 modules are being sunset: as of September 21, 2026, CMVP moves all FIPS 140-2 certificates to the Historical list, where they may be used for existing systems only — never new ones. If a module isn't on the CMVP active validation list, NIST treats the data it "protects" as unprotected plaintext.

Key takeaways

• FedRAMP requires FIPS 140-validated cryptographic modules wherever federal data is encrypted at rest or in transit; the active standard is FIPS 140-3.
• "FIPS-validated" means a module holds a CMVP certificate you can look up by number. "FIPS-compliant" is a marketing phrase with no standing — NIST does not recognize it.
• As of September 21, 2026, FIPS 140-2 certificates move to the Historical list: usable for existing systems only, not new authorizations.
• A module is validated for a specific version and operational environment. Run a different build, and you are outside the validation boundary.
• Verify every certificate yourself on csrc.nist.gov; algorithm validation (CAVP) alone is not module validation.

What does FedRAMP require for cryptography?

FedRAMP requires that all cryptography used to protect federal information be performed by a FIPS 140-validated cryptographic module. This flows directly from federal law: under the relevant NIST standards, U.S. agencies must use validated cryptographic modules whenever they require information to be cryptographically protected. FedRAMP, as the program that authorizes cloud services for federal use, inherits and enforces that requirement through the NIST SP 800-53 control baseline.

The control most cloud service providers (CSPs) cite is SC-13, Cryptographic Protection, which requires that cryptographic uses comply with applicable federal standards — meaning FIPS 140-validated modules. Related controls reinforce it: SC-8 (transmission confidentiality and integrity) for data in transit, SC-28 (protection of information at rest) for data at rest, and IA-7 (cryptographic module authentication). Across all of them, the operative word is validated.

NIST is blunt about the consequence of skipping validation. In CMVP's own words, non-validated cryptography is viewed as providing no protection to the information — the data is, in effect, considered unprotected plaintext. That is why an assessor will not accept "we use AES-256" as evidence. They will ask which module performs that AES-256, and for its CMVP certificate number.

Source: NIST CMVP — "if cryptography is required, then it must be validated"

What is FIPS 140-3 validation?

FIPS 140-3 (Security Requirements for Cryptographic Modules) is the federal standard that defines what a cryptographic module must do to be trusted for protecting sensitive government information. Validation is the formal process, run by NIST and the Canadian Centre for Cyber Security through the CMVP, of testing a module against that standard and issuing a certificate.

The process works like this:

1. An accredited, independent Cryptographic and Security Testing Laboratory (CSTL) tests the module against FIPS 140-3 and its supporting publications (the SP 800-140 series).
2. The lab submits a report to CMVP, which reviews it and, if it passes, issues a numbered validation certificate.
3. The certificate lists the exact module name, version, security level, and the operational environment(s) in which the validation holds.

CMVP began accepting FIPS 140-3 submissions on September 22, 2020, and stopped accepting new FIPS 140-2 submissions after September 21, 2021. A FIPS 140-3 validation stays on the Active list for five years (two years for interim validations) and may be used for new and existing systems during that window.

Source: NIST CMVP Overview — validation timeline and applicability

What is the difference between FIPS-validated and FIPS-compliant?

This is the single most expensive misunderstanding in FedRAMP cryptography. FIPS-validated means the module has an actual CMVP certificate you can verify. FIPS-compliant is a vendor phrase that usually means "we implemented FIPS-approved algorithms" — but implementing an approved algorithm is not the same as having the module that runs it tested and certified. NIST does not recognize "compliant" as a status, and FedRAMP assessors do not accept it.

Attribute	FIPS 140 validated	"FIPS compliant" / "FIPS capable"
Has a CMVP certificate number	Yes — verifiable on csrc.nist.gov	No
Independently tested by an accredited CSTL	Yes	Not necessarily
Recognized by NIST and FedRAMP	Yes	No — not a NIST status
Acceptable as 3PAO evidence	Yes	No
What it actually guarantees	The module, at a stated version and environment, met FIPS 140	Only that an approved algorithm appears in the product

NIST's guidance makes the trap explicit: a product does not meet the FIPS 140 requirements "by simply implementing an approved security function and acquiring algorithm validation certificates." Algorithm validation (through the Cryptographic Algorithm Validation Program, CAVP) is a prerequisite for module validation — but on its own it does not make a module validated. If a vendor offers a CAVP certificate and calls the product "FIPS compliant," that is not enough for FedRAMP.

Source: NIST CMVP — Validated Modules guidance

Where do you need FIPS-validated crypto in a FedRAMP system?

You need a validated module everywhere federal data is cryptographically protected. In practice that means three domains: data at rest, data in transit, and the key management that supports both. The table below maps the common touchpoints.

Domain	Where it shows up	Relevant control	What an assessor checks
Data in transit	TLS for web/API traffic, VPN tunnels, internal service-to-service encryption	SC-8	The TLS/VPN endpoint uses a validated module; certificate covers the running version
Data at rest	Disk/volume encryption, database and object-storage encryption, backups	SC-28	The storage encryption engine is a validated module, not just "AES on"
Key management	Key generation, storage, and protection (often an HSM or KMS)	SC-12, SC-13	The KMS/HSM module holds a current CMVP certificate at the right environment
Authentication	Cryptographic authenticators, MFA secrets, password hashing	IA-7	Authentication crypto is performed by a validated module

A useful instinct: anywhere your SSP narrative says "encrypted," ask by which module, and what is its certificate number? If you can't answer that for a given data flow, that flow is a finding waiting to happen. For a refresher on how these claims land in your authorization package, see our FedRAMP documentation explained guide.

How do you verify a module is actually validated?

Don't take a vendor's word for it — look the certificate up yourself on the CMVP validated-modules search. Follow these steps for every cryptographic module in your boundary:

1. Get the certificate number from the vendor, in writing. NIST recommends asking the vendor for a signed letter stating the product is a validated module or embeds one, that the module provides all cryptographic services in the solution, and citing the certificate number.
2. Search csrc.nist.gov for that number and confirm the module name and vendor match what you're actually running.
3. Check the status. The certificate must be on the Active list. If it's Historical, it is for existing systems only; if it's Revoked, it cannot be referenced for compliance at all.
4. Match the version and operational environment. The certificate states the exact validated version, part number, and the operating system / platform it was tested on. If you run a different build or a different OS, you may be outside the validation.

This verification step is where Boundera's evidence automation earns its keep. Instead of a consultant chasing certificate numbers across a dozen vendors before an assessment, the platform inventories the cryptographic modules in your cloud configuration, ties each to its CMVP certificate, and flags any that are Historical, Revoked, or running a version the certificate doesn't cover. If you're moving toward the new program model, the same approach feeds machine-readable evidence — see how we automate KSI evidence for FedRAMP 20x.

What are the common FIPS validation pitfalls?

The findings repeat themselves across CSPs. The most common are:

• Treating "FIPS-compliant" as good enough. A product that implements approved algorithms but has no module certificate is not validated. This is the number-one mistake.
• Running the wrong version. The module is validated at a specific version; if you upgrade past it (or run an older build), you've stepped outside the validated boundary. Patches matter.
• Wrong operational environment. A module validated on one OS or platform is not automatically validated on another. Software/firmware modules have porting guidance, but you must follow it — assuming portability is risky.
• Relying on a Historical or Revoked certificate. A Historical module cannot back a new system; a Revoked one cannot be used at all. With the September 21, 2026 FIPS 140-2 sunset, modules you relied on last year may now be Historical.
• Enabling the product but not FIPS mode. Many products ship a validated module that only operates in the validated configuration when "FIPS mode" is explicitly turned on. Default settings often are not the validated mode.
• Confusing CAVP algorithm certificates with module validation. Algorithm validation is necessary but not sufficient; only the module certificate counts.

Each of these turns into an SC-13 or SC-28 finding, then a POA&M item, and sometimes a schedule slip while you swap in a validated module. The fix is almost always cheaper before the assessment than after.

How does the 2026 FIPS 140-2 sunset affect FedRAMP?

It moves the goalposts for new authorizations. Through September 21, 2026, a CSP could still rely on FIPS 140-2 validated modules for new systems. After that date, CMVP places all FIPS 140-2 certificates on the Historical list — meaning they are acceptable for existing systems only. Any system pursuing a new FedRAMP authorization should be standing on FIPS 140-3 validated modules.

If your environment still depends on FIPS 140-2 modules, treat the migration as a real project: inventory where those modules live, check whether the vendor has a FIPS 140-3 replacement validated and on the Active list, and plan the swap before it blocks an authorization. CMVP's own guidance is to keep using FIPS 140-2 modules until FIPS 140-3 replacements become available — but for new systems, that runway closed in September 2026. For the full lifecycle context, see our complete FedRAMP authorization guide.

Frequently asked questions

Does FedRAMP require FIPS 140-2 or FIPS 140-3?

FedRAMP requires a FIPS 140-validated module, and the current standard is FIPS 140-3. FIPS 140-2 modules were valid for new systems only through September 21, 2026; after that they move to the Historical list and can support existing systems only. New FedRAMP systems should use FIPS 140-3 validated modules.

Is "FIPS-compliant" acceptable for FedRAMP?

No. "FIPS-compliant" is not a NIST-recognized status. FedRAMP requires a FIPS-validated module with a CMVP certificate you can verify. NIST states that implementing an approved algorithm and obtaining algorithm validation does not, by itself, make a module FIPS 140 validated.

What happens if I use a non-validated cryptographic module?

NIST considers non-validated cryptography to provide no protection — the data is treated as unprotected plaintext. For FedRAMP, that means a control failure (typically SC-13 or SC-28), a finding in the SAR, and a POA&M item until you replace the module with a validated one.

Where can I check if a module is FIPS-validated?

On NIST's CMVP validated-modules search at csrc.nist.gov. Search by certificate number or vendor, confirm the module name and version match what you run, and check that the certificate is on the Active list rather than Historical or Revoked.

Is algorithm validation (CAVP) the same as module validation?

No. CAVP validates individual algorithms and is a prerequisite for module validation, but a module is only "validated" when it holds a CMVP certificate. A vendor offering only CAVP certificates has not demonstrated a FIPS 140 validated module.

Does the module version matter?

Yes. A CMVP certificate validates a specific module version and operational environment. Running a different build, a different OS, or a patched version not covered by the certificate can place you outside the validation boundary, which an assessor will treat as non-compliant.

Where in my system do I need validated crypto?

Anywhere federal data is encrypted — data in transit (TLS, VPNs), data at rest (disk, database, object storage, backups), the key management behind them (KMS/HSM), and cryptographic authentication. Map each "encrypted" claim in your SSP to a specific validated module and its certificate.

Do I need to turn on a "FIPS mode"?

Often, yes. Many products include a validated module but only operate in the validated configuration when FIPS mode is explicitly enabled. Default settings frequently are not the validated mode, so confirm and document that FIPS mode is active.

Sources

• NIST — Cryptographic Module Validation Program (CMVP) overview
• NIST — CMVP Validated Modules search and guidance
• FIPS 199 — Standards for Security Categorization (NIST)
• FedRAMP — official program site

---

Last updated: June 2026. Written by the Boundera team.