From FIPS 140-2 to FIPS 140-3: What FedRAMP Teams Are Missing

The Quiet Shift That Isn’t So Quiet

For years, FIPS 140-2 has been the foundation of cryptographic compliance in U.S. federal systems. If your organization achieved FedRAMP authorization, there’s a good chance your cryptographic story was built on FIPS 140-2 validated modules.

But that era is ending.

FIPS 140-3 is now the active standard, and while the transition may appear administrative on the surface, it introduces meaningful changes that FedRAMP teams can’t afford to ignore.

Many organizations assume that if they already use FIPS-validated cryptography, they’re covered. In reality, the move to 140-3 raises the bar—not just for validation, but for how cryptography is implemented, verified, and maintained in modern environments.

The takeaway is simple: this isn’t a certificate refresh. It’s a shift in expectations.

What Actually Changed in FIPS 140-3?

FIPS 140-3 aligns with international standards (ISO/IEC 19790 and 24759), bringing U.S. cryptographic validation into closer harmony with global frameworks. That sounds like a bureaucratic update, but the implications are technical and operational.

Some of the most important changes include:

• Stricter entropy requirements
  Greater emphasis on approved random number generation and entropy sources (aligned with NIST SP 800-90 series).
• More rigorous testing procedures
  Validation now involves deeper scrutiny and more formalized testing processes. 
• Clearer module boundary definitions
  Especially relevant in software-defined and containerized environments.
• Algorithm lifecycle enforcement
  Stronger alignment with NIST’s evolving guidance on approved and deprecated algorithms. 

In short, FIPS 140-3 raises the expectation from “documented and tested cryptographic modules” under 140-2 to “formally standardized, internationally aligned, and more rigorously validated” modules and processes. It demands not only that cryptographic modules exist, but that they are precisely defined, correctly implemented, and demonstrably compliant with stricter assurance and testing requirements.

Why This Matters for FedRAMP

FedRAMP has always required the use of FIPS-validated cryptography for controls like SC-12 and SC-13. That hasn’t changed—but expectations around how organizations demonstrate compliance are evolving.

Auditors and assessors are increasingly aware of the transition to 140-3. That means:

• Systems relying on aging 140-2 validations may face heightened scrutiny
• Documentation must reflect awareness of current standards
• Organizations may need to justify the continued use of older modules

While 140-2 modules are not immediately invalid, they are on a path toward deprecation. Ignoring that trajectory can introduce risk during:

• Initial ATO assessments
• Continuous monitoring reviews
• System updates or re-authorizations

The Biggest Misconception: “Validated Once, Compliant Forever”

One of the most persistent misunderstandings in compliance is the idea that FIPS validation is a one-time achievement.

It’s not.

FIPS validation applies to:

• A specific version of a module
• Under a specific configuration
• Within a defined operational boundary

That means even small changes can break compliance:

• Updating a cryptographic library
• Changing build flags or compiler settings
• Running the module outside its approved mode
• Integrating it differently into your system

In cloud-native environments, where updates are frequent and automation is constant, this becomes a real challenge. Without careful controls, systems can drift out of compliance without anyone noticing—until an audit.

Cloud-Native Complexity: Where 140-3 Gets Hard

Modern architectures make cryptographic compliance significantly more complex than it was in traditional systems.

Consider a typical cloud-native stack:

• Base container image
• Application runtime
• Service mesh (e.g., mTLS)
• API gateways
• Underlying cloud infrastructure

Each layer may handle cryptography differently—and not all of them are guaranteed to use FIPS-validated modules correctly.

This creates several challenges:

• Blurred cryptographic boundaries
  Containers abstract away where crypto actually happens.
• Inconsistent enforcement
  One service may use a validated module correctly, while another does not.
• Ownership confusion
  Is crypto the responsibility of the app team, platform team, or vendor?

The result is a common but dangerous assumption:

If a FIPS-validated module exists somewhere in the stack, the system must be compliant.

That assumption doesn’t hold up under audit.

Migration Pitfalls Teams Are Already Facing

As organizations begin transitioning to FIPS 140-3, several patterns are emerging:

• Assuming 140-2 certifications automatically carry forward.  They don’t. New validations are required.
• Overlooking entropy requirements in cloud environments.  Not all cloud-based entropy sources meet stricter expectations.
• Using “FIPS-capable” libraries without proper configuration Capability is not the same as validated.
• Insufficient documentation. Many teams struggle to clearly demonstrate how cryptography is implemented and enforced.

These issues don’t just slow down audits—they create real compliance gaps.

What a Successful 140-3 Strategy Looks Like

Organizations that navigate this transition successfully tend to take a more structured approach:

1. Inventory

Identify every cryptographic module in use across your system.

2. Validate

Confirm certification status (140-2 vs 140-3) and approved modes of operation.

3. Enforce

Ensure FIPS mode is consistently enabled and correctly configured.

4. Monitor

Continuously verify compliance and detect drift over time.

This is not a one-time project. It’s an ongoing discipline.

Where Many Solutions Fall Short

A growing number of solutions focus on providing “FIPS-ready” components—pre-built artifacts that include validated cryptographic modules.

These can be helpful, but they often stop short of addressing the harder problems:

• Runtime enforcement
• System-wide consistency
• Audit-ready evidence

Having the right components is only part of the equation. What matters is how those components are used—and whether you can prove it.

Compliance Is a Moving Target

FIPS 140-3 represents more than a new standard. It reflects a broader shift toward greater rigor, transparency, and accountability in cryptographic compliance.

For FedRAMP teams, that means:

• Moving beyond checkbox thinking
• Understanding how cryptography works across the system
• Building processes that ensure compliance over time

Because in modern environments, compliance isn’t something you achieve once. It’s something you have to maintain—continuously.