FedRAMP 20x & the 2026 Consolidated Rules — RMF Coach

Lesson 1 — FedRAMP's Job, and What "Certified" Means (~9 min)

FedRAMP runs the assessment once; the agency still makes the risk decision.

Explain what FedRAMP does (and doesn't) do, and why FedRAMP Certified is not an agency ATO.

A cloud company wants to sell its service to federal agencies. Each agency, by law, has to manage the security risk of any system it uses. So does every agency now run its own months-long security assessment of the same cloud service?

That's the problem FedRAMP solves. Instead of 50 agencies assessing the same product 50 times, FedRAMP runs one standardized assessment that agencies can reuse. "Do once, use many."

FedRAMP 20x is the modernized version of that program under the Consolidated Rules for 2026 (CR26). The mechanics are changing — new vocabulary, automation, faster paths — but the core idea is the same: produce one trustworthy, reusable body of evidence about a cloud service so agencies don't each start from zero.

Here's the distinction that trips up even experienced people. FedRAMP runs the standardized assessment and confirms a provider completed it — that's FedRAMP Certified (the term that replaces "FedRAMP Authorized"). But FedRAMP does not grant an ATO and does not accept risk.

The authorization — the actual decision to accept the risk of running the system — still belongs to the agency's Authorizing Official (AO), made under the NIST Risk Management Framework, using FedRAMP's materials.

So the clean sentence is: FedRAMP certifies, the agency authorizes. A FedRAMP Certified product is one an agency can reuse to reach its own authorization decision quickly — not a product that is automatically approved for everyone.

Why would an agency trust someone else's assessment? Because Congress told it to. The FedRAMP Authorization Act (2022) and OMB's implementing memo created a presumption of adequacy: an agency shall presume that a FedRAMP package's assessment and materials are adequate for its own authorization.

That presumption is the legal engine of "do once, use many." It lets the agency reuse the assessed package and focus its attention on the slice of controls it is responsible for, inheriting the rest from the FedRAMP-certified platform.

But it's rebuttable, not absolute. The agency still owns its FISMA responsibilities and can require additional controls where it documents a genuine, demonstrable need. The presumption speeds the agency's decision; it doesn't remove the agency's judgment.

FedRAMP 20x isn't a clean overnight switch. The Consolidated Rules for 2026 introduce 20x alongside a modernized version of the traditional process, now called FedRAMP Rev5. For a stretch of 2026–2027 both run in parallel, which is exactly why the vocabulary is confusing right now.

The rules launched publicly in mid-2026 and adoption is staged: certain pipelines open first, mandatory adoption follows. We'll walk the actual dates in Module 2.

The practical takeaway for now: when you read a FedRAMP statement, check which track it describes — 20x (the new, cloud-native, automation-first path) or Rev5 (the modernized traditional path). They share goals but differ in mechanics.

Lesson 2 — Reading a Certification: Type × Class × Path (~9 min)

A FedRAMP certification isn't one thing — it's a profile with three dials.

Read a certification profile as type × class × path and explain each dial.

"FedRAMP Certified" is a starting point, not a full answer. Under CR26, a certification is described by a profile — three dials set together:

Type — how it's certified: Rev5 (modernized traditional) or 20x (cloud-native, automation-first).

Class — how much the provider shares and commits to: A, B, C, or D (Lesson 3).

Path — how it enters: Program Certification (no agency sponsor) or Agency Certification (sponsored).

So a real certification reads like "a 20x, Class C, Program certification." Three dials, set together, describe what a provider actually holds — and what an agency can reuse.

The type dial is about how a provider proves and maintains its security.

Rev5 is the modernized traditional process — the recognizable assessment lineage, streamlined. It suits services that aren't cloud-native, and it's the route for the most demanding systems (Class D).

20x is the new cloud-native process. It's built on FedRAMP-Certified infrastructure, and instead of a point-in-time narrative document it leans on automation that persistently monitors and reports the security state — the Key Security Indicators you'll meet in Module 2. Because it assumes certified underlying infrastructure, 20x is not available to a provider running its own infrastructure, and 20x for the highest class (D) only arrives in early 2027.

Same destination — trustworthy, reusable assurance — reached two different ways.

The path dial is about how a provider enters the program.

Program Certification is the new path: a provider submits directly to FedRAMP with no agency sponsor. This is a real shift — historically you needed an agency willing to sponsor you. Program Certification is available for 20x Classes A, B, and C.

Agency Certification is the traditional sponsored path, where an agency partners with the provider. It remains the only path for Class D (the most demanding systems).

The no-sponsor option lowers the barrier to entry for mature providers — they can earn a certification and get listed without first landing a federal customer.

Lesson 3 — Certification Classes A–D (~10 min)

Classes look like Low/Moderate/High — but that shortcut hides the real definition.

Place the four classes, use the FIPS-199 crosswalk, and explain why a class is not a security rating.

Most people meet the classes through the impact levels they already know. The practical crosswalk:

Class B ≈ Low — common small-scale or light-use services, unlikely to be used agency-wide.

Class C ≈ Moderate — enterprise services used across an agency or providing important government services. This is the most common class.

Class D ≈ High — mission-critical; a failure could cripple agency operations or cause catastrophic harm.

Class A is the odd one: it has no FIPS 199 equivalent. It's a brand-new on-ramp for mature security programs entering the federal market with minimal information up front, expecting to transition to B/C/D after initial adoption. So Low/Moderate/High slide down to B/C/D, and A is new on top.

Here's the nuance that separates a sharp practitioner from a sloppy one. The corpus says it plainly: certification classes are "unrelated to the overall security of a cloud service offering."

A class is not a security rating. It's a threshold for how much information the provider shares and the ongoing reporting and maintenance commitments they take on — which in turn governs whether the package is adequate for an agency system with given security objectives.

So "Class C = Moderate" is a useful shortcut, not the official definition. Two things worth saying out loud:

1. Class A is not "Low." It's a new on-ramp with no FIPS 199 level; Low/Moderate/High are B/C/D.

2. Classes aren't a security score. A higher class means more information and stronger commitments, not a "more secure" product.

Even though a class isn't a security score, it still sets how many controls a provider must satisfy. CR26 establishes required Rev5 baseline control lists by class:

Class B — 155 controls

Class C — 322 controls

Class D — 409 controls

Those numbers sit right next to the familiar NIST SP 800-53B Low/Moderate/High baselines (156 / 323 / 410), reflecting the same impact tiers with minor FedRAMP adjustments. The point: a higher class means more controls and stronger ongoing commitments, which is why the package it produces can support an agency system with more demanding security objectives.

In 20x, the provider doesn't just claim those controls once — automation keeps proving them. That's the next module.

Lesson 1 — KSIs and Continuous Validation (~9 min)

20x trades a once-a-year document for evidence that proves itself every day.

Explain what KSIs are and how continuous, machine-validated evidence replaces the narrative SSP.

In the traditional model, a provider writes a long System Security Plan describing how each control is met. An assessor checks it at a point in time, and it's largely a snapshot — accurate the day it's signed, drifting after.

20x replaces that snapshot with Key Security Indicators (KSIs) — concise statements of a provider's security capabilities, each backed by automation that persistently monitors and enforces the desired security state and reports how the KSI is performing.

Instead of "here's a document that says we do this," 20x asks for "here's machine-checked evidence that we are still doing this, right now." The burden shifts from writing prose to standing up automation that continuously validates the security state.

The class dial from Module 1 shows up here as how hard each KSI must be proven. CR26 scales automated KSI verification and validation by class:

Class A — automated verification is optional.

Up through Class D — at least four automated methods per KSI are expected.

Classes also set expectations for historical KSI metrics in the Security Decision Record (rule SDR-CSX-KMT): optional for Class A; recommended for Class B (a summary of each metric over the past 30 days and up to the past year, where available); required for Class C, which adds all daily metric data — including persistent-validation status — up to the past year (where available). Class D must significantly exceed the lower classes, with specifics to be set during the 20x Phase 4 Pilot.

The pattern is consistent: a higher class isn't "more secure" by fiat — it means the provider shares more and proves more, more continuously. That's what lets the resulting package support an agency system with more demanding objectives.

Continuous validation only works if the evidence is machine-readable. That's why 20x leans on OSCAL — the Open Security Controls Assessment Language — so KSI evidence, control information, and assessment results are structured data, not just prose.

Structured evidence can be checked by tools automatically and repeatedly: the provider's automation reports KSI performance, the assessor's tooling validates it, and the agency's tooling can ingest it. The hand-off stops being a stack of documents and becomes a flow of verifiable data.

This is the deeper reason 20x is "cloud-native": it assumes the underlying platform is FedRAMP-Certified and that security state can be expressed and proven as data, continuously, rather than narrated once.

Lesson 2 — The Package, the Assessor, and the Agency Decision (~10 min)

The certification produces a reusable package; the agency turns it into an ATO.

Name the 20x certification artifacts and the assessor, and trace how a Certified package becomes an agency authorization.

All the assessment work lands in one reusable bundle: the Certification Package. It carries the assessed evidence about the cloud service — the control information, the KSI evidence, the assessor's results — in a form an agency can pick up and reuse.

Alongside it sits the Security Decision Record (SDR), the structured record of the security decisions and the rule information behind the certification. For Classes B, C, and D, the assessor's overall summary of assessment must be included in the Certification Package Overview (it's optional for Class A).

