FedRAMP Policy for Cryptographic Module Selection and Use

Effective Date

Note: This is a draft policy that is posted for public comment. The formal public comment period closed on September 9th, 2024. Ongoing feedback on FedRAMP policies is always welcome by sending email to info@fedramp.gov.

Cloud service providers (CSPs), independent assessors (IAs), and FedRAMP designated leads must adhere to this version of the policy by MONTH DAY, YEAR. Reviewers of FedRAMP packages must adhere to this version of the policy starting on MONTH DAY, YEAR.

1. Policy Overview

Cryptography is the science of information hiding and verification. It includes the protocols, algorithms, and methodologies to securely and consistently prevent unauthorized access to sensitive information and enable verifiability of the information. The main goals include confidentiality, integrity authentication, and source authentication. Cryptography is critical to protecting cloud-based information systems and their data. Cryptographic algorithms are the basis of technologies that provide foundational security and privacy guarantees in modern systems, including encryption, digital signing, one-way hashing, privacy-enhancing technologies, and other security capabilities.

Cryptographic “modules” are hardware and software (including firmware) that implement security functions, including cryptographic algorithms and key generation, which are contained within a boundary. The boundary differentiates functionality that is contained within the module and functionality that is provided outside the module. Cryptographic modules can be, or be part of, open-source and proprietary software libraries, hardware security modules, on-device secure enclaves, or any other form of software or special-purpose hardware that can execute cryptographic algorithms.

When protecting federal information systems (“systems”) and information (“data”)¹, Federal agencies are required to use cryptographic modules that have been validated by an accredited laboratory as complying with the Federal Information Processing Standard (FIPS) 140 and are listed as validated by NIST’s Cryptographic Module Validation Program (CMVP). These modules use cryptographic algorithm implementations that have been validated by NIST’s Cryptographic Algorithm Validation Program (CAVP).

FedRAMP works primarily with commercially operated cloud service providers (CSPs) and is responsible for reviewing the security of those providers to meet the expectations of federal agencies. As a result, the FedRAMP process is responsible for applying the goals and requirements of the federal government into environments that are often operated very differently from those of many federal agencies.

FedRAMP needs to have a dedicated policy for how cryptographic module requirements will be applied in the context of managing and maintaining a system, as:

• Many cloud providers operate their software and security architecture using DevSecOps-based approaches that prioritize rapid patching and security feature development. These are security practices and outcomes that are in federal agencies’ interest to enable and incentivize in the services on which they rely, and FedRAMP should not discourage them. FedRAMP should especially avoid unintentionally creating pressures on cloud providers and agencies to rely on known-vulnerable software.
• Most commercially operated cloud providers in the FedRAMP marketplace serve a mix of government and non-government customers. Even when a cloud provider operates a government-focused instance of their service, this instance may share much of the same underlying software and hardware as other commercially-focused instances. This introduces complexity when different cryptographic modules, security functions, and algorithms are needed for different customer types. FedRAMP needs to enforce federal cryptographic standards in a way that does not require more complexity than is necessary.

This policy provides requirements for selecting and using cryptographic modules for cloud-based systems in a way that is informed by risk and focused on strengthening federal security overall. Note that selection and use of cryptographic modules is only one aspect of implementing, managing, and maintaining cryptography, and that using a validated module is not by itself sufficient.

FedRAMP has several goals for this policy:

1. Ensure that cryptographic algorithms and functions being used to protect the integrity or confidentiality of federal systems and data are approved.²
2. Avoid unintentionally incentivizing cloud providers to leave federal systems or data unprotected by omitting encryption and other applications of cryptography.
3. Promote the use of cryptographic modules that are free of known vulnerabilities over the use of validated modules with known vulnerabilities, except in cases where the unvalidated module’s use would clearly increase security risk over the use of a validated module.
4. Ensure that CSPs using unvalidated cryptographic modules document the rationale for doing so and a process for the ongoing assessment of their use in a way that is clearly visible to relying agencies, cloud service providers, and other stakeholders. Ensure that use of unvalidated modules is periodically reevaluated

To achieve these goals, this policy sets expectations for CSPs, independent assessors, agencies, and reviewers related to the assessment, review, and acceptance of given implementations. FedRAMP expects this policy to facilitate decisions necessary to keep federal systems and data secure.

2. Taking a Risk-Based Approach to Cryptographic Module Selection

FedRAMP is focused on the effective and transparent management of risk. Considering only the FIPS-validation status of a cryptographic module used by a product or service fails to take into account the larger risk picture based on how the module is used within the system (such as for an identity provider service or a cloud storage system versus a user endpoint), what functions it performs, what data is involved (including its sensitivity and the amount of data), and what known vulnerabilities exist in the module. For example, new vulnerabilities are discovered in FIPS-validated cryptographic modules from time to time. Federal agencies³ are required to patch or update this software in order to protect federal systems and data, but the fixed software is often not yet FIPS-validated.

