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.
FedRAMP Significant Changes: Adaptive, Transformative, Recurring
A FedRAMP significant change used to be a single, heavy trigger: alter your authorized system in a meaningful way and you faced a re-assessment conversation with no gradation. Under the Consolidated Rules for 2026, that changed. FedRAMP now sorts significant changes into defined categories, each with its own expectations, so the effort you face depends on the kind of change you are making rather than the fact that you made one. This guide defines each category from the official rules and explains what it means for your authorization. The reason the categories exist is practical. The 2026 significant change framework is built so that providers can keep improving their service while agency customers stay informed and can judge the risk of each change. Sorting changes by risk lets a low-risk update move quickly and reserves deep scrutiny for the changes that actually warrant it. Knowing which category a change falls into is therefore the first decision you make when you change an authorized service. What Counts as a FedRAMP Significant Change FedRAMP takes its base definition from NIST SP 800-37 Revision 2: a significant change is a change that is likely to substantively affect the security or privacy posture of a system. The word doing the work is substantively. Routine maintenance that does not move your security posture is not a significant change; a modification that could alter the risk picture is, and it triggers the notification framework regardless of which category it lands in. Under the 2026 rules, the Significant Change Notification framework organizes these changes into categories so that agencies can understand the expected risk of each one and make authorization decisions accordingly. The categorization is not paperwork for its own sake. It is the mechanism that lets a provider act on its own product while keeping the authorizing agency in the loop, and it is why classifying a change correctly matters as much as making it well. For the wider context of how an authorization is earned and kept, see what FedRAMP compliance involves. The FedRAMP Significant Change Categories The rules define three primary categories of significant change, separated by how much new security risk the change introduces. The distinction between them is a risk judgment, and it drives everything that follows. Adaptive Change An adaptive change is one that does not routinely recur and does not introduce substantive potential security risks that need to be assessed in depth. These are the deliberate, planned changes that are real but low-risk: they focus on engineering execution rather than changing how a customer uses the service, can be verified with minor updates to existing validation procedures, and do not force large changes to operational procedures, deployment plans, or documentation. An adaptive change is significant enough to notify on, but not significant enough to reopen your risk determinations. Transformative Change A transformative change is one that introduces substantive potential security risks that are likely to affect existing risk determinations and must be assessed in depth. These are the heavy changes: major new features or capabilities that may change how a customer uses the service, in whole or in part, and that require extensive updates to your security assessment, operational procedures, deployment plans, and documentation. A transformative change is the category that most resembles the old, single notion of a significant change, and it carries the deepest assessment expectation. Routine Recurring Change A routine recurring change is one that regularly and routinely recurs as part of ongoing operations, vulnerability mitigation, or vulnerability remediation. These are the changes you make constantly to keep a service secure and running, and the category exists so that necessary, repetitive work is not treated as if each instance were a novel event. Because the pattern is predictable, this category is handled as part of established operations rather than as a series of one-off notifications. Change category What it is Assessment expectation Adaptive Does not recur routinely and does not introduce substantive new security risk needing in-depth review Light: engineering-focused, minor validation updates, no major documentation change Transformative Introduces substantive potential risk likely to affect existing risk determinations Deep: assessed in depth, extensive assessment and documentation updates Routine recurring Regularly recurs as part of operations, vulnerability mitigation, or remediation Handled within established, repeatable operations The table separates the three by assessment expectation, and that is the practical axis: the category you assign determines how much work the change creates and how closely the agency will look at it. The risk in the framework is not the heavy category, it is misassigning the light one, because labeling a transformative change as adaptive to avoid an in-depth assessment is exactly the kind of misclassification that can put an authorization at risk when the agency reviews it. Certification Class Change: A Distinct Fourth Type Beyond the three notification categories, the rules define a fourth type worth understanding on its own: a certification class change. This is a significant change that is likely to change the FedRAMP Certification class for the entire cloud service offering, for example moving it from one class to another. It is distinct because its effect is not on a single risk determination but on the classification of the whole offering under the 2026 structure. If a change would move your service into a different Certification class, it is not just another adaptive or transformative change to notify on; it reshapes how the offering is authorized. Treat a potential class change as its own conversation, because it touches the foundation of your authorization rather than a component within it. What Significant Changes Mean for Your Certification The categories exist to keep your authorization intact while your service evolves, and the way they do that is by matching scrutiny to risk. A routine recurring change keeps security work flowing without repetitive notifications. An adaptive change is notified and handled lightly. A transformative change gets the in-depth assessment it warrants before it can be considered part of your authorized baseline. The framework, in other words, lets you keep
FedRAMP Gap Assessment: What It Covers, Costs, and Delivers
A FedRAMP gap assessment is the diagnostic that measures your cloud service against what FedRAMP actually requires before you commit to the formal authorization process, and it exists to answer one question: how far are you from authorized, and what will it take to close the distance. This guide explains what the assessment covers, what drives its cost, what it delivers, and how its findings map to your certification path, so you can tell a scoping conversation from a sales pitch when you go looking for one. The reason this matters more in 2026 is that FedRAMP’s requirements changed shape. Under the Consolidated Rules for 2026, the program expresses its requirements as Key Security Indicators rather than a static control checklist, and the submission artifacts changed with them. A gap assessment built on the old baseline measures you against the wrong target, so understanding what a current gap assessment covers is the first step in buying one that is worth the money. What a FedRAMP Gap Assessment Is and Is Not A FedRAMP gap assessment is an advisory diagnostic. It reviews your cloud service as it exists today, compares that reality against the FedRAMP requirements you will be measured on, and produces a prioritized picture of what is missing. It is preparation work, done before you enter the formal process, and its purpose is to remove surprises from an assessment that is expensive to fail. It is not the independent assessment that authorizes you. Under FedRAMP, an accredited third-party assessment organization performs the formal evaluation that leads to a FedRAMP Authorized designation, and that role is deliberately separate from advisory work. An advisor helps you get ready; the assessor independently judges whether you are. Elevate performs gap assessments as an advisor, which under the 2026 rules is a distinct and recognized role, and keeping that line clear protects the independence the formal assessment depends on. A firm that offers to both prepare you and independently assess you is blurring a line that FedRAMP draws on purpose. It is also narrower than a readiness engagement. A gap assessment is the point-in-time diagnostic that finds the gaps; the broader work of preparing a service to succeed, including remediation and provider selection, is covered in FedRAMP readiness assessment services. The gap assessment is where that broader effort starts, because you cannot plan remediation you have not yet scoped. What a FedRAMP Gap Assessment Covers The assessment measures three things: the requirements you must meet, the boundary they apply to, and the evidence you can produce today. Each shapes the findings, and each is where an assessment can be scoped too narrowly or too broadly. The Requirements It Measures Against Current FedRAMP requirements are expressed as Key Security Indicators, grouped into families that span identity and access management, change management, incident response, monitoring and logging, cloud-native architecture, supply chain risk, and more. A gap assessment works through those indicators and asks, for each one, whether your service meets it, partially meets it, or does not. Because the ruleset is machine-readable and versioned, the assessment measures against the version in force at the time, which is why a current gap assessment cannot rely on a control list carried over from the previous FedRAMP model. The Boundary It Examines FedRAMP requirements apply to your authorization boundary, the defined set of components that make up the service being authorized. The gap assessment examines that boundary: what is inside it, how data flows across it, what it connects to, and what it inherits from an underlying authorized platform. A boundary that is loosely defined produces a loose assessment, so part of the diagnostic is pressure-testing the boundary itself before measuring what is inside it. The Evidence It Reviews FedRAMP is proven through evidence, so the gap assessment reviews what you can actually show. It looks at whether your implementation is documented in a form that will populate the Certification Package Overview and the Security Decision Record, the artifacts that replaced the standalone system security plan under the 2026 rules. Where a control is implemented but undocumented, that is a gap the assessment records, because in a FedRAMP evaluation an undocumented control is treated as an unmet one. What Drives the Cost of a FedRAMP Gap Assessment There is no single price for a FedRAMP gap assessment, because the effort scales with the service being assessed. Rather than quote a number that would not survive contact with your environment, the honest way to understand cost is through the factors that move it. Cost driver Why it moves the cost Boundary size and complexity More components, integrations, and data flows mean more to review against each indicator Cloud architecture A cloud-native design maps to current requirements more directly than a lifted-and-shifted one Current security maturity Mature controls need confirmation; immature ones need discovery, which takes longer Documentation state Accurate existing documentation shortens the review; its absence lengthens it Inherited controls Building on an already-authorized platform reduces what must be assessed in your own boundary The pattern across these drivers is that cost tracks discovery, not size alone. A large but well-documented, cloud-native service can assess faster than a small one whose controls are real but unwritten, because the assessment spends its time finding and confirming rather than measuring. This is why an accurate quote requires a scoping conversation rather than a form: the drivers interact, and only your actual boundary determines where they land. The one thing that reliably raises cost is discovering late that the boundary was wrong, which is precisely what the assessment exists to prevent. What a FedRAMP Gap Assessment Delivers The output of a gap assessment is not a pass or fail; it is a plan. A useful one delivers two things you can act on and one thing you can decide with. The Findings Report The findings report records the state of each requirement: met, partially met, or unmet, with the evidence reviewed and the specific shortfall named. It is organized so that the