Updated July 2026 to reflect the FedRAMP Consolidated Rules for 2026, released June 25, 2026.

What it is

Certification Data Sharing (CDS), formerly Authorization Data Sharing (ADS) in the pilot era, replaces static certification packages delivered by email or portal download with live, programmatically accessible data served through a trust center. Agencies access your posture directly, in both human-readable and machine-readable formats.

FedRAMP wants to kill the PDF package. CDS is how.

Under the legacy model, authorization packages (SSP, SAP, SAR, POA&M) were stored in USDA Connect and shared manually with agencies. An agency would request access, someone would grant it, and the agency would download a snapshot that was already stale by the time they opened it. When the package was updated, agencies had to re-download. Multiple agencies consuming the same package received it independently, asked questions independently, and got answers independently.

CDS replaces this with a trust center model. Providers serve FedRAMP Certification Data continuously through a portal with both human-readable and machine-readable formats, programmatic API access, and access logging. Agencies consume the data directly. No email distribution. No stale snapshots. No per-agency package assembly.

Status: CDS is a final rule family in the FedRAMP Consolidated Rules for 2026, released June 25, 2026 and effective July 4, 2026. It applies to both 20x and Rev5 at Classes B, C, and D, with a few per-class variants reaching Class A. There is no beta and no prerequisite standard. 20x providers obtain the rules from July 4, 2026; Rev5 providers by January 1, 2027, maintaining by August 1, 2027. The central FedRAMP repository is going away entirely: providers migrate to FedRAMP-compatible trust centers by August 2027.

What it requires

CDS has three sets of requirements: what every provider must share (CDS-CSO), how a FedRAMP-compatible trust center must operate (CDS-TRC), and what applies once you use a trust center instead of USDA Connect (CDS-UTC), plus a Rev5-only migration rule. If you tracked the pilot: the provider and trust center requirements carried over into the CDS family with the same three-letter keys (PUB, SVC, CBF, HAD, RIS on the provider side; USH, PAC, AAI, ACL for trust centers), and the pilot’s 20x-only trust center mandate is now CDS-CSO-UTC for everyone.

Provider requirements (CDS-CSO)

CDS-CSO-UTC: Use a FedRAMP-compatible trust center. MUST. This is the headline change from the pilot, where the trust center was mandatory for 20x and merely encouraged for Rev5. Now it is a hard MUST for all providers of both types. USDA Connect is a transition mechanism, not a destination.

CDS-CSO-PUB: Publicly share up-to-date offering information in both human-readable and JSON formats: FedRAMP ID, service model, deployment model, business category, UEI, sales and security contacts, product website and logo links, service description, the detailed service list with security categories, a link to Secure Configuration Guidance, an overview of supplied documentation, a link to the trust center landing page with access instructions, the next OCR (Ongoing Certification Report) date, and the current FedRAMP Recognized independent assessment service. This is public-facing, not behind authentication. Agencies and prospective customers should be able to evaluate the offering without requesting access to anything.

CDS-CSO-SVC: Public detailed service list with security categories, using names that match your standard marketing materials. The list MUST be complete enough for a potential customer to determine which services are and are not in the Minimum Assessment Scope without requesting access to underlying certification data. This is more detailed than a marketing page.

CDS-CSO-FID: Always include the FedRAMP ID in all certification data once assigned: every report, notification, and communication that results from FedRAMP rules. Internal product names do not align with public materials; the FedRAMP ID does.

CDS-CSO-FRC: Publish FedRAMP Certification Reports with your certification data, without inappropriate modifications, within 2 weeks of receiving them from FedRAMP.

CDS-CSO-AVR: Availability reporting. A web service showing current and historical availability of core services over at least the past 30 days, including availability incidents, in both human-readable and machine-readable formats. It MUST stay available even when the primary offering is down (MUST for Classes B, C, and D; SHOULD for Class A). Your status page is now a FedRAMP obligation.

CDS-CSO-CBF: Consistency between formats. Providers MUST use automation to keep information consistent between human-readable and machine-readable formats. No manual synchronization between the document and the API. One source, two renderings. Manual format synchronization inevitably drifts; CDS requires automation that prevents drift by design.

CDS-CSO-IRP: Include relevant policies and procedures in the certification data, with a human-readable and machine-readable reference for each: name, file, brief summary, word count, current version, date of last update, and related FedRAMP Practices.

CDS-CSO-HAD: Historical certification data. Providers MUST supply snapshots of certification data aligned to each Ongoing Certification Report, available for the duration of the certification. Not just the current state. Agencies use the history for risk trending: is the vulnerability posture improving or degrading? Are accepted vulnerabilities accumulating or being worked off? You do not have to reconstruct history from before your first OCR, but every OCR after that gets a retained snapshot.

