FedRAMP moved the risk to agencies. Here is where it landed.

In four years FedRAMP has gone from a program that read every package, ran the monthly monitoring calls, and held the evidence, to a program that writes rules, certifies providers itself, and steps back. We went through the law, OMB Memorandum M-24-15, all sixteen FedRAMP notices from 2026, the Consolidated Rules for 2026, and the Marketplace data as of October 17, 2026, and asked one question about each change: did it move risk toward the agency or away from it?

The answer is lopsided. Of the sixteen changes we tracked, twelve move risk toward the agency authorizing official, one is a wash, one is neutral, and two move it away. The two that help are real, and we give them and their side effects their own section. But an agency CISO reading the new rules should understand that almost every comfort the old program provided (a sponsoring agency that read the package first, an impact-level label, a Security Assessment Report, a Customer Responsibility Matrix, a monthly POA&M, change approval, a FedRAMP-held repository, and a provider that filed the CISA report) is gone or going, while the agency's legal duty under FISMA has not moved an inch.

Key insights

• The law never moved the risk; the program removed the padding. The FedRAMP Authorization Act's presumption of adequacy (December 2022) says in the same breath that it does not change an agency's FISMA responsibility. The 2026 rules now make it an agency-head decision, with notice to FedRAMP, to ask a provider for anything more.
• "FedRAMP Certified" is an assurance label, not a security label. FedRAMP says so with an exclamation point, and says agencies may use a certification package "at any security category they deem appropriate following the Risk Management Framework." The Moderate and High labels agencies planned around are now Classes B, C, and D, and FedRAMP says the classes are not one-for-one replacements.
• The agency is now the one that calls CISA. Under the June 2026 incident rules, which took effect July 4, 2026 for new 20x certifications and reach everyone else on January 1, 2027, providers no longer report agency-related incidents to CISA. The affected agency does, on a clock that starts only when the provider's notice arrives. For Class B services that notice moved from one hour to six.
• The CRM is gone and nothing has replaced it for agencies. The Secure Configuration Guide covers administrator settings and maps to one control, CM-7. FedRAMP's own notice says it "will separately work with agencies to create standardized baselines that clearly separate the responsibilities." No date, no RFC.
• Every 20x service runs on a Rev5 platform. Zero of 22 infrastructure offerings are on 20x. Four hundred of the 534 certified offerings sit on five Rev5 hyperscaler listings. FedRAMP calls Rev5 "legacy" and "being actively replaced," and has no rule for what happens to a SaaS when its platform's certification type changes.
• The rules that cut risk are the vulnerability rules. From December 7, 2026, FedRAMP calls monthly scanning "insufficient," every finding carries a structured impact rating, and a provider that does not comply loses its certification after March 7, 2027. That is a higher bar than Rev5 ever set.

The scorecard

Each row is one change. "Toward agency" means the agency authorizing official carries more residual risk, more work, or less visibility than before. "Away" means less.

The law put the risk on agencies in 2022. The program spent 2025 and 2026 removing the padding.

The FY2023 National Defense Authorization Act wrote the presumption of adequacy into 44 U.S.C. 3613(e): a FedRAMP package "shall be presumed adequate for use in an agency authorization to operate." The next paragraph says the presumption does not change the agency's responsibility under FISMA, and preserves the agency head's authority to find "a demonstrable need for additional security requirements beyond the security requirements included in a FedRAMP authorization for a particular control implementation." That is the whole story in two sentences. The agency keeps the liability. The agency may ask for more. Everything since has made asking harder.

OMB Memorandum M-24-15 (July 25, 2024) said agencies "must presume" the package is adequate, that an agency which overcomes the presumption must document why and tell the FedRAMP PMO, and that the FedRAMP Director would decide whether more work was warranted. It also created the "program authorization," signed by the FedRAMP Director "for which an agency sponsor has not been identified." That was the end of the Joint Authorization Board model, and the first path to a government-wide authorization with no agency authorizing official reading the package.

