FIPS Validated Cryptography: What FedRAMP Requires and How to Verify Compliance

The FedRAMP Program lists "not having FIPS 140 validated encryption modules" as a common barrier to Cloud Service Providers (CSPs) completing authorization. It is not a deficiency you remediate after the fact, but a gate that can stop the process before your authorization package is even reviewed. 

That distinction matters for SaaS companies pursuing federal revenue: a deficiency gets flagged and fixed on a timeline, while a barrier means the Third-Party Assessment Organization (3PAO) won't submit your Readiness Assessment Report (RAR) until it's resolved. 

Understanding what Federal Information Process Standard (FIPS) validated cryptography requires, where it applies in the stack, and how to verify compliance before a 3PAO arrives is the difference between a predictable authorization timeline and one that stalls before it starts.

Key Takeaways

• Missing FIPS 140-validated modules are an authorization barrier that cannot be remedied later.
• "FIPS-capable" is not "FIPS-validated." Every cryptographic touchpoint must trace to an Active CMVP certificate number with FIPS mode enabled.
• Each layer of your stack is an independent FIPS boundary. Host-level FIPS mode doesn't cascade into containers, service mesh encryption doesn't cover application-level cryptography, and protocol version alone doesn't satisfy SSP requirements.
• Pre-assessment self-review is the cheapest fix. Build a cryptographic inventory, confirm FIPS mode at runtime, and align SSP terminology with FedRAMP's selection policy before the 3PAO arrives.

What FIPS-Validated Cryptography Is

The FIPS 140-3 and FIPS 140-2 standards are Federal Information Processing Standards published by the National Institute of Standards and Technology (NIST) that specify security requirements for cryptographic modules; they are not product certifications and are not the same as FedRAMP. They define requirements across eleven security areas at four levels.

The critical concept is the module boundary: a vendor-defined perimeter that determines what's inside the module. Validation applies only to that bounded module in a specific version and operational environment. 

The CMVP FAQ is explicit: "A product which uses an embedded validated cryptographic module cannot claim itself to be validated; only that it utilizes an embedded validated module."

FedRAMP enforces this distinction directly. The selection policy prohibits CSPs from using terms like "FIPS compliant" or "FIPS enabled" in authorization documentation. Your System Security Plan (SSP) must document, in Appendix Q, specific cryptographic module details, including CMVP certificate numbers (if validated), vendor names, module names, and versions.

Understanding what validation means is one half of the picture; the other is understanding how a module earns that status in the first place.

How the Validation Process Work

The CMVP program, a joint effort between NIST and the Canadian Centre for Cyber Security, manages testing and validation. Vendors submit modules to accredited labs, and the CMVP Validation Authorities review submissions and issue certificates.

Modules can be Active, Historical, or Revoked. A module on the In Process list doesn't count as validated, and neither does a Cryptographic Algorithm Validation Program (CAVP) certificate, which only confirms the mathematical correctness of an algorithm, not the security of the module itself.

With the validation mechanism established, the next question is where in a FedRAMP-authorized system those validated modules are actually required.

Where FedRAMP Requires FIPS-Validated Modules

Three controls form the backbone of FedRAMP's FIPS requirements at Moderate and High baselines.

SC-13 (Cryptographic Protection) covers all cryptographic functions, not only encryption. FedRAMP fills its parameter assignment with "FIPS-validated or NSA-approved cryptography." Hashing and random number generation are in scope, and key generation may also be covered depending on how SC-13 is interpreted alongside related controls such as SC-12. Per the FedRAMP 3PAO Readiness Assessment Report Guide, the controls whose cryptography is in scope for SC-13 include AU-9(3), CP-9(8), IA-2(6), IA-5(1), MP-5, SC-8(1), and SC-28(1).

SC-8/SC-8(1) (Transmission Confidentiality and Integrity) governs data in transit. The SAR guidance makes the enforcement boundary explicit: "The FIPS 140 mandate applies to NIST-tested and validated cryptographic modules that use approved algorithms. TLS alone does not satisfy this requirement." Deploying TLS 1.2 is necessary but insufficient; the cryptographic module underlying the TLS implementation must hold a CMVP validation certificate.

FedRAMP guidance requires that the encryption status of all data flows and stores be accurately depicted on diagrams and described in related SC control implementation statements.

SC-28/SC-28(1) addresses the protection of information at rest. Where SC-8 covers data moving between components, SC-28 covers data sitting in databases, object stores, backups, and volumes. The same FIPS validation requirement applies: the cryptographic module protecting data at rest must hold an Active CMVP certificate. One area where SC-28 and SC-8 intersect in practice is load balancer architecture. 

GSA guidance requires that "connections terminated at a load balancer shall employ re-encryption techniques to ensure end-to-end encryption," meaning data can't sit unencrypted between TLS termination and the backend service.

The MFA verifier requires FIPS validation at all baselines, including Low and LI-SaaS. Knowing which controls require FIPS validation is only useful if the distinction between validation and configuration is understood at the implementation level.

What "FIPS-Validated" Means in Practice for Your Stack

The implementation guidance shows why treating "FIPS-capable" and "FIPS mode enabled" as equivalent creates compliance problems.

• FIPS-capable means a validated module is installed, but the application hasn't been configured to use it. The application may silently invoke non-validated code paths.
• FIPS mode enabled means the system or application is configured at runtime to restrict cryptographic operations to FIPS-approved algorithms.
• FIPS-validated means the specific module version, configuration, and operational environment have been formally tested and received a CMVP certificate.

Most SaaS stacks have multiple independent FIPS boundaries, and satisfying one layer doesn't cascade to others.

