The FedRAMP Consolidated Rules for 2026: What Rev 5 Certification Holders Need to Know

Insight from Schellman's federal team on the FedRAMP 2026 Consolidated Rule update, featuring the program's biggest overhaul in years.

If you hold a FedRAMP Rev 5 certification, you've probably heard the term "CR26" floating around since late June. Whether you've bookmarked the deadlines page, or you've started wondering whether your SSP is about to become unusable, it's time to get oriented. The Consolidated Rules for 2026 (CR26) touch nearly everything about how you'll work with FedRAMP going forward, even if you’ve never considered the 20x path.

We recently hosted a client briefing to walk through what's changing, why, and what CSPs should do about it. Here's the rundown.

What is CR26?

For years, CSPs knew some FedRAMP requirements lived in the System Security Plan, some were FedRAMP-assigned parameters, and others were buried in "Additional FedRAMP Requirements and Guidance" or a boundary guidance PDF.

FedRAMP recently decided that model wasn't sustainable, so they consolidated everything. Every requirement for every stakeholder (CSPs, agencies, assessors, even FedRAMP itself) has been consolidated into one machine-readable rule set, which governs both Rev 5 and 20x. It's designed to be ingested directly into an LLM or a GRC tool, because, as Pete Waterman has noted publicly, that's genuinely the intent. If you try to read through it manually, you'll find rules that point to other rules that point to other rules. Feed it into your tool of choice instead.

The FedRAMP consolidated rules were published at the end of June 2026 as a genuine multi-year planning horizon through December 31, 2028. A lot of CSPs spent the last year and a half in limbo, watching FedRAMP publish RFC after RFC and notice after notice, never quite sure which proposed changes would stick. CR26 is FedRAMP's attempt to give everyone solid ground to build on. Though notably, FedRAMP is still publishing clarifications and administrative updates to the rule set inside that window.

Why CR26 Matters, Even If You're Staying on the Rev 5 Path

Your Rev 5 certification will be reviewed against CR26, not the old guidance, regardless of whether you ever pursue 20x. This is the new stand you're being held to. Additionally, your package format, vocabulary, and vulnerability management model are all changing. You should treat it as a single project with a plan, not a pile of separate checkboxes, and loop your agency customers in early, so nobody gets caught off guard.

The New Vocabulary Under CR26

Nearly every label you've used to describe your certification has changed:

One aspect that hasn't changed despite the rename is that FedRAMP still doesn't grant an ATO or accept risk on the government's behalf, it certifies that a standardized assessment was completed. Every agency that wants to use your service still has to make its own risk-based ATO decision. The terminology shift is partly an attempt to retire the misconception that the FedRAMP PMO are able to accept risk on behalf of federal agencies.

Also notably, the Certification Classes aren't a security rating, and they're not a repackaged version of Low/Moderate/High, even though mapping B→Low, C→Moderate, D→High is the easy shorthand everyone (including us) reaches for. FedRAMP has said directly that a Class B system can be more secure than a Class D one.

What actually differs by Class is the assurance cadence, meaning how often you're expected to continuously validate a given requirement. A Class D provider might need to reverify something every few hours; a Class B provider might only need to do it monthly. It's a commitment spectrum, not a security ladder.

The FedRAMP Deliverables According to CR26

FedRAMP no longer owns or mandates a giant stack of fill-in-the-blank templates. The SSP, SAP, SAR, POA&M, RET, SRTM, CIS, and CRM are all archived and tagged with a "use with extreme caution" banner on FedRAMP's legacy documentation page. In their place, FedRAMP now publishes required information and JSON schemas, and expects your package to be a living, continuously accurate reflection of your posture.

The two deliverables that matter now include:

• Certification Package Overview (CPO): think of it as the front matter of your old SSP. System description, boundary, third-party services in use. Notably, there's no explicit requirement for a boundary diagram anymore (there was actually a moment in an earlier draft where diagrams were prohibited that didn't survive to the final version, but it tells you how strongly FedRAMP wanted to move away from the old "map everything under the sun" diagram culture).
• Security Decision Record (SDR): the rough equivalent of Appendix A. For every applicable FedRAMP Rule and every applicable 800-53 control (KSIs too, if you're on 20x), you document in plain language how it's implemented, and our results as your assessor feed into that same record. FedRAMP was deliberate about the name here: they want you to own the decisions you make. If you decide not to implement something, that has to be documented.

One control update worth calling out by name: CA-5 (Plan ofAction & Milestones) has been removed from FedRAMP's control guidance entirely. Combined with most FedRAMP-assigned parameter values being pulled back in favor of CSP-defined ones, the message is consistent — FedRAMP wants you setting and justifying more of your own posture, not filling in a number they handed you.  

How to Scope Boundaries Under CR26

If you've ever sat in a boundary-scoping conversation that went nowhere because
nobody could agree on the old draft boundary guidance, you'll appreciate this one. That
guidance never got finalized as there was a variety of opinions from stakeholders who were unable to agree on the level of protection required for different data types. The consensus never arrived.

CR26 resolves this issue by handing scoping authority to the CSP: your Minimum Assessment Scope is defined by which information resources are likely to store, process, or transmit federal customer data, or that could affect its confidentiality, integrity, or availability. Nothing else has to be in your boundary.

If a service doesn't touch federal data and couldn't affect it, you don't need to bring it in-scope, and FedRAMP doesn't want CSPs to spend time and resources hardening your instance of that service against FedRAMP requirements. You do have to be transparent about what third-party services you are using with justification and compensating controls for anything that isn't FedRAMP-certified.

Your certification package needs enough detail for an agency to make a risk-informed decision, but it shouldn't include the kind of detail a threat actor could use to launch an attack against you. FedRAMP is explicitly trying to avoid turning every certification package into a blueprint.

Continuous Monitoring Under CR26

Monthly POA&M uploads and once-a-year assessments are giving way to a standing cadence: an Ongoing Certification Report every three months, plus a live Quarterly Review meeting to go with it. There's also a real structural shift in who you answer to day to day: after your initial certification, your sponsoring agency becomes just another customer under this collaborative model, rather than the sole gatekeeper for every change you want to make. FedRAMP explicitly does not want CSPs stuck because a partnering agency is non-responsive or risk-averse.  

Change Management Under CR26

The old Significant Change Request process required advance government approval for changes. This model was difficult to scale within cloud environments with rapid changes, ephemeral infrastructure, and resources frequently being spun up and spun down. CR26 replaces it with Significant Change Notification: notify, don't ask permission, sorted into three tiers:

• Routine recurring changes (automated maintenance, vulnerability patching): no notification, no assessor involvement.
• Adaptive changes (most feature/component updates): notify within 10 business days after making the change.
• Transformative changes (replacing a critical third-party service, a management plane migration — meant to be rare): notification before and after, with assessor
  review expected but not strictly mandated by FedRAMP itself.

Vulnerability Management Under CR26

The flat monthly-scan-and-POA&M model is retired in favor of Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER) under CR26. And this ruleset has the earliest mandatory date in the entire rule set (December 7, 2026), pulled forward specifically because CISA's Binding Operational Directive 26-04 forced the government's own hand on vulnerability management. This isn't a CSP-only change; the federal government has to comply with the same directive.