The Consolidated Rules for 2026 turned the memo's paperwork into prohibitions. Rule AGU-AGC-NAR: agencies "MUST NOT require additional information or materials from FedRAMP Certified cloud service offerings" beyond FedRAMP's rules, unless the head of the agency or a delegate "determines there is a demonstrable need and notifies FedRAMP." Rule AGU-AGC-TPP: agencies "MUST NOT require cloud service offerings to obtain or maintain a specific FedRAMP Certification Type" without the same finding. FedRAMP's agency responsibilities page adds that if a contract term stops a provider from following FedRAMP rules, "FedRAMP would be forced to revoke the cloud service offering's FedRAMP Certification" and "refer the issue to the agency Inspector General for review."

Read those together. The ISSO who used to email a vendor for an extra scan, an overlay attestation, or a monthly POA&M now needs an agency-head determination and a notice to FedRAMP. The agency's leverage over the provider shrank. Its liability did not.

FedRAMP is candid about this. Its 2026 agency page says FedRAMP "is not an oversight or enforcement body," but that "Oversight and enforcement is still performed!" by OMB, Inspectors General, and GAO. The Inspector General community's March 2026 cloud best practices document, which FedRAMP cites, tells auditors an agency "can never outsource its responsibility for governance." That document does not mention Key Security Indicators or the presumption of adequacy. It still describes 20x as a GSA pilot. Our reading: an authorizing official can expect to be audited against Rev5-era expectations for a 20x package.

"Certified" tells you how closely someone looked, not how safe the service is

Notice NTC-0004 (February 25, 2026) renamed every authorization a "FedRAMP Certification" and replaced the impact levels with Classes. Class B covers the old Li-SaaS and Low baselines, Class C covers Moderate, Class D covers High, and Class A is new. The notice says many commenters "reinforced the critical misconception that a FedRAMP assessment baseline labeled with a FIPS 199 security category was a de facto acceptance of risk for agency use at that security category," that "a FedRAMP Certification is not a guarantee that a cloud service has met all requirements to be appropriate for use by an agency at a given FIPS 199 security category," that FedRAMP "does not have the authority to make this determination on behalf of an agency authorizing official," and that agencies may use a certification package "at any security category they deem appropriate following the Risk Management Framework."

The agency Classes page puts it with an exclamation point: "Certification Classes indicate the level of assurance provided, not the level of security or protection provided!" Its adequacy table says Class B is adequate for "most Low impact agency information systems" and, with compensating controls, "some Moderate or High." That table is the closest thing to a Class-to-impact-level map FedRAMP offers, and it is advisory.

Under Rev5, the sponsoring agency's authorizing official read the whole package before anyone else could reuse it. Under the Program path, which is how nearly every 20x certification has been issued, the reviewer is FedRAMP, a team of 17 federal employees and 15 contractors. FedRAMP's own lesson from the 20x pilot was that "a fully open pilot with minimal guardrails produces a very wide range of implementation quality and clarity."

Class A deserves its own paragraph. Notice NTC-0007 (March 3, 2026) describes it as available only from the FedRAMP PMO, meant for "negligible or low risk pilot use," built on SOC 2 Type II as the starting framework, and "transitory," and says FedRAMP "is not providing a bridge from external frameworks to other classes of FedRAMP Certification." In the rules it needs seven KSIs, an independent assessment is optional (rule FRC-APP-FIA says "MAY" for Class A and "MUST" for B through D), and a SOC 2 Type II, GovRAMP, or FedRAMP Rev5 assessment (including FedRAMP Ready) from the past twelve months is the entry ticket. The agency-side brake is a SHOULD NOT: do not authorize a Class A offering for more than twelve months unless it is actively seeking a higher class. In our view Class A is the old FedRAMP Ready status, which FedRAMP retired on July 28, 2026 while pointing providers to Class A instead, rebadged as a form of "FedRAMP Certified." It appears on the Marketplace with the same word as a Class D service. The extra work is on the agency: compensating controls, a twelve-month clock, and an explanation to the auditor.

The evidence changed shape, and the inheritance map went missing

Under Rev5 a 3PAO wrote a Security Assessment Plan, tested the baseline, wrote a Security Assessment Report, and recommended for or against authorization. The 2026 rules say plainly that "FedRAMP does not require a separate Security Assessment Plan or Security Assessment Report for 20x or Rev5." The assessor, now a "FedRAMP Recognized independent assessment service," must verify measures "at a technical level, such as reviewing underlying code," and its summaries must appear in the provider's package "without inappropriate modification." The pilot-era standard said assessors "MUST NOT deliver an overall recommendation on whether or not the cloud service offering meets the requirements for FedRAMP authorization." We score this a wash for Classes C and D: agencies lose the test-case-level SAR and the independent recommendation, and gain a mandated technical review of code and automation. For Class A, where no assessor is required at all, it is a loss.

