FedRAMP RFC-0011: FedRAMP Pilot Standard for Storing and Sharing Authorization Data (Closed)

[rpalmer-gsa]

RFC-0011 FedRAMP Pilot Standard for Storing and Sharing Authorization Data

• Status: Closed
• Created By: FedRAMP PMO
• Start Date: 2025-05-23
• Closing Date: 2025-06-22
• Short Name: rfc–0011-standard-for-storing-and-sharing

Where to Review Comments

• Discussion Forum: https://github.com/FedRAMP/rfcs/discussions/33

Summary

The FedRAMP Standard for Storing and Sharing Authorization Data outlines requirements for cloud service providers who wish to self-host FedRAMP related authorization data and package materials within their own managed services. Providers who self-host this authorization data, including continuous monitoring materials, would not need to upload materials to the FedRAMP Secure Repository.

This standard will be accompanied by an optional pilot phase to allow FedRAMP, cloud service providers, and agencies to learn directly how to best implement this process. Requirements are likely to change based on feedback and learnings during the pilot. More information on the pilot will be provided separately at fedramp.gov. The pilot will be announced during June of 2025.

Motivation

FedRAMP has managed a centralized file repository that hosted most information about cloud service provider’s security plans for low and moderate FedRAMP authorizations in a single place for many years. The risks, complexity, and cost for managing a centralized repository is growing rapidly as FedRAMP scales past 400+ cloud services in the marketplace. This document-based sharing model must change so FedRAMP and cloud services can move increasingly towards relying on machine-readable information developed and shared via apis that facilitates automation.

Cloud service providers often provide trust centers or similar capabilities for commercial customers. These trust centers provide security information to potential and current customers, all controlled by the provider following standard commercial processes and procedures. These existing commercial practices should be reused to the greatest extent possible to ease the burden for both cloud service providers and agency customers.

This standard outlines the requirements that will underpin initial pilots for customer managed trust centers that include FedRAMP authorization data.

Explanation

The full draft standard is approximately 5 pages and is available for review in the following formats:

• Basic web formatting on fedramp.gov
• Basic text markdown on GitHub (below)
• PDF file: 0011-standard-for-storing-and-sharing.pdf
• Word file: 0011-standard-for-storing-and-sharing.docx

Discussion Requested

This draft standard is open for any public comment. FedRAMP encourages fast, informal comments from any member of the public. The public may submit multiple comments and may respond to other public comments. All comments from the public sent via email will be made public.

The FedRAMP Rev5 working group will continue to host discussions on potential best practices and implementation associated with this standard as well as related pilot activities.

---

RFC-0011 FedRAMP Pilot Standard for Storing and Sharing Authorization Data

Friday, May 23, 2025

---

Background

The FedRAMP Authorization Act (44 USC § 3609 (a) (8)) directs the Administrator of the General Services Administration to “provide a secure mechanism for storing and sharing necessary data, including FedRAMP authorization packages, to enable better reuse of such packages across agencies, including making available any information and data necessary for agencies…” This responsibility is delegated to the FedRAMP Director.

Oxford Languages defines a mechanism as “a natural or established process by which something takes place or is brought about.”

OMB Memorandum M-24-15 on Modernizing FedRAMP section 6 states that “In general, to encourage both security and agility, Federal agencies should use the same infrastructure relied on by the rest of CSPs’ commercial customer base.”

Introduction

The FedRAMP Pilot Standard for Storing and Sharing Authorization Data defines requirements for cloud service providers to store and share authorization data with federal agencies using their existing commercial processes and trust centers. This standard provides a secure mechanism to enable better reuse of authorization data across agencies and to make all necessary information and data available to agencies.

This standard will initially be implemented as an opt-in pilot open to cloud service providers, allowing FedRAMP, providers, and agencies to learn directly how to best implement and adopt an effective shared responsibility model for storing and sharing authorization data. Providers who establish trust centers that meet these requirements, as verified by FedRAMP, will be exempted from FedRAMP requirements to share materials via the FedRAMP Secure Repository on the USDA Connect Community Portal or existing secure repositories. Please note that explicit requirements during the pilot may vary slightly from the draft standard.

Cloud service providers MAY continue to rely on the FedRAMP secure repository they currently use for sharing information with agencies during the pilot and any following transition period. Providers SHOULD monitor the pilot as the existing FedRAMP Secure Repository and related mechanisms will likely be replaced with this model during FY26 (or earlier).

FedRAMP Trust Center Requirements

Cloud service providers SHOULD establish a trust center or similar centralized location to make security information and materials (“authorization data”) available to stakeholders.

1. The FedRAMP trust center MUST be highly visible on a provider’s core website and MUST clearly state that it includes FedRAMP related materials. The FedRAMP related section SHOULD be available via a direct link that can be included in the FedRAMP marketplace.

2. The FedRAMP trust center MUST publicly share the following information about the cloud service offering:

   1. Direct link to the FedRAMP Marketplace for the offering

   2. Description of the services offered within the FedRAMP authorization scope

   3. Information for requesting access to non-public FedRAMP materials

