The FedRAMP Consolidated Rules Explorer: Every 2026 Rule, Scoped to You

The 2026 FedRAMP Consolidated Rules (CR26) retire the vocabulary most teams built their programs around and replace it with 249 requirements spread across 17 rulesets, four service classes, two certification types, and two paths. That's a lot of surface area to read correctly — and almost none of it applies to everyone. The Consolidated Rules Explorer collapses all of it into the only question that matters: what is mandatory, recommended, or optional for you, with the exact rule text, deadlines, and NIST control mappings one click away.

This post is a full tour of what the Explorer does, where its data comes from, and how to use it to scope your obligations in a couple of clicks. You can open it now at boundera.io/consolidated-rules.

Key takeaways

• The 2026 Consolidated Rules (CR26) are 249 requirements across 17 rulesets, effective for 20x cloud service providers on July 4, 2026 and intended to run through the end of 2028.
• CR26 replaces the old Low / Moderate / High impact levels with four certification classes, A through D. The same requirement can be a MUST at one class and not apply at another.
• Set four filters — party, certification type (20x or Rev5), certification path (Program or Agency), and service class (A–D) — and the Explorer returns your in-scope requirements with a live MUST / SHOULD / MAY / MUST NOT count.
• For a Class B cloud service provider on the 20x Program path, 157 of the 249 requirements are in scope: 90 MUST, 41 SHOULD, 17 MAY, and 9 MUST NOT / SHOULD NOT.
• Every requirement carries its verbatim rule text, its deadline, and its NIST SP 800-53 control mappings — one click away.
• Data is read directly from the federal machine-readable source of truth, the FedRAMP/rules repository, so the Explorer reflects the current rules rather than a stale copy. Export any scoped view to CSV or JSON.

What are the 2026 FedRAMP Consolidated Rules?

The Consolidated Rules (often shortened to CR26) are FedRAMP's 2026 rewrite of its requirements into a single, machine-readable rulebook. Instead of prose spread across templates, memos, and baselines, each obligation is a discrete requirement with a stable identifier, a force level (MUST, SHOULD, MAY, or MUST NOT), an applicability by service class, and — where relevant — a deadline and NIST control mapping.

Two structural changes matter most. First, the familiar Low, Moderate, and High impact levels give way to four certification classes, A through D, that run from a mature commercial service making its first move into the federal market (Class A) to a system handling mission-critical federal information (Class D). We break the classes down in FedRAMP 20x Class A, B, C, and D Explained. Second, the rules are published as structured data, so tools can read them directly rather than paraphrasing a PDF.

The Explorer is a reader for exactly that structured data — a way to ask: given who I am and what I'm pursuing, what do these 249 requirements actually require of me?

The problem: the 2026 rules are a matrix, not a checklist

Under the old model you could point at Low, Moderate, or High and pull a baseline. CR26 doesn't work that way. A single requirement might be a MUST for a Class D offering, a SHOULD at Class C, and simply not apply at Class A. Layer in whether you're a provider or an assessor, whether you're on the Program or Agency path, and whether you're pursuing 20x or Rev5 (a choice we compare in FedRAMP 20x vs Rev5), and the question of what you actually have to do stops having a single printed answer.

Reading the rules front to back tells you everything every party could ever owe. It doesn't tell you your obligations. That gap — between the full corpus and your scope — is exactly what the Explorer closes. If you're still deciding whether federal authorization applies to you at all, start with Do You Actually Need FedRAMP? and come back once you know you're in.

Scope the rules to your situation

The Explorer is driven by four selectors. Set them to describe yourself, and the requirement set recomputes instantly.

Pick a cloud service provider working toward a 20x certification on the Program path with a Class B offering, and the tool tells you that 157 of the 249 requirements are in scope — and breaks that down immediately. Change any selector and the set recomputes: an assessor sees the requirements they must verify; an agency sees its side of the relationship; a Class D provider sees a longer, stricter list than a Class A one.

Mandatory, recommended, optional, prohibited — at a glance

For any scope, the Explorer shows a live tally by force. Here is the breakdown for that same Class B, 20x, Program cloud service provider:

Two things are easy to miss here. The first is the prohibited column: CR26 doesn't only tell you what to do, it tells you what you must not do. For example, a provider must not apply for more than one program certification type (FRC-CSO-POP), must not have a third party apply on its behalf (FRC-APP-NTP), must not include sensitive information in public continuous-monitoring reports (CCM-OCR-LSI), and must not disclose vulnerabilities irresponsibly (VER-RPT-NID). Those are as binding as any MUST, and easy to overlook if you're only reading for to-dos.

The second is that these numbers move the instant you change a filter. Drop from Class B to Class A and much of the matrix falls away — Class A carries the lightest initial set. Move up to Class D and the mandatory count climbs. You are always looking at your obligations, not a generic baseline.

The same rule, a different force by class

The most useful thing the Explorer makes visible is how a single requirement tightens as the class increases. It shows the force for your selected class and dims the values for the others, so the escalation is right there in the row:

