Frequently Asked Questions

The Federal Risk and Authorization Management Program (FedRAMP) is a government-wide program that promotes the adoption of secure cloud services across the federal government by providing a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP empowers agencies to use modern cloud technologies, with an emphasis on security and protection of federal information. To learn more, visit the About Us section on the FedRAMP web site.

FedRAMP eliminates duplicative efforts by providing a common security framework. Agencies review their security requirements against a standardized baseline. A cloud service provider (CSP) goes through the authorization process once, and after achieving an authorization for their cloud service offering (CSO), the security package can be reused by any federal agency.

FedRAMP enables the federal government to accelerate the adoption of cloud computing by creating transparent standards and processes for security authorizations and allowing agencies to leverage security authorizations on a government-wide scale.

Yes, FedRAMP is mandatory for all executive agency cloud deployments and service models at the Low, Moderate, and High risk impact levels. Please refer to the FedRAMP Policy memo for further information pertaining to FedRAMP’s applicability.

All official FedRAMP documentation is maintained on FedRAMP.gov. Opportunities for large-scale public comment periods will be messaged via a number of channels and methods. To ensure you are notified of these opportunities, subscribe to the FedRAMP distribution list for updates. Be sure to follow us on X (formerly Twitter) @FedRAMP to get notifications on other program updates.

FedRAMP is FISMA for the cloud. Per FISMA, the National Institute of Standards and Technology (NIST) is responsible for establishing “policies which shall set the framework for information technology standards for the Federal Government”. Based on this law, NIST developed the Risk Management Framework .

Both FedRAMP and FISMA use the NIST SP 800-53 security controls. The FedRAMP security controls are based on NIST SP 800-53 baselines and contain controls, parameters and guidance above the NIST baseline that address the unique elements of cloud computing.

There is a shared security responsibility model when using cloud products. Cloud service providers (CSPs) and customers (agencies or leveraging CSPs) both assume important security roles and responsibilities to ensure data is protected within cloud environments. CSPs are required to submit a Control Implementation Summary/Customer Responsibility Matrix (CIS/CRM) workbook as Appendix J to the System Security Plan (SSP). The CIS/CRM workbook identifies security controls that the CSP is responsible for implementing, security controls that the customer is responsible for implementing, security controls where there is a shared CSP/customer responsibility, and security controls that are inherited from an underlying FedRAMP Authorized Infrastructure-as-a-Service (IaaS) or Platform-as-a-Service (PaaS). CSPs use the CRM to describe the specific elements of each control where the responsibility lies with the customer.

If a Cloud Service Offering (CSO) is listed as FedRAMP Authorized on the FedRAMP Marketplace, it has successfully completed the FedRAMP authorization process. The FedRAMP Authorized designation indicates FedRAMP requirements are being met and a CSO’s security package is available for agency reuse. This means that any agency can request access to the security package for a FedRAMP Authorized CSO, review the security package, and issue their own Authority to Operate (ATO) for the product.More information on how to reuse an existing security package can be found in the FedRAMP Reusing Authorizations for Cloud Products Quick Guide.

As a registered USDA Connect (formerly OMB MAX) user, you have the ability to “Watch” a page. To watch a page, navigate to a folder within a package and click the icon labeled “Watchers” in the upper-right corner of the screen. Oncea drop-down opens, click “Watch This Page”. When a page is being watched, you will be notified via email of changes made to that page. This can be particularly helpful for cloud service providers (CSPs), agencies, or third party assessment organizations (3PAOs) as they anticipate the uploading of key documents, like a system security plan (SSP) or security assessment report (SAR). To stop watching a page, simply click again on the icon in the upper-right corner of the screen to open a dropdown and click “Stop Watching This Page”.

Simply email info@fedramp.gov to request access extensions. If your agency has issued an Authority to Operate (ATO) for the cloud service offering (CSO), you can submit the ATO to ato-letter@fedramp.gov and receive permanent access to the package as long as an ATO is on file with the FedRAMP Program Management Office (PMO).

An Initial Agency Partner or initial authorizing agency refers to the first agency to grant an Authority to Operate (ATO) using FedRAMP standards and baselines for the Cloud Service Offering (CSO). Some stakeholders use the term "Agency Sponsor.” FedRAMP does not recognize the concept of an agency sponsor because the ATO granted by the initial authorizing agency is not a government-wide risk acceptance. As described in FedRAMP's Reuse Quick Guide, OMB Circular A-130 requires agencies to individually authorize the operation of an information system and to explicitly accept the risk. Each agency that wishes to use the CSO will conduct its own risk review of the authorization package and grant its own ATO.