Think of the package as the product of the certification process — the concrete thing that makes "do once, use many" real. Everything before it exists to produce it; everything after it consumes it.

Independence is what makes the package trustworthy — the provider can't simply grade its own homework. An independent assessor validates the evidence and produces the assessment result that goes into the package.

The current term is "FedRAMP Recognized" independent assessor. The older label, 3PAO (Third-Party Assessment Organization), has been retired under the Authorization Act and the Consolidated Rules — you'll still hear it in the field, but the corpus uses "FedRAMP Recognized."

In 20x, the assessor's job tilts toward validating automated, machine-readable evidence rather than reading a narrative document — but the principle is unchanged: an independent party stands behind the result so an agency doesn't have to take the provider's word for it.

Now the pieces connect. The provider, with its FedRAMP Recognized assessor, produces a Certified package backed by KSIs and continuous evidence. That package is the reusable asset.

An agency that wants the service doesn't start a fresh assessment. By the presumption of adequacy, it presumes the package adequate, reuses it, and focuses on its own customer-responsible controls. Its Authorizing Official then issues the ATO under the NIST RMF — accepting the risk for that agency's use.

So the full sentence, end to end: FedRAMP certifies a reusable package; the agency reuses it and authorizes. The certification compresses the agency's work; it never replaces the agency's decision.