It may not be possible to meet requirements for both using FIPS-validated modules and using software without known vulnerabilities at the same time. In such situations, FedRAMP generally prefers the elimination of known vulnerabilities through patches or updates over continuing to use known-vulnerable software that is FIPS-validated, since the presence of known vulnerabilities can create risks that outweigh the assurance value provided through validation. Cryptography should still be used when and where it is needed.

FedRAMP’s goal for system security is to manage, mitigate, or resolve risks that are identified. To maximize security outcomes, FedRAMP, in consultation with NIST and the Office of Management and Budget, has developed this FedRAMP-specific policy for selecting and using cryptographic modules.

2.1. Cases Where a Validated Module Is Not Necessary

There are some cases where a CSP does not need to use a validated cryptographic module because the module is not necessary for protecting federal systems and data. Here are a few examples:

• Services are being provided to entities that do not support, cannot use, or cannot reasonably enforce the use of validated modules. For example, the CSP may be interacting with non-federal entities that cannot consistently support validated modules. Another example is certificate authorities that issue publicly trusted certificates as part of the Web PKI. The CSP has no means of enforcing or controlling the cryptographic modules used, where an attacker’s options for obtaining a fraudulent certificate are not impacted by the CSP’s choice of certificate authority.
• Another layer of cryptography is already present and uses a validated module to achieve the security requirements. When multiple layers of cryptography are used to protect federal systems or data, it may be sufficient for only one of those layers to use a validated module. For example, if an inner encryption layer uses a validated module, an outer encryption layer (like a VPN tunnel or a mesh) might not need to use a validated module. If a CSP elects to use a second encryption layer that goes beyond what is needed to meet the SC-8(1) and SC-28(1) controls, the additional layer could use unvalidated modules. Additional layers of cryptography should be documented within the relevant controls, clearly stating that they exceed the requirement.
• The cryptography is not needed to protect federal systems or data. FedRAMP does not require CSPs to use validated modules where federal systems or data are not involved, or where the cryptographic function is not used to provide security guarantees. CSPs still need to use cryptography to protect sensitive systems and data, and the use of validated modules without known vulnerabilities is encouraged, and can even be useful to support similar requirements in other regions.

2.2. Software with Validated Modules Has Known Vulnerabilities

The management and implementation of cryptography is a critical part of the system development life cycle. CSPs need to apply a risk-informed approach when addressing vulnerabilities in systems and cryptographic modules. As explained earlier in this section, FedRAMP generally prefers use of an unvalidated module with no known vulnerabilities over the use of a known-vulnerable validated module.

However, there are situations where the latter may pose less risk than the former – for example, when the known vulnerabilities in the software are already being effectively mitigated through other means. In such cases, the CSP needs to take into consideration the relevant factors. Examples of possible factors include:

• The risk inherent in the software, including:
• the risk from known vulnerabilities
• weakness in the cryptographic implementation that may be discovered by the FIPS 140 conformance testing processes
• any mitigations in place to address these risks
• The potential impact to agency missions if there is a degradation of confidentiality, integrity, or availability for the system or data. This may already be reflected in the FIPS 199 level assigned to the system.
• The maturity of the software, the degree to which the update is based on the source code used in a validated module, and the software provider’s history with navigating the module validation process. This can help in estimating the likelihood that a new or updated module will become validated.

3. Requirements and Recommendations

Section 3 is normative. All other sections are informative.

This section defines requirements related to cryptographic module selection for four types of stakeholders: CSPs, independent assessors, reviewers of FedRAMP packages, and FedRAMP designated leads (sponsoring agencies or the FedRAMP program). It also defines recommendations related to cryptographic modules for the providers of operating systems, operating system images, and containers.

Each requirement or recommendation has a unique identifier corresponding to the responsible party; for example, the fourth requirement for CSPs has identifier CSP04. This identification approach enables referencing specific requirements and recommendations in this and other resources.

3.1. Cloud Service Providers

The FedRAMP marketplace must facilitate effective risk-based decisions by both agencies and CSPs themselves. Agency authorizing officials (AOs) must be able to see and understand the risks in any cloud service offering they authorize. CSPs working toward a FedRAMP authorization also need the confidence and visibility to leverage or build on another FedRAMP authorized cloud service offering as part of their own offering.

CSPs play the most important role in ensuring the adequacy of cryptographic protections in cloud services, and in providing the information necessary to facilitate decision making by the CSP community and agencies.

The following requirements apply to all CSPs:

• CSP01: CSPs shall note in their System Security Plan (SSP) in SI-2 control responses whether their default position is to apply patches or other updates (use update streams) or to use validated modules (use validated module streams). CSPs shall determine their default position by performing a risk evaluation that takes into consideration the module’s use in the system and the likelihood and potential impact of vulnerability exploitation, as well as mitigations to prevent such exploitation.
• CSP02: CSPs shall accurately document in Appendix Q of their SSP all cryptographic use cases and modules and module versions in use. Use of unvalidated modules shall be documented at the service offering, component, and cryptographic function level(s) in use as well as potential federal system or data impact(s), facilitating assessment and transparency to agency AOs.
• CSP03: CSPs shall document in the customer responsibility matrix any customer-required configuration necessary to securely utilize a module to protect federal data and to ensure that only approved algorithms are used. This documentation shall consider differences between cryptographic modes of operation (e.g., FIPS mode) that may change as a result of a module update, including the need to technologically prevent functionality that would be otherwise allowed if operated in a different mode, such as use of unapproved cryptographic algorithms.
• CSP04: CSPs shall align their Security Assessment Plans (SAPs) to the requirements captured within this policy, which need to be assessed according to the requirements for independent assessors in Section 3.2.
• CSP05: CSPs shall transparently and accurately represent their FIPS status and any related claims within publicly available documentation for their FedRAMP service offerings. These representations must use terminology approved by NIST⁴. CSPs must not use ambiguous or CSP-defined terms such as “FIPS compliant” in their representations to FedRAMP.
• CSP06: CSPs using unvalidated modules shall periodically⁵ reevaluate their use in light of new and emerging threats, the lifecycle availability of validated modules, the effectiveness of mitigations, and the risk tolerance of AOs.
• CSP07: No exceptions can be made that will reduce the visibility of modules in required continuous monitoring data provided to FedRAMP or agencies. This ensures that FedRAMP and agency AOs can monitor any ongoing risk related to the use of cryptographic module versions.

The following requirements involve situations where new vulnerabilities are discovered in software in use that contains cryptographic modules:

• CSP08: CSPs shall determine if updating to a newer version of the software would eliminate the vulnerabilities. If it would, CSPs shall promptly update unless there are circumstances making that infeasible.
• CSP09: If updating the software to eliminate known vulnerabilities is not currently an option, CSPs shall create or update their POA&M based on the criticality of the vulnerabilities⁶ to communicate their plan for remediating or mitigating the vulnerabilities. The plan outlined in the POA&M will help inform AOs’ ongoing authorization decisions.
• CSP10: If the CSP’s default position is to prefer validated modules over updates, but the options for software updates that would eliminate known vulnerabilities all contain modules that do not have current FIPS validations, the CSP shall take into consideration the order of preference for cryptographic module selection expressed in list below. CSP documentation shall support the CSP’s determination of which preferred options cannot be reasonably implemented. The documentation shall include clear and consistent descriptions of all deviations from validated modules, along with the CSP’s approach to manage, mitigate, and remediate the risks, and any usage considerations for customer responsibilities related to the cloud service.
1. Mitigate the vulnerability in the validated module
2. Use an unvalidated module, in the following order of preference:
1. Module substantially similar to a FIPS-validated module; validated algorithm
2. FIPS validation in process for module; validated algorithm
3. Expired FIPS validation for a previously validated module; validated algorithm
4. Module not in FIPS validation process; validated algorithm
5. Algorithm is approved and tested but not yet validated, and the module is not in FIPS validation process
• CSP11: CSPs that are required to have POA&Ms related to their cryptographic module selection shall upload the internal evaluation, risk analysis, usage considerations, configuration, and impacted use cases documentation to the POA&M repository. These CSPs shall provide a monthly update within the POA&M on their progress, including evidence necessary to resolve the POA&M and documentation detailing any engagement with providers of cryptographic modules.

3.2. Independent Assessors

The following requirements detail activities that help ensure that CSPs are managing the selection and use of their cryptographic modules according to the requirements of Section 3.1.

IA01: IAs shall perform a comprehensive examination⁷ where unvalidated modules are used to meet a control requirement (i.e., when CSP09 and CSP10 apply). IAs shall ensure that such modules and mitigations are operating as intended and producing the documented security and risk management outcome.

IA02: IAs shall review module risk evaluation activities performed by the CSP in support of CSP10 to ensure they are thorough and well-formed, and that mitigations outlined are implemented as described and produce the desired outcome.

IA03: IAs shall verify that all cryptographic use cases and use of modules are accurately documented, including the specific modules and versions in use. IAs shall verify that documentation for all use of unvalidated modules facilitates assessment and transparency for agency AOs by including which components are affected, where the modules are used compared to the service offering, which cryptographic functions are used, and what risks remain for agencies to consider.