It depends on the quality of the authorization package. Because the initial authorizing agency is the first agency to review the authorization package, the process for getting to an informed risk-based decision may take longer and require more effort if there are aspects of the authorization package that are unclear, incomplete, inaccurate, or inconsistent.

The FedRAMP Program Management Office (PMO) provides guidance to Cloud Service Providers (CSPs) and third party Assessment Organizations (3PAOs) on how to deliver a high quality authorization package, but if the agency team is unable to determine the actual security posture of the cloud service offering (CSO) due to poor quality, the agency will provide feedback. The feedback may result in modifications to the package deliverables and/or additional testing, and additional review cycles.

No. It is not the initial authorizing agency’s responsibility to conduct ConMon oversight on behalf of all other agencies. OMB Circular A-130 requires federal agencies to implement the Risk Management Framework (RMF) described in NIST SP 800-37 . The RMF process includes a Monitor step. The purpose of this step is to maintain ongoing situational awareness about the security posture of the system in support of risk management decisions. Each agency that issues an ATO or ATU for a cloud offering must review the cloud service provider’s (CSP’s) ConMon activities to ensure the security posture remains sufficient for its own use and supports an ongoing authorization. This includes reviewing the monthly Plan of Action and Milestones (POA&M), approving deviation requests and significant change requests, and reviewing the results of the annual assessment. With the release of the FedRAMP Rev 5 baselines, security control CA-7 requires CSPs with more than one customer agency to implement collaborative ConMon. This approach is intended to streamline the ConMon process and potentially minimize duplicative efforts in a way that helps each agency still perform their due diligence related to ConMon. The PMO developed a recommended Collaborative ConMon approach, which is described in the FedRAMP Collaborative ConMon Quick Guide. Collaborative ConMon benefits agencies by allowing them to share responsibility for ConMon oversight, and it benefits the CSP by creating a central forum for addressing questions and achieving consensus related to deviation requests, significant change requests and the annual assessment - versus having to coordinate with each agency separately.

NIST SP 800-37 describes the ATO and ATU as very similar in that they both are the mechanisms for documenting and accepting risk of information systems, and approving the use of the system by the agency. ATUs are intended to be used for shared systems, but still document accepting risk and approving use (based on an external security assessment). Though FedRAMP accepts both ATOs and ATUs, there must be at least one ATO on file for the cloud service offering (CSO) in order for FedRAMP to accept an ATU.

Agencies should first notify the cloud service provider (CSP) that they plan to rescind their Authorization to Operate (ATO) as they no longer are using the service. After they have notified the CSP, the agency should send an email to info@fedramp.gov, CCing their CSP, which notifies the FedRAMP Program Management Office (PMO) that the service is no longer in use at the agency, and indicates the agency will rescind the ATO letter by a specific date.

A CSO must have at least one active Authority to Operate (ATO) from a federal agency on file with the FedRAMP Program Management Office (PMO) to maintain an Authorized designation on the FedRAMP Marketplace. Having an ATO on file with FedRAMP ensures at least one agency is conducting oversight of the Cloud Service Provider’s (CSPs) Continuous Monitoring (ConMon) activities.

If a CSP's service offering loses its only ATO on file with FedRAMP, the service offering may remain listed on the FedRAMP Marketplace as FedRAMP Ready for a maximum of 12 months while the CSP works to obtain a new ATO from a federal agency. If a new ATO is obtained during this period, the CSO will regain its FedRAMP Authorized designation. If an ATO is not achieved within 12 months, the CSP may maintain its FedRAMP Ready designation by working with a FedRAMP-recognized Third Party Assessment Organization (3PAO) to complete a Readiness Assessment of its service offering. Alternatively, the CSP may transition to In Process by fulfilling the requirements described in FedRAMP’s Marketplace guidance. This provision does not apply to service offerings that lose their only ATO due to lack of maintaining an acceptable security posture.

Please review the About FedRAMP Marketplace page for a full explanation of the provision for CSPs that lose their only ATO on file.

The FedRAMP Policy Memo does not apply to private clouds intended for a single organization that are implemented on premises (i.e., within a federal facility). In this scenario, agencies continue to follow the FISMA process and use the appropriate NIST security standards and guidelines for their private cloud-based information systems.

In the scenario where a dedicated private cloud application is deployed on top of another cloud (IaaS, PaaS) versus within a federal facility, the agency should use the FedRAMP process and baselines to authorize the cloud service. However, the FedRAMP PMO does not review packages for private clouds, grant a FedRAMP Authorized designation, or list them on the Marketplace because the concept of “reuse” does not apply.

There are three listing designations available on the FedRAMP Marketplace: FedRAMP Ready, In Process, or Authorized.