The control baseline is the bigger problem. The Phase One draft of 20x proposed 51 KSIs. The Phase Two pilot had 56 for Low and 61 for Moderate. The Consolidated Rules have 46, in ten themes, each tagged with "Related SP 800-53 Controls." There is no crosswalk showing which controls in a baseline those tags cover, and a 20x package contains no per-control implementation or inheritance statements. FedRAMP's Phase Two lesson, in its own words: requirements "presented as Key Security Indicators were confusing." Pete Waterman told the community, "I don't think we'll ever drive back towards 'fill out this spreadsheet exactly like this.'"

That is fine for a provider. It is a problem for an agency, because nothing changed on the agency side. NIST SP 800-37 still requires an agency system security plan that records every 800-53 control as implemented, inherited, or hybrid. The agency's GRC tool, whatever it is, is built around that. FedRAMP's own agency responsibilities page says the agency SSP "should only contain information that the agency is responsible for," and its Initial Authorization page warns, "Do not begin by copying a provider's security controls!" FedRAMP's agency SSP page lays out a per-control documentation table. What it does not do, and what no FedRAMP, NIST, or 3PAO document we could find does, is tell an ISSO how to derive an inheritance statement for AC-2 or SC-13 from 46 KSIs, and rule AGU-AGC-NAR discourages asking the provider. The mapping work, and every disagreement between agencies about how to do it, lands on agency staff.

Then there is the Customer Responsibility Matrix. Notice NTC-0013 (June 16, 2026) says the Secure Configuration Guide "replaces the Control Implementation Summary / Customer Responsibility Matrix and consolidates information about the customer responsibilities in a way that allows the cloud service provider flexibility to ensure the service is safely adopted without following a control template," and that "FedRAMP will separately work with agencies to create standardized baselines that clearly separate the responsibilities so they can engage in the RMF process correctly." The replacement, rule SCG-CSO-RSC, requires instructions for securely operating "top-level administrative accounts" and explanations of the settings those accounts control. It maps to one control, CM-7. Nothing in the rule requires the provider to say which controls the customer must implement. The guide tells an administrator which switches to set. It does not tell the authorizing official which controls the agency now owns. The sentence "will separately work with agencies" is FedRAMP's acknowledgement that the CRM's job for agencies has not yet been done. We found no date, RFC, or deliverable for that work.

Continuous monitoring followed the same arc. Monthly scans and POA&M updates, an annual assessment, and advance approval of significant changes are replaced by provider-published data: machine resources re-validated every seven days for Class B and every three for Class C, a human-readable vulnerability report at least monthly, and an Ongoing Certification Report every quarter. On the agency side, rule CCM-AGM-ROR says agencies "MUST review each Ongoing Certification Report," and rule AGU-AGC-GRC requires agency tooling that can produce and ingest OSCAL and JSON. FedRAMP states it "does not endorse a specific tool or fund agency GRC tooling." Significant change moved from approval to notification. "Adaptive" changes, which FedRAMP's examples say include "updates to operating systems, containers, virtual machines, software or libraries with known breaking changes" and swapping a cryptographic module for an equivalent one, are notified within ten business days after they are complete. Routine changes are not notified at all. FedRAMP's advice to agencies: "Monitor the provider's change process instead of trying to approve every individual change."

FedRAMP stepped out of the middle

The old FedRAMP repository is going away. Providers now run "FedRAMP-compatible trust centers," and FedRAMP's agency page says "FedRAMP will no longer act as an intermediary or dictate how providers protect and distribute commercial data." The same page says "a provider may deny an access request if it does not want to do business with an agency." The provider only has to tell FedRAMP within five business days. Granting access on request is a SHOULD.