3. The FedRAMP trust center MUST store additional information about the cloud service offering. This information MAY be available to the public based on a risk assessment by the cloud service provider, and MUST be available to federal agencies upon request, including:

   1. Security Plans and Appendices

   2. Assessments and Authorizations, including supporting artifacts

   3. Continuous Monitoring reporting/documentation and supporting artifacts

   4. Plan Of Action And Milestones (POA&M)

   5. Significant Change Notifications (SCN)

   6. Incident Reports

   7. Listing of other FedRAMP authorized services being leveraged

   8. Any other authorization data required by FedRAMP

4. The FedRAMP trust center MUST provide a well-documented API or similar machine access to authorization data for federal agencies.

5. Providers MUST make authorization data available in both human-readable and machine-readable formats.

6. Providers migrating from the FedRAMP Secure Repository on the USDA Connect Community Portal MUST provide migration information for agencies in their secure folder.

7. Providers SHOULD follow FedRAMP’s best practices and technical assistance on storing and sharing authorization data where applicable.

Provider Access Responsibilities

Cloud service providers are entirely responsible for the intellectual property stored in their FedRAMP trust centers and MUST manage all access to the authorization data stored in their trust centers.

1. Providers MUST publicly provide plain-language policies and guidance for federal government customers to follow to obtain and manage access to authorization data stored by the cloud service provider.

2. Providers MUST grant FedRAMP full access to all authorization data. This MUST include reasonable API access and a secure mechanism to routinely manage API credentials.

3. Providers MUST grant agency authorizing officials (and/or their delegates) full access to all authorization data if they have active customer agreements or indirectly use the service. This MUST include reasonable API access and a secure mechanism to routinely manage API credentials.

4. Providers SHOULD NOT store federal information that is within the FedRAMP Minimum Assessment Scope within the trust center; providers MUST limit access to such information according to the owner of that federal information.

5. Providers SHOULD include standard mechanisms that allow customers to manage authorization data access for their users and services directly; these mechanisms SHOULD be the same that customers use to manage access to other aspects of the cloud service offering.

6. Providers SHOULD grant agency Authorizing Officials and/or their delegates without an active customer agreement temporary full access to all authorization data as appropriate if an agency is directly or indirectly considering use of the system.

7. Providers SHOULD follow FedRAMP best practices and technical assistance related to storing and sharing authorization data as appropriate.

Agency Request Responsibilities

Agencies SHOULD use native mechanisms provided by cloud service offerings to manage their own user and/or service access to authorization data.

If such mechanisms are unavailable, agencies SHOULD follow the request process identified in the FedRAMP Marketplace for a specific cloud service offering to request access to authorization data for review.

In all cases:

1. Agencies MUST limit access of employees and services to non-public authorization data to employees and services with an explicit need for access.

2. Agencies MUST limit distribution of non-public authorization data to that required for agency operations and delete data after it is no longer needed.

3. Agencies SHOULD follow FedRAMP best practices and technical assistance related to storing and sharing authorization data as appropriate.

[Christcpd]

As a security practitioner, I have never been a fan of airing my laundry publicly. And as the 20x standard emerges, it has much more sophisticated underlying data that I would not want shared publicly. Especially those KSIs that will include exceptions and notes.

Example (not exactly from the KSI obviously)
KSI: MFA Enabled
Finding: Partial
Notes: The following accounts do not have MFA enabled as it would interfere with the service accounts operation: bu_admin, bu_user, sql_user, etc.... These accounts have interactive login disabled as a mitigating control.

As a malicious actor, I now know which accounts to target and how to target them.

"2. The FedRAMP trust center MUST publicly share the following information about the cloud service offering:" Perhaps adding some language to clarify that "MUST publicly share" is permissible behind a user registration and approval process." 20x does not have the same type of information that an auditor's report has currently. It is more robust with finer grained detail than any audit report today.

This would also preclude fourth party vendor from ingesting all that data without permission. I can see a new market where an information broker gathers up as much "free" information from FedRAMP organizations, augments it with risks and other data, and provides a for sale product. Hmmmm.... maybe I just got my startup idea.... :)

[rpalmer-gsa]

@Christcpd
Thanks for raising this important security concern.

My reading is that the public requirements under Trust Center bullet 2 appear fairly narrow, covering general information about the service offering and how to request access to more sensitive materials.

The detailed technical findings you're concerned about (like specific MFA exceptions and related account details) seem to fall under Trust Center bullet 3, which states this information "MAY be available to the public based on a risk assessment by the cloud service provider, and MUST be available to federal agencies upon request."

This suggests cloud providers would make their own risk-based decisions about what potentially sensitive information to make public, if any. I'd imagine sensitive implementation details would typically be kept behind access controls, but I'm curious how others view this balance.

[Christcpd]

Ah, I see that logic now. Thanks for pointing it out.

[cb-axon]

The FedRAMP trust center MUST store additional information about the cloud service offering. This information MAY be available to the public based on a risk assessment by the cloud service provider, and MUST be available to federal agencies upon request, including:
i. Security Plans and Appendices
ii. Assessments and Authorizations, including supporting artifacts
iii. Continuous Monitoring reporting/documentation and supporting artifacts
iv. Plan Of Action And Milestones (POA&M)
v. Significant Change Notifications (SCN)
vi. Incident Reports
vii. Listing of other FedRAMP authorized services being leveraged
viii. Any other authorization data required by FedRAMP