• FedRAMP Ready indicates that a third party assessment organization (3PAO) attests to a CSP’s readiness for the authorization process, and that a FedRAMP Readiness Assessment Report (RAR) has been reviewed and approved by the FedRAMP Program Management Office (PMO). The RAR documents the CSP’s capability to meet FedRAMP security requirements.
• FedRAMP In Process is a designation provided to CSPs that are actively working toward a FedRAMP authorization.
• The FedRAMP Authorized designation is provided to CSPs that have successfully completed the FedRAMP authorization process. This designation indicates the CSP’s security package is available for agency review and reuse. Private cloud offerings are not listed on the FedRAMP Marketplace as they do not meet the intent of “do once, use many times” and thus the security packages are not considered reusable.

More detail about these designations and how to be listed on the Marketplace can be found on the About FedRAMP Marketplace page.

As a first step, please complete the FedRAMP Cloud Service Provider (CSP) Information Form to notify the FedRAMP team of your intent to pursue a FedRAMP authorization with a federal agency. Submission of the form will generate a FedRAMP Package ID for your cloud offering. In addition, you will receive an email that describes the next steps in the authorization process, along with links to a number of helpful resources.

CSPs may use the FedRAMP logo. Use of the FedRAMP logo, in conjunction with qualified products, services, or organizations requires prior approval from the FedRAMP Communications team. As a first step, you should work with your legal counsel and your communications or marketing department to ensure you are compliant with the FedRAMP Branding Guidance and the items below for all marketing materials:

• The registration symbol (®) must be used with the FedRAMP name. The symbol does not have to be used every time the FedRAMP name is used; instead, use the registration symbol in the first instance the FedRAMP name is used, in the most prominent use, or both.
• The FedRAMP logo must be in compliance with the brand guide and always include the trademark symbol (™).
• Avoid any claims that your company is an exclusive or first provider of a FedRAMP Authorized service in a specific category.
• Avoid using the FedRAMP logo and name in a manner that would imply government endorsement of a company, its products, or its services. Neither the logo nor the FedRAMP name may be used in any other company name, product name, service name, domain name, or website title.

Please send your branded marketing materials to the FedRAMP Communications team at branding@gsa.gov and allow up to ten business days for a complete review.

3PAOs play a critical role in the authorization process by assessing the security of a cloud service offering (CSO). As independent third parties, they perform initial and periodic assessments of cloud systems to ensure they meet FedRAMP requirements. The federal government uses 3PAO assessments as the basis for making informed, risk-based authorization decisions for the use of cloud products and services. 3PAOs are accredited by the American Association for Laboratory Accreditation (A2LA). A list of FedRAMP recognized 3PAOs can be found on the FedRAMP Marketplace under the “Assessors” tab.

In addition to the critical role that 3PAOs play in assessing cloud services, some cloud service providers (CSPs) use 3PAOs as consultants to help prepare security documentation or provide security advisory services. When CSPs use 3PAO advisors, they must select a different 3PAO to conduct an assessment of their cloud service to ensure that the assessor maintains impartiality.

In order to become a FedRAMP recognized 3PAO, the American Association for Laboratory Accreditation (A2LA) must perform an initial assessment of the 3PAO and provide an initial assessment recommendation to FedRAMP for approval. For a 3PAO to maintain its FedRAMP recognition, A2LA must perform a favorable annual review and a full on-site reassessment every two years. A2LA assessments ensure 3PAOs meet the requirements of ISO/IEC 17020 (as revised) and FedRAMP-specific knowledge requirements. More information on becoming an accredited 3PAO may be found on the A2LA website .

For the Agency Authorization process, a 3PAO is recommended, but not required. A CSP’s agency partner may choose to use their own independent assessment organization to assess the system. If an agency chooses to use their own independent assessment organization, the Agency Authorizing Official must submit an attestation regarding the organization’s impartiality and independence. The independent assessment organization must use the most current FedRAMP templates for the assessment and follow all FedRAMP requirements.

No, using a FedRAMP Authorized infrastructure does not automatically make your service FedRAMP compliant. Each layer (i.e., IaaS, PaaS, and SaaS) must be evaluated on its own and become FedRAMP Authorized. However, when your software sits on a FedRAMP Authorized infrastructure, it will inherit controls from that authorized system and you can explain this in your documentation.

Yes, CA-8 requires a penetration test as part of the assessment/testing process for all baselines. For more information, please refer to the FedRAMP Penetration Test Guidance.

