FedRAMP 20x Class D Pilot: What RFC-0036 Would Require of Cloud Providers
FedRAMP 20x Class D moved from roadmap to proposed rules on October 15, 2026, when FedRAMP opened RFC-0036 with the specific requirements for a Phase 4 pilot of the highest assurance level under 20x. Until now, Class D could be reached only through the Rev5 Agency path. RFC-0036 does not change that yet: it is a proposal for a pilot of at most ten providers, and eligibility requires a CR26-compliant 20x Class C Certification before December 1, 2026. Comments close on November 19. This article explains what the RFC proposes, how it differs from the earlier outline in RFC-0033, who the pilot realistically fits, and what cloud providers should do before the window closes. What RFC-0036 Proposes for FedRAMP 20x Class D How RFC-0036 Fits Into Phase 4 FedRAMP set the approach for Phase 4 in RFC-0033 and said the full pilot requirements would follow as a second request for comment. RFC-0036 is that second request. It proposes two new definitions, updates to six rulesets, and ten new Key Security Indicators, and it covers only cloud-hosted services. Self-hosted and hybrid-hosted services are handled in separate tracks that run in parallel, and their rules do not exist yet. FedRAMP is explicit that none of this is settled. The RFC says additional rules and indicators may be added during or after the pilot and that existing ones are likely to change based on feedback, and RFC-0033 says the final rules from Phase 4 will be folded into the Consolidated Rules for 2027. FedRAMP also says it expects 20x Class D to provide a greater level of assurance than a legacy Rev5 Class D, and that it anticipates few commercial services will invest fully to reach it. That candor is the clearest signal of who this tier is for. Elevate’s explainer on FedRAMP High and Class D covers the Rev5 baseline that Class D means today. The Pilot Timeline and Who Can Join The pilot calendar comes from RFC-0033, and FedRAMP marks every date after the comment period as a target that assumes no unexpected delays. Date What happens Source October 15, 2026 RFC-0036 opens for comment RFC-0036 November 13, 2026 Providers that apply for 20x Class C before this date and intend to join the pilot should notify the FedRAMP Director RFC-0033 November 19, 2026 RFC-0036 comment period closes RFC-0036 December 1, 2026 Deadline to hold a CR26-compliant 20x Class C Certification to be eligible RFC-0033 December 1 to 4, 2026 Application window (target) RFC-0033 December 7 to 18, 2026 Initial discussions with participants (target) RFC-0033 February 17, 2027 Mandatory draft package submission and progress review (target) RFC-0033 March 17, 2027 Final pilot package submission deadline (target) RFC-0033 The table shows two dates that matter for most providers and several that matter only to those already inside the process. The binding date is December 1, and in practice November 13, because a provider that wants to join has to be far enough along with Class C to notify FedRAMP after submitting its application. RFC-0033 also targeted November 18 for final pilot requirements, one day before RFC-0036 closes, so expect the final text to arrive after the comment period. Participation is deliberately narrow. FedRAMP will cap the pilot at 10 participants, limit it to providers that have already shown they can meet 20x requirements, and expect them to engage a FedRAMP Recognized Independent Assessment Service and the FedRAMP PMO. Participants should also expect to engage FedRAMP’s Technical Advisory Group, the FedRAMP Board, and interested agencies. Phase 2 pilot participants are not exempt: they need a full CR26-compliant 20x Class C Certification by December 1 like everyone else. Class C First: The Progressive Path to Class D The most consequential proposed rule is FRC-CLD-PCD. It says a provider seeking a 20x Class D Certification must maintain a 20x Class C Certification without corrective action for at least six months, or receive a special exemption from FedRAMP for an urgent critical need. For the Phase 4 pilot itself, a full non-pilot 20x Class C Certification is required to qualify, but the six months are not. FedRAMP’s reasoning is stated in the rule’s notes: Class D is a very large investment for the program, and traditional High sponsorship often took many years, so the proposal breaks it into stages in which a provider demonstrates progressive assurance. The notes also settle a question for existing holders. No one with a Rev5 Class D is expected to give up that certification, but a Rev5 Class D provider moving to 20x still goes through 20x Class C first, and FedRAMP anticipates most will keep their Rev5 Class D even after earning a 20x Class D. FedRAMP signaled this direction at its Rev5 community meeting earlier this month, where it described Class C first as its intent. RFC-0036 puts proposed rule language behind it. Elevate’s recap of the meeting covers what FedRAMP said then. The Rules and Key Security Indicators in RFC-0036 Rules That Raise the Bar on Automation and Data Sharing The RFC does not reproduce the existing Class D rules, only the new or modified ones, and the pattern across them is data access. Class D providers would verify and validate machine-based resources at least every three days (VDR-TFR-MVX), which matches the current Class C expectation. They would have to make all recent historical vulnerability detection and response activity available in JSON for automated retrieval, updated persistently and at least every seven days (VER-TFR-MRH). That is a change from SHOULD to MUST for Class D. Two further rules push the same direction. The Security Decision Record would have to include historical Key Security Indicator metrics: a 30-day summary, a summary of up to a year where available, and metric data every four hours for up to a year (SDR-CSX-KMT). And providers would have to supply all machine-readable parts of the certification package through a web-compatible API (CDS-CSX-API), which FedRAMP calls a new rule for Class D. The practical reading is that a Class D agency customer would
FedRAMP Updates for Rev5 Providers: What the Latest Community Meeting Changed
The FedRAMP updates from the latest Rev5 community meeting add up to a clear message: the rules are settling, enforcement is arriving on a calendar, and Rev5 providers are being steered toward 20x without being forced there yet. FedRAMP added a new PAIN0 rating to vulnerability evaluation, tightened how public JSON data must be served, shared how long Rev5 reviews are really taking, and spent much of the Q and A explaining why the December 7, 2026 vulnerability dates are not a planning target. This article sorts those updates by what they change for a cloud service provider that holds, or is pursuing, a Rev5 certification. A note on sources: FedRAMP’s spoken guidance and its published rules can differ in wording. Rule identifiers appear where the public changelog confirms them, and anything that comes only from the meeting is attributed to FedRAMP’s speakers. FedRAMP Updates That Change Your Rule Set This Month PAIN0 Adds a Floor to Vulnerability Evaluation FedRAMP’s October 5 release of the Consolidated Rules for 2026 added a PAIN0 rating to the rule that governs how providers estimate potential agency impact (VER-EVA-EPA). It covers situations where it is extremely unlikely that any agency would notice an adverse effect. Before the change, a provider had to choose a rating from N1 through N5, so findings with no meaningful agency effect tended to default to N1, the lowest rating available. FedRAMP’s speakers described two practical uses. The first is any finding that is not a real exposure, such as a confirmed false positive, which the rules already say providers should evaluate and can now rate PAIN0 instead of forcing into N1. The second is a finding where exploitation would not realistically reach agencies. They also said no remediation or mitigation timeframes changed with the release, and that PAIN0 carries none of its own. The speakers also said the rule now asks providers to estimate the likely potential impact of exploitation, with likely defined as a reasonable degree of probability based on context. Their example was deliberately extreme: a far-fetched scenario in which an attacker overwrites every drive in a data center does not justify the highest rating for an ordinary vulnerability. That wording comes from the meeting, and the public changelog summary does not describe it, so confirm it against the current rule text before rewriting a methodology around it. For a provider with a documented rating method, the work is small but real: add PAIN0 to the scale, define when it applies, and keep the evidence behind each use. It is reasonable to expect scrutiny of the false positive process before PAIN0 is accepted on a finding, because a rating of zero takes the finding off the remediation clock. Elevate’s Vulnerability Management as a Service is built around that evaluate-and-document loop. Public JSON Data Must Carry the Right Headers The same release clarified that any public JSON data FedRAMP requires, including the marketplace listing file covered below, must be served with proper cross-origin resource sharing (CORS) and Content-Type settings so web applications can use it (FRC-CSO-JSN). FedRAMP’s speakers said some content tools cannot set those headers, and that providers should not host public JSON on them, because FedRAMP would otherwise have to override security settings to read the file. Their advice was to hand the question to engineers, who typically treat it as routine. The practical test is simple: request the file the way a browser would and read the response headers before FedRAMP does. Two Smaller Clarifications on Logos and Cryptographic Modules The public information rule (CDS-CSO-PUB) now says the required logo link must point to a properly named image file. Speakers added that the image appears on the marketplace listing, so a white logo on a transparent background will disappear against the page. The cryptographic module rule (CMU-CSO-UVM) gained a note explaining that a validated module includes only the algorithms it was validated with. If an upstream update adds algorithms the module never carried through validation, those algorithms are not covered by the validation, even when the product keeps the same name. Providers relying on a validated module should check which algorithms their update stream has added. Marketplace Listings Now Run on Your Own JSON File What FedRAMP Now Requires for Listings FedRAMP has moved marketplace listings from email and form exchanges to a public JSON file that the provider hosts and maintains. The requirement sits in the CR26 public information rules and applies to new listings and to existing ones. Speakers said FedRAMP made exceptions for a period to speed things up and is now enforcing the rule across the board for any provider that wants to change its listing. The reason is capacity: about 76 providers sit in the initial implementation phase, more than 500 are already listed, and the team cannot keep hand-editing listings for all of them. The upside, as FedRAMP framed it, is control. The marketplace is built daily, sometimes every two days, from the provider’s file, and FedRAMP wants the lag to shrink toward several checks per day. Providers can add and remove timely content such as meetings or blog posts. Some fields stay with FedRAMP, such as the certification class, and the file should include only information that applies to the provider today. Elevate’s guide to the FedRAMP marketplace listing covers the listing itself. How to Submit the File and Avoid Rework Providers submit the JSON location through FedRAMP’s help desk form, not by email, and FedRAMP validates the file at submission against a published JSON schema. The file can live anywhere the provider controls, including a cloud bucket, but it should be protected so no one else can alter it. A speaker estimated about twenty minutes of work if the provider copies from its current listing, and asked providers not to push engineers into an emergency sprint: stage the work over the next couple of weeks. Turnaround is expected to start at a couple of days and fall over time. Basic markdown works, embedded images may not,
FedRAMP Moderate Is Now Class C: What Changed
FedRAMP Moderate certification no longer exists as a standalone destination on the FedRAMP Marketplace. Under the Consolidated Rules for 2026, the designation formerly known as FedRAMP Moderate is now Class C, and a provider searching for how to pursue Moderate authorization today is searching for a label the program retired. The underlying risk tier survives largely intact. What changed is the name, the terminology it no longer collides with, and, depending on which certification type a provider pursues, the entire evidence model behind it. This article covers why the rename happened, what actually moved versus what only got relabeled, and what a provider pursuing Class C through FedRAMP 20x specifically has to prove. Why FedRAMP Moderate Became Class C The Renaming Traces to a Specific, Documented Problem The retirement of Low, Moderate, and High was not a cosmetic decision made for its own sake. FedRAMP’s impact levels, drawn from FIPS 199, existed alongside a completely separate Department of Defense Impact Level system, IL2 through IL6, used for DoD cloud authorizations. The two systems shared vocabulary without sharing meaning. A cloud service described as FedRAMP Moderate did not automatically satisfy DoD IL4, and the overlapping language in marketing materials and procurement documents produced genuine confusion about which standard actually applied to a given requirement. The retirement was formally anchored in Public Notice NTC-0004, published February 25, 2026, and finalized as part of the Consolidated Rules for 2026 when CR26 launched in late June. The new Certification Class structure maps largely one to one to the retired levels: Class A is a new transitional tier with no direct predecessor, Class B covers what was previously Low, Class C covers what was previously Moderate, and Class D covers what was previously High. What Actually Changed Versus What Only Got Relabeled The mapping between old and new terminology is close to direct, which is worth stating plainly because it resolves the most common anxiety providers have about this change. A provider authorized at Moderate today becomes FedRAMP Certified at Class C without needing to re-authorize from scratch. The underlying risk tier, the type of data in scope, and the general severity of a breach at that tier did not move. What did change is more specific than the class label. The evidence model a provider builds against Class C depends on which certification type it pursues, Rev5 or 20x, and that choice determines whether the provider is still assembling a traditional NIST 800-53 control set or building toward a machine-readable rules and indicators structure that did not exist under the legacy Moderate baseline at all. The name change is close to cosmetic. The evidence model underneath it, for a provider on the 20x path, is not. What FedRAMP Moderate, Now Class C, Actually Covers The Data and Risk Profile Did Not Move Class C applies to systems handling Controlled Unclassified Information and other non-public federal data, where a breach could cause serious harm, meaning disrupted operations, compromised personal data, or financial loss, without rising to the catastrophic consequences reserved for Class D. This is the same profile FedRAMP Moderate covered under the legacy terminology, and it remains the most common certification tier in the program. Historical GAO reporting put roughly three-quarters of agency-leveraged authorizations at the moderate-impact tier, and there is no indication the underlying distribution of federal cloud workloads shifted when the label did. Where Class C Sits Among the Four Classes Class C sits between Class B, the lightest tier, and Class D, the tier reserved for mission-critical systems where a breach could be catastrophic. Elevate’s guide to FedRAMP controls and classes covers the full breakdown across all four classes and their approximate control counts under Rev5. What is worth stating here, rather than repeating that full breakdown, is the practical reason Class C matters disproportionately to the provider community: most SaaS products that handle any federal data land at Class C, which makes it the tier the largest share of the market actually has to build toward, rather than a specialized case. Two Paths to Class C: Rev5 and 20x Rev5 Class C Is Still the Traditional Control Model A provider pursuing Class C through Rev5 builds against the NIST SP 800-53 control catalog, roughly 323 to 325 controls at this tier, documented through a System Security Plan, assessed by a FedRAMP Recognized Assessor, and reported through the traditional narrative and spreadsheet-based evidence model that has defined FedRAMP for over a decade. This path suits providers with complex or legacy infrastructure, and it remains available through the Agency Certification path with a sponsoring agency, or in limited cases through the temporary sponsorless pipelines described in Elevate’s guide to FedRAMP ATO in 2026. 20x Class C Replaces the Control Count With Rules and Indicators A provider pursuing Class C through FedRAMP 20x builds against a structurally different evidence model. Instead of a control count, the 20x path defines Class C, labeled Significant, through a specific set of applicable rules drawn from the FedRAMP Consolidated Rules, organized across the rulesets that cover marketplace listing, certification, boundary definition, assurance, and package requirements, alongside a defined set of Key Security Indicators mapped back to NIST 800-53 controls. A provider on this path is not producing a narrative SSP. It is producing machine-readable evidence against a named, versioned rule set, submitted through the Program Certification path without requiring an agency sponsor. This is the path where the terminology change matters most in practice, because there was no 20x Class C evidence requirement under the legacy Moderate label at all. A provider that built its entire compliance muscle memory around the Rev5 control-count model is not just relearning a new name. It is potentially building toward a different kind of evidence entirely, depending on which certification type its architecture and market strategy point toward. The Two Paths, Side by Side Dimension Rev5 Class C 20x Class C Evidence basis NIST SP 800-53 controls, roughly 323 to 325 158 rules plus 46 Key Security Indicators Core artifact
FedRAMP POA&M: What Replaced It Under the Consolidated Rules for 2026
FedRAMP POA&M documents no longer exist for cloud service providers. Under the Consolidated Rules for 2026, the Plan of Action and Milestones that CSPs filed for years has been eliminated entirely and replaced with a list of Accepted Weaknesses, a change FedRAMP made on the reasoning that a POA&M line item was, in practice, mostly used to formally accept a weakness for an extended period anyway. A provider still building its evidence package around a POA&M template, or a compliance team still searching for the current POA&M requirements, is working from a document type that FedRAMP retired. This article explains what changed, what replaced it, and the one related term that survived under a different owner and a different meaning. Why FedRAMP POA&Ms No Longer Exist What POA&M Used to Cover Under the legacy Rev5 model, the POA&M was one of the core documents in a provider’s security package, alongside the System Security Plan. Its scope covered every management, operational, and technical control that an assessment found less than fully effective, not only vulnerabilities in the CVE sense. A provider used the POA&M to record each weakness, the planned remediation task, the resources assigned to it, and a target completion date, and an authorizing official used the same document to track whether the provider was actually closing those gaps over time. That scope made the POA&M a catch-all. A missing configuration baseline, an incomplete access review process, and an unpatched CVE could all live on the same document, tracked with the same milestone structure, regardless of how different those three problems actually were in terms of urgency or evidence. A provider preparing for its annual assessment often spent as much effort reconciling the POA&M narrative with what had actually happened operationally as it spent on the underlying remediation work itself, because the document was reviewed on its own schedule rather than updated continuously as findings changed. The table below summarizes what changed between the legacy document and the model that replaced it. Dimension Legacy POA&M Accepted Vulnerability / Accepted Weakness Authored by The cloud service provider The cloud service provider, evaluated continuously Review cadence Periodic, tied to assessment or reporting cycles Continuous, as part of ongoing vulnerability evaluation Scope Any control weakness or deficiency, narrative-based Defined per finding, with a formal status and citation Format Narrative document, commonly Word or Excel Structured, machine-readable evaluation record Reading across that table, the shift is not only about which document a provider produces. It is about when the justification gets written. A POA&M narrative was often assembled or refreshed ahead of a review, describing progress against milestones set earlier. An Accepted Vulnerability record is populated at the point a finding crosses its required remediation window, carrying the specific architectural or operational reason for that status rather than a retrospective summary. The Change: Accepted Weaknesses Under CR26 The Consolidated Rules for 2026 replace that catch-all document with a narrower mechanism tied directly to the new Vulnerability Detection and Response and Vulnerability Evaluation and Reporting rulesets. FedRAMP’s own summary of the change states plainly that Plans of Action and Milestones have been eliminated entirely and replaced with a list of Accepted Weaknesses. Rather than a static document reviewed periodically, the model now expects continuous evaluation of findings, with any finding that is not mitigated or remediated inside its required timeframe moving into a defined Accepted Weakness status instead of sitting on an open milestone. The formally defined version of this concept that appears in FedRAMP’s own definitions is the Accepted Vulnerability, identified under rule FRD-ALL-31: a vulnerability the provider does not intend to fully mitigate or remediate, or that has not been and will not be fully mitigated or remediated within the maximum overdue period FedRAMP recommends or requires. That definition lines up directly with the 192-day threshold under rule VER-TFR-MAV covered in Elevate’s guide to FedRAMP vulnerability management: once a finding crosses that line, it stops being an open remediation item and becomes a documented, justified Accepted Vulnerability instead. Why FedRAMP Made the Change FedRAMP’s stated reasoning is direct rather than diplomatic: a POA&M was mostly functioning as a formal way to accept a weakness for a long period, so the program removed the extra document and built that acceptance directly into the vulnerability evaluation process itself. This fits the broader pattern across the Consolidated Rules for 2026, where FedRAMP has replaced several narrative, periodically reviewed documents with structured, continuously maintained records inside the Consolidated Rules framework. A provider no longer produces a POA&M for an authorizing official to review on a set cadence. It produces a live, evaluated record of every vulnerability, and any that remain open past the required timeframe carry an Accepted Vulnerability status with a documented justification attached. The practical effect of this change is that acceptance is no longer a separate administrative step a provider takes after the fact. Under the legacy model, a provider could remediate a finding, decide later that a different finding was not worth fixing on the original timeline, and formalize that decision by adding it to the next POA&M cycle. Under the current model, the acceptance decision is embedded in the same evaluation that produced the PAIN rating in the first place. A finding either gets remediated inside its required window, or it crosses that window and becomes an Accepted Vulnerability automatically, with the justification captured at that moment rather than assembled retroactively for the next scheduled review. Accepted Vulnerability Versus Accepted Weakness: Getting the Terms Right Accepted Vulnerability Is the Defined, Citable Term For anything that runs through the VDR and VER evaluation pipeline, the term with an actual FedRAMP definition and rule citation is Accepted Vulnerability, not the broader phrase Accepted Weakness. A provider building documentation or training a team on the new terminology should anchor on Accepted Vulnerability for CVE-style findings, since that is the term with a published definition an assessor can point to directly. Where the Broader Term Still Needs Confirmation FedRAMP’s own change summary uses the phrase
Potential Agency Impact: Building a Defensible FedRAMP PAIN Rating Methodology
Potential Agency Impact is the rating FedRAMP now requires for every detected vulnerability, and FedRAMP has been explicit that it will not hand providers a formula for calculating it. That flexibility lets a provider account for its own architecture instead of forcing every finding into one rigid model. It is also a trap for any program that treats the rating as optional homework, because without a documented, repeatable method, every score becomes an argument the provider has to win one finding at a time, in front of an assessor, for as long as that finding lives. This article walks through the eight factors FedRAMP names for deriving a Potential Agency Impact rating, the distinction that trips up most automated approaches, and the six-phase path to a methodology that holds up under review. Why Potential Agency Impact Needs Its Own Methodology FedRAMP Will Not Hand You a Formula FedRAMP’s Consolidated Rules for 2026 retire the old severity-based remediation clock and replace it with a Potential Agency Impact rating, scored N1 through N5, that drives the remediation timeframe together with exploitability, internet reachability, and the provider’s Certification Class. What has not changed under the new model is the absence of a prescribed calculation. FedRAMP states that it will not recommend a specific framework for deriving the rating, which means the methodology itself, not just the resulting score, is what an assessor reviews. This is a deliberate design choice, not an oversight. A fixed formula would force a provider running a single-tenant SaaS platform and a provider running a multi-agency shared services layer into the same calculation, when the actual consequence of a compromised asset differs enormously between the two. Letting each provider build a method around its own architecture produces a more accurate rating. It also means two providers can look at the same CVE and land on different, equally defensible PAIN ratings, because the rating is about consequence in context, not about the vulnerability in isolation. The Cost of Rating Without a Documented Method A provider that has not built a repeatable method usually falls into one of two failure patterns. The first is under-rating: treating every finding as routine because there is no structured way to identify the handful that genuinely warrant urgency. The second, more common pattern is over-rating everything out of audit anxiety, which produces a different problem. When every finding gets marked N4 or N5 regardless of actual exposure, the provider triggers escalations and notifications that do not reflect real risk, and the agency officials receiving those notices stop reading them closely. A genuine emergency then arrives inside a queue the agency has already learned to discount. Neither pattern survives an assessor asking a simple question: show the derivation. A provider without a documented method has no way to answer that question consistently across a finding set, which means every individual rating becomes a fresh negotiation. That is the condition this methodology work is meant to close. This is part of a broader shift inside the Consolidated Rules for 2026, where FedRAMP has moved several previously prescriptive parameters, not just the vulnerability remediation clock, toward outcomes a provider has to demonstrate rather than a checklist a provider fills in. A PAIN methodology is the clearest example of that pattern in practice, because the rating itself is simple to state and the defensibility of how a provider arrived at it is where the actual compliance work lives. The Downgrade Record The single habit that separates a defensible methodology from a fragile one is documenting every downgrade at the moment it happens, not reconstructing the reasoning later when an assessor asks. A finding that looks severe on a raw scanner score but gets rated lower because it sits behind a compensating control, runs on an isolated asset, or fails the reachability test needs that specific architectural fact recorded alongside the rating itself. A rating with no attached reasoning is indistinguishable, to a reviewer, from a rating nobody thought about. In practice this means the evaluation record for a finding carries more than the final N1 through N5 score. It carries the inputs across the eight factors, the reachability determination and the specific control that shaped it, and a plain statement of why the combination produced the rating it did. That record is what turns a self-test question like “why was this finding downgraded” into something a team member can answer in minutes rather than something that requires reconstructing a decision nobody wrote down. The Eight Factors Behind a PAIN Rating FedRAMP names a specific set of factors providers should weigh when deriving Potential Agency Impact, rather than leaving the inputs undefined along with the calculation. Stripped of the acronyms, the rating answers three layered questions: how much would it actually hurt if this were exploited, how likely is it to actually be exploited, and can an attacker actually reach it. The eight named factors map onto those three questions. Factor What it asks Criticality How important are the systems or information at risk? Reachability How might a threat actor reach the vulnerability, and how likely is that? Exploitability How easy is it to exploit, and how likely is that? Detectability How easy is it for an attacker to become aware of it? Prevalence How much of the environment is affected? Privilege How much access does successful exploitation grant? Proximate vulnerabilities Does this finding combine with other findings into something worse? Known threats Are known threat actors already using this technique? Reading down that table, none of the eight factors stands alone. A finding can score low on criticality and still warrant urgency if it combines with a second finding, through the proximate vulnerabilities factor, into a path an attacker could actually walk. A finding can look severe by CVSS alone and still land at a low PAIN rating if detectability and reachability are both low, because the practical consequence of that combination is a vulnerability that is real on paper but not realistically actionable against a federal agency
FedRAMP High After CR26: What Replaces the Baseline
FedRAMP High is a legacy term. The label itself, along with Low and Moderate, was retired from FedRAMP’s vocabulary under the Consolidated Rules for 2026, replaced by a four-tier Certification Class structure running A through D. A cloud service that would have been described as FedRAMP High a year ago is now certified at Class D, and understanding that mapping is only the first step. What actually changes operationally, beyond the label, is what most guidance on this topic gets wrong by treating the shift as a simple rename. This article explains why the High designation was retired, what Class D actually is and is not, and what genuinely changes for a provider operating at this tier, versus what stays the same underneath new terminology. Why “FedRAMP High” Disappeared From FedRAMP’s Vocabulary The retirement of Low, Moderate, and High was not a cosmetic decision. It traces to a specific, formally documented problem the old terminology created. The DoD Impact Level Confusion That Drove the Change FedRAMP’s Low, Moderate, and High impact levels, drawn from FIPS 199, existed alongside a completely separate Department of Defense Impact Level system, IL2 through IL6, used for DoD cloud authorizations. The two systems shared vocabulary without sharing meaning. A cloud service described as FedRAMP Moderate did not automatically satisfy DoD IL4, and a FedRAMP High system did not automatically satisfy IL5, but the overlapping language in marketing materials, procurement documents, and security collateral produced genuine confusion about which standard actually applied to a given requirement. FedRAMP’s decision to move to lettered Classes rather than a renumbered or renamed level system was deliberately chosen to break this overlap entirely. There is no Class equivalent to a DoD Impact Level, and treating Class D as interchangeable with IL5 repeats the exact confusion the rename was designed to eliminate. NTC-0004 and the Formal Retirement The retirement of impact-level terminology was formally anchored in Public Notice NTC-0004, published February 25, 2026, and finalized as part of the Consolidated Rules for 2026 when CR26 launched in late June 2026. The rules calls the old designations FIPS 199 impact levels; the new structure is the Certification Class system, and the mapping FedRAMP itself describes runs largely one to one: Class A is a new transitional tier with no direct predecessor, Class B covers what was previously Low, including the LI-SaaS variant, Class C covers what was previously Moderate, and Class D covers what was previously High. What Class D Actually Is Class D is the direct successor to the FedRAMP High designation, applying to cloud services handling the most sensitive non-classified federal data, where a breach could cause severe or catastrophic harm to operations, assets, or individuals. The Control Baseline Behind Class D The underlying NIST SP 800-53 Rev 5 control baseline behind the old High designation does not disappear under the new terminology. The former High baseline required roughly 410 controls across the program’s 17 control families, the most extensive of the three legacy baselines, and that depth of control implementation is what Class D still demands. The rename changes the label applied to this baseline, not the substance of what a provider has to implement and demonstrate to operate at this tier. Class D Stays on the Agency Path, Not 20x The single most consequential operational fact about Class D has nothing to do with terminology. Class D is the only Certification Class with no Program path and no FedRAMP 20x path available. Every Class D certification runs through the traditional Agency path, which means a Class D provider still produces the documented evidence package, a System Security Plan, a Security Assessment Plan and Report from an independent assessor, and a Plan of Action and Milestones, rather than the machine-readable Key Security Indicator model available to Classes A through C. This is not a temporary oversight. FedRAMP has been explicit that the 20x pilot program for the highest-sensitivity tier is not yet mature enough to extend the automated evidence model to it, which means a provider requiring what used to be called FedRAMP High should plan for a documentation-intensive certification process regardless of how sophisticated its underlying infrastructure automation already is. Timing for Providers Currently Pursuing or Holding This Tier A provider currently working toward a High-tier authorization, or holding one and planning a reauthorization cycle, needs to track two separate dates that interact with Class D specifically. CR26 becomes mandatory for all stakeholders on January 1, 2027, which means a Class D provider’s next assessment after that date is evaluated against the updated Rev5 baseline the Consolidated Rules establish, not the pre-CR26 control set. Separately, FedRAMP stops accepting applications for entirely new Rev5 certifications on June 11, 2027, and since Class D has no alternative path, a provider that has not started a new Class D certification by that date has no route to this tier available at all until FedRAMP potentially opens a 20x option for it in the future, on a timeline the program has not committed to. A provider evaluating whether it genuinely needs Class D, rather than a lower tier, should weigh this closing window as a real planning input, not a distant contingency. What Actually Changes Operationally Beyond the terminology itself, three practical changes matter for a provider currently operating, or planning to operate, at this tier. Terminology in Marketing and Procurement Collateral Every reference to FedRAMP High in a provider’s marketing materials, procurement documentation, contract language, and security collateral needs updating to Class D to stay accurate and to avoid the exact confusion the rename was meant to eliminate. This is a genuinely tedious but low-risk task, and it is worth treating as a project with an owner and a deadline rather than an update made piecemeal whenever someone happens to notice outdated language in a given document. Existing High Authorizations Are Not Affected in Substance A cloud service that already holds a FedRAMP Authorization at the High impact level retains that status; the terminology shift applies going forward to new
FedRAMP System Security Plan: Rev5 vs 20x Evidence
The FedRAMP System Security Plan is the document most cloud service providers associate with the entire certification process, and under CR26 it is only half true anymore. A Rev5 certification still requires a documented SSP, a narrative package describing the authorization boundary and how each applicable control is implemented. A FedRAMP 20x certification does not use an SSP at all. It replaces the narrative document with a Certification Package Overview and a Security Decision Record, machine-readable artifacts validated on an ongoing cadence rather than reviewed once and filed away. Which of these applies to a given provider is not a stylistic choice. It follows directly from certification type, and the window to still choose the SSP path is closing. This article covers what the traditional FedRAMP SSP must scope correctly, where SSP submissions most often fail review, how CR26’s evidence model replaces the SSP for 20x providers, and the strategic question every provider not yet certified needs to answer before starting. What the FedRAMP SSP Is and Why Scope Discipline Matters A System Security Plan defines the authorization boundary, the specific systems, data flows, and components inside the scope of certification, and documents how each applicable NIST SP 800-53 Rev 5 control is implemented within that boundary. This remains the required deliverable on the Rev5 path under CR26, alongside a Security Assessment Plan and Report from an independent assessor and a Plan of Action and Milestones tracking findings to closure. The SSP’s job is narrower than it sounds: it does not need to describe every security practice an organization follows, only what is inside the boundary and how the applicable controls operate there. Getting that scope wrong, in either direction, is where most SSP submissions run into trouble. The Boundary Diagram, Data Flow Diagram, and Control Narrative Must Agree Reviewers evaluate an SSP on clarity, completeness, conciseness, and consistency, and the most common failure is a mismatch between three artifacts that are supposed to describe the same system from three angles: the boundary diagram showing what is in scope, the data flow diagram showing how information moves through that scope, and the control narrative describing how each control operates within it. A boundary diagram that shows a component the data flow diagram omits, or a control narrative that describes a data protection mechanism the diagrams do not support, is not a minor inconsistency to a reviewer. It is a signal that the documentation was assembled by different people at different times without anyone reconciling the pieces, and it invites exactly the kind of scrutiny that turns a routine review into a prolonged one. A concrete version of this failure shows up often enough to be worth naming directly. A boundary diagram includes a managed logging service as an in-scope component. The data flow diagram, drawn separately, never shows data actually flowing into that service. The control narrative for the audit logging control describes the logging service in detail as the mechanism satisfying the requirement. An assessor reading all three together has a legitimate question: does log data actually reach this component, or was it added to the boundary diagram to make a control narrative look complete after the fact. Reconciling these three documents against each other, line by line, before submission is unglamorous work, but it is the specific work that prevents this exact question from ever being asked. The Inheritance Trap A provider building on infrastructure that already holds its own FedRAMP certification can inherit a portion of the control responsibility from that underlying provider, which meaningfully reduces the SSP’s scope of original documentation. This only works cleanly when the shared responsibility matrix assigns every inherited control explicitly, to the underlying provider, to the organization itself, or to both, with no control left in an ambiguous middle where each party assumes the other has it covered. A control that both parties assume the other documents is a control neither party actually implements, and it surfaces as a finding at the worst possible time, during the independent assessment rather than during internal review. Physical and environmental protection controls are a common site for this gap. A provider hosting its service on a certified cloud infrastructure platform may reasonably assume that facility-level physical security is entirely the infrastructure provider’s responsibility and requires no mention in its own SSP. That assumption is correct for the physical facility itself, but it does not automatically extend to every physical or environmental control in the family, some of which may depend on how the provider’s own equipment or configuration within that facility is managed. Confirming, control by control, exactly where the inherited responsibility ends and the provider’s own responsibility begins, rather than inheriting the entire family as a block, is what keeps this specific gap from surfacing during assessment. The “Not Applicable” Trap Marking a control as not applicable is sometimes the correct scoping decision and sometimes a shortcut that creates a bigger problem than it solves. A control marked not applicable when the offering’s actual architecture invokes it is one of the fastest ways to stall a review, because an assessor who finds the use case the SSP denied has grounds to question the reliability of every other applicability decision in the document, not just the one they caught. Every not-applicable determination should be traceable to a specific architectural reason, documented in the SSP itself, not asserted without support. A Different SSP for a Different Framework Organizations working across multiple compliance programs sometimes conflate the FedRAMP SSP with the System Security Plan required under CMMC, since both frameworks use the same document name and both trace back to NIST-based control catalogues. The two are not interchangeable. A CMMC SSP documents implementation of NIST SP 800-171 controls protecting Controlled Unclassified Information on a defense contractor’s own systems, while a FedRAMP SSP documents NIST SP 800-53 Rev 5 controls within a cloud service offering’s authorization boundary for the purpose of agency reuse. An organization holding both a FedRAMP-authorized product and a CMMC obligation on its
FedRAMP Consulting: What the CR26 Advisor Role Changes
FedRAMP consulting used to operate in a gray zone. Advisory firms helped cloud service providers navigate authorization, but the program itself had no formal category for what they did, no listing process, and no accountability structure distinguishing a firm that genuinely knew the framework from one that had simply decided to sell FedRAMP services. The Consolidated Rules for 2026 closed that gap. CR26 now defines Advisor as one of five formal stakeholder categories in the program, alongside FedRAMP itself, agencies, cloud service providers, and independent assessors, with its own published rules covering who can claim the role and what they owe the program in return. This article explains what that change actually means, what CR26 now requires of a FedRAMP advisor, how it should reshape the build-versus-buy decision a provider faces, and what a buyer should verify before hiring one. Why FedRAMP Consulting Just Became a Formally Defined Role For most of FedRAMP’s history, advisory work sat outside the program’s formal structure entirely. A provider could hire any firm claiming FedRAMP expertise, with no external mechanism to verify that claim beyond reputation and references. CR26 changes that by giving advisors a defined place in the program’s rules, not a special status, but a defined one with real obligations attached. The Five CR26 Stakeholder Categories CR26 organizes the entire FedRAMP program around five stakeholder groups, each with its own section of published rules: FedRAMP itself, which sets and administers the rules; agencies, which consume authorized cloud services; cloud service providers, which build and operate the systems being certified; independent assessors, which perform the assessments that support certification; and advisors, which help providers navigate the process without performing the assessment themselves. Structuring the rules this way means every stakeholder category, including advisors, now has a defined scope of responsibility rather than an implicit one inferred from industry practice. What “Advisor” Means Under CR26, Specifically Under CR26, an advisor is explicitly not an independent assessor. Advisory services help a provider understand the rules, map its current state against the framework, plan a certification path and class, and prepare for assessment, but they do not perform the assessment itself and cannot grant any official status. A company may offer both advisory and assessment services, but CR26 requires it to clearly specify which capacity it is acting under at any given point in the certification process. This distinction is not a formality. Assessment independence is a core integrity mechanism in the program, and blurring the line between advising a provider and assessing it undermines the credibility the whole certification depends on. How Advisors Fit Between the Other Stakeholder Roles An advisor’s position in the CR26 structure sits deliberately outside the direct line between provider and assessor. The cloud service provider owns the certification and bears responsibility for its accuracy. The independent assessor evaluates the provider’s evidence and forms an independent judgment the agency relies on. The advisor sits alongside that relationship, helping the provider prepare, without inserting itself into the evaluation itself. This positioning is what makes the advisory-versus-assessment separation so consequential: an advisor that starts acting like a shadow assessor, effectively pre-grading the provider’s readiness in a way the provider then presents to the real assessor as settled fact, quietly compromises the independence the entire structure exists to protect, even if no rule is technically broken in the process. Why This Matters More Than Terminology A skeptic might read this as a rename with no practical consequence. That reading misses what actually changed. Before CR26, a buyer evaluating FedRAMP consulting firms had no external reference point to check a claim of expertise against. Now, the program itself publishes rules that a legitimate advisor operates under, which means a buyer has something concrete to verify rather than a sales pitch to take on faith. The formalization did not create new competence requirements for advisors. It created a public standard a buyer can check a firm against, and that shifts real leverage toward the buyer. What the Pre-CR26 Market Actually Looked Like Before this ruleset, the FedRAMP consulting market ran almost entirely on reputation, referrals, and self-description. A firm could describe itself as a FedRAMP expert on its own website with no external body confirming or disputing that claim, and a buyer’s only real recourse was calling references and hoping those references were representative rather than cherry-picked. This produced a market where the loudest marketing often outcompeted the deepest expertise, because nothing structurally rewarded the difference. The FedRAMP PMO changes that came with 20x already signaled the program moving toward more structured, verifiable participation across every stakeholder group, and the formal Advisor category is that same shift applied specifically to the consulting layer that sits outside the certification boundary itself but heavily influences how providers reach it. What CR26 Actually Requires of a FedRAMP Advisor The rules governing advisors are specific enough to function as a genuine due-diligence checklist, not just a description of the category. Three sets of requirements matter most to a provider evaluating consulting support. Website and Disclosure Requirements Under rule MKT-CAS-WEB, an advisor seeking a Marketplace listing must maintain a public website that supplies, in both human-readable and machine-readable format, a general description of the consulting or advisory service, contact information, the specific types of consulting or advisory services offered, and optionally, positive attestations from customers or customer references. This is a low bar in isolation, but it is a bar every legitimate, currently listed advisor has already cleared. A firm that cannot point to a website meeting this standard is either not listed or has let its listing lapse, both of which are worth asking about directly before signing anything. The Marketplace Listing Process Rule MKT-CAS-LRQ requires an advisor to complete a formal Advisor Listing Request Form to be listed in the FedRAMP Marketplace. FedRAMP does not review or endorse the substance of an advisor’s work, but it does maintain a centralized set of listings tracking which firms have gone through this process and meet the baseline information-sharing requirements. A
FedRAMP Vulnerability Management: The 2026 VDR Deadline
FedRAMP vulnerability management is being rebuilt, and the deadline is closer than most providers realize. On December 7, 2026, two new rulesets, Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER), become mandatory for every cloud service offering that holds or seeks FedRAMP Certification. A grace period runs to March 7, 2027, after which certification is revoked for any offering not following the rules. This is not a FedRAMP 20x-only change. It reaches every Rev5 provider in the Marketplace, and it lands before the mandatory 20x adoption date. This article explains where the rule came from, what VDR and VER require, how the new risk-based prioritization model works, why multi-tenant architecture changes the math, what an agency reviews, and the concrete steps a provider needs to take before the December deadline. Why FedRAMP Vulnerability Management Changed in 2026 For years, FedRAMP vulnerability management ran on a fixed clock. Scan on a set cadence, score each finding by severity, and remediate inside flat windows tied to that severity. The model was simple to audit and poor at distinguishing a critical flaw on an internet-facing authentication service from an identical score on an isolated internal tool. In 2026 the program replaced that clock with a risk-based model, and it did so on a compressed timeline. The Directive Behind the Rule The change traces to CISA Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued on June 10, 2026. The directive pushes federal cybersecurity away from remediating raw scanner counts and toward prioritizing vulnerabilities that are internet-reachable, exploitable, and known to be exploited. A binding operational directive, on its own, binds federal civilian executive branch agencies. It does not reach a private company directly, which is the detail that makes the next step matter. How the Directive Became a CSP Requirement FedRAMP closed that gap with Public Notice NTC-0014 on June 16, 2026, which folds the directive’s risk model into the Consolidated Rules for 2026 through the VDR and VER rulesets. This is the mechanism that makes the model bind a cloud service provider: not the directive itself, but FedRAMP adopting it as a condition of certification. Any provider that follows the VDR and VER rules meets the timelines, prioritization requirements, and approach set out in the directive. A provider that does not follow them puts its certification at risk regardless of how the underlying directive is worded. The Deadline That Arrives First The single most useful thing to take from this change is the calendar, because the compliance dates do not land together. The table below sequences the dates that matter for an existing provider. Date Event What it means for a certified provider June 10, 2026 CISA BOD 26-04 issued The risk-based model is set for federal agencies June 16, 2026 FedRAMP NTC-0014 published The model becomes a condition of FedRAMP Certification December 7, 2026 VDR and VER mandatory Non-compliance begins for any offering still on the legacy process March 7, 2027 Grace period ends Certification revoked for offerings not following the rules January 1, 2027 Broader Consolidated Rules mandatory for Rev5 A separate, later obligation than the vulnerability deadline The order in that table is the point. VDR and VER become mandatory on December 7, 2026, which is earlier than the January 1, 2027 mandatory adoption of the broader Consolidated Rules for existing Rev5 providers. A provider tracking only the 20x transition calendar can miss the vulnerability deadline entirely, because it arrives first and is driven by an external directive rather than by the 20x rollout. The original plan was gentler, with mandatory adoption set for June 1, 2027 and a grace period into 2028. That timeline was pulled forward, which is the reason this now demands attention in the current quarter rather than next year. What the VDR and VER Rules Require The two rulesets work together. VDR defines how a provider detects, prioritizes, and responds to vulnerabilities under a risk model. VER contains the evaluation and reporting rules drawn from the VDR, separated into their own ruleset for convenience. Together they replace the legacy scan-and-remediate cadence that has defined FedRAMP continuous monitoring since the program began. The table below contrasts the legacy model with the model that becomes mandatory in December. Dimension Legacy scan model VDR and VER model Prioritization basis CVSS severity tier in isolation Impact, exploitability, and reachability in context Remediation clock Flat windows by severity Timeframe driven by contextual risk rating Reporting Monthly scan output Structured, machine-readable evaluation and response records Focus Clear the scanner queue Address internet-reachable, exploitable, known-exploited findings first The shift in that table is not cosmetic. Under the legacy model, a provider could spend engineering capacity remediating a high-severity finding on an asset that holds no federal data and has no path from the internet, while a genuinely dangerous finding waited in the same queue. The new model forces each finding to be evaluated against what the affected asset actually does, whether it is exposed, and whether it is being exploited in the wild. That is a more defensible use of finite engineering time, and it is now a certification requirement rather than an option. The End of the Flat Scan Clock The legacy cadence assigned fixed remediation windows by severity, commonly 30 days for critical and high findings, 90 for moderate, and 180 for low. The VDR model retires that flat clock. Remediation timeframes now derive from a contextual rating, which means two findings with identical scanner scores can carry very different deadlines depending on the asset they sit on and their real exposure. Providers that have built their entire vulnerability workflow around the flat clock will find that the workflow itself, not just the paperwork, has to change. The New Prioritization Model: Impact, Exploitability, and Reachability At the center of the VDR model is a structured way to rate how much a given vulnerability actually threatens a federal agency. This replaces severity-in-a-vacuum with a rating that reflects context, and it is the part of
FedRAMP Significant Changes: Adaptive, Transformative, Recurring
The FedRAMP annual assessment is what many cloud providers still search for, and the honest answer is that under the 2026 Consolidated Rules it is no longer how ongoing authorization works. The once-a-year assessment event was a feature of the Rev5 era. FedRAMP now runs on Collaborative Continuous Monitoring, a model built on current, shared information rather than a periodic checkpoint. This guide explains what the annual assessment was, what replaced it, and what continuous evaluation actually means for a cloud service provider day to day. The shift is not cosmetic. Moving from an annual assessment to continuous monitoring changes when you do the work, how agencies see your posture, and what you have to sustain between authorizations. Providers who prepare for the old rhythm, cramming for a yearly event, will be working against a model that expects current evidence all the time. What the FedRAMP Annual Assessment Was Under Rev5, ongoing authorization leaned on a periodic assessment cadence, and the annual assessment was its anchor. Rather than reviewing every control every time, the traditional approach reviewed a rotating selection of controls at each annual assessment, so the full control set was covered over successive cycles. The annual assessment was a scheduled event: a point in the year when an assessor examined a portion of the environment and the authorization was refreshed on the strength of that review. That model made sense when authorization information moved on paper and in periodic packages. Its weakness was the gap between checkpoints. A posture confirmed at an annual assessment could drift over the following months, and the agency relying on that authorization had limited visibility into the drift until the next cycle. The 2026 rules were written to close that gap, which is why the annual assessment gave way to something continuous. What Replaced It: Collaborative Continuous Monitoring Under the Consolidated Rules, ongoing authorization runs on Collaborative Continuous Monitoring. The purpose of the model is to let agencies use shared, current authorization information from providers as part of each agency’s own continuous monitoring strategy, encouraging automated monitoring and review while leaving each agency to make its own risk-based decisions about ongoing authorization. The word that matters is current: the model is built on information that stays up to date rather than a snapshot taken once a year. Two defined artifacts carry the model, and together they replace the annual event with a continuous rhythm. The Ongoing Certification Report The Ongoing Certification Report is a regular report that a FedRAMP Certified provider supplies to its agency customers under the Collaborative Continuous Monitoring rules. It is the continuous stream of authorization information that keeps agencies current on the provider’s posture, and it is the mechanism that removes the long silence between annual checkpoints. Instead of a once-a-year package, the agency receives regular, current reporting it can act on. The Quarterly Review The Quarterly Review is a regular synchronous meeting a FedRAMP Certified provider hosts for its agency customers, also under the Collaborative Continuous Monitoring rules. Where the Ongoing Certification Report is the flow of information, the Quarterly Review is the conversation: a scheduled touchpoint where the provider and its agency customers discuss posture, changes, and risk directly. It gives the collaboration in continuous monitoring a cadence without returning to a single annual event. Legacy annual assessment (Rev5) Collaborative Continuous Monitoring (CR26) Cadence Periodic, a once-a-year assessment event Continuous, with regular reporting and quarterly reviews Form A rotating selection of controls reviewed each year An Ongoing Certification Report plus a synchronous Quarterly Review Agency role Reviews the annual result Uses shared, current information for its own risk-based decisions Provider posture Prepare for a yearly event Sustain current evidence continuously The table makes the real change visible: the work moved from a concentrated annual push to a continuous obligation, and the agency moved from receiving a periodic result to using live information for its own decisions. That second shift is easy to miss and important, because each agency now makes its own ongoing risk-based decision from current data rather than deferring to a single annual verdict. What Continuous Evaluation Means for CSPs For a provider, the practical change is that authorization evidence is now something you sustain, not something you assemble once a year. The environment has to stay in a state where current information can be reported at any time, which rewards automation and continuous internal monitoring over periodic scrambles. The providers who adapt best treat the Ongoing Certification Report as a byproduct of well-run operations rather than a document they generate on a deadline. The Quarterly Review changes the relationship with agency customers as well. A regular synchronous meeting means posture and changes are discussed while they are current, not reconstructed after the fact, which raises the value of keeping your significant-change classification and your monitoring data clean and ready. Continuous evaluation is less forgiving of drift than an annual cycle, but it is also less likely to produce a nasty surprise at a single high-stakes checkpoint. For the full detail of how ongoing monitoring works under the new rules, see what is changing in FedRAMP continuous monitoring for 2026, and for the operational picture after authorization, see FedRAMP continuous monitoring after your authorization. How to Prepare for the Shift Preparing for continuous monitoring is mostly about operating as if you are always being observed, because under this model you effectively are. Keep monitoring data current and automated so that the Ongoing Certification Report reflects reality without a manual push. Build the Quarterly Review into your calendar as a standing commitment to your agency customers rather than an ad hoc meeting. And keep the discipline around change and evidence tight between reviews, because the model assumes your reported posture is always accurate. The transition also has timing. Existing Rev5 authorizations do not vanish the day the new rules take effect; they continue through a defined transition while providers move onto the Certification model, and the annual-assessment cadence persists for those authorizations until they convert.