FedRAMP 20x: What CR26 Changes for Cloud Service Providers (CSPs)

Summary: FedRAMP 20x replaces narrative compliance documents with continuously verified automated evidence. CR26, the Consolidated Rules for 2026, governs both 20x and Rev5, and becomes mandatory on January 1, 2027. If you hold a Rev5 authorization, several obligations already apply to you. This article covers the renamed vocabulary, the new Certification Classes, what changes on Rev5, and every dated deadline through 2028.

If you already hold a FedRAMP authorization, the hardest part is behind you. The authorization, assessment, and documentation you spent years building do not disappear. What FedRAMP 20x changes is how the Federal Risk and Authorization Management Program (FedRAMP) evaluates security effectiveness and maintains trust in your environment over time.

That change is now written down in one place. On June 24, 2026, FedRAMP published the Consolidated Rules for 2026, or CR26, a single rulebook covering both the Rev5 and 20x certification paths. A meaningful share of what it changes lands on cloud service providers (CSPs), whether or not a provider pursues 20x at all.

DISCLAIMER: This article reflects FedRAMP’s CR26 and related public notices as understood as of July 14, 2026. It is an educational resource prepared by Aprio, not official FedRAMP guidance, and not legal, regulatory, or compliance advice. Confirm all date sensitive data at fedramp.gov before relying on it.

What is FedRAMP 20x?

FedRAMP 20x is FedRAMP’s modernized certification model. It replaces long, narrative security documents with automated and continuously verified evidence, organized around specific, testable outcomes called Key Security Indicators (KSIs). FedRAMP piloted the model through 2025 and formalized it on June 24, 2026 with CR26.

Rev5 asked what a provider would do, answered in writing. 20x asks what is true about the provider’s system right now, answered from the live environment. Certification follows from the proof rather than the paperwork. A KSI states the security outcome and stops there. How you implement, monitor, evidence, and manage it over time is yours to design.

What is a Key Security Indicator?

A Key Security Indicator, or KSI, is a specific, testable security outcome that a provider proves with evidence from the live system rather than describing in a narrative. Each KSI carries a three-part code built for machine readability. In KSI-IAM-AAM, KSI identifies the item type, IAM identifies the family, Identity and Access Management, and AAM identifies the specific indicator, Automating Account Management.

CR26 defines roughly 50 KSIs, about 250 rules, and more than 350 three-letter codes across the program. Treat those counts as approximate, since CR26 is still being adjusted.

What is CR26 and when does it become mandatory?

CR26, the Consolidated Rules for 2026, is the single rulebook governing FedRAMP’s modernization effort. It covers the Rev5 and 20x certification paths at once and sets the terms under which a provider may move from one to the other. FedRAMP published it on June 24, 2026, and it becomes mandatory for all stakeholders on January 1, 2027.

• CR26 defines the KSIs and the program rules in the same document: A meaningful share of what changes for a Rev5 provider comes from the program rules directly, not from adopting KSIs.
• CR26 is not a reauthorization event: Your Rev5 authorization stays valid and keeps its normal annual assessment timeline. Your Marketplace listing, authorization boundary, and agency acceptance all carry over automatically in the updated FedRAMP Marketplace.

Rev5 is not retired, though it does have a horizon. FedRAMP stops accepting new Rev5 applications on June 11, 2027, and Rev5 remains available on an ongoing basis through at least December 31, 2028.

What FedRAMP vocabulary has changed under CR26?

Much of the early confusion about 20x is vocabulary rather than substance. Several terms that have anchored FedRAMP conversations for years were renamed on June 24, 2026.

One distinction is worth getting right before the rest: FedRAMP certifies, and an agency authorizes. Historical use of ‘authorization’ caused confusion, since only agencies can authorize a cloud service offering. Under CR26 those are two separate gates issued by two different parties, a return to the structure of the NIST Risk Management Framework.

Table 1: New vocabulary under CR26

None of these renames change your cloud service offering architecturally, but they do change your language. Update your Trust Center, sales materials, and contracts to match.

What are the FedRAMP Certification Classes and how do they map to Low, Moderate, and High?

CR26 replaces the Low, Moderate, and High impact levels with Certification Classes. The mapping is direct:

• Low becomes Class B;
• Moderate becomes Class C;
• High becomes Class D; and
• Class A is new. It takes the place of FedRAMP Ready, at a lower and more achievable bar than FedRAMP Ready imposed.