When something goes wrong, FedRAMP tells the agency its "first step should be to escalate the issue within the Cloud Service Provider directly," then to go to the Contracting Officer, because non-compliance "may be a breach of contract," then to an inbox at FedRAMP, which "will follow up with the provider and, if necessary, request corrective action." FedRAMP's responsibilities page states that FedRAMP "does not enter into any legal agreements or contracts with cloud service providers, and has no legal enforcement authority or responsibility," that it "can request corrective action by a cloud service provider or independent assessor and companies may choose to take action in such cases, but FedRAMP cannot force them to do so," and that after revocation "no other punitive action is available." FedRAMP acknowledges that after certification a provider's interactions with the PMO are limited and that agencies "will likely be the first to know if a provider is failing to meet FedRAMP's standards."

There is something to like here. An agency that found a problem under Rev5 often waited for FedRAMP to act. Now it can go straight to the provider and the contract. But the direct relationship cuts both ways: a small agency with one seat of a product has the same escalation path as a department with ten thousand, and the provider's willingness to do business is the gate to the evidence. No FedRAMP page describes what happens when an agency and FedRAMP disagree about a certification. Rule AGU-USE-RCF says only that agencies must "collaborate with FedRAMP when discrepancies or conflicts arise." The Definitions page has no entry for "Corrective Action Plan."

Incident reporting: the clock moved to the agency, and the Class B clock got longer

The pilot-era 20x incident procedures required a provider to report a confirmed incident to CISA, to FedRAMP, and to every agency customer within one hour. Notice NTC-0012 (published June 3, 2026; in force July 4, 2026 for new 20x certifications and January 1, 2027 for Rev5 and existing 20x certifications) reversed the CISA leg: "FedRAMP will no longer expect private companies to report incidents regarding agency customers directly to CISA. Instead, agencies using these cloud services will be expected to do so based on the identified impact to their own agency services." FedRAMP's reasoning is that providers "do not and can not understand the actual impact to agency operations." Agencies "will receive additional guidance." As of October 17, 2026, we could not find it.

The provider's duty to tell the agency is now tiered by class. For incidents rated PAIN 3 to 5, a Class D provider must send an initial report within 15 minutes, a Class C provider within one hour, and a Class A or B provider within six hours. The clock starts when the provider concludes the incident is reportable, not when it detects it. The notice says it "is not a violation of these procedures if a cloud service provider regularly waits for days after identifying an incident before they evaluate the incident," adding that doing so "is very likely to cause customer agencies to re-evaluate their use of a service that does not take federal customers seriously." That is a market remedy, not a rule.

For the agency security operations center this is a new job. The agency owns the federal reporting window for a breach it did not detect, in a system it does not run, and its window can only begin when the provider's notice lands. For a Low system on a Class B service, that notice can lawfully arrive six hours after the provider made up its mind, which can be days after the event. The 15-minute Class D notice is a real improvement, and we count it below.

Too much change for a staff this small, with the agency rulebook still a placeholder

On March 24, 2025, the day it announced 20x, FedRAMP said the Rev5 agency path "is the sole active path to FedRAMP authorization" and "no changes to this path are planned at this time." Fifteen months later, notice NTC-0013 told providers to "consider carefully whether or not to invest in a Certification Type that is being actively replaced." In between, FedRAMP's FY25 retrospective says the Joint Authorization Board "had shut down unexpectedly for nearly a year," while "nearly 500 companies have made significant investments in FedRAMP Rev5-based compliance" and "over 200 authorizing officials are using Rev5-based processes."

The team doing this shrank by more than half. In late 2024 the PMO had about 80 contractors; by March 2025 their contracts were expiring and the number was heading toward zero, alongside about 18 federal staff. On October 8, 2026, FedRAMP reported "17 federal employees and 15 contractors," a "more than 50% reduction in staff from 2 years prior."

Volume alone is not risk. The risk is in how the volume lands on agencies. Of the 17 rulesets in the Consolidated Rules for 2026, the Agency Use ruleset is the only one still marked "Placeholder." Every provider ruleset is "Stable." The agency rules nonetheless carry a July 4, 2026 effective date. Rules keep changing through the changelog without a public notice: on October 8, 2026, a Class B provider's duty to summarize KSI metrics over 30 days was downgraded from MUST to SHOULD, and no notice has been issued since July 22. The legacy Agency Authorization Playbook, version 4.1 from November 2025, covers only the Rev5 process it says will "cease operations at the end of FY27." The 2026 Initial Authorization page gives five steps with no durations, no templates, no Class-to-impact-level guidance, and no word on overlays such as CJIS, IRS Publication 1075, HIPAA, or DoD Impact Levels. The 20x page has no agency FAQ.