Watch it happen with one provider. Northwind Files, a cloud document service, wants to sell to agencies and pursues a 20x, Class C, Program certification.

Northwind's security lead, Mara Lindqvist, stands up the automation that proves Northwind's KSIs continuously and assembles the Certification Package — with the Security Decision Record inside. An independent FedRAMP Recognized assessor, Devin Cole — the role people used to call a 3PAO — validates the machine-readable evidence and adds the overall summary of assessment to the package.

Because Northwind took the Program path, it submits directly to FedRAMP with no agency sponsor, and gets listed once Certified.

Then an agency ISSO, Ray Whitfield, finds Northwind on the marketplace. He doesn't reassess from scratch: by the presumption of adequacy he reuses Northwind's package, focuses on his agency's customer-responsible controls, and his Authorizing Official issues the ATO. One certification, one reusable package, a fast agency decision. Your turn next.

Lesson 3 — The Transition Timeline (~8 min)

Two systems run at once on a published schedule — know where you are on it.

Place the key CR26 transition dates and explain how Rev5 and 20x coexist during the transition.

The Consolidated Rules launched publicly in mid-2026 and roll out on a published schedule. The milestones that matter most:

Jul 28, 2026 — FedRAMP Ready goes legacy; no new Ready submissions — pursue 20x Class A instead.

Aug 3, 2026 — the FedRAMP 20x Class A pipeline opens (applications begin).