Continuous monitoring ensures a service offering maintains an appropriate security posture for the life of the system. Cloud service providers (CSPs) maintain and validate the security posture of their service offering through vulnerability management, including monthly operating system, database, web application, and container scanning reports. CSPs also conduct an annual assessment and report incidents. Please refer to the FedRAMP Continuous Monitoring Strategy Guide for a list of all continuous monitoring deliverable requirements and to the FedRAMP Continuous Monitoring Performance Management Guide for guidance on continuous monitoring and ongoing authorization in support of maintaining a security authorization that meets the FedRAMP requirements.

All of the false positives, found during the annual assessment, should be added to the plan of action and milestones (POA&M). If they are approved before the SAR is closed/signed, they are moved to the “Closed POA&M Items” tab. If they have not been approved, they should remain in the “Open POA&M Items” tab until approved. Then, at least annually during assessment, the false positives should be evaluated for continued false positive status. For more information on handling the annual assessment and scan findings review the FedRAMP Continuous Monitoring Strategy Guide.

A change in infrastructure would be considered a significant change that would need to be evaluated for the scope of the change, impact on the risk posture, and could possibly result in the need for re-authorization. See the FedRAMP Significant Change Policies and Procedures guidance for more information.

Program offices seeking to expedite onboarding of a CSP authorization can consider source selection criteria that can be used in evaluating cloud service offerings (CSOs) that may already have an existing type of FedRAMP authorization. Inclusion of such evaluation criteria should be discussed with the agency acquisition integrated project team (IPT), including appropriate legal representation.

FedRAMP requirements apply to all federal agencies when federal information is collected, maintained, processed, disseminated, or disposed of by cloud service providers (CSPs). Federal agencies are responsible for ensuring the FedRAMP requirements are met. Contractors are held accountable for performance written into a contract. Program and project managers must include FedRAMP requirements in performance criteria, deliverables, and other appropriate performance outcomes to facilitate inclusion in contract awards.

No. The FedRAMP process builds on FISMA and the National Institute of Standards and Technology (NIST) baseline controls by removing requirements that are not applicable to commercial entities and replacing those with controls more appropriate for ensuring security related to protecting information maintained on behalf of the federal government.

Perhaps. FedRAMP Ready means a CSP has expressed an interest in becoming a federal provider by sharing information with the federal government that indicates they can meet several of the baseline FedRAMP criteria. FedRAMP Ready does not mean the vendor has achieved FedRAMP authorization.

In some cases, but only if there are an adequate number of vendors to allow for effective competition. Inclusion of FedRAMP authorization as a condition of contract award or use as an evaluation factor should be discussed with the agency acquisition integrated project team (IPT), including appropriate legal representation.

Yes. If an agency has constraints and/or requirements for specific data locations (e.g., data-at-rest), the agency should make those specific requirements known through the solicitation process. FedRAMP does specify data location requirements in the High baseline as part of control SA-9 (5); however, FedRAMP does not provide or specify data location requirements for the other baselines. Beyond FedRAMP, other federal statutes, regulations, or policies may apply.

No. Federal agencies have the responsibility and discretion to include any requirements necessary to protect information. FedRAMP sets a baseline for protecting federal information in a cloud environment.

FedRAMP requires CSPs to describe their organization’s personnel screening requirements. If an agency has requirements for federal background investigations, or additional screening and/or citizenship and physical location (e.g., U.S. citizens in Continental United States [CONUS] offices only), then those requirements would need to be specified in the solicitation language, which may affect bid pricing.

To achieve a FedRAMP Ready designation, a CSO’s MFA solution must comply with NIST Special Publication (SP) 800-63B, which requires the use of FIPS 140 validated encryption for MFA tools. While agencies may accept risk by allowing a CSP to work through POA&M actions to achieve compliance with NIST SP 800-63B requirements, a Readiness Assessment Report (RAR) has no authorizing official to accept and approve risk for open POA&Ms. A FedRAMP Ready designation indicates to agencies that a cloud service can be authorized without significant risk or delay due to noncompliance. The use of FIPS 140 validated cryptographic modules, where encryption is required, is a federal mandate, as indicated in the RAR template. This applies to MFA tools as well.

The FedRAMP PMO has provided additional resources below that apply to all MFA tools, where required (authenticators and verifiers).

MFA resources:

• On low baseline systems, FIPS 140 validated crypto modules are only required for MFA verifiers, not authenticators.
• On Moderate baseline systems, user-provided (“bring-your-own”) authenticators are exempt from having to meet FIPS 140 requirements, particularly in the government-to-public use case. Note: This exemption does not apply to CSP personnel. The FIPS 140 requirement still applies to CSP employee and contractor authenticators.

Security control SC-13 requires that FIPS 140-validated or NSA-approved cryptographic modules (CMs) are used where cryptography is required.

For more information on SC-13, please reference the SC-13 Additional FedRAMP requirements and guidance described in the FedRAMP Security Controls Baseline.

