If you've been through a FedRAMP authorization before, you have never had to run a trust center. You wrote the package, uploaded it to a government-run repository, and the government handled the rest. Agencies who wanted your materials asked the government, not you.
That's changed. Storing and sharing your certification materials is now your job, done through a system you own or license. FedRAMP calls it a FedRAMP-compatible trust center, and it comes with a specific list of things the system has to do.
The shift underneath all of it is that the old model shared documents and the new one shares data. Certification data is meant to be a live picture of where your security posture stands right now, which agencies can check continuously, not just once a year.
Here's what the FedRAMP 20X certification data sharing (CDS) requirements call for:
CDS-CSO-PUB requires your service details published in both human-readable form and JSON matching FedRAMP's schema. That includes your FedRAMP ID, service and deployment model, UEI number, sales and security contacts, product website, next Ongoing Certification Report date, and your current FedRAMP Recognized assessor.
CDS-CSO-SVC requires a list of every service you offer with its security category, complete enough that a prospective customer can work out what's inside and outside your Minimum Assessment Scope without asking you for anything. The names have to match what you use in your normal marketing materials, so an agency isn't reconciling internal codenames against your website.
CDS-CSO-IRP requires a register of your policies and procedures. For each one: the name, the file, a short summary, the current version, the date it was last updated, the word count, and any related FedRAMP Practices.
CDS-TRC-USH is the requirement that breaks most existing setups. Trust centers must share certification data without interruption, and FedRAMP defines that plainly — parties shouldn't have to request manual approval each time they need access, or work through a complicated process. The stated preference is on-demand, just-in-time provisioning. If your plan involves a queue where someone reviews each agency request, that doesn't satisfy this. Control belongs at the entitlement layer, deciding who is allowed access, not at the moment of each retrieval.
CDS-TRC-SSM extends that. Once an agency has access, its own administrators should be able to add and manage their people without coming back to you.
CDS-TRC-PAC requires a documented API covering all of your certification data, explicitly including the human-readable materials and not just the JSON. Agency systems are expected to pull from you directly.
CDS-TRC-HMR covers the other side: a party with access should be able to view and download your data in both formats.
CDS-UTC-AGA asks you to share the full certification package with an agency that requests it. This sits alongside uninterrupted sharing rather than contradicting it — certification data flows continuously, while the certification package is a discrete bundle an agency can ask for.
CDS-UTC-AAD covers the case where you say no. Deny an agency's access request and you have five business days to notify FedRAMP. That's one of the few hard clocks in these rules, so a denial should be a deliberate, dated, logged action rather than something that happens by silence.
CDS-CSO-CBF requires automation to keep the human-readable and machine-readable versions consistent. This is the quiet requirement that rules out maintaining a document and a JSON file side by side. If a person is typing the same value into two places, you aren't meeting it.
CDS-CSO-RIS lets you decide what gets shared and what stays withheld. FedRAMP's intent is specific: give agencies enough to make an authorization decision, but leave out details that would help an attacker. Their own example is useful — write that administrators with physical access can log in directly, not the actual break-glass credentials. This isn't permission to omit unfavorable findings. Abstract the exploitable specifics, keep the risk.
CDS-CSO-HAD requires snapshots of your certification data aligned to each Ongoing Certification Report, available for as long as you hold certification. You don't have to reconstruct anything from before your first report.
CDS-TRC-AAI requires an inventory of which federal agency users and systems currently have access, plus a history of who has had it, producible for FedRAMP on request.
CDS-TRC-ACL requires you to log every access and keep summaries for at least six months, and each party should be able to pull up the records of its own access.
What this means in practice
Strip out the rule IDs and you're being asked for six things:
- A single source of truth that renders to both formats without anyone retyping anything
- A public page exposing your services and scope with no gate
- Authenticated access that works without a per-request approval
- A documented API covering everything
- An access log and an entitlement inventory you can produce on demand
- Versioned snapshots tied to your reporting cycle
Two of those things reshape the trust center design more than the rest:
Automated consistency isn't optional. If your plan is to regenerate a JSON file whenever someone updates a document, the two will drift, and preventing that drift is why the rule exists.
And "without interruption" access requests rules out having per-request approval queues. The decision about who gets access to your trust center still belongs to you, but approval happens once at provisioning.
This is the list NYLE Trust Center was built against — a federal trust center, rather than a commercial one with FedRAMP fields added after the fact. If you're working out whether to build or buy, we're glad to walk through where you'd land.