FedRAMP Consolidated Rules for 2026
The Consolidated Rules for 2026 are the rules a FedRAMP provider follows to obtain and keep a certification. They move the certification package from word-processor templates to structured data, and they move certification data out of a federal portal and into a trust center the provider hosts.
CR26 was published on June 24, 2026, as structured machine-readable data. Optional adoption opened July 4, 2026. It becomes mandatory for all stakeholders on January 1, 2027.
CR26 renames FedRAMP Authorization to FedRAMP Certification and replaces impact levels with certification classes: A (Pilot), B (Low), C (Moderate), and D (High). The class sets the depth and scope of the package a provider owes. Every class supplies the Certification Package Overview in both human-readable and JSON formats under CPO-CSO-OVR, so machine-readable data is not reserved for the top class. Class D owes the most comprehensive package.
What changes for a Rev5 provider
The package itself changes. For a CR26 certification, the Security Decision Record replaced the System Security Plan as the authorization record, and it is machine-readable JSON rather than a word-processor document. The Certification Package Overview is a separate machine-readable summary supplied in both human-readable and JSON formats. The word-processor template that used to carry the plan is no longer the deliverable.
Where the data lives changes. A provider stores and shares its certification data in a FedRAMP-compatible trust center on a platform of its choosing, and that trust center exposes documented programmatic access to the data. The data stays the provider's intellectual property. It is not federal information.
How the data is produced changes. When certification data exists in both human-readable and machine-readable forms, automation has to keep the two consistent, and a provider supplies historical snapshots aligned to its Ongoing Certification Reports. Maintaining the two forms by hand is no longer a workable approach.
The rules that shape the package
CR26 states its requirements through rule identifiers. These carry the most weight for a provider planning its package and its data sharing.
- CPO-CSO-OVR
The Certification Package Overview in both forms
CPO-CSO-OVR requires the Certification Package Overview in both human-readable and JSON formats. The overview is a separate machine-readable summary. The Security Decision Record, not the overview, replaced the System Security Plan.
- CDS-CSO-UTC
A trust center is required
Providers must use a FedRAMP-compatible trust center to store and share certification data. The provider hosts it on a platform of its choosing, and the data remains the provider's intellectual property. It is not federal information.
- CDS-TRC-PAC
Programmatic access
Trust centers must provide documented programmatic access to all certification data, including the human-readable materials.
- CDS-CSO-CBF
Automation keeps formats consistent
When certification data exists in both human-readable and machine-readable forms, providers must use automation to keep the two consistent.
- KSI
Key Security Indicators for 20x
On the FedRAMP 20x path the whole package is machine-readable, validated against 46 Key Security Indicators across 10 categories, from identity and access management to supply chain risk. Each indicator maps to NIST SP 800-53 controls.
The dates
Every date below comes from the published ruleset or from FedRAMP's own timeline. The obligation dates run on the Rev5 track, for services that already hold a certification.
- June 24, 2026
FedRAMP publishes the Consolidated Rules for 2026.
- July 4, 2026
Optional adoption opens. Providers may begin following CR26 ahead of the mandatory date.
- July 28, 2026
FedRAMP Ready becomes a legacy status. No new FedRAMP Ready submissions are accepted after this date.
- January 1, 2027
CR26 becomes mandatory for all stakeholders. Significant change notifications and the Minimum Assessment Scope take effect for services already certified.
- March 7, 2027
The grace period ends for vulnerability detection and response and for vulnerability evaluation and reporting, mandated by CISA BOD 26-04.
- April 2, 2027
Collaborative continuous monitoring takes effect for services already certified.
- June 1, 2027
The Rev5 grace period ends for cryptographic module use, incident evaluation and communication, and significant change notification.
- June 11, 2027
FedRAMP stops accepting new Rev5 certifications.
- July 1, 2027
The Certification Package Overview requirement takes effect for services already certified, in both human-readable and JSON formats.
- August 1, 2027
Certification Data Sharing takes effect for services already certified. A provider that adopts a trust center serves its certification data from there.
- February 1, 2028
The Certification Data Sharing grace period ends for Rev5. It is the last Rev5 grace period.
What it costs to be late
Following CR26 within its effective dates and grace periods is what maintains a FedRAMP Certification. The obligations phase in through 2027, each with its own effective date, and the last Rev5 grace period, for Certification Data Sharing, ends February 1, 2028. A provider that reaches an effective date without the data in the required form is out of compliance with the rule that date belongs to. The Rev5 track is also closing to newcomers: FedRAMP Ready goes legacy on July 28, 2026, and no new Rev5 certifications are accepted after June 11, 2027.
Machine-readable and OSCAL
A machine-readable package holds the certification data in a structured format that software can read directly, rather than a word-processor document a person has to parse by hand. CR26 itself is published this way, as structured JSON. OSCAL is the first approved format, and it is not the only one permitted. The list stays open to the formats FedRAMP identifies, which today include at least OSCAL and JSON. FedRAMP also publishes its own JSON schemas for the parts of the package the rules require in JSON, such as the Certification Package Overview schema.
What the package looks like
Here is one control from an authorization package, shown as machine-readable OSCAL and in plain terms.
{
"control-implementation": {
"implemented-requirements": [
{
"uuid": "ir-ac2-0001",
"control-id": "ac-2",
"props": [
{ "name": "implementation-status", "value": "implemented" }
],
"statements": [
{
"statement-id": "ac-2_smt.a",
"uuid": "stmt-ac2-a",
"by-components": [
{
"component-uuid": "comp-aws-iam",
"uuid": "bc-ac2-a-01",
"description": "Account creation, modification, and disablement are managed in AWS IAM and reconciled against Security Hub findings on each change."
}
]
}
]
}
]
}
}Illustrative OSCAL, not a real package.
The same control, in human terms.
Who reviews and signs
Every package is reviewed by a practitioner and signed before it reaches an agency, and the signature carries one of two affiliations. In the first, your own practitioner reviews and signs, and our signature notarizes that self-attestation, so an agency can verify the exact bytes and see that nothing changed after signing. In the second, a TRGR practitioner reviews and signs, so the agency receives an independent third-party review rather than the provider's own attestation. Which of the two signed is recorded inside the signed bytes and verifies against the same public key an agency already uses to check the package, so a self-attestation cannot be presented as an independent TRGR review.
How TRGR fits
TRGR builds the certification as running infrastructure and generates the machine-readable package from live system state, in an approved machine-readable format such as OSCAL. The same automation renders the human-readable view from that source, which is the consistency CR26 asks of providers that publish both forms. TRGR also ships the trust-center software a provider runs in its own account: a read API that serves certification data to agencies programmatically, an access log, an inventory of the agencies holding access, and keys an agency can use to verify a package signature with no TRGR account. TRGR does not operate a trust center and is not itself FedRAMP-compatible. Each trust-center rule binds the provider, and the provider is the client running the software.