The status of a cryptographic module submitted for testing and validation can be found at the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website .

Usually not. Some vendors may use terms such as FIPS-compliant or FIPS-approved because the product is using a FIPS-approved algorithm, but not using a National Institute of Standards and Technology (NIST)-tested cryptographic module (CM). The product must actually be submitted for testing and validated through the NIST Cryptographic Module Validation Program (CMVP) to be considered FIPS-validated. Non-validated cryptography is viewed by NIST as providing no protection to the information or data - in effect, the data would be considered unprotected plaintext. Other important considerations:

• FIPS-validated CMs must be configured in an approved mode, which is documented in the associated security policy.
• Many FIPS-validated CMs also include non-approved algorithms even when run in FIPS mode. Only algorithms listed as approved in the CM’s security policy should be used.
• Third party assessment organizations (3PAOs) validate the use of a FIPS-validated CM by checking the certificate number, validating that the CM is configured in an approved mode, and only uses algorithms listed as approved in the CM’s security policy. Agencies and FedRAMP reviewers will also check the certificate number for each CM listed in the FedRAMP System Security Plan (SSP) and other documents to confirm validation status.

National Security Agency (NSA)-tested and approved cryptographic modules (CMs) are also acceptable. The NSA validation status of a CM can be found on the National Information Assurance Partnership (NIAP) website . Since FIPS 140-validated CMs are by far more commonly used in cloud service offerings (CSOs) than NSA-approved CMs, we will refer to FIPS mode from here on.

Any FIPS certificate with a status of Active is acceptable. Active FIPS 140-2 certificates can be accepted by federal agencies until September 22, 2026. After that time, the Cryptographic Module Validation Program (CMVP) will place the FIPS 140-2 validated modules on the Historical List, allowing agencies to continue using these modules for existing applications only. Active FIPS 140-3 certificates are acceptable now.

No. The SC-13 requirement applies to cryptographic modules (CMs) used to implement TLS; the use of TLS alone does not satisfy the requirement. While TLS 1.2 and above are required at the protocol level, it is necessary to demonstrate that FIPS 140-validated CMs are used to implement the protocol. It is worth noting that some FIPS 140 validated modules may not support cryptographic algorithms to allow for TLS 1.3. In addition to listing ports and protocols, CSPs must also identify the component that performs the encryption function along with the FIPS validation certificate number. For each component and data flow, the SSP Data Flow Diagram(s) and control implementation statements should clearly depict one of the following:

• FIPS-validated CM is implemented [with certificate number in SC-13 control description]
• Encryption is implemented, but not FIPS-validated
• Encryption is not implemented

Documentation that lacks accounting of FIPS status for each component delays the authorization process.

• For Cloud service offerings (CSOs) pursuing FedRAMP Ready (required for a FedRAMP JAB authorization), all federal mandates must be met. This means FIPS 140-validated modules must be implemented where encryption is required. Gaps cannot be addressed within a plan of action and milestones (POA&M).
• For CSOs pursuing a FedRAMP authorization via the FedRAMP Agency Authorization path, agency authorizing officials (AOs) may risk-accept FIPS 140 gaps under some circumstances. The first step is for the 3PAO to fully document and validate the FIPS status and document gaps in the POA&M to inform an AO’s risk-based authorization decision.

• CSP should take the approach that FIPS-validated CMs need to be implemented everywhere cryptography is required, and not look for exceptions.
• FedRAMP documentation should clearly show encryption and FIPS validation status for every data store, every data flow and authentication method.
• Plan of action and milestones (POA&M) should be established where gaps exist. The POA&M should include the reason for using non-compliant modules, for example:
• Migrated to a new version of the product; CM is undergoing National Institute of Standards and Technology (NIST) FIPS validation
• FIPS certificate for current version of the product is now “historical”; vendor seeking FIPS validation for new product
• Product does not support FIPS-validated encryption
• Component breaks in FIPS-mode, waiting for vendor patch

• POA&Ms should include a clear remediation plan and timeline to help inform an AO’s decision, for example:
• Replace component with FIPS-validated module prior to authorization
• Patch when compliant version available from vendor
• Remain on historic version of the module while awaiting migration to compliant version of the product
• Remain on historic version of the module while awaiting migration to compliant version of CM or product provided by different vendor

Compliance checks are used to evaluate configuration settings and provide general insight into the overall effectiveness of configuration management activities. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 control for configuration settings is CM-6; however, compliance check findings often map directly to specific 800-53 controls.