IA04: IAs shall verify that POA&Ms related to cryptographic modules are created by the CSP when required, are updated on a monthly basis, and are not overdue.

IA05: IAs shall verify that required artifacts are provided that demonstrate CSP work with the cryptographic module providers, as well as submission of modules, including achieving validated status.

3.3. Package Reviewers

The following requirements apply to FedRAMP reviewers and designated lead package review teams. Package reviewers help ensure that CSPs are managing the selection and use of their cryptographic modules according to the requirements of this policy in Section 3.1, which are a requirement for all FedRAMP authorizations.

PR01: Package reviewers shall ensure that all cryptographic use cases and modules are accurately documented, including the specific modules and versions in use. Reviewers shall verify that the use of unvalidated modules is documented at the service offering, component, and cryptographic function, and agency system impact(s), facilitating assessment and transparency to agency AOs.

PR02: Package reviewers shall validate that the assessment artifacts represent a thorough evaluation where unvalidated modules are used to meet a control requirement.

PR03: Package reviewers shall evaluate risk evaluation activities performed by the CSP to ensure they are thorough and well-formed, and that mitigations outlined are implemented as described and produce the desired outcome.

3.4. FedRAMP Designated Leads

FedRAMP designated leads are the entities responsible for sponsoring a CSP for a FedRAMP authorization. A designated lead can be an authorizing official at another federal agency who is the sole sponsor, or the lead agency within a multi-agency authorization, or can be GSA through the FedRAMP Director in the case of a program-sponsored authorization.

Designated leads help ensure that CSPs are managing the selection and use of their cryptographic modules according to the requirements of this policy in Section 3.1.

DL01: FedRAMP designated leads shall review documentation that captures the cryptographic module provider’s approach to managing cryptographic module validation as part of their system development life cycle.

DL02: FedRAMP designated leads shall review SC-13 findings in the POA&M and related risk identification and mitigation documentation provided within the CSO repository.

3.5. Operating System Distribution, Operating System Image, and Container Image Providers

The following recommendations apply to the providers of operating systems, operating system images, and containers containing cryptographic modules. CSPs should ask the following of providers:

OSP01: Providers of operating system distributions, operating system images, and container images should be transparent about changes they make in their software in regards to cryptographic modules. For example, their change logs should include information if cryptographic modules were changed and the nature and extent of any changes. This will help organizations using the cryptographic modules to better estimate the risk associated with those changes.

OSP02: Providers of operating systems should promote the use of “update streams” over the use of “validated module” streams. Pinning to validated modules often has a negative net effect on software dependencies that can result in the use of outdated, vulnerable versions of other software components in the operating system. This can increase the overall number of severe vulnerabilities in libraries and other software across the operating system, making it less secure overall.

OSP03: Providers of operating systems should periodically resubmit their software for FIPS validation to maintain a high level of cryptographic module assurance. Some CSPs may be tracking FIPS validations and delaying upgrades until validations are completed.

OSP04: Providers that implement algorithms should ensure that these algorithms are tested and meet NIST requirements using the CAVP Automated Cryptographic Validation Testing System (ACVTS). Once algorithm testing has been initially set up⁸ with the ACVTS server, this process can be automated for each release.

Revision History

FedRAMP will review this policy on a yearly basis and will issue revisions as needed. Suggestions for improving the policy are welcome at info@fedramp.gov.

Footnotes

1. OMB Circular A-130, “Managing Information as a Strategic Resource” defines federal information system as “an information system used or operated by an agency or by a contractor of an agency or by another organization on behalf of an agency” and federal information as “information created, collected, processed, maintained, disseminated, disclosed, or disposed of by or for the Federal Government, in any medium or form.” ↵
2. Approved cryptographic algorithms and functions are listed on the Cryptographic Algorithm Validation Program site. ↵
3. Sources of these requirements include FIPS 200, Minimum Security Requirements for Federal Information and Information Systems and Cybersecurity Directives from the Cybersecurity and Infrastructure Security Agency (CISA). ↵
4. See use of FIPS 140 logos and phrases on the CMVP website for specific phrase and logo requirements. ↵
5. For frequency requirements, see Section 3 of the FedRAMP Plan of Actions and Milestones (POA&M) Template Completion Guide. ↵
6. This is consistent with vulnerability management requirements defined in the FedRAMP Plan of Actions and Milestones (POA&M) Template Completion Guide, Section 3 of FedRAMP Vulnerability Scanning Requirements, and the FedRAMP Vulnerability Deviation Request Form ↵.
7. SP 800-53A Rev. 5, Assessing Security and Privacy Controls in Information Systems and Organizations ↵
8. See how to access ACVTS for more information on use of the ACVTS. Usage guidelines are also available. ↵