FIPS 140-3 vs. 140-2: What the Cryptography Standard Upgrade Means for FedRAMP Authorization

The Federal Risk and Authorization Management Program (FedRAMP) authorization process surfaces Federal Information Processing Standard (FIPS) 140 validation as a hard requirement early and often.

Controls SC-13, SC-28, and IA-7 all point back to the same underlying obligation: every cryptographic module protecting federal data must appear on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) validated list.

FedRAMP-related guidance has identified the lack of FIPS 140-validated encryption modules as a common barrier to cloud service providers completing authorization. The ongoing transition from FIPS 140-2 to FIPS 140-3 has created uncertainty for teams mid-authorization, particularly around module procurement, System Security Plan (SSP) documentation, and continuous monitoring obligations.

Key Takeaways

• 140-2 remains valid. Active FIPS 140-2 validated modules remain acceptable for new systems through September 21, 2026, but the CMVP stopped accepting new 140-2 submissions in April 2022.  
• 140-3 changes testing. FIPS 140-3 aligns with ISO/IEC 19790 and, through associated testing and CMVP guidance, includes non-invasive attack mitigation testing for higher security levels and requirements for entropy source documentation.  
• Transition risk is operational. Module procurement timing, SSP documentation accuracy, and continuous monitoring status changes all require active management during the overlap period.  
• Boundary scope still matters. Software-as-a-Service (SaaS) vendors deploying within a pre-authorized boundary inherit many infrastructure-layer controls on day one, but cryptographic module obligations still depend on the modules inside their own authorization boundary.

FIPS 140 Is a Federal Cryptographic Validation Standard

FIPS 140 is a U.S. government standard that specifies the security requirements cryptographic modules must meet to protect sensitive federal information. Published by NIST under the Department of Commerce and titled Security Requirements for Cryptographic Modules, it sets the baseline that any encryption module touching federal data must satisfy before it can be used in a federal system.

The standard is enforced through the Cryptographic Module Validation Program (CMVP), a joint program between NIST's Computer Security Division and Canada's Center for Cyber Security (CCCS) that has operated since 1995. A validated module has a CMVP certificate number, a defined module boundary, and an associated security policy document published alongside that certificate.

NIST guidance draws the enforcement line clearly: for federal compliance, cryptography must be implemented in a NIST-tested and validated module within its specified operational environment, and cryptography implemented in an unvalidated module does not satisfy FIPS requirements. Running a FIPS-approved algorithm through an unvalidated module fails the audit.

FedRAMP still requires the module itself to be validated. The transition changes which validation standard a module follows.

FIPS 140-2 Defined Federal Cryptography Requirements for Two Decades

FIPS 140-2 was signed and issued in 2001 and received its last substantive update in December 2002. CMVP continued accepting FIPS 140-2 submissions after FIPS 140-3 submissions opened in September 2020, until the cutoff on September 22, 2021, with a final hard deadline of April 1, 2022, under the official transition timeline document.

The standard specifies requirements across eleven distinct security areas, and a module's overall security level equals the minimum level achieved across all rated areas. The four levels map directly to procurement decisions:

• Level 1: Software-only implementations with at least one approved algorithm, requiring no physical security mechanisms or operator authentication.  
• Level 2: Adds tamper-evident coatings or seals plus role-based authentication for operators accessing the module.  
• Level 3: Adds physical tamper-resistance with detection and response, identity-based authentication, and mandatory separation of critical security parameter interfaces. Private keys may only enter or leave the module in encrypted form.  
• Level 4: Requires a complete physical protection envelope where penetration from any direction must trigger immediate zeroization of all plaintext critical security parameters.

Those baseline levels still shape procurement and documentation decisions. The transition to FIPS 140-3 changes how teams need to approach testing, supporting documentation, and certain technical requirements.

FIPS 140-3 Updates the Standard Against Current Threat Models

FIPS 140-3 was finalized on March 22, 2019, and the CMVP began accepting submissions under the new standard on September 22, 2020.

A key change from 140-2 to 140-3 is that the latter aligns with ISO/IEC 19790:2012 and is implemented through the CMVP's associated validation documentation and security policy materials. It incorporates ISO/IEC 19790:2012 for security requirements and ISO/IEC 24759:2017 for testing procedures by reference.

For FedRAMP teams, this shift changes how validation is documented, tested, and maintained. Labs use different standards and procedures, and higher security levels now bring physical and non-invasive attack requirements along with additional supporting evidence for approved algorithms and entropy sources. The three subsections below break down where those changes land.