For initial assessments, annual assessments, and significant change requests, FedRAMP requires a clear understanding, on a per-control basis, of where risks exist. Therefore, 3PAOs must analyze compliance check findings as part of the controls assessment. Where a direct mapping exists, the 3PAO must document additional findings per control in the corresponding Security Assessment Reports (SAR) Risk Exposure Table (RET), which are then documented in the CSP’s plan of action and milestones (POA&M). This will likely result in the details of individual control findings overlapping with those in the combined CM-6 finding, which is acceptable.

For monthly continuous monitoring, cloud service providers (CSPs) and third party assessment organizations (3PAOs) are now asked to track these findings on a new tab of the POA&M document called “Configuration Findings”. There are no continuous monitoring triggers associated with these findings and they will not count as an “open” POA&M item. This new tab will only facilitate the tracking of and ability to see the deviation from the baseline that was set during the last assessment.

While findings assessed during the annual assessment or the initial assessment require the application of the specific control, any net new item found during monthly continuous monitoring can be labeled as “CM-6” until the next assessment when the specific control should then be applied and forever, thereafter, remain with the finding.

TIC modernization aligned with the Office of Management and Budget (OMB) M-19-26 provides flexibility for TIC capabilities and architectures supporting cloud implementations. Generally, TIC controls are aligned with the National Institute of Standards and Technology (NIST) SP 800-53 and should be aligned and evaluated to support the appropriate FedRAMP security control baselines. Determining the applicable and appropriate controls is a responsibility of both CSPs and agencies to establish a solution architecture that supports TIC policy enforcement points and other protections described in the TIC 3.0 Reference Architecture and TIC 3.0 Security Capabilities Catalog.

Cloud service providers (CSPs) will be implementing Rev. 5 controls based on the plans created from their Rev. 4 to Rev. 5 gap analysis. SCRs will be based on Rev. 4 or Rev. 5 determined by those CSP-specific implementation plans, and as coordinated with your agency authorizing official (AO).

Please refer to the "FedRAMP Baseline Rev. 5 Transition Schedule" section of the FedRAMP Baseline Revision 5 Transition Plan to determine your place in the transition schedule and what guidance you should follow in coordination with guidance from your agency authorizing official (AO).

If a Security Technical Implementation Guide (STIG) configuration parameter is more restrictive than the associated FedRAMP Rev. 5 baseline requirement, the cloud service provider is under no obligation to implement the STIG parameter unless it is covered under an Executive Order or DHS Emergency Directive.

Yes, Cloud service providers, in the continuous monitoring (ConMon) phase, are required to utilize automated scanning tools to perform service configuration scans monthly and provide the scan results to the FedRAMP documentation repository as part of the monthly ConMon deliverable. 3PAOs will ensure that service configuration scans are performed during annual assessments and provide those scans as part of the SAR.

While a WBS is not required, it may be requested by your agency authorizing official (AO). Please confirm your AO's expectations; however, the POA&M should have sufficient detail so that an AO can track the activities and progress made.

Each control should be tracked separately as a unique POA&M so that they can be managed separately.

Cloud service providers must manage their plan of action and milestones (POA&Ms) the same way they manage POA&Ms during continuous monitoring.

The FedRAMP Rev. 4 to Rev. 5 Assessment Controls Selection Template was developed to help. cloud service providers, 3PAOs, and agencies determine which controls need to be assessed during an annual assessment.

POA&Ms created, to document Rev. 5 control gaps, can be captured as Low severity "manual findings". Once the Rev. 5 control is fully implemented, a CSP should identify the evidence that supports POA&M closure in column Y "Supporting Documents" of the POA&M. For CSPs in the continuous monitoring phase, FedRAMP recognizes this may result in a spike of past due POA&Ms during the transition. Please work with your agency AO to determine the appropriate course of action.

CSPs with a FedRAMP authorization must utilize the Rev. 5 SSP template to identify the gaps between their Rev. 4 control implementations and the Rev. 5 requirements. CSPs should have already documented Rev. 4 to Rev. 5 gaps within the POA&M and the Rev. 5 CIS/CRM template. This provides stakeholders visibility into the Rev. 4 controls that have changed and what the CSP will do to implement the Rev. 5 requirements while also documenting the entire Rev. 5 gap.

Yes. The FedRAMP PMO is not providing a template.

FedRAMP is not providing a SCRM template at this time; however, NIST SP 800-161 includes sample SCRM templates in Appendix D.

CSPs are required to perform (or acquire 3PAOs to perform) Red Team exercises in accordance with CA-8(2) and must provide evidence in the form of a Red Team test plan that documents the scope, methodology, and approach of the exercise. CSPs must also provide the results of the exercise in the form of a Red Team test report. 3PAOs are required to validate and attest to the Red Team test plan and report during the initial SAR testing and during annual assessment testing.

