CR26 Is Live: FedRAMP's Consolidated Ruleset for 2026 Officially Dropped
· 12 min read

CR26 Is Live: FedRAMP's Consolidated Ruleset for 2026 Officially Dropped

#FedRAMP#FedRAMP20x#CR26#Compliance-as-Code#GRC-engineering#OSCAL

Last week, FedRAMP officially released the Consolidated Rules for 2026. CR26 is no longer a preview. It is the operating ruleset for the FedRAMP program, effective July 4, 2026 through December 31, 2028, with mandatory adoption beginning January 1, 2027.

I wrote about the public preview back in May and called the preview model itself one of the most interesting moves FedRAMP had made in years, and I stand by that read, because the final release validates it. Most of what was in the preview made it through, a few things hardened, and some structural pieces that were placeholders are now load-bearing, while the program’s posture toward machine-readable rules took another visible step forward.

This post is the follow-up, covering what dropped, what is now binding, and what I would be doing about it if I were on the CSP side.

What Dropped Last Week

The June 24 release is less a single document and more a coordinated repackaging of where the FedRAMP program now lives. FedRAMP’s own framing of the underlying approach is worth quoting before the mechanics, because it sets the lens for everything else. The program describes 20x as “a new approach to cloud security assessment and authorization that moves beyond traditional compliance to focus on the security decisions that matter most,” organized around five principles: Transparency, Flexibility, Accountability, Accuracy, and Automatic Validation. The phrase the program uses repeatedly is moving “away from paperwork and toward evidence.” That is the substrate underneath everything CR26 codifies.

A few concrete moves in the release itself:

New canonical site at fedramp.gov/2026. The preview site at preview.fedramp.gov is sunsetting and explicitly should not be used after July 1, 2026. The /2026/ namespace is now the address of the operating ruleset.

Legacy Rev5 and 20x Pilot documentation moved to fedramp.gov/legacy. Not deleted, not deprecated for existing authorized services, but no longer the front door. The signal here is unambiguous: CR26 is the program, and Rev5 is a path inside it, not the other way around.

JSON schemas for machine-readable compliance packages shipped as deliverables. This is the piece I want to slow down on, because it is the single most concrete advance from the preview. Where the preview promised machine-readable as a direction, the final release ships actual JSON schemas you can build against, so the FedRAMP requirements catalog is no longer just becoming an API in the abstract; the contract surface is now published.

The Marketplace was updated for CR26. Certification Class display (A/B/C/D) is live. The legacy Low/Moderate/High labels are on their way out, and as I covered in the preview post, pricing visibility is gone per NTC-0005.

The old github.com/FedRAMP/docs repository was archived on June 19 in preparation for the release, and now redirects users to three new repos that carry the actual content:

That last one is worth a beat. FedRAMP is publishing an explicitly LLM-optimized version of the ruleset, and the FedRAMP/2026 repo includes an AGENTS.md file that calls out Codex, Claude Code, and other repo agents by name. A federal program is not just publishing rules in a machine-readable format; it is publishing them in a format intended to be consumed by AI coding agents working inside its own repos. The implication for compliance tooling vendors and for internal GRC engineering teams is that the rules are now first-class input to the same automation stack everyone is building anyway.

What Held Between Preview and Final

Almost all of the structural pieces I wrote about in May made it through.

The Class A/B/C/D structure is intact. Class B replaces Low and Li-SaaS, Class C replaces Moderate, Class D replaces High, and Class A remains the pilot tier. The mapping is what was telegraphed in NTC-0004, and CR26 codifies it across the rest of the rule text.

The effective dates held their shape. July 4, 2026 is the effective date, January 1, 2027 is the mandatory adoption date, and CR26 is the operating baseline through December 31, 2028. That is a thirty-month stable content window, and it is the first time in a long time that FedRAMP has handed CSPs a planning horizon that long.

The dual-path model holds. Rev5 and 20x are both still valid paths inside CR26, and they are explicitly not interchangeable, so CSPs pick a lane. Existing Rev5 holders are not being force-migrated, but they are subject to the applicable Balance Improvement Releases under CR26 once mandatory adoption kicks in.

The 3PAO / IA accreditation floor stayed. Independent Assessors must complete at least two assessments every two years to retain accreditation. As I noted in May, this is going to shake out the long tail of 3PAOs that hold accreditation but rarely actually assess.

ConMon continues the move toward Ongoing Authorization Reports. Quarterly published OARs replace the monthly artifact-heavy submission pattern, with quarterly synchronous review meetings for Moderate (Class C) and High (Class D). The assessor’s role continues to shift from document review toward verification of outcomes and automated evidence.

What Hardened

A few pieces moved from “directional” in the preview to “binding” in the final.

Machine-readable packages have an enforcement clock. CR26 does not hang machine-readable on a single distant deadline; it folds the obligation into the same date model as everything else, effective for adoption on July 4, 2026 and required for most rules on January 1, 2027, with the higher classes carrying the heaviest expectations because they have the most resources to account for. That sounds comfortable on a calendar and uncomfortable on the engineering side, because nobody’s compliance pipeline is currently structured to emit a complete, schema-valid OSCAL package as a build artifact on demand. The JSON schemas that shipped last week are the spec you build against, and if your evidence collection still runs through humans pasting screenshots into a portal, you have less time than you think.

One nuance worth flagging: the Class D certification path itself is still being developed under FedRAMP 20x Phase 4, which is targeted for FY27. The CR26 rule text references Class D, but the operational pilot is later. The practical read: if you are a current FedRAMP High provider, you are not being asked to migrate to a Class D 20x model today. You are being asked to align with CR26’s plain-language rules and machine-readable expectations on the timeline the program lays out, while the Class D pilot infrastructure stands up around you.