FedRAMP's Security Director, Nicole Thompson, said on October 8, 2026, that instead of reading the rules, people are "googling, or they're relying on past advice." In May she said of agency reactions to 20x packages, "It looks different than what they're used to." Greg Barbaccia, then the Federal CIO, said in September 2025 that "cultural things" must change in government before reuse works. We agree. Culture changes faster when there is a procedure to follow.

SaaS went first. The platforms under it did not move.

This is the risk we think is least discussed. On October 17, 2026, the FedRAMP Marketplace listed 534 authorized offerings. Twenty-eight are 20x. All twenty-eight are SaaS, or PaaS plus SaaS. Zero of the 22 infrastructure-as-a-service offerings are on 20x. Every hyperscale platform (AWS, Azure, Google Cloud, Oracle) remains Rev5.

So a 20x SaaS, certified on measured outcomes and machine-validated evidence, runs on a platform certified on documents under rules FedRAMP calls "legacy." Among 105 provider-submitted 20x package overviews in FedRAMP's public data, the "FedRAMP Certified" third-party resources named most often are AWS US East/West, AWS GovCloud, Google Cloud, Google Workspace, GitHub Enterprise Cloud, and Azure Commercial. Every one is a Rev5 certification.

The 2026 rules dropped "leveraged authorization" as a package concept, and 20x packages have no inheritance statements. A provider must document its "third-party information resources" with justifications and mitigations, and the package schema records the FedRAMP ID of a certified resource but not its certification type. No rule in the consolidated set addresses what happens when a third-party resource's certification type changes, lapses, or is revoked. The only hard layering rule so far is in the Class D draft published October 15, 2026 (RFC-0036), which says a 20x Class D service "MUST be deployed on a FedRAMP Class C or FedRAMP Class D Certified" IaaS or PaaS, a rule FedRAMP says "clarifies a gap in the current rules." It was published after 28 SaaS certifications already existed.

The timeline makes this concrete. New Rev5 applications end June 11, 2027. Existing Rev5 certifications "will remain active until at least December 31, 2028, unless FedRAMP is otherwise directed," and the end date "is likely to be no later than 2029." FedRAMP's FY27 goals include 20x Class C or D certifications for hyperscalers, but the High pilot that was planned for the last quarter of FY26 only reached a request for comment in October 2026, no hyperscaler has a 20x package overview in the public repository, and we found no public 20x commitment from any of them. In May 2026, Thompson said of High-impact infrastructure, "I don't even know that that's a problem that we solve entirely with 20x, or whether Rev. 5 stays around."

The last time FedRAMP changed baselines, from Rev4 to Rev5, a SaaS on a platform that had not yet moved had to track the gaps as "Vendor Dependencies," and "the SaaS CSP must verify the status of these deficiencies every 30 days and document the status in the POA&M." There is no POA&M under 20x. If a platform's Rev5 certification ends before its 20x certification exists, every dependent SaaS's "certified" resource becomes an uncertified one, with no FedRAMP-defined step for the SaaS or for the agency. Because 400 of 534 offerings sit on those platforms, any Rev5 end date is, in practice, a hyperscaler date, and the agency ATOs on top of those 400 offerings are the ones exposed.

The staggered cliff

Agencies hear "Rev5 runs to the end of 2028." The headline is true and the detail is not. The 2026 rules take hold ruleset by ruleset, each with its own grace period, and a provider that misses one loses its certification "with public notice." There are no extensions.

No fedramp.gov page says what an agency must do with a live ATO when the provider's certification is revoked, suspended, or moved from Rev5 to 20x. The only agency-facing continuity advice we found came from the Cloud Security Alliance, not FedRAMP: do not assume a currently authorized vendor stays authorized, and flag vendors without a written transition plan in the risk register by early 2027.

Where the changes reduce risk

An honest scorecard names the wins, and some of them are substantial.

