Federal Risk and Authorization Management Program (FedRAMP):

Overview

FedRAMP standardizes security assessment for cloud services used by federal agencies, built on NIST SP 800-53 controls. FIPS 140 validation is a prerequisite baked directly into SC-13, SC-12, and IA-7: cryptography must be provided by a FIPS 140-validated, or NSA-approved and NIAP-compliant, module, not merely FIPS-compliant custom code.

In January 2025, the FedRAMP Board approved an updated Cryptographic Module Policy (v1.1.0) that gives CSPs two paths: a “validation module stream” that prioritizes staying on the latest FIPS-validated module version, and an alternate stream to incorporate urgent security patches faster than a full re-validation would allow. In parallel, FedRAMP 20x, a modernized, more automatable authorization approach built around Key Security Indicators, became effective for Low-impact authorizations on May 30, 2025, with CSPs required to participate in the 20x pilot to qualify.

Why it matters

FedRAMP’s own program guidance names “not having FIPS 140 validated encryption modules” as a common barrier that can stop an authorization package before a 3PAO even submits the Readiness Assessment Report, a gate rather than a fixable-later deficiency.

The FIPS 140-2 to 140-3 transition compounds this risk for CSPs specifically: a module that was fine at initial authorization can shift to Historical status mid-ATO-cycle, and a CSP relying on infrastructure cryptography it doesn’t directly control, cloud provider libraries, embedded TLS stacks, still owns the compliance gap if that module lapses on September 21, 2026.

How this maps to cryptography 

FedRAMP addresses cryptography through several interlocking control areas. The key areas with direct cryptographic implications are:

Audit readiness

Assessments and examinations, whether self-conducted, performed by a regulator, or reviewed by an independent assessor, focus on demonstrated evidence rather than policy statements alone. Key areas that examiners and assessors commonly probe:

• FIPS Module Active-Status Verification:  Are all cryptographic modules protecting federal data confirmed Active on the CMVP validated modules list, not Historical or still in process?
• Version-to-Certificate Matching in the SSP:  Does the System Security Plan accurately identify the exact module version and certificate number deployed in production?
• POA&M for Modules Approaching Historical Status:  Is there a documented Plan of Action and Milestones for any module approaching the September 21, 2026 FIPS 140-2 sunset?
• Key Establishment and Management Documentation:  Are key generation, distribution, and destruction procedures documented and tied to a specific validated module?
• Continuous Monitoring Evidence for 20x KSIs:  Can the organization produce automated, ongoing evidence of cryptographic control status rather than only point-in-time assessment artifacts?
• Signed Artifact Verification for Deployments:  Are container images, build artifacts, and patches deployed into the authorization boundary cryptographically signed and verified?

TAKE THIS TO MANAGEMENT

FedRAMP’s own guidance calls out missing FIPS validation as a common reason authorization packages never get submitted at all, not a finding we fix during assessment. If our cryptographic modules, including the ones inherited from our cloud infrastructure provider, aren’t on the CMVP Active list with a version that matches our SSP, we don’t get to the 3PAO review in the first place.

September 21, 2026 adds a mid-cycle risk we haven’t had to manage before: a module that was Active when we were authorized can move to Historical status while our ATO is still in force. We need ongoing visibility into every module’s validation status, not a one-time check at authorization, and FedRAMP 20x’s push toward continuous, automated evidence makes that visibility a baseline expectation rather than an option.