Aug 31, 2026 — the 20x Class B and C pipelines open.

Jan 1, 2027 — mandatory adoption; over the following year all providers move to the Consolidated Rules to keep their certification.

Jun 11, 2027 — no new Rev5 certifications accepted.

These are FedRAMP's published dates and can shift — always confirm against the live timeline before acting. But the shape is fixed: 20x opens class by class through late 2026, and the program becomes mandatory at the start of 2027.

During the transition, both vocabularies are correct at the same time — and that's the source of most confusion.

A provider certified under the modernized Rev5 type still holds a valid certification; new providers may enter via 20x as the pipelines open. A provider on the legacy Rev5 lineage isn't suddenly non-compliant — there's a window, and new Rev5 certifications end Jun 11, 2027.

The practitioner's job is to say which world a statement lives in. "This service is FedRAMP Certified" should prompt: which type — Rev5 or 20x? Which class? Which path? The transition rewards precision and punishes the flattened "FedRAMP approved" shorthand.

Keep the legacy framing straight too: the older FIPS 199 Low/Moderate/High language still appears, and it maps to Classes B/C/D — show the bridge, don't pretend one replaced the other overnight.

Put it all together. A FedRAMP 20x certification is described by a profile — type × class × path. The provider proves its security continuously through KSIs backed by automation and machine-readable OSCAL evidence, validated by a FedRAMP Recognized independent assessor. The result is a reusable Certification Package.

FedRAMP certifies that package. It does not issue an ATO. An agency reuses the package under the presumption of adequacy, focuses on its own controls, and its Authorizing Official authorizes — issuing the ATO under the NIST RMF.

And it's all happening now, on a published schedule, with Rev5 and 20x side by side into 2027. That live, in-transition quality is exactly why it's worth learning precisely — and why this course refreshes from FedRAMP's canonical corpus whenever the rules move.

Lesson 1 — From Documents to Data (~8 min)

The 20x package is a linked set of machine-readable records, not a binder of narratives.

Explain the shift from narrative documents to schema-defined JSON, and how the package links together.

Under Rev 5, an authorization package is mostly prose: an SSP that narrates each control, assessment reports, POA&M spreadsheets. A human reads them; nothing else can.

FedRAMP 20x changes the format itself. The Consolidated Rules define a set of machine-readable documents, and FedRAMP publishes a JSON Schema for each one — the exact fields, which are required, and the allowed values. A submission either conforms to the schema or it doesn't; software can check it in milliseconds.

That's what makes continuous validation possible: when the package is data, currency and completeness can be verified automatically instead of during a months-long document review.

One honest caveat: FedRAMP labels these schemas a prototype — they are still changing, and FedRAMP says plainly not to build production compliance systems on them yet. The direction is settled; the field names are not. (This course tracks the schemas at a pinned revision and is refreshed when they change.)

The hub of the set is the Certification Package Overview (rule FRC-CSO-PKG): the top-level record describing the cloud service offering and its certification.

Every other document — the Security Decision Record, a Significant Change Notification, an incident report, a vulnerability report — carries a certificationPackageOverviewUri field: the full URI of that provider's overview. That one field turns a pile of files into a package: given any single record, you can find the offering it belongs to, and given the overview, everything else links back to it.

Compare that to today: an assessor cross-referencing a POA&M row against an SSP section by hand. In 20x the linkage is a field a machine can follow.

Open the Security Decision Record (SDR-CSO-FRR) and the fields are familiar.

For each NIST 800-53 control it records a controlImplementationStatus from a fixed vocabulary — Implemented, Partially Implemented, Not Implemented — plus the parameter values the provider selected and an implementation description. That's the same decision you make in Phase 1 of a simulation run, now as a machine-checkable field.

For each KSI it requires three separate statements: implementation (how the provider achieves it), validation (how the provider checks itself), and assessment (how the independent assessor verified it) — plus typed evidence: Log, Report, Screenshot, Configuration, Policy, Procedure, or Audit Record.

Read that triple again: provider implements → provider validates → independent assessor assesses. That's the role separation you practice every time you switch hats — the schema encodes it as three required fields.