Vulnerability management got harder on providers, and that protects agencies. Notice NTC-0014 (June 16, 2026) made the vulnerability detection and reporting rules mandatory for every certified offering on December 7, 2026, with revocation after March 7, 2027. It states that "the legacy monthly vulnerability scanning process that most FedRAMP Rev5 Certified cloud services currently follow is insufficient." Providers must detect persistently, re-validate machine resources every three to seven days, publish a human-readable report at least monthly, rate every finding by reachability, exploitability, and potential adverse impact, and treat anything unfixed after 192 days as an accepted weakness that agencies can see. FedRAMP says it "has confirmed with CISA" that providers following these rules "will meet or exceed the expectations for the protection of federal information required by BOD 26-04." The caveat: remediation deadlines are SHOULD, the clock runs from the provider's own evaluation, and the provider assigns the impact rating.

Class D incident notice went from one hour to 15 minutes. For High services, that is four times faster in how quickly an agency learns about a serious incident, and providers that skip impact estimation must report everything as the highest severity, which errs toward over-notification.

Every agency customer now gets the quarterly report, not just the sponsor. Under Rev5, the monthly deliverables went to the sponsor and to the FedRAMP repository; a reusing agency had to request access and go looking. The Ongoing Certification Report goes to "all necessary parties" every three months, covering changes, planned changes, accepted weaknesses, incidents, and the list of agencies using the product. For Classes C and D the provider must host a quarterly review. The MUST-read duty on agencies also makes neglect auditable, which is a protection for the diligent.

Package freshness and self-validation are now rules, not hopes. A new application's package must have been verified within the previous seven days, a Class C package must be refreshed at least every two weeks, and Class C requires at least two automated validation methods per KSI (four for Class D). The assessor must review code, not screenshots. AWS's reference architecture for providers building 20x monitoring on its platform shows what this looks like in practice: scans every three days for Class C, drift detection every 14 days, a quarterly report pipeline in human- and machine-readable form, and a one-hour notification workflow for high and critical findings.

The remedies are written down for the first time. Public revocation, Inspector General referral, notice to other agencies, corrective action plans that agencies are told about, and a rule that a provider which denies an agency access must tell FedRAMP within five business days and keep six months of access logs.

The supply side improved, measurably. GSA reported 114 authorizations in FY2025 through July against 49 in all of FY2024, with waits down from more than a year to about five weeks. Pilot durations we computed from the status changelog were a median of about 50 days for Class B and about 90 for Class C. The "Lost Sponsor" pipeline rescues agencies whose vendor's sponsor walked away. An agency that needs a service nobody else has authorized no longer has to carry the whole package itself.

The warning label is more honest. "Assurance, not security," and a twelve-month SHOULD NOT on Class A, are warnings the old all-or-nothing "Authorized" badge never carried. Agencies that believed a JAB Moderate P-ATO was a government-wide risk acceptance were wrong then, too. The new language says so.

The limit on all of these is that no independent measurement of agency security outcomes under 20x exists. The gains are structural and rule-based. Most became mandatory only between July 2026 and March 2027, and they apply in full to 28 services.

Our view

FedRAMP did not transfer risk to agencies so much as unmask it. The law placed residual risk on the agency authorizing official in 2022. The 2025 and 2026 changes removed the apparatus (sponsor review, impact labels, the SAR, the CRM, the monthly POA&M, change approval, the central repository, the provider's CISA call) that let agencies behave as though it sat somewhere else. What agencies got in return is better in kind: continuous, structured, revocation-backed provider data. It is not yet better in practice, because few agencies have tooling that can ingest it (FedRAMP's own community thread makes that point), the rules that govern it are still being edited, there is no 20x authorization procedure, no inheritance method, and an oversight community still auditing to the old artifacts.

The agencies most exposed over the next eighteen months are not the ones using 20x services. There are almost none of those; the Marketplace shows three agencies with their own ATOs on 20x services (Veterans Affairs, the Election Assistance Commission, and Agriculture), against thousands of agency ATOs on Rev5 services. The exposed agencies are the hundreds with live ATOs on Rev5 services whose certifications face revocation cliffs from March 7, 2027, on platforms with no 20x path and no public commitment to one.

What agencies should do now