Not at this time; however, FedRAMP will continue to have discussions to determine whether this is a capability to include in the future.

CSPs will document all operational requirements and false positives from configuration checks the same way that they do vulnerabilities identified from automated scanning tools. Please consult the FedRAMP POA&M Template Completion Guide for further guidance. Not applicable and alternative implementations for configuration settings should be discussed with your agency AO to determine the appropriate course of action.

There are some privacy-related controls in the FedRAMP baselines; however, like with Rev. 4, FedRAMP did not include the privacy overlay (Privacy Control Baseline) that NIST has defined in SP 800-53B or any PT controls as part of the FedRAMP baselines. It is the responsibility of each agency to determine their own privacy-related requirements and work with the CSP to make sure those controls are implemented. Privacy controls can fluctuate greatly depending on the data types, which is why these are not included as part of the FedRAMP baselines. CSPs should work with their agency AO to determine if the agency has privacy requirements above and beyond what is specified in the Rev. 5 FedRAMP baselines. There are no current plans to provide a Rev. 5 PTA/PIA template for CSPs to complete. Agencies should execute a PTA/PIA to ensure that they are meeting their privacy requirements.

FedRAMP will leverage NIST SP 800-161 as the requirements for supply chain considerations for all commercial, proprietary, and open source sources in cloud service offerings (CSO)s. If the technology is being used, or leveraged by the CSO, the supply chain controls apply. The supply chain risk management plan should enumerate all the products and the plan for managing any risks including open source. According to the supply chain controls, CSPs need to document the scope, methodology and the depth of documenting, managing and testing for the source of products or code being used. The supply chain controls are in scope for audits for FedRAMP but the supplier management is the responsibility of the CSP. 3PAOs will be examining the records and documents, not the individual suppliers.

While the supplemental guidance states that security awareness and security literacy training are two separate training activities, there is no requirement for giving separate trainings, only that the training covers both the topic categories. There is no requirement to provide distinct basic and advanced training. However, organizations may decide to separate basic and advanced concepts or combine them. Organizations determine the content of literacy training and awareness based on specific organizational requirements, the systems to which personnel have authorized access, and work environments (e.g., telework).

Control plane traffic in the context of external telecommunications systems are the exchanges with the telecommunication providers that allow for the use of data and voice services and include (e.g., management protocols, Domain Name Services (DNS) and Border Gateway Protocol (BGP)). The term management plane is not a NIST term and not mentioned in this control but in this context it would be the plane where device management and monitoring takes place inside the authorization boundary. While there would not be a prescribed implementation detecting changes the protocols that defined network level changes do have safeguards built. How the CSP chooses to monitor for changes will be dependent on the implementation.

CSPs can assess the baseline risk factors defined in NIST SP 800-161, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, Appendix E Table E-1. CSPs will need to work with their vendors to gain access to the necessary documentation that the CSP can review to determine whether the vendor is in alignment with NIST 800-171 or equivalent framework. That may be an internal assessment performed by the supplier, a third-party, or in support of a framework such as PCI or ISO/IEC 27001 and others.

Network connections are represented in several areas of an SSP. The reference number assigned in the “Data in Transit (DIT)” table of Appendix Q should be used to align these entries to the “Ports, Protocols, Service (PPS)” table, and DIT lines on the data flow diagram (DFD).

All DIT connections should be included in all three places and are consistently aligned.The Rev. 5 templates address this by:

• Ensuring all DIT is represented in all three locations
• Provides a reference number for traceability from one to another
• Reduces clutter on the DFD by requiring only the reference number on each line

It is expected that a single entry in the Appendix Q DIT table will have the same properties in the PPS table, and on the DFD. CSPs are encouraged to consolidate the DIT table to unique entries rather than a row for every connection in the CSO.

This control does not prescribe the use of any specific tool or technology. Understanding data types and location, and when the data is transmitted internally and outside of the boundary can be accomplished through multiple implementations. This functionality should be in place in operations and can inform design and architecture decisions. If there is a single solution or there are multiple technologies that use automated mechanisms to identify the location and type of data and protect the organizational and privacy data, that meets the intent of the control. The solution should be documented in the SSP. Ultimately, the authorizing official will determine if the documented solution meets the intent of the control and properly identifies and protects the organizational and privacy information.

Yes, CSPs will likely be applying for FedRAMP authorization and ET Prioritization at the same time. They are not linked in the ET Prioritization Framework because the authorization paths are changing as a result of the anticipated finalized OMB Memo. The exact details of how the processes will be integrated and rolled out will be made clearer in future blogs and documentation after the new paths are released.

Yes. You must have a complete package to apply for an ET Prioritization. Please refer to the Prioritization Framework in the Evaluation Process for details.

