FedRAMP certification data sharing rules for 2027

TL;DR

• FedRAMP's 2026 consolidated rules, currently in public preview at preview.fedramp.gov/2026, introduce a Certification Data Sharing (CDS) framework that lets cloud service providers share their authorization package via a trust center instead of the USDA Connect Community Portal.
• Four trust center MUST requirements apply: CDS-TRC-USH (on-demand just-in-time access), CDS-TRC-PAC (programmatic access to all certification data), CDS-TRC-AAI (federal user and system inventory available to FedRAMP on request), and CDS-TRC-ACL (access log retention for at least six months).
• Provider-side MUSTs include CDS-CSO-HAD (three years of version history), CDS-CSO-PUB (public JSON metadata page), CDS-CSF-TCM (USDA Connect migration notification), and CDS-UTC-AAD (five-business-day denial notice to FedRAMP).
• Rev5 providers can adopt voluntarily from July 4, 2026 and must comply by January 1, 2027; the grace period ends February 1, 2028. 20x providers are required from July 4, 2026.
• A trust center is an alternative to USDA Connect, not a mandate. The rules are in public preview and have not yet been finalized.

FedRAMP's 2026 consolidated rules, published in public preview, introduce a formal Certification Data Sharing (CDS) framework. The goal is to give cloud service providers a structured alternative to the USDA Connect Community Portal for sharing their FedRAMP authorization packages with federal agencies.

Before CDS, the standard path was straightforward: agencies accessed provider packages through USDA Connect, a shared portal managed by the USDA. The new rules let providers run a FedRAMP-compatible trust center instead, provided that trust center meets specific requirements for access, logging, and metadata.

The framework organizes requirements by audience. CDS-TRC-* requirements apply to trust centers. CDS-CSO-* and CDS-CSF-* requirements apply to the cloud service provider (the cloud service offering, or CSO). CDS-UTC-* requirements govern provider-to-FedRAMP notifications.

These rules are currently in public preview at preview.fedramp.gov/2026 and have not yet been finalized. FedRAMP's scope guidance, which defines what falls inside and outside federal authorization requirements, is published at fedramp.gov/docs/authority/scope/.

No, a trust center is not a blanket requirement. The CDS framework gives providers a choice: continue using USDA Connect, or adopt a trust center that satisfies the CDS requirements. Providers who stay on USDA Connect are not required to build or license a trust center.

That said, the direction of travel is clear. The CDS-CSF-TCM requirement specifically governs migration away from USDA Connect, which reflects an expectation that adoption will grow over time. For providers already thinking about trust centers for commercial buyers, meeting CDS requirements in parallel is the logical path. Our companion guide covers what makes a trust center FedRAMP-compatible and how to choose one.

One important nuance: per FedRAMP's scope guidance, a federal agency accessing a commercial trust center to evaluate a vendor's security posture is outside FedRAMP scope. The trust center platform itself does not need a FedRAMP authorization for that use case. If you encounter a vendor claiming their trust center is "FedRAMP authorized," ask specifically what authorization that refers to.

There are four trust center MUSTs. CDS-TRC-USH requires on-demand access for all necessary parties without manual approval delays. CDS-TRC-PAC requires documented programmatic access to all certification data. CDS-TRC-AAI requires a user and system access inventory available to FedRAMP on request. CDS-TRC-ACL requires access logs retained for at least six months.

Each applies to any trust center used to share FedRAMP certification data, regardless of whether the provider is on Rev5 or 20x. What each requirement means in practice:

CDS-TRC-USH: The trust center must share certification data with all necessary parties without interruption, via on-demand just-in-time provisioning. Manual approval queues that delay a federal agency's access to an authorized package do not satisfy this requirement. The intent is clear: an agency with a legitimate need gets access without waiting for a human to approve the request.

CDS-TRC-PAC: The trust center must provide documented programmatic access to all certification data, including human-readable materials. Access through a browser-based portal alone does not satisfy this requirement. The data must also be reachable via an API or equivalent mechanism.

CDS-TRC-AAI: The trust center must maintain an inventory of every federal agency user and system that has accessed certification data, along with the history of those accesses. FedRAMP can request this inventory at any time. Providers cannot satisfy this requirement by relying on system-level access logs that are never aggregated into a user-facing inventory.