Most of the Marketplace holds a Moderate authorization, now Class C.

Class matters beyond the label, because CR26 ties obligations to it. Incident reporting windows are set by two things: the incident’s severity rating and your Certification Class. Class D is tightest, Class C sits in the middle, and Classes A and B are the most lenient. Class D providers also face the fullest machine-readable authorization data requirements.

The pipelines opened on a staggered schedule: Class A on August 3, 2026, and Classes B and C on August 31, 2026, the realistic starting point for most Moderate providers.

What changes even if you stay on Rev5?

A meaningful share of CR26 applies to you today, with no decision about 20x required and no path change involved. Some of it carries risk to the authorization itself if missed.

Two obligations are already being enforced. The FedRAMP Security Inbox (FSI) has been mandatory for every Rev5 provider listed in the Marketplace since January 5, 2026. It requires a dedicated, monitored email address, meeting specific authentication standards, routed to a senior security official who can respond on the organization’s behalf. Public notification of noncompliance began March 1, 2026, full Marketplace removal began May 1, 2026, and removal plus a three-month certification ban began July 1, 2026.

A Secure Configuration Guide has been mandatory for all Rev5 cloud services since March 1, 2026, covering Certified, In Process, and Ready listings. It supplements your Customer Responsibility Matrix rather than replacing it, and FedRAMP provides no template.

Vulnerability management and continuous monitoring

Rev5 vulnerability management has run on the same rhythm for years: scan once a month, log what you find, and carry it onto a plan of action and milestones (POA&M). NTC-0014 replaces that with persistent, risk-based vulnerability management evaluated against actual exposure and exploitability. Compliance becomes mandatory on December 7, 2026, with a grace period for correction through March 7, 2027. After that date, a noncompliant certification can be revoked.

Severity alone no longer drives remediation. CR26 weighs actual exposure, reachability, exploitability, and potential agency impact, so two vulnerabilities with the same CVSS score can land differently. Anything on CISA’s Known Exploited Vulnerabilities catalog must be remediated by CISA’s own due dates regardless of mitigation status.

Continuous Monitoring (ConMon) changes as well. If your service has more than one agency customer, you are now expected to share ConMon data with all of them, not only your original authorizing agency. That means one shared reporting cycle covering every agency at once, shifting under CR26 toward a quarterly cadence.

Incident reporting

Reporting timeframes are now tiered by Certification Class, and the former Potential Adverse Impact rating is renamed Potential Agency Impact N-rating, or PAIN, on a five-point scale from N1 to N5. For the most severe rating on a Class D service, the initial report window is as short as 15 minutes.

For a Class C service, the clock reads: one hour for an initial report at N3 and above, with updates every six hours and a final report within six hours of recovery; 24 hours at N2, with updates every 24 hours; and one business day at N1.

Two further changes now belong to your runbook. Providers must name the agencies likely affected by an incident, and the former requirement to report agency and customer incidents directly to CISA has been removed. FedRAMP has not published a separate deadline for this notice, NTC-0012; it is expected to take effect under CR26’s January 1, 2027 mandatory date.

Documentation and the certification package

The Rev5 documentation stack is being replaced. The System Security Plan and its appendices, the Security Assessment Plan, and the Security Assessment Report consolidate into two persistently maintained documents: the Certification Package Overview (CPO) and the Security Decision Record (SDR). The POA&M is retired, replaced by separate vulnerability tracking and reporting. Both new documents must exist in human-readable and machine-readable JSON form, and FedRAMP supplies a schema rather than a template.

Separately, NTC-0013 rebuilds the Rev5 baseline without requiring KSIs. Your control baseline does not change. You are still assessed against the same NIST SP 800-53 controls at your assigned level. What changes is who is setting the parameters. Where FedRAMP once assigned organization-defined parameter values, providers now set their own and justify them against mission needs, business requirements, applicable laws and regulations, or industry standards.

The NTC-0013 baseline rebuild applies to your first independent assessment that finishes after January 1, 2027. The CPO and SDR transition apply to assessments that start after that date. For an assessment spanning the cutoff, those two rules can point in different directions.

What does an Independent Assessor do differently under CR26?

Your assessor’s role has not changed. It is still an independent organization engaged to evaluate your cloud service and give your agency authorizing official a recommendation to act on. What changed is the method, formalized under CR26 as Independent Verification and Validation (IV&V), and it applies to Rev5 assessments and 20x alike.