KSI verification expectations got tiered by class. Preview-era rule edits (in the changelog, e.g., FRMR FRC-CSX-VVK) added class-specific automated KSI verification expectations: roughly, optional for Class A, with the bar rising to at least four automated verification methods per KSI at Class D. That class-tiered automation requirement carried into the final release. The era of “we have a control narrative for that” is closing fast for anyone aiming above Class B.

The Marketplace transition is live, not coming. Class display is on the Marketplace today and pricing is off it, so the transition you were planning for is already in effect.

The Deadlines That Actually Bite

The most useful thing CR26 hands you is a real calendar, and the cleanest way to read it is straight from the machine-readable rulesfile FedRAMP published with the release, where every requirement carries its own dates rather than inheriting one global deadline.

  • July 4, 2026 is the optional adoption date. This is when CR26 becomes effective and a provider can intentionally start operating under the consolidated rules, and it is the date the rulesfile stamps on the vast majority of requirements.
  • January 1, 2027 is the date the rules become required. For most requirements this is both the obtain date for new certifications and the maintain date for existing ones, which is the point at which CR26 stops being something you read and plan against and becomes something you are measured on.
  • A staggered set of grace periods through 2027 and into 2028 is the nuance most summaries flatten. Individual requirements get their own runway past the January date: Significant Change Notification, Cryptographic Module Use, and Incident Evaluation and Communication run to June 1, 2027, while Certification Data Sharing and the Security Decision Record run to August 1, 2027, with the latest grace period in the file reaching February 1, 2028. The lesson is that there is no single cliff, so you have to read the date model per requirement rather than assume one deadline covers your whole package.
  • December 7, 2026 is the outlier worth knowing about. Under NTC-0014, both Vulnerability Detection and Response and Vulnerability Evaluation and Reporting become mandatory on that date for any cloud service offering obtaining or maintaining Certification, which explicitly includes existing Rev5 providers, so this is one place where the modernization reaches back and touches services that authorized under the old model. December 7 is not a clean cliff, though, because a CSO that is not yet ready can stay certified under a corrective action plan with agency notification through March 7, 2027. The honest framing is mandatory on December 7, 2026 with a CAP bridge to March 7, 2027, after which Certification is revoked for anyone not following the rules.

CR26 is also explicitly time-boxed through December 31, 2028, which is the far edge of the thirty-month planning window the program has been advertising. The shape that emerges from the rulesfile is less a single ladder than a July 2026 start, a January 2027 hard line for most obligations, and a tail of requirement-specific grace periods that runs into 2028. None of those dates are comfortable once you map them against how long it actually takes to re-tool an evidence pipeline.

What CSPs Should Be Doing This Quarter

The temptation, again, is to wait, and I would not. FedRAMP’s own framing from the Phase 2 lessons is direct on this: “Cloud service providers need deep engagement from engineering teams to adopt the approach.” That is not a documentation problem, it is a build problem.

Pick your lane and commit. If you are a current Rev5 Moderate provider, your path inside CR26 is Class C. If you have been considering 20x for a new offering, the rules for that lane are now formally in force as of July 4. The choice is no longer “watch the space”; it is a deliberate path decision with documentation, evidence, and assessment implications.

Treat the JSON schemas as a spec, not a curiosity. The package contract is published. The January 1, 2027 required date is the first hard line for most of the ruleset, and the rest of the program is moving toward machine-readable as the default mode of submission. If your GRC platform, your evidence pipeline, or your CI/CD attestations cannot emit against these schemas, the gap between you and a 20x-native competitor is going to be visible to assessors and to agency reviewers.

Subscribe to the rules repos like they are dependencies. FedRAMP/2026, FedRAMP/rules, and FedRAMP/2026-markdown are now versioned artifacts you can watch, diff, and integrate. The program is treating rule text as software, and so should you.

Re-baseline your SSP narrative against the plain-language MUST/MUST NOT structure. A lot of legacy SSP prose is going to read as either redundant or insufficient against the consolidated, declarative rule text. Identify the gap before an assessor does.

Map your KSI verification posture by class. If you are aiming at Class D, the bar is at least four automated verification methods per KSI. If your current evidence story is one screenshot per control, the delta is large and quantifiable. The good news is that it is also addressable through tooling rather than headcount.

Drop your tracking channels into the GitHub Issues and Discussions for the new repos. The preview model worked by making feedback canonical and public. The final release continues that posture. The CSPs that benefit from the rule set evolving over the next thirty months are going to be the ones that show up in the issues, not the ones emailing the program office.

The Bigger Read

I have been saying for a while that FedRAMP is in the middle of the most consequential modernization the program has ever attempted, and that the people running it are doing the work in public partly because they want better feedback and partly because they do not have the bandwidth to do it any other way. CR26 going final is the moment that bet pays out, or it doesn’t.

What I saw in the preview window was a program that listened more carefully than I expected to industry comment. What I see in the final release is a program that took the next step in the direction it has been signaling for a year: declarative rules, machine-readable packages, GitHub as the workbench, AI-consumable documentation, classes instead of impact levels, continuous monitoring instead of point-in-time audits. None of these are independent. They are all expressions of the same five-principle framing the program uses about itself — transparency, flexibility, accountability, accuracy, and automatic validation — and of the same single line, away from paperwork and toward evidence. Compliance is software now, and the program is treating it as such.

The full announcement and new ruleset live at fedramp.gov/2026. The legacy material lives at fedramp.gov/legacy. The repos are at github.com/FedRAMP. The clock starts July 4, and the hard wall lands January 1.

There is no part of this you benefit from waiting on.

Mario Lunato is the Field CISO at Knox Systems and writes about FedRAMP, cloud security, and GRC engineering at OneUpSec.tech.