Authorization Data Sharing: What ADS Requires and How to Automate It

What it is

Authorization Data Sharing (ADS) replaces static authorization 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 authorization package. ADS is how.

Under the traditional 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.

ADS replaces this with a trust center model. Providers serve authorization 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: optional open beta since February 2, 2026 (beta ends May 22, 2026). Prerequisite: providers must also participate in the SCN and VDR betas to adopt ADS.

The relevant KSI: KSI-AFR-ADS.

What it requires

ADS has two sets of requirements: what the provider must share, and how the trust center must operate. The distinction matters because a provider could share the right data through the wrong mechanism and still fail the trust center requirements.

Provider requirements (MUST)

ADS-CSO-PUB: Publicly share up-to-date offering information. This includes service model, deployment model, UEI, contact information, service list, customer responsibilities, and the next OAR (Ongoing Authorization Report) date. This is public-facing. Not behind authentication. Agencies and prospective customers should be able to evaluate the offering without needing access to the full authorization package. This is a transparency requirement that did not exist in the traditional model.

ADS-CSO-SVC: Public detailed service list with security objectives. The service list has to be clear enough for customers to determine FedRAMP scope without accessing the authorization package itself. If an agency is evaluating whether a provider’s FedRAMP authorization covers the service they want to use, the service list should answer that question. This is more detailed than a marketing page. It maps services to security objectives and scope boundaries.

ADS-CSO-CBF: Keep human-readable and machine-readable formats consistent, automatically. No manual synchronization between the PDF and the API. One source, two renderings. If the human-readable SSP says control AC-2 is implemented with Entra ID, the machine-readable version must say the same thing. Manual format synchronization inevitably drifts. ADS requires automation that prevents drift by design.

ADS-CSO-HAD: 3 years of historical authorization data. Not just the current package. Three years of history, accessible and queryable. Agencies use this for risk trending and authorization decisions. An agency evaluating whether to authorize the use of a provider’s system wants to see the trend: is the vulnerability posture improving or degrading? Are POA&M items being closed or accumulating? Three years of history answers those questions.

ADS-CSO-RIS: Provide enough information for authorization decisions. The data shared should be sufficient for an agency to make an informed authorization decision. The caveat: SHOULD NOT include information that enables exploitation. This creates a tension that the trust center implementation must resolve. Share enough for agencies to assess risk. Do not share so much that an attacker could use the information. The trust center handles this through role-based access: public information is visible to everyone, detailed security data is restricted to authenticated agency users.

Trust center requirements (MUST)

ADS-TRC-USH: Uninterrupted sharing. The trust center has to be available. Downtime means agencies lose access to your authorization data. This is an availability requirement for the trust center itself, separate from the availability of the system being authorized. Planned maintenance is expected, but the trust center needs to be treated as a production system with appropriate uptime targets.

ADS-TRC-PAC: Documented programmatic access. An API. Documented. Not a “send us an email and we will provide a download link” process. The API enables agency-side automation. An agency running its own risk management platform should be able to pull authorization data programmatically and integrate it into their risk assessment workflows.

ADS-TRC-AAI: Agency user inventory. You have to track which agencies and which individuals have access to your authorization data. This is a provider responsibility. The trust center knows who is accessing the data. The inventory is maintained as a property of the platform.

ADS-TRC-ACL: Access logging for 6+ months. Every access to authorization data is logged and retained for at least 6 months. Who accessed what, when, and how. This provides accountability and supports incident response if authorization data is accessed improperly.

Rev5 vs 20x distinction

The trust center requirement differs by framework version:

• Rev5: Share via USDA Connect unless using a trust center (ADS-CSL-UCP, MUST). Using a trust center is a SHOULD for Rev5 (ADS-CSL-UTC). Rev5 providers can continue with USDA Connect and meet the requirement.
• 20x: Trust center is mandatory (ADS-CSX-UTC, MUST). USDA Connect is not sufficient for 20x. The trust center is the only acceptable sharing mechanism.

This means Rev5 providers who plan to transition to 20x need to build the trust center capability before the transition. Starting on USDA Connect and planning to add a trust center later means a platform buildout under 20x migration pressure.

graph LR
    OSCAL[OSCAL Data Model] --> TC[Trust Center]
    TC --> HR[Human-Readable View]
    TC --> MR[Machine-Readable API]
    TC --> LOG[Access Logging]
    TC --> INV[Agency User Inventory]
    AG1[Agency 1] --> TC
    AG2[Agency 2] --> TC
    AG3[Agency N] --> TC
 
    style OSCAL fill:#2b5797,stroke:#5b9bd5,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
    style INV fill:#1a3d1a,stroke:#a9dc76,color:#fff
    style AG1 fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style AG2 fill:#5c1a3d,stroke:#ff6b9d,color:#fff
    style AG3 fill:#5c1a3d,stroke:#ff6b9d,color:#fff