CDS-TRC-ACL: The trust center must log access events and retain summaries for at least six months.

These four requirements are mandatory. Two additional requirements, CDS-TRC-HMR and CDS-TRC-SSM, are framed as SHOULD in the current draft, meaning recommended but not required at this stage.

The following requirements fall on the cloud service provider, not on the trust center platform itself.

CDS-CSO-HAD: Providers must keep historical versions of their certification data available for three years. Federal agencies conducting multi-year vendor assessments need access to prior package versions to track how a provider's security posture has changed over time.

CDS-CSO-PUB: Providers must publicly share service metadata in both human-readable and machine-readable JSON formats. The required fields are: FedRAMP Marketplace link, service model, deployment model, UEI (Unique Entity Identifier), contacts, trust center landing page link, next assessment date, and current assessor. This is a public metadata page, not a gated document, and it must be kept current as assessors and dates change.

CDS-CSF-TCM: When a provider migrates from USDA Connect to a trust center, they must notify all parties who currently access their package via USDA Connect, and leave migration instructions in the existing USDA Connect folders. Agencies and reviewers who relied on those folders need to know where the package moved and how to request access. Switching without forwarding instructions fails this requirement.

CDS-UTC-AAD: If a provider denies an agency's access request to their certification data, they must notify FedRAMP within five business days of that denial.

Rev5 providers must comply with all CDS requirements by January 1, 2027, with a grace period ending February 1, 2028. 20x providers are required to comply from July 4, 2026, with the grace period ending at their first annual assessment after January 1, 2027.

The full Rev5 timeline breaks down as follows:

• July 4, 2026: Optional adoption opens. Rev5 providers may begin using a trust center for CDS from this date.
• January 1, 2027: Requirements must be met. Rev5 providers using a trust center must satisfy all applicable CDS-TRC-* and CDS-CSO-* requirements.
• August 1, 2027: Ongoing compliance expected from this date.
• February 1, 2028: Grace period ends. Providers out of compliance after this date no longer have grace-period cover.

For 20x providers:

• July 4, 2026: Required from this date. 20x providers must comply with CDS requirements immediately.
• January 1, 2027: Maintain from this date.
• First annual assessment after January 1, 2027: Grace period ends.

The gap between "requirements must be met" and "grace period ends" is not an extended runway. It reflects the time FedRAMP expects providers to need to catch up operationally. GRC teams should treat January 1, 2027 as the hard target for Rev5 and July 4, 2026 for 20x, not the grace period dates.

CDS-CSF-TCM governs the migration act itself rather than ongoing trust center operations. It activates the moment a provider stops using USDA Connect as their primary sharing channel and has two distinct steps.

First, notify all necessary parties before the switch. Anyone who currently accesses your authorization package through USDA Connect needs advance notice that the package is moving. FedRAMP does not specify a notice window, but the intent of the requirement is that agencies have enough lead time to update their internal processes before the old access path stops working.

Second, leave migration instructions in the USDA Connect folders. When you move your package to a trust center, place a document in the existing USDA Connect folders that tells agencies where the package now lives and how to request access. A dead link with no forwarding note fails this requirement.

Think of CDS-CSF-TCM as a 301 redirect with a human instruction attached. The goal is continuity of access, not a clean break that creates a gap for agencies who depend on your package for procurement or authorization decisions.

CDS-CSO-PUB is worth treating on its own because it differs in kind from the access and logging requirements. It is a public page with a specific set of machine-readable fields, and it applies to any provider using a trust center for CDS.

The JSON output must include: FedRAMP Marketplace link, service model, deployment model, UEI, primary contacts, the trust center landing page URL, next assessment date, and the name of the current assessor.

For most providers, the content is not the hard part. The hard part is building or configuring a page that outputs valid JSON, keeping it current as assessor or date information changes between assessment cycles, and making it discoverable by automated procurement tools. FedRAMP's intent is that federal systems can pull this metadata without human intervention, which means a manually updated PDF does not satisfy the requirement.

Two trust center requirements appear as SHOULD rather than MUST in the current public preview draft. They are recommended, not mandatory. In regulatory contexts, SHOULD typically signals that these may become MUSTs in future revisions, or that a provider's compliance posture looks more credible when they are met.

