For as long as FedRAMP has existed, the Marketplace has been the front door. Agencies went there to find authorized offerings, and FedRAMP, not providers, controlled access to the compliance packages behind them. FedRAMP 20X moves that responsibility. Providers now publish and manage access to their own certification data, and the entry point for all of it is a public page you host yourself.
CDS-CSO-PUB is the rule that defines that page. It calls for sixteen specific fields, published in both human-readable form and JSON, on a page an agency can read without logging in or asking anyone for access. For most agencies evaluating your offering, it is the first thing they will see and the last thing anyone on your team will remember to update.
What CDS-CSO-PUB requires
- Publish the required information about your offering on a public webpage, or share it publicly through a FedRAMP-compatible trust center.
- Publish it in both human-readable form and JSON.
- Make sure your JSON conforms to FedRAMP's Certification Package Overview schema (FRC-CSO-PKG).
- Clearly display your FedRAMP ID once assigned. This one comes from a neighboring rule, CDS-CSO-FID, which requires the ID across all of your certification data.
The sixteen fields
FedRAMP qualifies the list below as the information that is available and applicable, and means that literally: where an item genuinely does not apply to your offering, you say so rather than invent a value.
| Field | What goes in it |
|---|---|
| FedRAMP ID | Assigned FedRAMP ID |
| Service Model | IaaS, PaaS, or SaaS |
| Deployment Model | Public, private, hybrid, or government-only |
| Business Category | Business category per FedRAMP's taxonomy |
| UEI Number | Unique Entity Identifier |
| Sales Contact Information | Who agencies reach to buy |
| Security Contact Information | Who agencies reach on security matters |
| Product Website Link | URL for the offering |
| Link to Product Logo | A URL that resolves to the logo, not an uploaded image |
| Overall Service Description | Description of the offering |
| Specific services and security categories | Each service with its security category, per CDS-CSO-SVC |
| Link to Secure Configuration Guidance | URL to the guidance |
| Documentation overview | Overview of the documentation supplied for the offering |
| Trust Center landing page link | URL to the trust center, with instructions for accessing what it holds |
| Next Ongoing Certification Report date | Date of your next OCR, per CCM-OCR-NRD |
| Current independent assessment service | Your current FedRAMP Recognized assessor for the offering |
What conformance actually demands
The rule describes a page, but the implementation is closer to a pipeline. Publishing sixteen fields is a week of work. Keeping sixteen fields accurate through a certification cycle is a different problem, because these values change at very different rates and almost none of them belong to whoever maintains the page. Sales contacts turn over. The assessor changes when a contract renews. The OCR date advances every cycle, the service list moves whenever the assessment boundary does, and three of the fields are links to assets that another team can relocate without ever knowing a FedRAMP obligation depended on them resolving.
None of those changes manage themselves, and that is the failure worth designing against: not a missing field, but a field that was correct when you published it and over time stopped being correct, on a page an agency is entitled to rely on. CDS-CSO-CBF anticipates part of this by requiring automation between the human-readable and JSON formats, which means a person regenerating the JSON on a quarterly cadence is not conformant no matter how reliable that person is.
Timing
Sequence matters here as much as the deadline does. A public listing sounds like something you produce once you are certified, but the dependency runs the other way: you need a listing that meets CDS-CSO-PUB in order to request a FedRAMP ID, and then to maintain certification afterward. Teams that schedule this work at the end find it blocking them at the beginning.
As for the dates, 20X providers reached optional adoption and the obtain milestone on July 4, 2026, with the maintain milestone on January 1, 2027. Because providers are certified at different times, the grace period has no fixed end; it closes on your first FedRAMP independent assessment started after January 1, 2027.
How NYLE handles this
NYLE implements every CDS requirement for FedRAMP, which means the public page and the trust center it points to are parts of one system rather than two projects that have to be kept in agreement. For CDS-CSO-PUB specifically, providers enter all sixteen fields once, and both the human-readable page and the schema-conformant JSON are rendered from that single source. Neither is generated by hand, so the two cannot diverge and CDS-CSO-CBF is satisfied by construction rather than by review. Because NYLE also provides the trust center, the fourteenth field resolves to a landing page inside the same platform, with the access instructions the rule asks for behind it.
If you are scoping against the January 1, 2027 deadline, here is a test worth running first. Take your current public materials and try to fill all sixteen fields from a system of record rather than from memory, noting every field you had to ask another team about. Those are the fields that will go stale, and whether they do is what CDS-CSO-PUB is actually measuring.