• Write your own CISA runbook for provider incidents. You own that filing now. Decide who receives provider notices, how the PAIN rating maps to your federal reporting thresholds, and what you do when the notice is late.
• Decide your Class-to-impact-level policy and document it. FedRAMP will not do this for you. Write down which Classes your agency accepts for Low, Moderate, and High, and what compensating controls a step down requires.
• Build the inheritance method before you need it. Pick a crosswalk from the 46 KSIs to your 800-53 baseline, even an imperfect one, and apply it consistently. Push your GRC vendor for OSCAL and JSON ingestion; rule AGU-AGC-GRC requires it and FedRAMP will not fund it.
• Put every Rev5 vendor without a written transition plan on the risk register by early 2027. Ask for the plan at the next contract action: which class, which year, and which platform. Ask SaaS vendors specifically what happens if their IaaS does not move.
• Assign someone to read every Ongoing Certification Report. It is a MUST, it is auditable, and it is the only quarterly account of your vendor's weaknesses and incidents you will get.
• Treat Class A as a pilot label. Twelve months, compensating controls, and a plan to move or leave.
• Track the deadlines by ruleset, not by the 2028 headline. The FedRAMP tracker on FedXchange shows each service's certification type and will flag changes to the services you bookmark.

Sources

• 44 U.S.C. 3613, as reproduced on fedramp.gov
• OMB M-24-15, process section, as reproduced on fedramp.gov
• FedRAMP NTC-0004: FedRAMP Certification and Classes
• FedRAMP NTC-0007: Class A and external frameworks
• FedRAMP NTC-0012: Incident communication
• FedRAMP NTC-0013: Rev5 updates, Secure Configuration Guide
• FedRAMP NTC-0014: Response to CISA BOD 26-04
• Consolidated Rules for 2026: Agency Use rules
• Consolidated Rules for 2026: Certification Classes for agencies
• Consolidated Rules for 2026: Certification Packages for agencies
• Consolidated Rules for 2026: Reporting concerns
• Consolidated Rules for 2026: FedRAMP responsibilities
• Consolidated Rules for 2026: Agency responsibilities
• Consolidated Rules for 2026: Secure Configuration Guide ruleset
• Consolidated Rules for 2026: Key Security Indicators
• Consolidated Rules for 2026: Independent Verification and Validation ruleset
• Consolidated Rules for 2026: Collaborative Continuous Monitoring ruleset
• Consolidated Rules for 2026: Significant Change Notification ruleset
• Consolidated Rules for 2026: Vulnerability Detection and Response ruleset
• Consolidated Rules for 2026: Certification Data Sharing ruleset
• Consolidated Rules for 2026: Complete rulesets and status
• Consolidated Rules for 2026: Important dates
• Consolidated Rules for 2026: Rev5 deadlines by ruleset
• Consolidated Rules for 2026: What's changing for Rev5
• Consolidated Rules for 2026: Changelog
• FedRAMP RFC tracker and RFC-0036, 20x Class D pilot
• FedRAMP 20x
• FedRAMP in 2025 (March 24, 2025)
• FedRAMP FY25 retrospective (September 30, 2025)
• FedRAMP FY26 report: From foundation to implementation (October 8, 2026)
• FedRAMP Agency Authorization Playbook v4.1 (November 2025)
• FedRAMP Rev5 Transition Guide (2023)
• FedRAMP Marketplace data (GitHub), October 17, 2026
• FedRAMP community discussion #38
• CIGIE: OIG Best Practices for Cloud Computing (March 2026)
• Nextgov/FCW: GSA seeks to boost understanding of FedRAMP 20x overhaul (October 8, 2026)
• FedTech: FedRAMP 20x is live, now what (May 19, 2026)
• MeriTalk: FedRAMP in the crosshairs (March 7, 2025)
• Federal News Network: CIO council building list of "top-tier" services amid FedRAMP reforms (September 2025)
• Nextgov: GSA doubles FedRAMP authorizations (August 11, 2025)
• Davis Wright Tremaine on the Consolidated Rules (July 9, 2026)
• Cloud Security Alliance research note on the 20x transition (July 24, 2026)
• AWS Public Sector Blog: Continuous monitoring under FedRAMP 20x (September 17, 2026)