CDS-TRC-HMR: The trust center should provide certification data in both human-readable and machine-readable formats. This is distinct from CDS-TRC-PAC, which governs programmatic access to data. HMR is about the format of the data itself: a human reviewer reads a rendered document, while an automated system parses structured data from the same source.

CDS-TRC-SSM: The trust center should provide self-service access provisioning and management features. This pairs directly with CDS-TRC-USH. A trust center that requires a manual admin to grant every access request will struggle to reliably satisfy CDS-TRC-USH's on-demand just-in-time requirement while also claiming to meet the intent of CDS-TRC-SSM.

For GRC teams evaluating trust center platforms, the practical question is whether self-service provisioning is a core architectural feature or an add-on. Platforms built primarily for commercial buyers often default to admin-approved workflows, with self-service available only as a premium tier or a late-added option. That choice shows up in how reliably the platform satisfies both USH and SSM in a federal-facing context. Wolfia was built with self-service provisioning as a baseline capability, which is relevant to both SHOULD requirements and the mandatory CDS-TRC-USH.

Wolfia's trust center is built for security and GRC teams managing access control and documentation at scale, and its feature set maps directly to the CDS-TRC requirements.

Self-service provisioning (CDS-TRC-USH, CDS-TRC-SSM): Wolfia supports on-demand access requests with click-through NDA gating and self-service provisioning workflows. Agencies or reviewers request access and receive it without waiting for a manual admin to approve the request, which satisfies the just-in-time access requirement in CDS-TRC-USH and the spirit of the SHOULD requirement in CDS-TRC-SSM.

Access inventory and logging (CDS-TRC-AAI, CDS-TRC-ACL): Wolfia's CRM integration gives providers full visibility into who accessed which documents, when, and for how long. That visibility is what CDS-TRC-AAI requires: an inventory of federal agency users and systems with access history, available to FedRAMP on request. Access log data is retained and reviewable, addressing CDS-TRC-ACL.

Document versioning (CDS-CSO-HAD): Wolfia's document hosting includes version control so that prior versions of your authorization package remain accessible alongside the current one. For providers who need three years of version history under CDS-CSO-HAD, this is a built-in capability rather than a custom build.

Questionnaire intake: When agencies submit questionnaires or RFPs alongside a trust center review, Wolfia's questionnaire upload intake routes them through the same self-maintaining knowledge base, with source citations on every answer. This keeps the response workflow connected to the same document library powering the trust center rather than splitting it across two systems.

Pricing is all-inclusive: access logging, CRM integration, NDA gating, and self-service provisioning are not premium tiers or credit-gated features.

For more on how trust center platforms compare across the features that matter for federal-market vendors, the guide to trust center software for SaaS security teams covers the full competitive landscape. The trust center implementation guide walks through setup in detail for teams starting from scratch. For vendors managing federal compliance across multiple frameworks, the same access control and logging capabilities apply directly to CMMC 2.0 questionnaire workflows as well.

Generic GRC trust centers built primarily for commercial buyers, including Vanta, Drata/SafeBase, and Conveyor, do not advertise FedRAMP CDS alignment. That does not mean they cannot meet the requirements, but GRC teams will need to audit each requirement ID against the platform's feature set rather than assuming compliance. Custom self-hosted trust pages will face the most friction with CDS-TRC-PAC (programmatic access), CDS-TRC-ACL (log retention), and CDS-CSO-HAD (three-year version history), since those capabilities require dedicated infrastructure rather than a static web page.

The CDS framework in FedRAMP's 2026 consolidated rules is a structural change in how authorization packages move between providers and federal agencies. The requirement IDs are specific, the deadlines are firm, and the MUST versus SHOULD distinction is meaningful: the four trust center MUSTs are baseline compliance requirements, not aspirational features to address later.

GRC teams at cloud service providers should map each requirement ID against their current trust center platform's capabilities now, before the July 4, 2026 date for 20x providers and the January 1, 2027 date for Rev5. The migration requirement (CDS-CSF-TCM) and the public JSON metadata page (CDS-CSO-PUB) both involve external communication and public-facing infrastructure that take more lead time than internal configuration changes.

The rules are in public preview and may change before the compliance dates activate. Track updates at preview.fedramp.gov/2026 and build your compliance roadmap against the current draft now rather than waiting for finalization. The deadline calendar does not adjust when the final text publishes.