The philosophy shift is significant: FedRAMP found that most real-world attacks didn't trace back to a scored CVE. So instead of mandating exactly how you find vulnerabilities, CR26 lets you define your own approach: scanning, bug bounties, penetration testing, threat intelligence, whatever combination fits your environment, as long as you document it in your certification package. Every method that surfaces something now feeds one unified pipeline: a scan finding, a manual control gap, and a penetration test result are all just "vulnerabilities" now, graded and remediated the same way.

Grading runs on three questions:  

1. Is it reachable — directly or indirectly — from the internet?
2. Is it likely to be exploited?
3. How bad would the impact be to customers if it were?

That last question produces a PAIN rating (Potential Agency Impact, N1 through N5), and PAIN (combined with reachability and exploitability) sets your remediation clock. The worse and more exposed a vulnerability is, the faster it has to be fixed; some combinations carry deadlines measured in hours. Anything still open after 192 days gets relabeled an Accepted Vulnerability with a documented justification as a forced transparency mechanism.

We think this is a genuine improvement. Under the old model, teams burned enormous time chasing anything scored "High" on CVSS, whether or not that severity actually made sense in their specific environment. This model lets you get strategic about what actually matters to your system and ultimately your customers.

Two related, practical notes:

• CM-6 configuration benchmarks are no longer mandated. DISA STIGs and CIS
  Benchmarks used to be close to a requirement; now it's an organization-defined
  parameter. You define and justify your own hardening baseline (your agency may
  still ask for a specific one, which is a conversation to have with them, but is not a
  FedRAMP requirement anymore).
• Reporting changes shape. Open vulnerabilities get reported at least monthly using a defined JSON structure, and if something is severe enough, it can trigger your incident response process as an actual incident, not just a line item.

FIPS 140-2 / 140-3 Is More Realistic Under CR26

The timing here is almost too convenient: FIPS 140-2 modules move to historical status on the NIST calendar right around when CR26 lands, and there's a real backlog on FIPS 140-3 certification. FedRAMP responded by tying the strength of the cryptography expectation to Certification Class rather than leaving it a flat, universal MUST. Further, the new rules specify that FIPS 140-2 / 140-3 validation only applies to the protection of federal customer data.

At Class C (roughly today's Moderate), validated modules move from a hard requirement to a strong "should" — meaning there has to be a compelling reason not to use one, but the door isn't fully closed if you have one. Class D holds the line at MUST. FedRAMP also now formally credits "update streams" of an already-validated module, which should ease some of the long-standing lag between a new software release and its official re-validation.

What CSPs Should Do Between Now and January 1, 2027

1. Get your agencies into the conversation now. Many will have expectations beyond FedRAMP's own baseline, such as a legacy-style risk write-up, specific views on your Quarterly Review cadence. Don't let them find out about CR26 from a surprised email.
2. Start mapping your SSP content into CPO + SDR. This isn't a find-and-replace exercise; it's a structural change, and it'll take real time.
3. Pressure-test your vulnerability detection and response capability against VDR/VER now. December 7, 2026 arrives well before most of the rest of CR26.
4. Start building toward machine-readable delivery. JSON for your CPO, SDR, and change notifications; a compliant Trust Center to replace USDA Connect (which is being phased out. This is an operational change to make now, not something to fold into next year's assessment).
5. Decide your long-term path. 20x isn't yet built for non cloud-native CSOs, but that's expected to change as FedRAMP pilots non cloud-native controls alongside the upcoming Class D pilot. Weigh that timeline against your own roadmap before committing either way.

Moving Forward with FedRAMP's Consolidated Rules for 2026

CR26 isn't a light refresh. The underlying NIST 800-53 controls haven't moved much, but nearly everything wrapped around them from the vocabulary, package format, vulnerability model, and the way you interact with your sponsoring agency has changed. The good news is that FedRAMP built in a genuine multi-year runway to get there, and a lot of what's required is things many mature CSPs are already doing in some form. The work now is making it visible, documented, and aligned with what CR26 actually asks for.

If you want to talk through what this means for your specific certification, path, and class, reach out. We'd be happy to help you build the transition plan now.