The Federal Risk and Authorization Management Program (FedRAMP) authorizes cloud service providers to sell to the United States federal government. FedRAMP authorizations build on a baseline of security controls drawn from NIST SP 800-53. With NIST's publication of SP 800-53 Revision 5 in September 2020 (with updates through Revision 5.1.1 in November 2023), FedRAMP transitioned its baselines to Revision 5, with full provider migration deadlines that ran through 2024 and 2025.
This article walks through the cryptographic controls in FedRAMP Rev 5, identifies the specific NIST SP 800-53 controls that govern cryptography (SC-13, SC-12, IA-7, and supporting controls), and explains where the post quantum transition affects FedRAMP authorized cloud services.
References point to the FedRAMP Program Management Office (fedramp.gov) and to NIST CSRC.
FedRAMP Baselines
FedRAMP Rev 5 publishes baselines at three impact levels, Low, Moderate, and High, plus FedRAMP Tailored, a reduced path for low-impact SaaS (LI-SaaS). The Moderate baseline is the most common for general purpose cloud services. The High baseline applies to cloud services hosting High impact systems per FIPS 199 categorization, and is required for many DoD CUI workloads.
Each baseline is a list of NIST SP 800-53 controls that the cloud service provider (CSP) must implement. The baseline plus additional FedRAMP specific guidance forms the System Security Plan (SSP) requirement.
Cryptographic Controls at the Top Level
Cryptographic controls in NIST SP 800-53 Revision 5 appear in several control families:
- System and Communications Protection (SC), particularly SC-12 and SC-13
- Identification and Authentication (IA), particularly IA-5 and IA-7
- Access Control (AC), particularly AC-17 and AC-18
- Audit and Accountability (AU), particularly AU-9 and AU-10
- Configuration Management (CM), particularly CM-2
The two anchor controls are SC-12 (Cryptographic Key Establishment and Management) and SC-13 (Cryptographic Protection).
SC-13: Cryptographic Protection
SC-13 requires the system to implement cryptographic mechanisms in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines. The control implementation typically references:
- FIPS validated cryptographic modules per FIPS 140-2 or FIPS 140-3
- NIST approved algorithms (AES, SHA-2, SHA-3, RSA, ECDSA, etc.)
- Specific configuration of these algorithms in supported protocols
The control assignment typically takes the form of a list: "the information system implements cryptographic protection using FIPS validated cryptography for protection of CUI in transit and at rest, including AES-256-GCM for symmetric encryption, RSA-3072 or ECDSA P-384 for asymmetric operations, and SHA-384 for hashing."
SC-13 is technology-neutral: the organization defines the types of cryptography employed, which is what lets an authorizing official require or accept post-quantum algorithms as they become FIPS-approved. That organization-defined parameter is the entry point for ML-KEM and ML-DSA in FedRAMP.
SC-12: Cryptographic Key Establishment and Management
SC-12 governs the lifecycle of cryptographic keys. The control requires the organization to establish and manage cryptographic keys when cryptography is employed within the system, in accordance with NIST SP 800-57.
Specific requirements include:
- Documented key management policy and procedures
- Approved key generation mechanisms (typically NIST SP 800-90 family RNGs)
- Secure key distribution
- Cryptoperiod definition for each key purpose
- Key rotation according to documented cryptoperiods
- Key escrow and recovery procedures where applicable
- Key destruction when no longer needed
For cloud services, key management is often delegated to a Key Management Service (KMS). AWS KMS, Azure Key Vault, and Google Cloud KMS each have FedRAMP authorized service offerings. The CSP that uses one of these services inherits its key management controls and documents the inheritance in the SSP.
IA-7: Cryptographic Module Authentication
IA-7 requires the use of mechanisms for authentication to a cryptographic module that meet FIPS or NIST requirements. This control is typically straightforward to implement when FIPS validated modules are in use.
The implementation evidence includes the FIPS validation certificate number for the module, the configuration that places the module in approved operating mode, and the procedures for key entry and key exit through the module's authenticated interfaces.
AC-17 and AC-18: Remote Access and Wireless
AC-17 (Remote Access) and AC-18 (Wireless Access) require cryptographic protection of remote and wireless connections. Implementation typically involves:
- TLS for HTTPS
- VPN with IPsec or similar
- WPA3 for wireless (where applicable to the CSP environment)
- SSH for management traffic
- mTLS for service to service authentication
These controls inherit from SC-13 for algorithm choices but add additional configuration requirements like inactivity timeouts and access logging.
AU-9 and AU-10: Audit Log Protection and Non Repudiation
AU-9 protects audit logs from modification or deletion using cryptographic integrity mechanisms. AU-10 provides non repudiation through digital signatures or cryptographic message authentication.
Implementation patterns include:
- Hash chains across log files
- Digital signatures on log batches with time stamping
- Write once read many (WORM) storage backed by cryptographic integrity
- Forwarded logs to immutable storage with integrity verification
PQC implications here are significant because log integrity controls operate over long retention periods. A log file signed with RSA today should remain verifiable when the signing infrastructure migrates to ML-DSA or hybrid signatures.
FedRAMP Specific Cryptographic Requirements
FedRAMP adds specific requirements on top of the NIST SP 800-53 baselines. The FedRAMP PMO publishes:
- Annex A: Documentation Requirements
- FedRAMP Specific Controls (FedRAMP+)
- Trusted Internet Connection (TIC) requirements that affect external communication
For cryptography, the most consequential FedRAMP additions are FIPS validated module requirements (more strict than vanilla NIST SP 800-53), specific TLS cipher suite requirements, and key management documentation depth.
The FedRAMP TLS Configuration Guidance has been updated through Rev 5 to align with NIST SP 800-52 Revision 2 and to permit hybrid PQC TLS configurations in pilot deployments.
Inheritance from Cloud Service Provider
A FedRAMP authorized CSP can offer cryptographic services that downstream customers inherit. For example:
- AWS KMS Provides FIPS 140-2 / 140-3 validated key management. Customer applications can call KMS for encryption operations and inherit the validated module status.
- Azure Key Vault Premium provides HSM backed keys with FIPS 140-2 Level 3 validation.
- Google Cloud KMS provides FIPS 140-2 / 140-3 validated key management.
When an agency builds an application on an authorized CSP, the agency's SSP can document inheritance of these cryptographic controls. This reduces the agency's own implementation burden but requires the agency to verify the CSP's authorization and inheritance details.
Authorization Boundary and Cryptographic Scope
The authorization boundary is the set of components that fall under the FedRAMP authorization. Cryptographic controls apply to everything inside the boundary. Common boundary patterns include:
- Multi tenant SaaS within a single VPC
- Single tenant deployments with dedicated infrastructure
- Government Community Cloud (GCC) regions
The boundary diagram in the SSP shows the cryptographic mechanisms at each interface point: TLS at external interfaces, mTLS at internal service interfaces, encryption at rest in storage components, and key management at the KMS interface.
FedRAMP Authorization Process
A CSP pursuing FedRAMP authorization works through:
- Initial readiness assessment
- Selection of an accredited Third Party Assessment Organization (3PAO)
- SSP and supporting document development
- 3PAO assessment
- Agency authorization (the former Joint Authorization Board path was retired under FedRAMP modernization; the FedRAMP Board now sets policy and authorizations are agency-driven)
- Continuous monitoring
The 3PAO assessment includes cryptographic control verification. The 3PAO will:
- Review the SSP cryptographic sections
- Verify FIPS validation certificates
- Test TLS configurations
- Verify encryption at rest is enabled
- Review key management procedures
- Sample audit log integrity mechanisms
The continuous monitoring phase includes monthly vulnerability scans and annual reassessments. Cryptographic configuration drift gets caught in continuous monitoring.
Post Quantum Cryptography in FedRAMP
NIST SP 800-53 Revision 5 does not explicitly require PQC. The cryptographic algorithm choice in SC-13 is "FIPS validated cryptography that meets the requirements of applicable federal laws, executive orders, directives, policies, regulations, standards, and guidelines."
The applicable guidance now includes NIST FIPS 203, 204, and 205 as approved PQC algorithms. CMVP validated modules with PQC support are entering the queue. Once those modules carry FIPS validation certificates including PQC algorithms, FedRAMP CSPs can claim PQC support inherited from those modules.
The Office of Management and Budget memo M-23-02 directs agencies to inventory PQC vulnerable cryptographic systems and prepare migration plans. CSPs serving these agencies will face flow down of PQC migration expectations through SLA and contract clauses. We cover this further in our 2035 NSA CNSA deadline plan and our FedRAMP and SOC 2 PQC requirements article.
High Impact and DoD Cloud Considerations
CSPs serving DoD with CUI workloads face additional requirements via DoD Cloud Computing SRG (Security Requirements Guide). Impact Levels (IL) 4, 5, and 6 add stricter controls. IL 5 typically requires DoD specific tenancy and additional cryptographic controls.
For NSS workloads, CNSA 2.0 algorithms become mandatory rather than permitted. CSPs supporting NSS must demonstrate ML-KEM-1024, ML-DSA-87, AES-256, and SHA-384/512 support per the CNSA 2.0 timeline.
What This Means for CSPs
A FedRAMP authorized CSP in 2026 should:
- Verify all cryptographic modules in use are CMVP validated, with current certificates.
- Maintain a cryptographic inventory aligned to the SSP.
- Engage CMVP queue providers about PQC validation timelines.
- Plan PQC pilot deployments for hybrid TLS and signature workflows.
- Track FedRAMP PMO guidance updates.
What This Means for Federal Customers
A federal agency consuming FedRAMP authorized cloud services should:
- Review the CSP's SSP for cryptographic control details.
- Verify the CSP's continuous monitoring includes cryptographic configuration validation.
- Add PQC migration expectations to contract refresh cycles.
- Coordinate with the Office of the CIO on the agency's broader PQC migration plan per OMB M-23-02.
Continuous Monitoring and Cryptographic Drift
FedRAMP requires continuous monitoring after initial authorization. Monthly vulnerability scans, annual reassessments, and significant change reviews keep the cryptographic posture current. Cryptographic configuration drift is a common finding, where a system that originally used strong cipher suites slowly accumulates legacy support to accommodate older clients.
CSPs should monitor cipher suite negotiation logs and alert when deprecated ciphers are negotiated more than a defined threshold. Customer agencies should review CSP continuous monitoring reports for cryptographic findings and request remediation timelines.
Future FedRAMP Updates
The FedRAMP Authorization Act of 2022 codified FedRAMP into statute (44 USC 3607 et seq.) and directed several modernizations. The PMO has been updating templates, automation tools, and authorization processes through FedRAMP 20x and similar initiatives. Cryptographic controls will be refined as part of these updates, with PQC adoption likely accelerating once OMB issues binding deadlines.
Agencies and CSPs should track FedRAMP PMO publications, especially for changes in the SSP template cryptographic sections and changes to baseline control sets.
FAQ
Q: Does FedRAMP require AES-256? A: FedRAMP requires FIPS validated cryptography. AES-128 and AES-256 are both FIPS validated. The choice depends on the impact level and specific guidance, with AES-256 increasingly the default for High impact baseline.
Q: Can I use a non FIPS validated cryptographic library in a FedRAMP system? A: Not for protection of CUI. Non FIPS validated cryptography may be acceptable for non security purposes (such as content addressed file naming), but anything protecting confidentiality, integrity, or authenticity of CUI must be FIPS validated.
Q: When will FedRAMP require PQC? A: FedRAMP follows NIST SP 800-53 and applicable federal directives. There is no specific PQC date for FedRAMP, but the migration is expected to track OMB M-23-02 and broader federal timelines.
Q: How does cloud KMS inheritance work? A: A CSP using AWS KMS, Azure Key Vault, or Google Cloud KMS can document inheritance of those services' cryptographic controls in its SSP. The 3PAO verifies the inheritance and the underlying service's FedRAMP authorization.
Q: What is the difference between FedRAMP Moderate and High? A: Moderate applies to systems with moderate impact per FIPS 199. High applies to systems with high impact, typically including CUI, financial information, or other sensitive categories. High has additional controls and tighter cryptographic requirements.
Sources
- FedRAMP, Authorization Boundary Guidance and Rev 5 Templates. https://www.fedramp.gov/documents-templates/
- NIST SP 800-53 Revision 5, Security and Privacy Controls. https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
- NIST SP 800-57 Part 1, Recommendation for Key Management. https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
- NIST SP 800-52 Revision 2, TLS Configuration Guidelines. https://csrc.nist.gov/pubs/sp/800/52/r2/final
- OMB Memorandum M-23-02, Migrating to Post Quantum Cryptography. https://www.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf
- NIST FIPS 203 (ML-KEM) and FIPS 204 (ML-DSA). https://csrc.nist.gov/projects/post-quantum-cryptography
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.