1. Alignment to International Standards and Revised Testing Procedures

The international alignment introduces new reference documents and procedural changes that lab assessors and FedRAMP teams must account for during validation planning.

• 19790:2012 governs the security requirements themselves, replacing the requirement text previously contained in FIPS 140-2.  
• 24759:2017 is used for cryptographic module testing under FIPS 140-3 in place of the earlier Derived Test Requirements (DTR), which require procedural changes for National Voluntary Laboratory Accreditation Program (NVLAP)- accredited labs.  
• NIST manages U.S.-specific modifications through the SP 800-140 series (SP 800-140 through SP 800-140F), which are key supporting documents for FIPS 140-3 work in practice.

2. Updated Physical Security and Non-Invasive Attack Resistance Requirements

Higher-level modules now face explicit testing for side-channel and physical attack vectors that were not formally addressed under FIPS 140-2.

• Security Levels 3 and 4 are affected by the primary technical change. Area 8 shifted from Electromagnetic Interference and Electromagnetic Compatibility, under 140-2, to Non-Invasive Security, under 140-3.  
• Three non-invasive attack categories are now formally in scope: power analysis attacks, electromagnetic analysis attacks, and timing attacks.  
• Procurement decisions for Hardware Security Modules (HSMs) are directly affected. Applicable requirements for FedRAMP key management infrastructure depend on the system's categorization and selected controls.

3. Approved Algorithm List Changes and Entropy Source Requirements

Algorithm approval and entropy documentation requirements have tightened, creating audit risk for teams that have not refreshed their cryptographic inventory.

• Triple-DES (3TDEA) for encryption was disallowed after 2023, and SHA-1 for digital signature generation is restricted under SP 800-131A Rev2. If your application or any inherited component uses either, this is an active audit finding.  
• Entropy source documentation is substantially more rigorous under 140-3. All entropy sources must comply with SP 800-90B entropy guidance, requiring noise source documentation, operating condition specifications, and validated conditioning components.  
• Entropy Source Validation (ESV) may be required when the module's entropy source is within the operational environment, whereas CMVP, at a minimum, requires documentation demonstrating conformance to SP 800-90B.  
• Post-quantum cryptography (PQC) algorithms are being validated through the FIPS 140-3 framework. NIST approved three PQC standards in 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).

Side-by-Side Comparison of FIPS 140-2 and FIPS 140-3

The two standards diverge across publication date, base reference framework, algorithm governance, submission status, and sunset treatment. The table below consolidates those differences so procurement and authorization teams can quickly identify which dimensions affect their boundary decisions.

Each row maps to a decision teams face during the transition, from whether to rely on an existing 140-2 certificate to how to plan around interim 140-3 validation windows.

FIPS 140-2 and 140-3 Coexist During the Transition

NIST's transition policy creates a defined overlap period. Both FIPS 140-2 active certificates and FIPS 140-3 validated modules currently satisfy FedRAMP's cryptographic requirements under SC-13, SC-28, and IA-7. The FedRAMP cryptographic module policy v1.1.0, approved by the FedRAMP Board on January 16, 2025, is the operative document.

SaaS teams usually encounter three coexistence scenarios during authorization:

• Using an existing FIPS 140-2 validated module: Acceptable today, but confirm the certificate's active status through your continuous monitoring cycle. After September 22, 2026, Historical modules will no longer support new system deployments.  
• Submitting a new module for CMVP validation: All new submissions undergo FIPS 140-3 validation. Plan for a lengthy review cycle between submission and certificate issuance.  
• Procuring a third-party FIPS-validated component: Verify the specific CMVP certificate number, validated version, and whether the provider follows the validation stream or the update stream.

Each scenario carries its own evidence and timing implications, and most teams encounter more than one within a single authorization boundary. The risk is not the coexistence itself, but how easily a module's status can shift between scenarios without the SSP catching up.

The FIPS 140-3 Transition Can Delay FedRAMP Authorization

The coexistence period creates several points where cryptographic module decisions directly impact authorization timelines.

Procuring a module that sits only on the CMVP Modules in Process list leaves a gap that a 3PAO will flag against SC-13, SC-28, SC-8, or IA-7, triggering POA\&M documentation and transition planning. Documenting module evidence incorrectly, such as referencing a Modules in Process (MIP) version, an unconfirmed 140-2 certificate, or the prohibited term "FIPS compliant," produces the same outcome. Validation status can also shift mid-cycle: many modules moved to the Historical List on July 1, 2022; the September 22, 2026 sunset will repeat that event, and interim 140-3 certificates may expire within a single Authority to Operate (ATO) cycle.