CDS-CSO-RIS: Responsible information sharing. Provide enough information to support agency authorization decisions, but SHOULD NOT include sensitive details that would likely enable a threat actor to cause harm. Share enough for agencies to assess risk; abstract the specifics that would lead to compromise. Role-based access resolves most of this tension: public information is visible to everyone, detailed security data is restricted to authenticated agency users.

Trust center requirements (CDS-TRC)

CDS-TRC-USH: Uninterrupted sharing. MUST. Agencies should not have to request manual approval every time they need certification data. FedRAMP’s stated preference is on-demand just-in-time access provisioning. The trust center is a production system with uptime expectations, separate from the availability of the offering itself.

CDS-TRC-PAC: Programmatic access. MUST. Documented programmatic access to all certification data, including programmatic access to the human-readable materials. Not a “send us an email and we will provide a download link” process. An agency running its own risk management platform pulls your data through the API.

CDS-TRC-AAI: Agency access inventory. MUST. The trust center maintains an inventory and history of federal agency users and systems with access to certification data, and makes it available to FedRAMP on request. The inventory is a property of the access system, not a side report.

CDS-TRC-ACL: Access logging. MUST. Log access to certification data and store summaries for at least six months. Who accessed what, when, and how; parties SHOULD be able to request the logs that pertain to them.

CDS-TRC-HMR: Human and machine-readable certification data available to view and download in both formats. SHOULD.

CDS-TRC-SSM: Self-service access management. SHOULD. Agencies provision and manage access for their own users and services directly, instead of filing requests with you.

Using a trust center, and the Rev5 migration

CDS-UTC-AAD: You may deny an agency access request as a business decision, but you MUST notify FedRAMP within 5 business days of doing so.

CDS-UTC-AGA: Providers SHOULD supply certification package access to agencies on request.

CDS-CSF-TCM (Rev5 only): When migrating to a trust center, providers MUST notify all necessary parties and MUST leave information in their existing USDA Connect Community Portal secure folders explaining how to get certification data from the trust center. Do not strand the agencies who still look in the old place.

The migration clock: Rev5 providers obtain the CDS rules by January 1, 2027 and maintain them by August 1, 2027, with grace ending February 1, 2028. The central repository is replaced by August 2027. Waiting means a platform buildout under migration pressure.

graph LR
    SRC[Live Compliance Data] --> TC[Trust Center]
    AG[Agencies] --> TC
    TC --> HR[Human-Readable View]
    TC --> MR[Machine-Readable API]
    TC --> LOG[Access Logging + User Inventory]

    style SRC fill:#2b5797,stroke:#5b9bd5,color:#fff
    style AG fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style TC fill:#1a5c3d,stroke:#51cf66,color:#fff
    style HR fill:#5c4a1a,stroke:#ffc857,color:#fff
    style MR fill:#4a1a5c,stroke:#c77dff,color:#fff
    style LOG fill:#1a3d5c,stroke:#4ecdc4,color:#fff

Why it matters

CDS reframes the relationship between providers and agencies around certification data.

Under the old model, authorization packages were static documents shared on request. The provider updated the package (usually monthly or quarterly), uploaded it to USDA Connect, and agencies pulled it when they needed it. The data was always at least a few days stale. When multiple agencies consumed the same package, each one received it independently. If an agency had questions, they contacted the provider directly. The same questions came from multiple agencies, independently. The provider spent time on what was essentially a document distribution and Q&A problem.

CDS changes this dynamic in several ways.

Live data instead of snapshots. The trust center serves current data. When certification data changes (a new vulnerability is evaluated, a change is implemented, a control status updates), the trust center reflects it. Agencies access the current posture, not a snapshot from last month’s reporting cycle.

One-to-many sharing. All agencies access the same trust center. The provider publishes once. Updates are visible to all agencies simultaneously. No per-agency distribution. No “Agency A has the March package but Agency B still has February.” One format, served to all consumers. The reporting burden scales with the complexity of the security posture, not with the number of agencies.

Programmatic access. CDS-TRC-PAC requires documented API access to everything, human-readable materials included. Agencies can integrate certification data into their own risk management tools. This is the foundation for the agency side of FedRAMP automation: risk assessment driven by live provider data instead of periodic document reviews, which is exactly what the Collaborative Continuous Monitoring rules expect agencies to do.

Transparency by default. CDS-CSO-PUB and CDS-CSO-SVC put the basic information in the open: what services are covered, what the scope is, when the next OCR lands, who the independent assessor is. Before CDS, agencies often had to request access just to evaluate whether an offering covered what they needed.

Historical context. CDS-CSO-HAD requires a retained snapshot for every OCR, kept for the life of the certification. This turns certification data from a point-in-time artifact into a trend. Is the posture improving or degrading? Are vulnerabilities being addressed or accepted? The trend tells a story that a single snapshot cannot.