Items like POA&Ms and incident reports contain sensitive vulnerability or operational data and do impact the confidentiality, integrity, or availability of federal systems. In line with minimum assessment scope and standard Boundary Requirements, this data likely should be held to the same security standards as the system itself. Trust centers often do not meet these standards in the case of FedRAMP moderate or High systems. As a CSP, we don't classify our trust centers as being permitted to store this kind of information, let alone actually share such information through it. Recommending this section be revised to:
-Avoid suggesting these may be made public without additional controls
-Require CSPs to indicate how agencies may securely request access
-Clarify storage must be within a system commensurate with the impact level of the authorized service, and within the provider’s minimum FedRAMP assessment scope

Suggested rewrite for item 3:

3. The FedRAMP trust center MUST identify how federal agencies can request access to the following authorization data. This information MUST be stored in an environment commensurate with the impact level of the authorized service, and within the provider’s FedRAMP Minimum Assessment Scope. The provider MAY make select materials public only after performing and documenting a risk assessment that is made available to agency authorizing officials. The following information MUST be made available to federal agencies upon request, including:
   i. Security Plans and Appendices
   ii. Assessments and Authorizations, including supporting artifacts
   iii. Continuous Monitoring reporting/documentation and supporting artifacts
   iv. Plan Of Action And Milestones (POA&M)
   v. Significant Change Notifications (SCN)
   vi. Incident Reports
   vii. Listing of other FedRAMP authorized services being leveraged
   viii. Any other authorization data required by FedRAMP

[wisecryptic]

I believe that the general direction is that authorization data is NOT at the same impact level as Customer data and therefore practices managing access and sharing information with stakeholders are much more important than a full FedRAMP implementation and review of authorization data.

I am a little hesitant to store POA&M data on trust centers, but these usually store other sensitive material such as pentests and vulnerability reports so I think the gap is smaller than it looks and I think the streamlined approach will be easier to monitor than making a carve-out specifically for that information.

[cb-axon]

I understand the intent, but authorization documentation frequently includes highly sensitive information—explicitly identifying vulnerabilities, control gaps, or intentionally unimplemented controls—that directly highlights weak areas valuable to an attacker. This is often at the specific request of agency customers. Given this, such data should clearly be treated with protections equal to customer data, in our opinion.

In practice, trust centers typically host summaries or public-facing materials, not detailed or actionable vulnerability data. Storing sensitive, explicit vulnerability details in a lower-security trust center isn't consistent with secure practice. Protecting this data must prioritize security over convenience.

[cb-axon]

5. Providers MUST make authorization data available in both human-readable and machine-readable formats.

The definition of “machine-readable” is increasingly subjective—modern tools can easily parse human-readable formats like Word and Excel. Recommend clarifying what’s expected (e.g., structured formats like JSON, XML, etc.) and adjusting this to a SHOULD, with a MUST only if an agency AO requires it.

Suggested rewrite for item 5:

5. Providers SHOULD make authorization data available in both human-readable and structured machine-readable formats (e.g., JSON, XML), where appropriate. Providers MUST do so if agency Authorizing Officials request machine-readable access for integration into their internal systems.

[wisecryptic]

I believe we haven't reached consolidation on machine readability at this time. Thus, subjective, ambiguous language in machine readability is a feature, not a bug. From my perspective, this allows early adopters much greater flexibility, while also allowing FedRAMP to promote machine readability on a faster timetable.

The two lesser options are either arbitrarily define machine readability which I think will cause a lot of whiplash throughout the ecosystem at this point and likely consolidate on a format that is not yet ideal, which will cause further second order effects of sloppy overpriced implementations,
OR
hold off on machine readable-type language for another 6-18 months. This does not seem to be the preference of FedRAMP.

I'm more concerned about API references as far as complexity and consolidation goes.

[cb-axon]

2. Providers MUST grant FedRAMP full access to all authorization data. This MUST include reasonable API access and a secure mechanism to routinely manage API credentials.

3. Providers MUST grant agency authorizing officials (and/or their delegates) full access to all authorization data if they have active customer agreements or indirectly use the service. This MUST include reasonable API access and a secure mechanism to routinely manage API credentials.

6. Providers SHOULD grant agency Authorizing Officials and/or their delegates without an active customer agreement temporary full access to all authorization data as appropriate if an agency is directly or indirectly considering use of the system.

This is just a minor wording comment - here "Full access" should be changed to "at least read access" - Full access allows users with such permissions to overwrite documents such as SSPs and such, which can (and has) happened erroneously, and causes confusion. Suggest requiring read access at minimum with this, so that agencies can access the data necessary, but not overwrite it.

[wisecryptic]

Thank you for putting this together. I’m sure the community is excited to see where this goes

The risks, complexity, and cost for managing a centralized repository is growing rapidly as FedRAMP scales past 400+ cloud services in the marketplace.

Having a responsibilities to both companies and customers to safeguard information, this has been a growing concern for me as well. By distributing information, the cost vs reward of large scale compromise should shift significantly against the favor of malicious actors.