Lesson 2 — The CR26 Document Set, Record by Record (~10 min)

Ten records cover the package, its changes, its vulnerabilities, and its incidents — in a vocabulary you can read.

Name each CR26 document, what it carries, and the vulnerability vocabulary (PAIN N-ratings, LEV/IRV, accepted vulnerabilities).

The draft set has ten document schemas. Grouped by job:

Package core — the Certification Package Overview (the hub) and the Security Decision Record (controls, parameters, KSIs, evidence).

Change — the Significant Change Notification: what's changing, why, and its plan.

Vulnerability lifecycle — the Vulnerability Detail Report, Accepted Vulnerability Info, and Historical Vulnerability Evaluation and Reporting Activity: every detected vulnerability, every risk acceptance, and the track record over time.

Incidents — the Incident Report in three stages: initial, ongoing, final (IEC-CSO-IIR / OIR / FIR).

Ongoing certification — the Ongoing Certification Report (CCM-OCR-AVL): the continuing story an agency can check.

Marketplace — Assessor Information and Advisor Information (MKT-IAS-WEB / MKT-CAS-WEB): the listing records behind the public marketplace.

If you've played a full simulation run, this list should feel familiar: it's the monitor phase, itemized.

In the simulation's monitor phase you route changes: minor ones through normal change management, significant ones into re-evaluation. The Significant Change Notification (SCN-CSO-INF) is that decision as data.

Its changeType field allows exactly two values — Adaptive or Transformative (per SCN-CSO-EVA) — and routine recurring changes are excluded entirely: no SCN required. The notification also carries the categorization explanation, reason, customer impact, a plan-and-timeline with milestones, the impacted KSIs or Rev5 controls to be re-verified, and the business/security impact analysis.

Notice what that last pair encodes: the SCN expects you to know which controls or KSIs the change touches — the Security Impact Analysis thinking you practice in change-board runs — and to commit to a dated plan for re-validating them.

The vulnerability records speak a compact language:

PAIN N-rating — the Potential Agency Impact N-rating, an integer N0–N5, estimating the likely impact on agency customers if the vulnerability is exploited (VER-EVA-EPA). N0 means exploitation is extremely unlikely to have any adverse effects on agencies. Ratings aren't static: a PAIN reduction event records the date a mitigation landed and the new rating, so the report shows impact going down over time.

LEV — is the vulnerability likely exploitable? (isLikelyExploitable, per VER-EVA-ELX.)

IRV — is it internet-reachable? (isInternetReachable, per VER-EVA-EIR.)

Each record also carries its detection (when, by what tool), an evaluation-completed date that starts the remediation clock (VER-TFR-MAV), an overdue flag that requires an explanation when true, and a final disposition: Fully Mitigated, Partially Mitigated, Remediated, or False Positive (omitted while the vulnerability is still open). FedRAMP keeps mitigated and remediated apart on purpose (VDR-CSO-RES): mitigation reduces the risk, even to negligible, but the flaw still exists; remediation removes it entirely.

Together LEV + IRV + the N-rating drive how fast a fix is due — the timeframe tables in the rules key on exactly these classifications. If you've triaged findings in a ConMon run, you've already made every one of these judgments; 20x just names them.

Two records close the set.

Accepted Vulnerability Info (VER-RPT-AVI) is a vulnerability the provider is choosing to live with — the schema requires the full vulnerability detail plus an acceptanceRationale. If you've hit the stale risk-acceptance situation in a monitor run, you know why that field is required: an acceptance without a current reason is just an unmanaged weakness with paperwork.

Historical Vulnerability Evaluation and Reporting Activity (VER-TFR-MRH) keeps the longitudinal record — how the provider has actually evaluated and reported over time, not just this quarter's snapshot.

The whole module in one sentence: the 20x package is a linked graph of schema-defined records — controls and KSIs in the SDR, changes in SCNs, weaknesses in the vulnerability trio, incidents in three-stage reports, all hanging off one Certification Package Overview — readable by machines continuously instead of by humans annually. The schemas are still a labeled prototype; the shape of the future package is already legible.