Each scenario starts at the infrastructure and boundary-design level long before an assessor reviews the SSP. What if the infrastructure layer carrying most of the cryptographic burden were already in place?

FIPS 140-3 Compliance Is an Infrastructure Problem Before It Is an Application Problem

Cryptographic module compliance is decided at the infrastructure layer long before any application code touches federal data. The cloud platform, key management service, container base images, and service mesh endpoints determine whether a SaaS vendor's authorization boundary contains validated modules at all and whether those modules will maintain Active status throughout the continuous monitoring lifecycle.

If the infrastructure layer is not already running validated modules in FIPS mode, with documented certificates and version tracking, no amount of application-layer hardening will close the gap during a 3PAO assessment.

Deploying inside a pre-authorized boundary changes the math. Knox Systems is a FedRAMP-as-a-Service platform that operates a pre-authorized boundary, and the cryptographic module obligations that most often delay authorization are handled inside that boundary rather than left to each vendor to rebuild.

Knox addresses FIPS 140-3 compliance through:

• Pre-selected validated cryptographic modules. Knox runs on modules that hold active CMVP certificates, with version tracking aligned to the deployed environment so the validated version always matches the running version.  
• FIPS mode enforcement across the boundary. Key management, HSM-backed operations, TLS termination, and storage encryption are configured in FIPS mode by default, removing the most common misconfiguration findings at assessment.  
• Appendix Q evidence maintained continuously. Certificate numbers, module versions, use cases, and FIPS mode confirmations are tracked inside the boundary, so the SSP artifacts that vendors inherit are current.  
• Continuous monitoring of CMVP status changes. When a module moves toward Historical status or an interim validation approaches its expiry, the transition is managed at the platform layer rather than becoming an emergency for each tenant.

The residual application-layer responsibility, custom cryptography, container image selection outside the inherited stack, and any service that performs encryption outside the platform's validated modules become a much smaller surface to defend. Vendors keep their own boundary focused on the application, while the cryptographic module obligations that drive most authorization delays sit inside infrastructure that has already cleared them.

Infrastructure-First Deployment Shortens the Path to FedRAMP Cryptographic Compliance

The September 22, 2026, FIPS 140-2 sunset and lengthy FIPS 140-3 validation queues mean every cryptographic module decision now carries timing risk against an active continuous monitoring lifecycle.

Teams entering FedRAMP authorization need to know whether the modules powering their authorization boundary have active CMVP validation, whether that validation will hold through their monitoring cycle, and whether the documentation is in place to prove it. Both versions satisfy FedRAMP controls today, but the fastest defensible path is to deploy within an infrastructure where module selection, validation tracking, and Appendix Q evidence are already maintained.

Knox Systems offers a pre-authorized boundary, enabling SaaS vendors to achieve authorization in approximately 90 days at 90% less cost than traditional approaches, which often take 12 to 36 months and cost upwards of $3.5 million. Vendors inherit many infrastructure-layer controls at the boundary instead of building and documenting that layer from scratch, including cryptographic module selection, FIPS mode enforcement, and Appendix Q artifacts, which this transition makes harder to maintain in-house.

Book a meeting today to discuss your authorization timeline.

FAQs About FIPS 140-3 and FedRAMP Authorization

What happens to existing FedRAMP authorizations when their FIPS 140-2 modules move to Historical status?

Historical status does not automatically invalidate existing authorizations, but those modules cannot support new system deployments. Continuous monitoring artifacts must document the replacement plan and migration timeline before the sunset date.

How long does FIPS 140-3 validation typically take after CMVP submission?

Review timelines vary based on lab workload and module complexity, but the queue between submission and certificate issuance often extends from many months to over a year. Procurement plans should account for this lag rather than treat submission itself as a milestone.

Can a FIPS 140-3 Level 1 module satisfy FedRAMP Moderate requirements?

Yes. Level 1 software modules meet the baseline FedRAMP requirement when properly configured in FIPS mode. Higher levels apply when physical key protection or HSM use cases are involved within the boundary.

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

"FIPS compliant" implies alignment with the standard without independent testing, while "FIPS validated" means the module holds an active CMVP certificate.

Are FIPS 140-3 interim validations treated the same as full validations?

Interim validations issued under the June 2024 policy carry a two-year active period rather than the standard five years. Continuous monitoring planning must account for the shorter window, since some interim certificates may expire within a single authorization cycle.