Kernel FIPS mode in RHEL applies from the kernel through cryptographic modules to applications, but user-space applications must be configured to respect FIPS policies. Enabling FIPS mode on a host (kernel parameter fips=1) doesn't force user-space applications or containers to use validated modules. If they bypass system libraries, the host configuration is irrelevant.

Container-based images require independent FIPS module validation. Host-level FIPS mode doesn't extend into containers. The relevant verification point is the specific module, version, and operational environment documented in the CMVP search.

Service mesh encryption addresses transport between pods but doesn't cover application-level cryptographic operations. Istio's COMPLIANCE_POLICY=fips-140-2 environment variable enforces TLS 1.2 with approved cipher suites, but it must be set on the Istiod container, every proxy sidecar, and all Istio components. Setting it only in the control plane isn't enough, and connections between restricted and unrestricted proxies can silently negotiate non-FIPS cipher suites.

Go's transition creates compatibility risks. The historical GOEXPERIMENT=boringcrypto approach has documented failures in Go 1.25/1.26, and because it's incompatible with native FIPS 140-3 mode, an obvious workaround isn't available. Go's native FIPS 140-3 module (GOFIPS140=v1.0.0, Go 1.24+) is the recommended path, though CMVP validation is still in process.

OpenSSL 3.x requires explicit configuration of a FIPS provider. The FIPS provider must be explicitly loaded, and if a package manager updates fips.so without re-running openssl fipsinstall, the provider may fail to load because the installation configuration contains a MAC that must match the installed module.

Those implementation boundaries are what a pre-assessment review is designed to surface before an external assessor does.

How to Verify FIPS Compliance Before Your 3PAO Assessment

Verifying compliance involves building an inventory, confirming every module, and capturing FIPS mode, while recognizing common gaps. 

Build a complete cryptographic inventory. For every TLS termination point, disk encryption implementation, database connection, key management service, authentication module, VPN endpoint, and SSH implementation within your boundary, identify the specific software library or module, not just the protocol. Document each implementation at the cryptographic module/certificate level — for example, OpenSSL FIPS Provider 3.0.8/3.0.9 validated under Certificate #4282.

Verify every module. Use Advanced Search to check the exact vendor, module name, and version. Confirm Active status, not Historical or Revoked. Download the Security Policy and verify your deployment matches the approved Operational Environment. For any module still on FIPS 140-2 with the 2026 sunset approaching, document a POA&M entry.

Confirm FIPS mode. On Linux, verify fips_enabled returns 1. For OpenSSL, confirm the FIPS provider is loaded at runtime, not just present on the filesystem. For containers, verify the base image includes a validated module and that FIPS mode is active within the container. Note: fips-mode-setup doesn't work correctly in containers. Capture screenshots, logs, and configuration outputs as evidentiary artifacts.

The eight most common gaps found during self-review are:

1. FIPS module installed, but FIPS mode not enabled
2. TLS protocol version documented as FIPS compliance
3. Historical-status modules without a POA&M
4. Non-FIPS modules in containers and third-party dependencies
5. Custom modifications to validated crypto libraries
6. Incomplete Appendix Q, missing internal data flows or key management entries
7. Prohibited "FIPS compliant" terminology in SSP documentation
8. CAVP algorithm certificates presented in place of CMVP module certificates

The gaps surfaced in a self-review are the same ones a 3PAO will examine during formal assessment, though the consequences of finding them then are considerably higher.

What a 3PAO Checks for FIPS Compliance During Authorization

Self-review helps you catch what you can fix on your own timeline. Once the 3PAO arrives, the clock is theirs.

The Readiness Assessment Report (RAR) includes FIPS 140 compliance as a federal mandate, framed as a binary question: "Are FIPS 140-Validated cryptographic modules consistently used where cryptography is required?" The RAR Guide is unambiguous: "3PAOs should NOT submit a RAR to FedRAMP until they validate that all CSO federal mandates have been met."

The 3PAO verifies both the Active CMVP status and the FIPS-enabled mode of operation for each module. They request Security Policy documentation, verify that data flow diagrams match the deployed encryption status, and confirm that Appendix Q covers all data-at-rest and data-in-transit scenarios. For modules that use update streams, CSPs must retain artifacts demonstrating that updated major versions were submitted to the CMVP within 6 months of release. A missing artifact chain is itself an audit finding.

FIPS gaps can block readiness and delay assessment timelines. High-severity findings trigger a 30-day remediation window, cannot be deferred as Operational Requirements, and carry into continuous monitoring after authorization.

That verification burden shrinks significantly when infrastructure-layer controls are inherited rather than built from scratch. Knox Systems, a FedRAMP-as-a-Service platform, operates on a pre-authorized Knox FedRAMP boundary. SaaS companies on the Knox model can pursue federal authorization in approximately 90 days at approximately 90% less cost than traditional methods.

Kovr.ai, an AI-native cyber compliance platform serving the U.S. Air Force and U.S. Space Force, needed FedRAMP Moderate authorization but couldn't afford the traditional timeline as a startup fresh out of stealth. Knox provided a sponsorless ATO path and handled the infrastructure-layer compliance — including FIPS controls and environment configuration — while Kovr.ai used their own compliance automation platform for the application-layer policies and self-assessment. The result: FedRAMP Moderate authorization in six weeks.

The Path to FIPS Compliance Begins Here

Every quarter without FedRAMP authorization is a quarter where the agencies you're targeting are signing contracts with vendors who already have it. Those deals don't come back around. The RFP cycles keep moving, the budgets get allocated, and the incumbents get stickier. 

Meanwhile, every FIPS gap sitting undiscovered in your stack is a 30-day remediation window you haven't started yet — time that compounds against a timeline that was already tight. 

None of that gets easier by waiting. Knox inherits the infrastructure-layer FIPS controls, so your team can focus on the application-layer work that's actually yours to solve. Book a meeting to see how it works for your company.