IV&V asks two separate questions:

• Verification: did you implement what you documented?
• Validation: does that implementation produce the intended result, tested against your live, running system?

Depth and breadth both increases. Depth, because a static screenshot showing a setting was configured once is no longer sufficient proof on its own. Your assessor will ask to observe controls operating live, meaning a real-time walkthrough of configuration logic and the automated check firing. Breadth, because CR26 expects every applicable FedRAMP rule to be assessed, not only the NIST 800-53 controls you are used to. Applicable is the operative word here. FedRAMP’s text is explicit that if a rule does not apply to you, the information is not required.

The line on assessor independence is also narrower than it has ever been. Your assessor can walk you through what a rule or KSI requires, flag unclear evidence, and discuss better ways to test something. What an assessor cannot do is hand you an implementation and promise it will pass. That is why looping your assessor in early is worth doing. IV&V takes effect for assessments that start after January 1, 2027.

What are the FedRAMP 20x and CR26 deadlines?

Several pages ranking on this topic still describe Rev5 as retiring in 2027. Under CR26 that is not what the dates say. One caution before you copy anything into a project plan: FedRAMP issued multiple versioned corrections to CR26 within weeks of release, tracked in a dedicated changelog. Confirm date-sensitive items at fedramp.gov before acting on them, particularly close to an assessment.

How should you decide whether to convert now or later?

The strongest predictor of transition effort is automation maturity: the degree to which your controls are continuously enforced, continuously validated, and capable of producing evidence as a byproduct of normal operations. Common indicators include infrastructure as code, centralized identity with automated just-in-time provisioning, policy as code, structured centralized logging, continuously validated configurations, and automated security testing.

The following questions are worth working through with your team, your agency, and your assessor:

1. How much of your security posture is already automated and continuously verifiable?

Identity is the biggest single tell. Services using an external identity provider with enforced multifactor authentication and automated provisioning start much closer to 20x than those handling authentication inside the application.

2. When is your next independent assessment?

Do not treat “before or after 2027” as one test. Compare your actual start and finish dates against each rule separately.

3. Can you support Rev5 and a 20x build at the same time?

Moving early means running two tracks for a period, which existing teams cannot simply absorb alongside their current work.

4. Is waiting actually a strategy?

It can be the right call, but it is not open-ended. Rev5 remains available through December 31, 2028, so every provider works inside a finite window.

5. Is a specific agency asking for 20x or does 20x serve your broader federal growth strategy?

A transition that looks marginal for one agency relationship can look different through the lens of future market access.

Whether your application was designed cloud native or lifted and shifted onto compliant infrastructure after the fact. A cloud native build, with containers or serverless, identity delegated to a managed provider, infrastructure as code, and structured logging shipped to a central store, already produces a large share of what 20x asks for. A lift and shift application on the same authorized hosting does not. The infrastructure underneath is compliant; the application was never designed to produce this kind of evidence.

A common market perception holds that 20x is cheaper than Rev5 because it trades a documentation stack for automation. While that may be true for a cloud native service, where the remaining work is largely configuration and wiring, it does not hold for a dated lift and shift application, where transition can mean re-architecture work more extensive than the documentation burden it replaces. 20x relocates cost more than it removes it, from documentation effort to engineering effort.

Final thoughts

Rev5 led with compliance and assumed security followed. 20x leads with security and lets compliance follow from the proof. Your documentation time should fall, while your architecture, development, and technical security work will likely rise.

Three things are worth doing this quarter, whichever you decide about 20x. Confirm your FedRAMP Security Inbox is live and monitored. Ask your assessor whether your next assessment starts and finishes before or after January 1, 2027, since those two tests trigger different requirements. And get an honest read on your automation maturity before you budget anything.

Aprio’s full transition guide for CSPs covers all of this in full, including minimum assessment scope, significant change notification, and the assessment mechanics chapter by chapter. Download the guide today.

 

CONFIRM AGAINST CURRENT FEDRAMP GUIDANCE: FedRAMP issued multiple versioned corrections to CR26 within the first weeks after release, tracked in a dedicated CR26 changelog. Confirm specifics at fedramp.gov/2026, fedramp.gov/2026/changelog, and github.com/FedRAMP/ rules before acting on any date sensitive item, particularly close to an assessment.