Why it matters

ADS reframes the relationship between providers and agencies around authorization 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.

ADS changes this dynamic in several ways.

Live data instead of snapshots. The trust center serves current data. When authorization data changes (a new vulnerability is discovered, 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 ConMon cycle. An agency evaluating risk sees the current state, not the state as of whenever the last package was uploaded.

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.” No per-agency formatting. 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. ADS-TRC-PAC requires documented API access. Agencies can integrate authorization data into their own risk management tools programmatically. This is the foundation for the agency side of FedRAMP automation: continuous risk assessment driven by live provider data instead of periodic document reviews.

Transparency by default. ADS-CSO-PUB and ADS-CSO-SVC require public information about the offering. Before ADS, agencies often had to request access just to evaluate whether a provider’s authorization covered what they needed. ADS puts the basic information in the open: what services are authorized, what the scope is, what the next reporting date is.

Historical context. ADS-CSO-HAD requires 3 years of historical data. This turns authorization data from a point-in-time snapshot into a trend. Is the provider’s security posture improving or degrading? Are vulnerabilities being addressed or accumulating? The trend tells a story that a single snapshot cannot.

The trust center is not a document library. It is a data platform. That distinction matters for implementation. 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

Authorization data sharing 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 POA&M 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 POA&M 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. Three years of history meant three years of 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.

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

How we automate it

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

1. OSCAL as the source. SSP, SAP, SAR, and POA&M are maintained as OSCAL-structured data. The machine-readable requirement (ADS-CSO-CBF) is met natively because machine-readable IS the source. You do not produce a machine-readable version from a human-readable document. You produce a human-readable rendering from machine-readable data. The source is structured. The renderings are views. Consistency is a property of the architecture, not a manual synchronization task.
2. Human-readable rendering from the same data. Agencies get readable documents: formatted SSPs, POA&Ms, vulnerability reports. Those documents are generated from the OSCAL source. Because the rendering is automated, the human-readable and machine-readable formats cannot drift. When a control status changes in the source data, both renderings update. No manual sync. No opportunity for inconsistency.
3. Trust center platform. A portal serves authorization data with role-based access for agencies, programmatic API access per ADS-TRC-PAC, and human-readable views. ADS-CSX-UTC (MUST for 20x) is the end state. The trust center is not a file share. It is an application that serves data, manages access, logs activity, and maintains history. Public information (ADS-CSO-PUB, ADS-CSO-SVC) is available without authentication. Detailed authorization data requires authenticated agency access.
4. Delta generation between versions. Changes between OAR cycles are tracked and exposed as structured deltas. Agencies see what changed since last quarter without re-reading the entire package. “3 new vulnerabilities, 7 remediated, 1 POA&M closed, 2 changes completed” is more useful than a 50-page document. The delta is computed from the structured data, not manually authored.
5. Just-in-time agency access provisioning. New agency users are provisioned through the trust center with the right roles. Access is logged per ADS-TRC-ACL for 6+ months. No manual approval queues that delay access for weeks. When an agency analyst needs access to evaluate the authorization, they get it through the trust center with appropriate role assignment and immediate logging.
6. Agency user inventory. ADS-TRC-AAI is met by keeping the inventory as a property of the trust center, not a side report. The trust center knows who has access, what role they hold, which agency they represent, and when they last accessed the data. The inventory is always current because it is a property of the access system, not a manually maintained list.
7. 3-year history as data. Historical authorization data (ADS-CSO-HAD) is retained as queryable data, not archived file versions. Agencies can access prior posture for audit and risk decisions. Trending accepted vulnerabilities over 12 months is a query, not a manual compilation from a folder of old packages. The history is versioned and time-stamped. Any point-in-time snapshot can be reconstructed.
8. Public offering information. ADS-CSO-PUB fields (service model, deployment model, UEI, contact info, service list, customer responsibilities, next OAR date) are published as live data in the trust center, updated automatically when the source records change. No manual updates to a static “about” page. The service list (ADS-CSO-SVC) is generated from the system documentation, not maintained as a separate document.

The idea: build authorization data as structured data, serve it through APIs, and let automation handle format consistency. The trust center is the delivery mechanism. OSCAL is the data model. 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.]