The trust center is not a document library. It is a data platform. A document library stores files. A data platform serves structured data through APIs, renders it in multiple formats, logs access, manages users, and retains history. The implementation effort is different.

The pain we lived

Sharing certification data was one of our biggest manual burdens before we built it into the platform.

Every month, for every client, we assembled the ConMon package: POA&M, Vulnerability Deviation Report, asset inventory, scan summaries, change log. Each package was assembled from multiple sources, formatted, cross-checked, and uploaded to USDA Connect. The same data, presented slightly differently depending on the agency’s preferences. Some agencies wanted the POA&M in their template. Some wanted additional context fields. Some wanted the data in a specific order. We maintained multiple formatting variants of the same data.

Agencies pulled packages on their own schedule. Some checked monthly. Some checked quarterly. Some asked for packages by email because they did not want to log into USDA Connect. The distribution mechanism was inconsistent, and we spent time managing the distribution process rather than managing the security posture.

When an agency asked a question about the package, the answer required digging into the source data. “What is the current status of this item?” meant checking the ticketing system, not the uploaded document, because the document was already a snapshot. The document said “in progress” because that was the status when the package was assembled. The ticket said “remediated” because the fix was deployed yesterday. The document was stale. The data was not.

Format consistency was a manual exercise. The human-readable report and the machine-readable version (when required) were produced separately. They drifted. A field updated in one was not updated in the other. An assessor compared the two, found discrepancies, and the discrepancy became a finding. The fix was re-syncing the formats. The real fix was never producing them separately in the first place.

Historical data was a folder of past packages. History meant files organized by date. If an agency or assessor asked “show me the trend for accepted vulnerabilities over the last 12 months,” the answer was opening 12 files, extracting the relevant data from each one, and building a spreadsheet. The data was there. It was not queryable.

Agency access tracking did not exist in any structured form. We knew who had access to USDA Connect at a system level. We did not have an inventory of which agencies had accessed which packages, when, or how often. If someone asked “which agencies have viewed our latest package?” we could not answer.

Certification data was treated as documents to be produced and shared, not as structured data to be served and consumed. CDS formalizes the shift to a data-centric model.

How we automate it

CDS is a platform problem before it is a compliance problem. Certification data has to be structured, current, consistent between human and machine formats, and served with access logging and history. Here is how we built it into Stratus GRC-ITSM.

1. Structured compliance data as the source. The system documentation lives as structured, queryable data: Capabilities, Components, control implementations, and implementation statements, alongside the tickets and evidence that operations generate. Not OSCAL; the final rules make OSCAL optional and define their own JSON schemas, so the platform models compliance data natively and emits the machine-readable formats FedRAMP actually requires. The source is structured. Everything else is a rendering.
2. Two renderings, one source. Human-readable reports and machine-readable outputs are rendered from the same structured source, so they cannot drift. When a control status or vulnerability record changes in the source data, both renderings update. CDS-CSO-CBF requires automation that keeps formats consistent; rendering both from one source meets it as a property of the architecture, not a manual synchronization task.
3. A trust center report group. Customer-facing and agency-facing reporting is consolidated into a trust center report group that draws from live operational data. Customers see exactly their own system’s data through scoped report variants; agencies get the FedRAMP-facing variants of the same reports. Same tested queries, different audiences, no per-agency package assembly.
4. Machine-readable certification data artifacts, generated automatically. The machine-readable history and the FedRAMP submission artifacts (system data, significant-change, vulnerability, and incident reports) are generated from live operational data in the FedRAMP JSON shapes. Nobody assembles them by hand, which is the only way the “current and consistent” expectations of CDS survive contact with a busy month.
5. Public offering information as live data. The CDS-CSO-PUB fields (service model, deployment model, contacts, service list, next OCR date) come from the same system records everything else uses, so the public view updates when the source records change. The service list (CDS-CSO-SVC) is generated from the system documentation, not maintained as a separate document.
6. History as data. Snapshots aligned to OCR cycles (CDS-CSO-HAD) are retained as queryable data, not a folder of archived files. Trending accepted vulnerabilities over 12 months is a query, not a manual compilation from old packages.

The trust center layer wraps this: uninterrupted access per CDS-TRC-USH, a documented API per CDS-TRC-PAC, and the access inventory and logging (CDS-TRC-AAI, CDS-TRC-ACL) maintained as properties of the access system rather than side reports someone remembers to update.

The idea: build certification data as structured data, render every format from the same source, and let automation handle consistency. The trust center is the delivery mechanism. Human-readable documents are rendered outputs, not primary artifacts. Static documents and email distribution belong to the old model.

Compliance is a byproduct of operations, not a separate workstream.

FAQ

This article is part of a 15-part series on the operational disciplines that CMMC, FedRAMP Rev5, and FedRAMP 20x all test. [Read the series overview: Stop Building for Compliance. Build for Operations.]