The FedRAMP trust center MUST be highly visible on a provider’s core website and MUST clearly state that it includes FedRAMP related materials.

Soft question on the intended outcome of making the FedRAMP trust center ‘highly visible? Normally a core website is primarily managed by marketing with perhaps a link to a trust subdomain which leads to a providers portal. This portal is primarily accessed by current and investigating customers, whereas the marketing site will be aimed at a much wider audience. I can foresee potential conflicts of vision in implementation of this.

Providers SHOULD include standard mechanisms that allow customers to manage authorization data access for their users and services directly; these mechanisms SHOULD be the same that customers use to manage access to other aspects of the cloud service offering.

I'd like to understand the intent of this better. Generally a cloud service offering authorization and access mechanisms will and should be separate from a Trust center. I am not aware of Trust centers being implemented with full idp integrations per customer, and the overhead on that would be substantial.
My recommendation is to strike 5.

[austinsonger]

1. The draft implies a likely phaseout of the FedRAMP Secure Repository in FY26 but doesn’t define whether this pilot is a precursor to a mandatory shift.

   • Ask: Will this model become mandatory for Moderate/High systems? If so, when and what migration requirements will be imposed?
   • Recommendation: Add a timeline roadmap or migration decision triggers to help CSPs prepare.

2. Define Minimum API Functionality - The requirement for a “well-documented API or similar machine access” is vague.

   • Suggestion: Specify minimum API capabilities:
     • Metadata query and filtering
     • Document format/version retrieval
     • Authentication/authorization token model (e.g., OAuth2 or SAML)
     • Audit logging for access

3. Mandate Metadata for Machine-Readable Docs - Machine-readable formats without consistent metadata won’t scale for automated monitoring tools.

   • Recommendation: Require structured metadata (e.g., JSON or XML manifest) with:
     • Authorization status and impact level
     • Document version/date
     • Point of contact
     • Assessment type (Initial, Reauthorization, Annual)

4. Clarify Rules Around Temporarily Public Access (Pre-Acquisition Phase)

   • Ask: Should this be based on pre-decisional NDAs or some FedRAMP-defined intake process?
   • Suggestion: Provide criteria or minimum safeguards for granting this level of access (e.g., signed statement of intent, verified agency domain).

5. Require Alignment With OSCAL

   • For machine-readability and interoperability, OSCAL-based documents should be encouraged (or required) wherever possible.
   • Suggestion: Add language like: “Where possible, authorization data SHOULD be made available in OSCAL or other NIST-aligned formats.”

[vedigaurav]

Thank you for drafting this document.

Below are few suggestions that, if incorporated into this RFC, could enhance clarity and reduce ambiguity.

1. Lifecycle Management of Authorization Data
   Gap Identified: RFC-0011 does not specify how long data should be retained or when it should be archived or deleted.
   Recommendation:
   Add a section defining minimum retention periods for authorization data (e.g., 3 years post-authorization), criteria for data archiving, and mandatory deletion or sanitization processes once data is obsolete or the service is decommissioned. You can also introduce explicit lifecycle requirements for authorization data stored in FedRAMP trust centers. For example, data should be retained in a readily accessible (“hot”) state for a minimum of 12 months after generation or last use, followed by archival (“cold”) storage for an additional period (e.g., up to 3 years), after which deletion may be permitted unless otherwise required by law or agency agreements.
   This mirrors the hot/cold data retention approach in OMB Memorandum M-21-31, which mandates availability of key cybersecurity-related data (e.g., logs) in a hot state for 12 months and retention for 18 months. A similar model for FedRAMP Trust Centers could be adopted that would support incident response, authorization reviews, and audits, while allowing for cost-effective long-term storage.

2. Version Control and Change Tracking
   Gap Identified: The RFC lacks requirements around version tracking for documents like SSPs, POA&Ms, or Incident Reports.
   Recommendation: Require trust centers to maintain and expose document version history, with metadata including publication date, version number, and change description. This could be via metadata or changelogs accessible through the API.

3. Trust Center Availability and Reliability
   Gap Identified: The RFC does not define expected uptime, service reliability, or incident handling for trust centers.
   Recommendation: Add requirements or expectations for availability (e.g., 99.9% uptime), response time for access issues, and procedures for notifying agencies when the trust center is down or compromised.

4. Auditability and Access Logs
   Gap Identified: The RFC references API access but does not mention access audit logging, which is critical for monitoring and incident response.
   Recommendation: Require that trust centers log all access to sensitive authorization data (including API access), and that these logs be retained and made available to FedRAMP and agencies upon request.

5. User Experience and Accessibility
   Gap Identified: No guidance is provided on ensuring the trust center is usable, navigable, or accessible for individuals with disabilities.
   Recommendation: Recommend that trust centers follow Section 508 compliance for accessibility, and offer a standardized navigation model or UI pattern (e.g., search, filter by document type/status/date) to reduce confusion and improve agency use.

6. Data Classification & Labeling
   Gap Identified: There's no requirement to clearly label the sensitivity or classification of documents shared via the trust center.
   Recommendation: Require all uploaded documents to include clear classification labels (e.g., Public, For Official Use Only, Controlled Unclassified Information) and associate them with metadata for automated handling and access control.