CSPs are encouraged to start their FedRAMP authorization as soon as possible. If a CSP does not already have a package in the queue when the prioritization request is made, then there is a low probability of being selected in the current application period. The prioritization process can only benefit the CSP if their security package is ready for evaluation by the Agency review team.

If a CSP is already FedRAMP-authorized and is interested in adding Artificial Intelligence to their offering, this would be handled through the Significant Change Request process in coordination with their Authorizing Official.

An AI model card, explained here , is a short document that accompanies trained machine learning models that provides transparent model reporting and explains source, quantity, and freshness of training data. Model cards also disclose the context in which models are intended to be used, details of the performance evaluation procedures, and other relevant information.

These are a sampling of reasonable, public or open source model cards that include information that reflects expected content in a model card. FedRAMP has elected to use the Hugging Face model card as its base. The examples provided below may not follow the Hugging Face model card standard and are provided as illustrative examples. Offerers are expected to use the FedRAMP model card template and must provide a response to all non-optional fields.

• Hugging Face model card template
• Meta Llama3 family of LLMs model card
• Meta Code Llama model card
• Google Gemma model card
• Anthropic Claude model card with focus on Claude2
• LMSYS Vicuna model card
• openai gpt2 model card
• HPCAI Colossal Llama model card

Below are some sample model card writing guides or utilities that may be useful to CSPs in developing their model card. This is not an endorsement of any included tools or guides. CSPs are encouraged to follow the FedRAMP model card template located in GitHub .

https://huggingface.co/docs/hub/en/model-card-annotated

This model card writing tool can be used by a CSP to generate a basic model card and then use an editor which supports markdown, such as visual studio code to modify the generated model card.

https://huggingface.co/spaces/huggingface/Model_Cards_Writing_Tool

FedRAMP acknowledges that model cards are being introduced as a new concept and therefore has worked to provide utilities that can assist CSPs in building and accelerating the delivery of the requested artifact. As such, we have provided examples of model cards that are already in the ecosystem. We’ve provided a template that is direct about what fields FedRAMP is interested in reviewing. Additionally, these model card writing utilities have been helpful to others in starting their model cards. No endorsement of these utilities should be implied.

Model cards will be evaluated via a qualitative process. The model cards are intended to provide transparency regarding what use cases the model is good for, what training data was used, how fresh or recent is that data, and any limitations, biases, or risks that exist in the offering itself. These are necessary so that federal agencies can determine how to leverage the offerings and best apply them to their mission needs. Therefore, FedRAMP will look to prioritize those offerings that most completely supply data to the required fields and are thorough in providing quality answers in the model card responses.

CSPs that are in process and have completed an assessment with their 3PAO must complete the process of the authorization before adding ETs to their package for consideration. If an assessment has not been performed, ET could be introduced so long as the 3PAO assessment plan is updated to test the ET. Once FedRAMP Authorized, the ET can be added via the Significant Change Request (SCR) process.

Generalized APIs that support chat interfaces, code generation, and text based image generation are listed in Executive Order 14110 . Following the draft public comment period, it was decided that additional capacity was needed for prioritization of these tools, along with an emphasis on both user interactive tools as well as programming interfaces that could enable more platforms and applications to incorporate generative Artificial Intelligence features.

The Emerging Technology Prioritization Framework reuses the previously described JAB definitions for demand including these three sources: 1) Current customers, 2) indirect customers, and 3) potential customers. See pages 3-6 of the Emerging Technologies Prioritization Criteria and Guidance under “Breakdown of Demand Categories” for additional details around the accepted demand categories and examples of each. Please note, unlike the previous Joint Authorization Board’s (JAB) demand criteria, CSPs are now required to apply with a minimum of at least 1 current customer or agency partner.

CSPs will need a demand score of 3 in order to be prioritized. There will need to be at least 1 current customer to also be prioritized. The remaining contributing points can come from a combination of the 3 demand sources. Please review page 4 of the Emerging Technologies Prioritization Criteria and Guidance under “Demand Scoring Rubric” for a further breakdown of the demand scoring rubric.

As a result of lessons learned from the JAB, there are caps placed on both the indirect and potential customer sources of demand. Indirect demand is now capped at 4 total submissions, and potential demand is capped at 8 total submissions. This allows CSPs to add a total of 1 point for each of these categories to their total demand score.

The list of ET for prioritization will be reviewed annually at a minimum, or as directed by the FedRAMP Board for adjustments or alterations. In the future, FedRAMP will open a request mechanism to Agencies and industry to submit ideas for additional Emerging Technologies. These will be validated with the Federal CIO council and government stakeholders before being added to the approved list.