FedRAMP cryptographic requirements have moved from a quiet technical detail to a front-of-line condition for authorization. If your cloud service cannot show which cryptographic modules protect federal customer data, and use validated modules where your certification class requires them, the gap can stall a certification package before it reaches review.
That is the shift every cloud service provider (CSP) needs to internalize. Cryptography is now a gate, not a footnote you fix later. This guide breaks down the controls that matter, the recent policy changes to plan around, and what assessors actually look for.
Cryptography is now a FedRAMP gate, not a footnote
FedRAMP program guidance names the absence of FIPS 140 validated encryption modules as one of the most common barriers to authorization. It is not treated as a deficiency you remediate mid-cycle. It can halt a package before your Third Party Assessment Organization (3PAO) submits the Readiness Assessment Report.
The practical takeaway: validate your cryptographic modules first, then build your compliance narrative around them. Doing it in the opposite order is how CSPs lose months.
What FedRAMP is and who it applies to
FedRAMP standardizes security assessment for cloud services used by federal agencies. It is built on NIST SP 800-53 controls, and under FedRAMP 20x it also draws on Key Security Indicators (KSIs), which act as a baseline equivalent rather than control-by-control narratives.
In plain terms: if you sell cloud services to the federal government, FedRAMP defines the security bar you must clear, and cryptography is a load-bearing part of that bar.
Who needs to pay attention
The requirements reach further than most teams expect. Three groups are directly on the hook:
- Cloud Service Providers (SaaS, PaaS, IaaS) pursuing FedRAMP Certification at Class A, B, C, or D, on either the 20x or Rev5 path.Independent Software Vendors selling through federal cloud marketplaces and reseller channels.
- Third-Party Assessment Organizations (3PAOs) that conduct Readiness Assessment Reports and annual security assessments.
The FedRAMP cryptographic requirements that matter
FedRAMP addresses cryptography through interlocking NIST SP 800-53 control areas. The unifying rule across all of them: cryptography must come from a FIPS 140 validated module, or an NSA-approved and NIAP-compliant module, not FIPS-compliant custom code.
Two validation programs sit underneath that rule. Modules are validated under the Cryptographic Module Validation Program (CMVP). Algorithms are tested under the Cryptographic Algorithm Validation Program (CAVP). A module you deploy needs to trace back to both.
Three controls carry the weight.
SC-13: cryptographic protection of federal data
SC-13 requires you to encrypt federal data at rest and in transit exclusively through FIPS 140 validated or NSA-approved cryptographic modules. Where an unvalidated module is unavoidable, document the rationale in a list of Accepted Weaknesses which is replacing the former Plan of Action and Milestones (POA&M).
SC-12: key establishment and management
SC-12 governs the keys that protect your cloud service offering. It calls for documented key generation, distribution, storage, access, and destruction procedures aligned to NIST SP 800-56 and SP 800-57.
IA-7: cryptographic module authentication
IA-7 covers authentication. It requires that authentication mechanisms be implemented through validated cryptographic modules rather than ad hoc libraries assembled by developers.
What changed: from the 2025 Cryptographic Module Policy to FedRAMP 20x
Two recent developments deserve a place in every CSP’s planning. One reshapes how you keep modules current, and one modernizes how authorization evidence is produced.
Cryptographic Module Policy v1.1.0 (dual streams)
The FedRAMP Board approved the FedRAMP Policy for Cryptographic Module Selection and Use, version 1.1, on January 16, 2025. It remains the reference for Rev5 until the CMU rules become mandatory on January 1, 2027. It gives CSPs two paths:
- A validation module stream that prioritizes staying on the latest FIPS validated module version.
- An alternate stream that lets you incorporate urgent security patches faster than a full re-validation would allow.
Both paths depend on module version and certificate tracking. You need current evidence of exactly which FIPS validated module version and certificate number is running in production. Without that tracking, neither stream holds up under review.
FedRAMP 20x and Key Security Indicators
FedRAMP 20x is a modernized, more automatable authorization approach built around Key Security Indicators. The KSI standard first took effect on May 30, 2025 for 20x Low pilot authorizations. Pilot participation is no longer the way in: the Class A pipeline opened August 3, 2026, and the Class B and Class C pipelines opened August 31, 2026.
The important shift for cryptography is continuous. 20x KSIs support continuous monitoring of cryptographic posture, meaning automated, ongoing evidence rather than a point-in-time snapshot at assessment.
One CR26 change is directly related to cryptography: FIPS 140 encryption is expected where data is sensitive, and FedRAMP no longer assumes all federal customer data and metadata is sensitive. Providers document their FIPS 140 use so agencies can judge the fit against their own use case.
The FIPS 140-2 to 140-3 transition: a compounding risk for CSPs
The move from FIPS 140-2 to 140-3 is a distinct risk for cloud providers, because a module that was fine at initial authorization can shift status mid-ATO-cycle. On September 21, 2026, every remaining active FIPS 140-2 certificate moves to the CMVP Historical List, a status federal agencies should not include in new procurements.
Here is the trap: even when you rely on infrastructure cryptography you do not directly control, such as cloud provider libraries or embedded TLS stacks, you still own the compliance gap if that module lapses on September 21, 2026. Replacement module validation can take 18 to 30 months, so the runway is shorter than the calendar suggests. Tracking the CMVP Active and Historical Lists is the only way to know where you stand.
Audit readiness: what assessors actually probe
Assessments focus on demonstrated evidence, not policy statements. Saying you use validated cryptography is not the same as proving which module, which version, and which certificate is live in production. Come prepared to show your work.
The evidence checklist
Expect examiners to probe these areas:
- FIPS module active-status verification: confirm modules appear as Active on the CMVP validated modules list, not Historical or in process.
- Version-to-certificate matching: the exact module version and certificate number in production, recorded in the Certification Package Overview.
- Accepted Weakness record for historical modules: for any FIPS 140-2 module still in production after the September 21, 2026 sunset, a documented justification and a dated plan to move to an actively validated FIPS 140-3 module.
- Key management documentation: key establishment and management procedures tied to a specific validated module.
- Continuous monitoring evidence: automated, ongoing data supporting your 20x KSIs.
- Signed artifact verification: signatures on container images, build artifacts, and patches deployed into the authorization boundary.
How Keyfactor can help
Meeting FedRAMP cryptographic requirements comes down to knowing what cryptography you run, proving it is validated, and keeping that evidence current. Keyfactor’s solutions map directly to the control areas above.
Keyfactor AgileSec handles module version and certificate tracking against the CMVP Active and Historical Lists, the discipline that Policy v1.1.0 depends on. It scans your IT landscape to find, catalog, and score cryptographic assets, so you know where every module lives before an assessor asks.
EJBCA provides FIPS validated PKI supporting SC-13 (data encryption) and IA-7 (authenticator modules). It issues and manages the certificate-based identity your cloud service relies on, with the auditability regulated environments require.
Keyfactor SignServer (with Signum) signs container images, build artifacts, and patches deployed into the authorization boundary, supporting the signed artifact verification assessors expect. Centralized, policy-driven signing replaces ad hoc tooling with traceable, auditable workflows.
Keyfactor Command covers key establishment and management (SC-12), module migration planning, and continuous monitoring evidence for 20x KSIs. It discovers and automates certificates and keys across any CA and environment, so lifecycle events do not turn into compliance gaps.
Together these run on the Keyfactor Trust Control Plane: one platform that observes, analyzes, provisions, orchestrates, and governs every cryptographic asset and machine identity. The payoff for FedRAMP is a single system of record, so the evidence any framework asks for comes from one place instead of a scramble across teams.
Conclusion and next steps
Cryptographic governance is a competitive capability, not just a penalty-avoidance exercise. Mature crypto visibility and lifecycle management help you move faster through FedRAMP certifications and recover faster from certificate expirations and algorithm deprecations.
Start with three practical steps:
- Gain visibility into every cryptographic asset across your environment.
- Assess against current and near-term requirements, verifying module validation status against the 2026 sunset.
- Establish automation for certificate and key lifecycles before gaps become blocked federal deals.
Ready to see how this works in practice? Request a Demo.
Got FedRAMP cryptography questions? We’ve got answers.
What cryptographic standard does FedRAMP require?
FedRAMP requires approved cryptography implemented through a FIPS 140 validated module, an update stream of a validated module, or an NSA-approved module. Modules are validated under the CMVP, and algorithms are tested under the CAVP. How strictly validated module use is required now varies by certification class: mandatory at Class D, recommended at Class C, and optional at Classes A and B. Documenting the modules in use is required at every class.
Which NIST SP 800-53 controls carry FedRAMP’s cryptographic requirements?
The core controls are SC-13 (cryptographic protection of federal data), SC-12 (key establishment and management), and IA-7 (cryptographic authenticator module compliance). Together they cover encryption, key lifecycle, and authentication through validated modules.
Can a missing FIPS validated module really block a FedRAMP certification?
Yes. FedRAMP’s own program guidance names the absence of FIPS 140 validated encryption modules as a common barrier. Validated module use is mandatory at Class D, recommended at Class C, and optional at Classes A and B (CMU-CSO-UVM). Undocumented cryptography is a finding at any class.
What is the FedRAMP Cryptographic Module Policy v1.1.0?
Approved by the FedRAMP Board on January 16, 2025, it gives CSPs two paths. A validation module stream prioritizes staying on the latest FIPS validated module version, and an alternate stream lets CSPs incorporate urgent security patches faster than a full re-validation would allow.
What is FedRAMP 20x and when does it apply?
FedRAMP 20x is the automation first certification path, built around Key Security Indicators rather than control by control narratives. The KSI standard first took effect on May 30, 2025 for 20x Low pilot authorizations. It now applies through the Consolidated Rules for 2026: the Class A pipeline opened August 3, 2026, and the Class B and Class C pipelines opened August 31, 2026. Class D remains on the Rev5 path for now..
Why does the September 21, 2026 FIPS 140-2 sunset matter for cloud providers?
On that date, remaining active FIPS 140-2 certificates move to the CMVP Historical List. A module that was fine at initial authorization can shift to Historical status mid-cycle, and a CSP still owns the compliance gap even when it relies on infrastructure cryptography it does not directly control.
What evidence do FedRAMP assessors look for around cryptography?
Assessors focus on demonstrated evidence: active-status verification of modules on the CMVP list, version-to-certificate matching in the Certification Package Overview, a list of Accepted Weaknesses for modules nearing the 2026 sunset, documented key management tied to a validated module, continuous monitoring data showing the module versions in use, and signed deployment artifacts.
What should a CSP do first to prepare?
Start by gaining visibility into every cryptographic asset and its module validation status, then verify module version to certificate accuracy and replace anything now sitting on the CMVP Historical list.