[jspenc72]

A few comments and a recommended addition...

One thing that the FedRAMP marketplace and authorization process has excelled at is clear separation of responsibilities. For example, every agency knows that every cloud service provider (CSP) that offers a product listed on the marketplace underwent a FedRAMP Audit that was performed by an authorized "Assessor" with a listing on marketplace.fedramp.gov/assessors. I would like to see this pattern maintained with trust center providers (TSPs). Given the industry move toward automated data collection, status updates could change on a daily basis and an assessor has no way to constantly ensure updates are reflected on the Trust Center. With the current requirements there is no difference between an actual "Trust Center" and a marketing page created by the CSP for their product.

Recommended Addition:

1. List Trust Center Providers on their own separate tab from Product, Agencies and Assessors on the Fedramp Marketplace
   

2. Add specific wording that requires each Product on the FedRAMP marketplace use a 3rd party (20X or similarly authorized) trust center provider (TSP) to continuously update their Trust Center and that the trust center MUST not be maintained solely by the CSP themselves.

8. Cloud Service Providers MUST commission a FedRAMP authorized Trust Center Provider to maintain and update their FedRAMP Trust Center.

FedRAMP Trust Center Requirements

Cloud service providers SHOULD establish a trust center or similar centralized location to make security information and materials (“authorization data”) available to stakeholders.

1. The FedRAMP trust center MUST be highly visible on a provider’s core website and MUST clearly state that it includes FedRAMP related materials. The FedRAMP related section SHOULD be available via a direct link that can be included in the FedRAMP marketplace.

2. The FedRAMP trust center MUST publicly share the following information about the cloud service offering:

   1. Direct link to the FedRAMP Marketplace for the offering
   2. Description of the services offered within the FedRAMP authorization scope
   3. Information for requesting access to non-public FedRAMP materials

3. The FedRAMP trust center MUST store additional information about the cloud service offering. This information MAY be available to the public based on a risk assessment by the cloud service provider, and MUST be available to federal agencies upon request, including:

   1. Security Plans and Appendices
   2. Assessments and Authorizations, including supporting artifacts
   3. Continuous Monitoring reporting/documentation and supporting artifacts
   4. Plan Of Action And Milestones (POA&M)
   5. Significant Change Notifications (SCN)
   6. Incident Reports
   7. Listing of other FedRAMP authorized services being leveraged
   8. Any other authorization data required by FedRAMP

4. The FedRAMP trust center MUST provide a well-documented API or similar machine access to authorization data for federal agencies.

5. Providers MUST make authorization data available in both human-readable and machine-readable formats.

6. Providers migrating from the FedRAMP Secure Repository on the USDA Connect Community Portal MUST provide migration information for agencies in their secure folder.

7. Providers SHOULD follow FedRAMP’s best practices and technical assistance on storing and sharing authorization data where applicable.

[cb-axon]

8. Cloud Service Providers MUST commission a FedRAMP authorized Trust Center Provider to maintain and update their FedRAMP Trust Center.

This isn't something that should be REQUIRED. If anything, it should identify that if the trust center hosts all KSIs and information that it must meet be approved at the appropriate FedRAMP level, but if a CSP whose business is not specifically to host a "trust center" wants to create one themselves, they should 100% be allowed to do that. This also boxes out other "on-prem" trust center providers that CSPs may want to utilize to ensure the data stays within their boundary, but is still available for Agency's to access.

[jspenc72]

Thanks for sharing your comments @cb-axon I appreciate the points you made and hearing the other side of this discussion.

Just a few thoughts to reiterate and reinforce my position. Having been involved in multiple FedRAMP ATOs I can say in my humble opinion, CSPs self maintaining and reporting their own FedRAMP compliant "trust center", is a VERY bad idea. Should FedRAMP also allow CSPs to become the assessors for their own products? (absolutely not) Should the employee who does the accounting for a CSP also do their irs audit? (absolutely not) Separation of responsibilities is a MUST in this world...

A Trust Center Provider (TCP) has two responsibilites:

1. Continuously Audit: Through integration with the CSP offering via automation, software agent, manual review, etc and continuously check the status of all controls within the FedRAMP framework and record any findings or changes.
2. Continuously Report: these findings internally to the CSP for remediation, to the FedRAMP Assessor for review/assessment and externally on the Trust Center website in a way that both informs the Agencies of control deficiencies via POAM while avoiding disclosure that could be used by a bad actor.

A Trust Center will be linked to the Product listing on the FedRAMP marketplace, so it becomes the canonical source of information related to their FedRAMP offering for Agencies who are evaluating the security of their Product(s). Given the move to continuous monitoring and compliance reporting of control status checks, POAM, etc it is of paramount importance that Agencies who are evaluating a Product be able to rely on trust center information to make their decisions.

This isn't something that should be REQUIRED. If anything, it should identify that if the trust center hosts all KSIs and information that it must meet be approved at the appropriate FedRAMP level, but if a CSP whose business is not specifically to host a "trust center" wants to create one themselves, they should 100% be allowed to do that. This also boxes out other "on-prem" trust center providers that CSPs may want to utilize to ensure the data stays within their boundary, but is still available for Agency's to access.