Read the top row left to right: using FIPS-validated cryptographic modules is optional for a Class A or B service, expected at Class C, and mandatory at Class D. A dash in the Class A column — which appears on many rows — means the requirement simply doesn't apply at that class, which is why Class A providers see so much of the matrix drop away. If you're planning to certify at a higher class later, this view is the difference between a 'nice to have' today and a hard requirement at your target class, visible before you commit. (The automated-verification rows tie directly to Key Security Indicators; see What Are FedRAMP 20x KSIs?.)

The 17 rulesets, grouped by lifecycle stage

The requirements are organized into rulesets — families like Minimum Assessment Scope or Vulnerability Detection and Response — each with a three-letter code that prefixes its requirement IDs. The Explorer groups the rulesets a provider works through into five lifecycle stages, so you can read them in roughly the order you'll act on them:

A sixth grouping, Agency use, covers the agency side of the relationship and appears when you set the party filter to a federal agency. One honest note: the lifecycle stages are Boundera's navigational grouping to make the corpus easier to move through. The ruleset codes, force values, statements, applicability, and dates are read verbatim from the federal source — we don't editorialize those. The vulnerability rulesets (VDR and VER) are where the old POA&M workflow gives way to persistent detection and response; we cover that shift in VDR vs POA&M, and the monitoring side in FedRAMP Continuous Monitoring Automation.

Every rule, with text, deadlines, and control mappings

Scoping is only half the job; you also have to act on each requirement. Every row in the Explorer opens to the exact, verbatim rule statement from the federal source, the deadline that applies to it, and its NIST SP 800-53 control mappings. The deadlines are not uniform — different rulesets come due on different dates:

Because the deadline and the control mapping travel with each requirement, you can go from whether a requirement is in scope to what it says, when it's due, and which NIST controls it satisfies without leaving the row. The NIST mappings are what let a Rev5-style control narrative and a 20x requirement line up against the same evidence — the connective tissue we get into in OSCAL for FedRAMP.

Always current, because it reads the source of truth

The Explorer doesn't work from a snapshot someone pasted into a CMS. It reads from FedRAMP/rules — the structured, machine-readable JSON that FedRAMP publishes as the authoritative version of the Consolidated Rules — at version 2026.07.01.01, published July 1, 2026. FedRAMP has said CR26 is intended to be the operating ruleset through the end of 2028, and as it's revised, the Explorer reflects the current text rather than a stale copy. For how the 2026 rollout unfolds over time, see the FedRAMP 20x Roadmap.

Reading from the source has a quiet benefit: the force values, IDs, and dates you see in the Explorer are the same ones a machine-readable evaluation would use, so there's no drift between what you read and what your tooling checks.

Export to CSV or JSON

Any scoped view exports in one click. Take CSV into a spreadsheet or a POA&M-style tracker to assign owners and due dates; take JSON into your own tooling to drive a checklist, a dashboard, or an evidence pipeline. The export carries your scope, so your engineers get your obligations — not the full 249-row corpus they'd have to filter themselves. Because each row keeps its requirement ID, the export is a natural starting point for a machine-readable readiness tracker rather than a static spreadsheet.

Who it's for

The party filter changes the entire question, so the Explorer serves several audiences from one dataset:

• Cloud service providers use it to see exactly what a target class demands before committing to it — and to compare the jump from, say, Class B to Class C before signing up for the stricter tier.
• Independent assessors use it to confirm which requirements are in force for the offering in front of them, so an assessment covers what CR26 actually requires and nothing it doesn't.
• Advisors use it to scope engagements without re-deriving the matrix by hand for every client.
• Federal agencies use it to see their side of the relationship — the Agency use obligations that come with consuming an authorized service.
• Anyone can switch the party filter to 'any party' to read the whole corpus when they need the complete picture.

How the Explorer fits your authorization workflow

The Explorer answers what applies to me; it's the front door, not the whole house. Once you know your in-scope requirements, the work is turning that list into boundary decisions, evidence, and continuous validation. That's where the rest of a 20x program comes in — Key Security Indicators and their evidence, vulnerability detection and response, and the continuous-monitoring cadence that keeps an authorization live. If you're evaluating how much of that a platform should automate, FedRAMP Compliance Tools in 2026 is a good companion read, and engineering readiness for FedRAMP 20x covers what your team needs in place first.

Try it

Open the Consolidated Rules Explorer, set the four filters to describe your situation, and read your obligations directly. When you're ready to turn that scoped list into an execution plan — control mapping, evidence collection, and continuous monitoring — that's the part Boundera's platform handles.

Sources

• FedRAMP Consolidated Rules for 2026 — fedramp.gov
• Using the FedRAMP Consolidated Rules — fedramp.gov
• FedRAMP Certification Classes — fedramp.gov
• FedRAMP/rules (machine-readable source of truth) — github.com/FedRAMP/rules

Last updated: July 2026. Written by the Boundera team.