I have nothing against a CSP also becoming a Trust Center Provider for other products just don't tell them they can do it solely on their own, for their own products.
Also, "on-prem" trust centers and keeping information in the boundary is a non issue given requirement number 1, that the trust center itself must be "publicly accessible on the CSP website".

1. The FedRAMP trust center MUST be highly visible on a provider’s core website and MUST clearly state that it includes FedRAMP related materials. The FedRAMP related section SHOULD be available via a direct link that can be included in the FedRAMP marketplace.

If we are to differentiate a trust center from just another product promo piece or blog article about how good a CSPs product is... we need a separation of responsibility.

[pete-gov]

The following public comment was received via email:

Comment #	Section	Quote	Comment	Recommendation
1	Provider Access Responsibilities	N/A	The section does not cover the "chain of custody" for authorization packages when provided from the 3PAO. The purpose that USDA Connect provided was independence from the CSP and the 3PAO to avoid any package manipulation or obfuscation of findings identified during the assessment. The 3PAO could submit a locked copy that prevented any changes.	The PMO should consider setting expectations for the "chain of custody" of an authorization package.
2	Provider Access Responsibilities	Providers MUST grant agency authorizing officials (and/or their delegates) full access to all authorization data	There is no access requirement for 3PAOs.	The PMO should consider requiring that 3PAOs that have contracted with a CSP must be granted access to the trust center to confirm continuous monitoring activities are occurring and that authorization packages have not been modified.
3	FedRAMP Trust Center Requirements	N/A	This standard doesn't cover the consequences of non-compliance with the requirements for a trust center.	The PMO should consider clarifying consequences for not meeting the new trust center model, up to removal from the FedRAMP marketplace.
4	FedRAMP Trust Center Requirements	The FedRAMP trust center MUST store additional information about the cloud service offering. This information MAY be available to the public based on a risk assessment by the cloud service provider, and MUST be available to federal agencies upon request	This section notes that additional information about the CSO (including the SSP, POA&M, incident reports, etc.) may be available to the public based on a risk assessment by the cloud service provider. It's not clear what this risk assessment would be based on (i.e., risk appetite of the sponsoring / partnering agency, impact level of the CSO, etc.).	The PMO should consider clarifying the expectations for a risk assessment by the CSP to release additional information about the CSO to the public.
5	FedRAMP Trust Center Requirements	Providers MUST make authorization data available in both human-readable and machine-readable formats.	It's not clear if this infers that 3PAOs will be required to deliver both human-readable and machine-readable packages.	The PMO should consider clarifying whether 3PAOs are required to deliver both human-readable and machine-readable packages.
6	Provider Access Responsibilities	Providers SHOULD NOT store federal information that is within the FedRAMP Minimum Assessment Scope within the trust center; providers MUST limit access to such information according to the owner of that federal information.	It's not clear where federal information included within the FedRAMP Minimum Assessment Scope should be stored if not permissible in a CSP's trust center. FRR-MAS-01 states that "Providers MUST identify a set of information resources to assess for FedRAMP authorization that includes all information resources that are likely to handle federal information or likely to impact the confidentiality, integrity, or availability of federal information handled by the cloud service offering." Based on that definition, it reads as though it would be inappropriate to host anything in the trust center that is likely to impact the confidentiality, integrity, or availability of federal information. FedRAMP required documentation often include details about a CSPs security stack (SSP) as well as details on exploitable vulnerabilities (SAR / RET, POA&M).	The PMO should consider clarifying where documentation that contains information that is likely to impact the confidentiality, integrity, or availability should be stored if not permissible within the trust center.
7	Provider Access Responsibilities	N/A	The standard does not appear to cover the scenario in which an agency revokes their ATO for a particular CSO. If this is handled via coordination with the FedRAMP PMO, would CSPs be notified so that they could deprovision individuals from that agency from the trust center?	The PMO should consider clarifying FedRAMP PMO responsibilities when it comes to communicating when a federal agency revokes their ATO for a particular CSO.

[pete-gov]

The following public comment was received via email:

Thanks for the opportunity to review and provide initial feedback on RFC-0011. Rubrik appreciates the PMO's continued engagement with industry and looks forward to the continued partnership. Have a great weekend!

• The term "reasonable API access" is broad and lacks specific technical definition within the RFC. This ambiguity may present a challenge, as varying interpretations by CSPs could lead to inconsistent API implementations across the FedRAMP ecosystem, potentially hindering the goal of seamless data reuse by agencies. Minimally acceptable implementation requirements will be crucial for both CSPs, who need clear targets for development, and for FedRAMP and agencies, who need predictable ways to consume data.
• Requesting clarity on whether existing FedRAMP baselines (e.g., Moderate, High) will apply directly to these trust centers, or if a tailored set of controls will be defined.
• Requesting clarity on how FedRAMP intends to verify these CSP-managed trust centers, as mentioned by the phrase "as verified by FedRAMP". Understanding the assessment scope, methodology, the potential role of 3PAOs, and the expected level of effort would help industry prepare.

[pete-gov]

The following public comments were submitted via our google form:

Timestamp	Agency/Organization	Primary Stakeholder Community	Public Comment
5/25/2025 20:22:43	Public	Private Sector - Other	None.
5/30/2025 16:51:00	Salesforce	Cloud Service Provider (CSP)	Section: Introduction Text: ""The FedRAMP Pilot Standard for Storing and Sharing Authorization Data defines..."" Comment: The term ""authorization data"" is referenced throughout this document, but there is no definition. Is this just considered what is in the FedRAMP ""package"" (or future concept of a ""package"" as we move to a more continuous model?) If so, proposing that FedRAMP provides this definition with parameters on what it includes."
5/30/2025 16:51:13	Salesforce	Cloud Service Provider (CSP)	"Section: Introduction Text: ""Providers SHOULD monitor the pilot as the existing FedRAMP Secure Repository and related mechanisms will likely be replaced with this model during FY26 (or earlier)."" Comment: No comment for the standard per se, but eagerly anticipating a more defined timeline for CSP migration here beyond just ""FY26""."
5/30/2025 16:51:30	Salesforce	Cloud Service Provider (CSP)	"Section: Provider Access Responsiblities Text: ""Providers MUST publicly provide plain-language policies and guidance for federal government customers to follow to obtain and manage access to authorization data stored by the cloud service provider."" Comment: Does this mean that the the FedRAMP Package Request process will go away? That is not exactly clear after reading this - when an agency needs access will they still will out the package request form and provide to FedRAMP? Proposing confirmation on this."
5/30/2025 16:51:52	Salesforce	Cloud Service Provider (CSP)	"Section: Provider Access Responsiblities Text: ""Providers MUST grant agency authorizing officials (and/or their delegates) full access..."" Comment: Does ""full access"" also include raw scans? In the past, only JAB officials received our fraw scans. We'd like confirmation on what ""full access"" means and what delegates may mean to ensure only relevant parties get access to raw scans."
5/30/2025 16:52:07	Salesforce	Cloud Service Provider (CSP)	"Section: Provider Access Responsiblities Text: ""Providers SHOULD grant agency Authorizing Officials and/or their delegates without an active customer agreement temporary full access..."" Comment: Proposing that for any technical assistance documents supporting this, would like to see the definition of ""temporary"" here, such as five business days."
6/10/2025 8:50:44	Amazon Web Services (AWS)	Cloud Service Provider (CSP)	1. Clarification of Assessment and Authorization Artifacts: The reference to "Assessments and Authorizations, including supporting artifacts" should be explicitly limited to FedRAMP standard artifacts limited to: SSP, POA&M, SAP, SRTM, SAR, and RET. Assessment evidence should be explicitly excluded from this requirement, as it should continue to be only shared directly with 3PAOs through secured mechanisms. 2. Continuous Monitoring Documentation Scope: Regarding the requirement for FedRAMP trust centers to store additional information about the cloud service offering, the "Continuous Monitoring reporting/documentation and supporting artifacts" that must be available to federal agencies upon request should be specifically limited to the current one-page ConMon report. This clarification ensures consistency with existing practices while preventing potential over-sharing of sensitive operational data. 3. Incident Report Classification: "Incident Reports" should be revised to "Confirmed Security Incident Notifications" for clarity and precision. 4. Authorization Data Requirements: Regarding the FedRAMP trust center requirements and provider access responsibilities, the following clarifications are needed: * In the list of information that must be stored in the FedRAMP trust center, the phrase "any other authorization data required by FedRAMP" is overly broad and should be revised to "mutually agreed authorization data" * The requirement for providers to make authorization data available in both human-readable and machine-readable formats needs specific examples of acceptable machine-readable formats * In the context of granting access to FedRAMP and agency authorizing officials, the reference to "all authorization data" should be explicitly limited to POA&M, SCN, SAP, SSP package, SRTM, RET, and SAR These clarifications will help ensure consistent implementation and understanding of the authorization data storage and sharing requirements across cloud service providers. 5. Access and Terminology Clarifications: * The document should explicitly state whether trust center access is limited to federal agencies only * The term "providers" should be clearly defined as Cloud Service Providers (CSPs) * "Agencies" should be explicitly defined as federal agencies, if that is the intent * The reference to "existing secure repositories" should be clarified as "other existing secure repositories" * "Security Plans and Appendices" should be revised to "Applicable System Security Plans and Related Appendices" for greater precision
6/10/2025 13:11:26	Solventum	Cloud Service Provider (CSP)	I appreciate that this new policy creates flexibility for FedRAMP and CSPs to host and share a CSP's FedRAMP documentation in a way that will likely be easier and faster. However, in my experience, CSPs with High Impact ATOs that were responsible for maintaining their own repositories did not always include or provide all necessary FedRAMP documentation. While the agency contract would be one way to ensure that a CSP is meeting all requirements, many contracts are written before any amount of FedRAMP requirements are understood. I think it would be helpful to have some mechanism called out in this policy that allows an agency stakeholder to escalate any issues with the FedRAMP package that is being shared or provided by the CSP to a resource within the FedRAMP PMO. I expect that the FedRAMP PMO would like to ensure some amount of consistency and accountability for the quality and completeness of the documentation provided by CSPs and will not leave it up to agency stakeholders to ensure consistency and accountability. How will the FedRAMP PMO do this? Including a general description in the policy would be helpful.
6/10/2025 17:33:12	Palantir	Cloud Service Provider (CSP)	1. "Cloud service providers SHOULD establish a trust center or similar centralized location to make security information and materials (“authorization data”) available to stakeholders." i would think this would be MUST not SHOULD, this isn’t optional is my understanding. 2. "The FedRAMP trust center MUST be highly visible on a provider’s core website and MUST clearly state that it includes FedRAMP related materials. The FedRAMP related section SHOULD be available via a direct link that can be included in the FedRAMP marketplace." I think having the direct link in the marketplace would be more than enough. i would flip this, there MUST be a direct link from the FedRAMP marketplace and then it SHOULD be on the website. Having one central place for all customers / agencies to go (the marketplace) is the simplest for end agencies to understand vs searching the web. 3. "This information MAY be available to the public based on a risk assessment by the cloud service provide" I feel that most of these documents should never be public facing, that seems like it would break FedRAMP rules. Things like POA&M, SSP, SARs etc shouldn’t be public as that would give away to much information about a CSO. 4. "The FedRAMP trust center MUST provide a well-documented API or similar machine access to authorization data for federal agencies." I would feel like if you are going to require API access there would need to be a well defined standard that should be meet. leaving this open ended is going to present a lot of issues. each partner having their own API process is never going to scale and would be a nightmare to manage. 5. "Providers MUST make authorization data available in both human-readable and machine-readable formats." We would need to define the machine-readable formats. 6. "Providers SHOULD include standard mechanisms that allow customers to manage authorization data access for their users and services directly; these mechanisms SHOULD be the same that customers use to manage access to other aspects of the cloud service offering." This is going to be very hard, as most agencies wont’ approve their IdP connecting to other system they haven’t themselves ATOed. They tend to only allow their IdP to access their specific tenant. 7. "Agency Request Responsibilities" There should be something added about how agencies are responsible for account management for their employees. General comment, while the other RFC have seemed very well thought out and have minor tweaking here and there to make them better this RFC seems to have missed the mark by my view coming from someone that works with this process for the past 2 years running a high repository. This doesn’t seem like something that would be operationalized well in the current form. Maybe starting small and then expanding would lead to greater success. The API stuff is nice to have but isn’t a critical day 1 operation. the API items introduce a ton of complexity. Like if someone is using o365, box, google docs, etc would this all be supported to this standard? i would suggest dropping the API stuff at the start. I would also suggest dropping machine readable formats for the initial start and adding that in later. Most agencies just want a PDF/Word/Excel copy of the document they want to review then can download.
6/13/2025 18:01:22	Gitlab, Inc.	Cloud Service Provider (CSP)	Moving away from huge Word document templates towards Markdown files (or similar) controlled through Git would be a huge improvement in collaboration, speed, and change control. Keeping our SSP up-to-date is a huge pain, given our Appendix A alone is 814 pages. Only one team member can work on it at a time, committing it to our Git repo is slow, and its easy to miss something in review. Breaking it out into markdown would alleviate all of that, and allow us to bake in policy validations into CICD, similar to how this linkedin post describes it - https://www.linkedin.com/posts/ayoubfandi_grcengineering-gitlab-policyascode-activity-7338929175774343168-QqYV
6/22/2025 13:27:07	CSP-AB	Cloud Service Provider (CSP)	Text: Cloud service providers SHOULD establish a trust center or similar centralized location to make security information and materials (“authorization data”) available to stakeholders. Comment: In the context of granting access to FedRAMP and agency authorizing officials, the reference to "all authorization data" should be explicitly limited to POA&M, SCN, SAP, SSP package, SRTM, RET, and SAR. This distinction should be defined and referenced throughout the document. Text: Assessments and Authorizations, including supporting artifacts; Continuous Monitoring reporting/documentation and supporting artifacts Comment: The scope of documents should be defined to ensure that agencies and CSPs know exactly what is required. With open ended requirements scope creep can lead to non-uniform requests. Text: FedRAMP’s best practices and technical assistance Comment: This should be explicitly defined with references to ensure consistency. Text: Providers MUST publicly provide plain-language policies and guidance for federal government customers to follow to obtain and manage access to authorization data stored by the cloud service provider. Comment: Confirmation required: Does this mean that the existing FedRAMP Package Request form/process will go away? Currently, CSPs that own and maintain their own repos heavily leverage this process to establish new access for agency customers. Text: Providers MUST grant agency authorizing officials (and/or their delegates) Comment: What level of access is expected to be granted for Non-AO individuals? What does "Full Access" mean in this context? Assuming that mean every single piece of our FedRAMP Package? Our main concern is that this includes RAW scans and non-AO individuals will be expecting raw scans. This will be a tough sell
6/22/2025 20:11:09	Elastic	Cloud Service Provider (CSP)	FedRAMP Trust Center Requirements Section 3 mandates Trust Center is posing a major shift for data storage: Why would you give the public access to the documents that explain how you implement controls for the entire system and all of its live vulnerabilities? Does this contradict Provider Access Responsibilities Section 4?