RFC-0020: FedRAMP Authorization Designations #110
Replies: 33 comments 33 replies
-
|
Should 20x Level 5 and 6 mention Validation instead of Certification package in the table? |
Beta Was this translation helpful? Give feedback.
-
|
I think this is somewhat confusing: Some of the BIR stuff is beta, or must be done in conjunction with a CSP's AO, and cannot be unilaterally achieved. So someone might be stuck at level 3 somewhat involuntarily and then would appear to be 'less good' than a potential competitor at level 4. If that's the intended result, I'm not sure it should be. At the very least, I'd like to see 'no one can get level 4/6 until all of the BIR stuff is in general release and non-optional' |
Beta Was this translation helpful? Give feedback.
-
|
I also (and have commented on this elsewhere) worry about the stigma of 'corrective action' if corrective action is unclearly defined without means for appeals. Basically we don't want anyone penalized for a good faith disagreement over an particular requirement that may not be as clear as intended. Also, does it make sense to adjust these to ''unaddressed corrective action' or something to that effect. If someone fixes the underlying cause of the CAP, I'm not sure it makes sense from a risk acceptance perspective to keep that as a black mark. It's not necessarily indicative of a lack of rigor or due care (particularly in light of good faith disagreements). |
Beta Was this translation helpful? Give feedback.
-
|
The differences between the FedRAMP "certified" designation and the FedRAMP "validated" designation are not clear. How will these different designations be used to acquire new CSPs? Will RFPs specify a solution must be FedRAMP "certified" rather than FedRAMP "validated"? It is difficult enough trying to educate everyone on these terms and the nuances won't be understood by most people. Suggest going with 1 designation that means you've successfully been through the process (regardless of whether it is Rev5 or 20x), especially with Rev5 being phased out (and with Rev5 possibly temporarily opening up for no sponsorship). Which gets to another point: why does any of this process hinge on Federal sponsorship? That is out of industry control and shouldn't be baked into this process at all. FedRAMP can vet a CSP solution irrespective of whether a federal agency is sponsoring it or not. And even though the 20x pathway does not require a sponsor, industry will still have to pay hundreds of thousands of dollars each year to re-do a 3PAO review if they have no sponsor. Why? You've already vetted the CSP and they are doing continuous monitoring. It is still a heavy financial burden for businesses. Thanks for your consideration of these items. |
Beta Was this translation helpful? Give feedback.
-
|
A few questions as I work through this: On the level definitions - The descriptions use phrases like "typical amount of information" (Level 3) versus "significant amount of information" (Level 5), but I'm not seeing the underlying NIST control mappings that would make these levels concrete. For Rev5, we have well-understood Low/Moderate/High baselines tied to SP 800-53. What's the equivalent for these new levels? Is Level 3 still the ~325 controls from Moderate, or is that changing? Without that anchor, it's hard to know what a CSP is actually committing to at each tier - and what an agency should expect to find in the package. On the problem this solves - The motivation section identifies a real issue: agencies sometimes adopt FedRAMP services without reviewing the package or issuing their own ATO, assuming someone else is handling oversight. That reads to me like a governance gap, not a terminology gap. Will calling it "Certified" instead of "Authorized" actually change that behavior? I'm genuinely curious what mechanisms exist (or are planned) to ensure agencies do the work on their side - reviewing packages, making risk determinations, issuing ATOs. If those mechanisms don't exist, renaming gives agencies new terminology to skip over rather than fixing the underlying accountability problem. One concrete suggestion - The Levels 1-6 naming is going to collide with DISA's Impact Levels (IL2, IL4, IL5, IL6) in procurement conversations. They mean completely different things, but program offices often conflate FedRAMP and DISA requirements already. Would something like "Assessment Tier" or "Coverage Tier" instead of "Level" help distinguish these? Or even just avoiding the specific numbers DISA uses (2, 4, 5, 6)? |
Beta Was this translation helpful? Give feedback.
-
|
Having discussions with customers on this RFC and others. Has the PMO given any thought to the perception / optics of FedRAMP Certified vs. FedRAMP Validated, where agencies may interpret "Certified" as more robust than "Validated" or vice versa? |
Beta Was this translation helpful? Give feedback.
-
|
Gap #1 Gap #2 Gap #3 Gap #4 Gap #5 Gap #6 Gap #7 |
Beta Was this translation helpful? Give feedback.
-
|
General Concern About FedRAMP Certified (Rev5) Timing: If the sole change is terminology, simply update the wording from "FedRAMP Authorized" to "FedRAMP Certified" (e.g., "FedRAMP High Certified") without introducing numbered levels. If FedRAMP proceeds with new certification levels:
Regarding the Motivation Section: Renaming authorizations to "Level X FedRAMP Certified" will not address this misconception. This is fundamentally a training and education issue that requires targeted interventions beyond terminology changes. Related Recommendation: I have had to explain to government customers that my Appendix K FIPS 199 categorization is not one for one applicable to their specific use case and that they must conduct their own system categorization. |
Beta Was this translation helpful? Give feedback.
-
|
We strongly support the transition to a number-based level system, which better reflects assessment depth and aligns with DISA’s mission and operational needs. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Observations.
With the DoD/DoW placing a priority on speed and innovation, they will need to leverage compliant commercial cloud extensively. The ability to go through a sponsorless certification process is a no-brainer compared to deploying the app inside a DoD/DoW cloud, if the addressable market is there for the right scale. |
Beta Was this translation helpful? Give feedback.
-
|
I'm only here because of Pete's engagement farming post on LinkedIN last night.
So for example, Wayne Enterprises holds a "Validated High 80" on their CSO BatGadgetsGov. But their competitor, Queen Consolidated holds a "Validated Moderate 90" on their CSO Arrows'R'Us GovCloud. |
Beta Was this translation helpful? Give feedback.
-
|
Mostly adding support to these sentiments which were more thoroughly framed in other comments:
|
Beta Was this translation helpful? Give feedback.
-
Feedback: FedRAMP Authorization Designations (Level 1-6)Thank you for RFC-0020 proposing authorization level nomenclature (Levels 1–6) to decouple FedRAMP authorization designations from federal impact categorization (FIPS 199 or successor). I support this modernization. My review confirms RFC-0020 is FISMA-compliant and does not create statutory conflicts. Summary: Compliance Assessment✅ FISMA Compliant: RFC-0020 does not conflict with FISMA (44 U.S.C. § 3544) requirements. Agency AOs retain full authorization authority; RFC-0020 only changes nomenclature and decouples FedRAMP authorization levels from agency categorization decisions. ✅ FAR Compliant: FAR Part 39 (cloud services procurement) requirements unchanged; CSPs must still meet federal security standards. RFC-0020 aligns with FAR 2.0 modernization efforts to simplify and standardize procurement processes. ✅ OMB M-24-15 Aligned: Supports modernization intent; removes false equivalence between FedRAMP levels and FIPS 199 impact categories. Implementation Support AreasArea #1: Procurement Language Updates (FAR Part 39 Contracts & FAR 2.0 Alignment)Issue: Federal agencies use RFQs that reference FedRAMP Low/Moderate/High levels. RFC-0020 changes this to Levels 1–6. What Agencies Need:
Recommendation: FedRAMP should develop and publish (in parallel with RFC-0020 implementation) a "Procurement Language Modernization Guide" showing pre/post RFC-0020 contract language. Area #2: Transition Timeline ClarityIssue: RFC-0020 changes FedRAMP Marketplace listings from Low/Moderate/High to Levels 1–6. Agencies and CSPs need a clear transition period. Questions for PMO Clarity:
Recommendation: Publish transition timeline showing:
Area #3: Nomenclature Mapping (Current vs Proposed)Issue: RFC-0020 introduces Levels 1-6, but agencies already track multiple overlapping labels. Without a clear crosswalk, this creates a confusing triple or quadruple mapping between:
Why This Matters: AOs, contracting officers, and CSPs will need to translate among these terms for RFQs, ATO decisions, and Marketplace listings. If the crosswalk is not explicit, agencies risk mixing authorization designations with impact categorizations. Recommendation: Publish a one-page crosswalk table and use it consistently across guidance, Marketplace listings, and procurement templates. Example format:
Include a note that FIPS 199 impact category remains an agency decision, while FedRAMP Levels represent authorization designations based on standardized baselines. Area #4: AO Tooling & Guidance for Decoupling DecisionProblem: RFC-0020 says FedRAMP level ≠ agency impact category. But AOs need guidance on when to accept a lower FedRAMP level for a higher-impact system (if ever acceptable). Example Scenario:
Current RFC-0020 Gaps: Agency Contexxt Feedback:
Recommendation:
Area #5: Control Baseline Clarity NeededIssue: RFC-0020 Levels map to NIST SP 800-53 control baselines. But baselines are not static—NIST may update SP 800-53r6 or beyond. Question for PMO: Example concern:
Recommendation:
Testing Recommendation: Pilot with GSA IT ScheduleSuggestion:
Timeline: Pilot with ~50 GSA Schedule IT services (March–June 2026), then roll out to full Marketplace (July–Sept 2026). ClosingRFC-0020 is legally sound and operationally beneficial. Decoupling FedRAMP levels from impact categories gives AOs necessary flexibility while maintaining NIST baseline rigor. I recommend focusing implementation effort on:
I am willing to support GSA pilot testing in a personal capacity if FedRAMP seeks public input. Submitted by: Trevor Lowing (private citizen, personal capacity) |
Beta Was this translation helpful? Give feedback.
-
|
Overall, I support the intent of clarifying designations and separating FedRAMP from agency ATO language. That said, a few concerns stand out.
On a positive note, I have strong support for publishing target assessment completion timelines. Clear performance targets and turnaround metrics help both agencies and CSPs plan effectively and hold the process accountable. 🎯👏 |
Beta Was this translation helpful? Give feedback.
-
The Cloud Service Providers - Advisory Board submits the following comments.Motivation - a FedRAMP authorization at a given traditional NIST FIPS 199 securityobjective (Low, Moderate, High) does not necessarily align with the security objective of an agency information system that reuses that FedRAMP authorization.
Rev5 Certified Levels
Certified Level 4
Certified Level 6: This level also means that the cloud service provider has implemented all Rev5 Balance Improvement Releases and met nearly all recommendations from FedRAMP with no corrective action for the past year.
Marketplace Lifecycle for Rev5: The target time for this step is less than 30 days if the package is truly complete.
20x Validated Levels
|
Beta Was this translation helpful? Give feedback.
-
|
The current 1-6 level structure directly conflicts with DISA’s Impact Levels and lacks a clear framework for equivalency. To ensure clarity and utility, Rev5 certified levels should maintain parity with existing governmental standards. While the rationale for Validated levels is clear, the transition from Validated to Certified remains problematic without an Authority to Operate (ATO). As the preference for Certified status consistently outweighs Validated levels, any interim stages offer limited value to companies pursuing authorization. Currently, MaintainX has a package prepared for agency review; however, we are unable to proceed due to the lack of a clear authorization path. We suggest establishing recognizable equivalencies from the upper Validated levels to lower Certified levels to facilitate this process for providers. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with the representative from GovRAMP's opinions fully. I want to also state that RFC's language is misleading and burying the lead on the impact of RFC-0020. This RFC should be kicked back and broken up into 2-3 proposals. A lot of the feedback is good but we are peeling the onion instead of remember we came for an apple. The title and summary make it seem like this is just about changing verbage however This RFC does two other things:
In its current state I see it as a boon for 20X CSPs and their sales teams but harmful and confusing to established Rev 5 CSPs or newcomers that can't afford a FedRAMP build and a real advisor to help them navigate these changes. |
Beta Was this translation helpful? Give feedback.
-
Posting Comments on Behalf of Fortreum, LLCGeneral Comment – FedRAMP Certified (Rev5)These levels, while intending to simplify the approach, add additional complexity once the Rev5 Balance Improvement Releases (BIRs) are incorporated at Levels 4 and 6. For example, if a CSP maintained a FedRAMP Moderate authorization and implemented all BIRs, they would arguably be meeting more FedRAMP requirements at the assigned Level 4 than a FedRAMP High authorized CSP assigned Level 5. SuggestionReduce the levels to 1–4:
Add an additional identifier for CSPs meeting all BIRs and having no CAPs for the past year:
General Comment – FedRAMP Validated (20x)Similar logic and reasoning as the Rev5 approach applies here. Detailed CommentsComment 1Section: Motivation, first paragraph The explanation does not tell the whole story clearly. It states:
However, a FedRAMP ATO on the Marketplace does indicate that the CSO has been granted an ATO by at least one agency or the JAB. Therefore, at least one agency has authorized it. This should be clarified. Suggested addition: Even though a CSO is listed on the Marketplace as having an ATO, each agency AO must review the package and authorize their own agency’s use of that CSO. Comment 2Section: Motivation, paragraphs two and three Confusion about what FedRAMP authorization means can be addressed through better education rather than adding more paths. The logic here is not entirely valid. Adding new paths will likely increase confusion, particularly for those new to FedRAMP who are already trying to understand the distinctions between authorization, certification, and validation. Comment 3Section: Motivation, paragraph six The RFC states:
However, the document does not later describe any changes to 3PAO assessment requirements or monitoring requirements. It only discusses package completeness requirements. This should either be clarified or aligned with the stated intent. Comment 4Section: FedRAMP Certified (Rev 5), first paragraph Is “FedRAMP Certified” the new agency-less path described in RFC-0023? If yes:
Comment 5Section: FedRAMP Certified (Rev 5), first paragraph The text states:
If so, consider renaming this to “FedRAMP Program Authorization” to maintain consistency with Agency Authorization terminology. Comment 6Section: FedRAMP Certified (Rev 5), first paragraph Do agencies still need to issue their own ATO on top of FedRAMP Program Certification? Or is this equivalent to a JAB ATO and accepted government-wide? This distinction should be made explicit. Comment 7Section: FedRAMP Certified (Rev 5), table Do the Certification Levels apply:
Clarification is needed. Comment 8Section: FedRAMP Certified (Rev 5), table Calling these “levels of certification” adds complexity to an already complex process. If the goal is to indicate completeness:
The objective appears to be package completeness, not certification depth. Comment 9Section: FedRAMP Certified (Rev 5), table The level structure becomes inconsistent once Rev5 BIRs are incorporated. Example: A Moderate CSP that implements all BIRs could meet more FedRAMP requirements at Level 4 than a High CSP assigned Level 5. Suggested AlternativeReduce levels to 1–4:
Add fractional identifiers:
Comment 10Section: FedRAMP Certified (Rev 5), table Certified Level 5 applies to High systems. However, RFC 0023 states that FedRAMP Program Certification cannot be used for High packages (see LPC-GEN-LVL “Level Limited” section). This appears inconsistent. Comment 11Section: Marketplace Lifecycle for Rev 5 Add the following statuses:
Some of the lifecycle entries appear to be sub-processes rather than statuses. Suggested structure: Preparation
Authorized
Comment 12Section: Marketplace Lifecycle for Rev 5, item 3 Is “Assessment by FedRAMP”:
Will the same review be conducted for Agency ATO packages? Comment 13Section: Marketplace Lifecycle for Rev 5, item 5 Is “Remediation” equivalent to a Corrective Action Plan (CAP)? If so, rename this to CAP for clarity. Also: Will a CSP be placed in remediation for failing to adhere to newly finalized FedRAMP policies, such as Security Inbox updates? Comment 14Section: FedRAMP Validated (20x), first paragraph Stating that a 20x Validated package is “FedRAMP authorized” implies equivalency with Rev 5 packages. That is not accurate. Rev 5 and 20x packages do not implement the same control sets or assurance depth. This distinction must be clearer. Comment 15Section: Marketplace Lifecycle for 20x, table Similar concerns as the Rev5 lifecycle structure apply here. Comment 16Section: Marketplace Lifecycle for 20x, item 2 Rev 5 packages cannot be prioritized? Please clarify. |
Beta Was this translation helpful? Give feedback.
-
Clarification on Impact Level Equivalency Across Certified and Validated DesignationsWe support the intent of this RFC to reduce confusion between a FedRAMP authorization and an agency Authorization to Operate (ATO), and to introduce clearer terminology through the “Certified” (Rev5) and “Validated” (20x) designations. To further reduce confusion, we recommend explicitly clarifying that the introduction of new designations and numbered levels does not alter or redefine the underlying FIPS 199 impact level equivalency of the applicable FedRAMP baseline. Specifically, the RFC should clearly state that:
Absent an explicit statement of equivalency, stakeholders may misinterpret the 20x pathway or the new numeric designations as establishing different or tiered versions of Low, Moderate, or High impact baselines. Clarifying that impact levels remain constant—independent of pathway - would reinforce that these reforms modernize assessment and assurance mechanisms rather than redefine security categorization. We recommend adding a clarifying statement such as:
Making this equivalency explicit would materially reduce confusion across agencies, cloud service providers, and acquisition stakeholders while preserving the clear separation of responsibilities described in this RFC. |
Beta Was this translation helpful? Give feedback.
-
Public Comment on RFC-0021: Expanding the FedRAMP MarketplaceThese comments are my own opinions and experiences - not of my employer(s). Meow. Gap 1 - FedRAMP "levels" are falling into the same "trap" that DoD Cloud SRG did - align to DoD Cloud SRG Impact Levels or leave Low, Moderate, and High aloneThe proposed transition from FIPS-199 'Low, Moderate, High' to a numbered 1-6 level system in RFC-0020 represents a significant administrative burden with negligible security benefit.
Why? The proposed 1–6 level system repeats the architectural flaws of the early DoD Cloud SRG. Historically, the DoD attempted to use "intermediate" levels (like IL1 and IL3) to categorize data that didn't fit neatly into Public vs. CUI buckets. This resulted in:
FedRAMP should not ignore this history. Creating "Level 4" (Moderate + BIRs) implies a new impact tier that does not exist in FIPS-199 or the current SRG, leading to "Contractual Chaos" for existing federal cloud procurements. For a history lesson on DoD Cloud SRG Impact Levels over time: GAP 2: Decoupling System Impact Levels from Documentation CompletenessA "Level" should remain a fixed pointer to the FIPS-199 Impact Level (Low, Moderate, High). The thoroughness of a package—such as the inclusion of Balance Improvement Releases (BIRs) or a clean CAP history—is Metadata about the package.
Instead of a 1–6 level "certification" system, FedRAMP should retain existing standard impact levels and introduce a separate Quality/Completeness Requirements as metadata to the CSP Marketplace entry. These requirements for Quality/Completeness then be rated in the standard Benefits of this approach:
GAP 3: From "FedRAMP Certified" to "FedRAMP Annual Authorization"Propose that "FedRAMP Certified" in this RFC be renamed "FedRAMP Annual Authorization."
GAP 4: From "FedRAMP Validated" to "FedRAMP Continuous Authorization" or "FedRAMP Ongoing Authorization"Propose that "FedRAMP Validated (20x)" be renamed "FedRAMP Continuous Authorization" or "FedRAMP Ongoing Authorization"
NIST SP 800-37 Rev. 2 defines Ongoing Authorization as a departure from the "static, point-in-time" process. It is a "time-driven or event-driven" authorization that relies on a robust Information Security Continuous Monitoring (ISCM) strategy.
In the current RFC-0020 draft, "Validated" implies a completion of a review. However, the intent of the 20x path is to move away from "one-off" reviews.
Using
GAP 6: Decoupling Lifecycle Status from Authorization TypeThe current RFC conflates Authorization Methodology with Marketplace Lifecycle. These should be treated as two independent data dimensions. Mixing them creates "status fragmentation" and forces AOs to learn different progress terminologies for different paths. The Proposed State-Machine Architecture Recommend a unified set of Lifecycle Statuses that apply to all systems, regardless of whether they are pursuing Annual or Continuous Authorization. Example:
Why Decoupling Matters
|
Beta Was this translation helpful? Give feedback.
-
|
RFC-0020: FedRAMP Authorization Designations (Certified, Validated, and Level System) I am a FedRAMP-recognized independent assessor. I support the intent of RFC-0020 to reduce confusion between FedRAMP program status and an agency Authorization to Operate (ATO) decision. I also support a consistent Marketplace representation that reduces misinterpretation risk for agencies and providers. Across the broader RFC discussions, multiple commenters have asked for (1) an authoritative crosswalk between legacy terminology and the new level system, (2) standard claim language to reduce marketing misrepresentation, and (3) clear, objective criteria for any level attributes tied to improvements and corrective-action history. The requests below focus only on RFC-0020.
Comment: Proposed clarification:
Comment: Proposed clarification:
Comment: Proposed clarification:
Comment: Proposed clarification:
Comment: Proposed clarification:
Comment: Proposed clarification (suggested disclaimer text):
Comment: Proposed clarification:
Personal capacity note: This comment is submitted in an individual capacity and does not represent any employer or organization. Matthew S. Graham, CISSP |
Beta Was this translation helpful? Give feedback.
-
|
I like the concept of Certified and Validated as distinctions between Rev5 and 20X paths. Perhaps an approach that keeps Low/Moderate/High as the authorization impact rating - to keep consistency with NIST and FIPS, and to avoid confusion/consternation among Federal Agencies that make explicit callouts in contract language. A CSP goes through Rev5 or 20X and gets FedRAMP Moderate Certified/Validated, Level 1. They implement all of the SHOULDs and don't have substantial risks, they get Level 2. They go beyond the spirit of the KSIs for Moderate and impress the PMO, no risks, do all/most of the SHOULDs/MAYs/etc, they get Level 3. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
Thank you to the FedRAMP team for taking a fresh look at authorization designations and for directly addressing the long-standing confusion around what "authorization" represents in practice. Clarifying this terminology is worthwhile and appreciated. That said, I share the concern raised by several other commenters that changing Rev. 5 designations - if they are only intended to persist through roughly 2027 - may not justify the disruption. Introducing short-lived terminology changes risks creating churn in documentation, contracts, and internal governance processes without delivering lasting value. I am also concerned about the possibility of parallel paths emerging where CSPs must maintain Rev. 5 authorization packages for some agency customers while simultaneously pursuing 20x approaches for early adopters. Without a clear unifying model, this could increase complexity for CSPs, agencies, and assessors rather than reduce it. One alternative framing to consider is moving away from authorization terminology entirely and instead thinking in terms of security Agencies could then evaluate systems based on a combination of their own (data / mission's) impact level and system's FedRAMP security maturity tier, using both to inform risk acceptance and ATO decisions. Below is a rough example of how this could be structured:
I realize this idea would require significant refinement, but it could provide a unifying model that supports:
In short, a cloud security maturity-oriented approach could help FedRAMP shift the conversation from "what controls are documented" to "how securely the system actually operates over time." Thank you again for the thoughtful RFC and for continuing to modernize the program. |
Beta Was this translation helpful? Give feedback.
-
|
This is a governance problem dressed up as a terminology problem. Agencies skip package review and bypass the Categorize step because there are no accountability mechanisms on the agency side — not because "authorized" is a confusing word. A label change will not change that behavior. Embedded agency-side guidance in the Marketplace would. The RFC should acknowledge this limitation rather than imply that nomenclature is the fix. "FedRAMP Certified" will be read as a security endorsement — which is precisely the misunderstanding FedRAMP is trying to correct. Every major compliance framework (ISO 27001, SOC 2, PCI DSS) uses "certified" to mean an independent body validated security conformance. The RFC immediately contradicts this by stating certification levels "do not indicate security." That disclaimer will not survive contact with a procurement official. The label works against the stated goal. The 1-6 numbering will collide with DISA Impact Levels in DoD procurement. Contracting officers who already conflate FedRAMP and DISA requirements will write RFPs referencing "Level 4 or higher" believing it aligns with IL4. FedRAMP needs a published statement of non-equivalence and should consider whether "Assessment Tier" is less collision-prone than "Level." Levels 4 and 6 are unreachable at launch. Required Balance Improvement Releases are still in beta or require AO coordination CSPs cannot unilaterally initiate. Publishing phantom tiers creates false marketplace signal and makes compliant CSPs appear inferior to competitors through no fault of their own. Withhold these levels until prerequisites are in general release, or label them explicitly as forthcoming. "No corrective action for the past year" is the wrong standard and creates perverse incentives. A CSP that found a gap and closed it in 30 days should not be treated identically to one that ignored findings for eleven months. More importantly, this standard incentivizes CSPs to avoid transparent engagement with FedRAMP reviewers to dodge formal corrective action — the opposite of the relationship model FedRAMP should want. Replace this with "no unresolved corrective action at time of level assessment" and publish a formal appeals mechanism before this goes live. Assessment coverage and compliance track record are two different things — collapsing them into one number loses information. A CSP with deep documentation and one resolved POA&M is not equivalent to one with shallow documentation and a clean record. Separate these into two independently queryable Marketplace attributes: an Assessment Coverage Tier and a Compliance Track Record Indicator. We support FedRAMP's modernization direction. These comments are intended to strengthen implementation, not oppose the initiative. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from Coalfire on Thu Feb 19 @ 5:25PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc. RFC-0020 FedRAMP Certified (Rev 5) Why not simplify by saying (for example): "The FedRAMP Certification package includes all required information for use in a moderate impact authorization decision in most cases." • What is the meaning of "in most cases" and "in many cases"? I expect this to be a common question from CSPs. Is that there to account for situations when an agency has additional requirements beyond a fedramp baseline? Can you add a section explaining this? Even 1-2 sentences would be helpful. Certified vs. Validated Alternative Why not use the term "provisional authorization", which is already a well-known industry term, instead of certified/validated? This would align with the DoW model where DISA grants the PA and the agency grants the ATO. |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from Information Technology Industry Council (ITI) on Thu Feb 19 @ 4:07PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc. ITI’s Comments on RFC-0020 FedRAMP Authorization Designations Pete Waterman Dear Mr. Waterman The Information Technology Industry Council (ITI) appreciates the opportunity to comment on RFC-0020 FedRAMP Authorization Designations. ITI is the premier global advocate for technology, representing the world’s most innovative companies. Founded in 1916, ITI is an international trade association with a team of professionals on four continents. We promote public policies and industry standards that advance competition and innovation worldwide. Our diverse membership and expert staff provide policymakers the broadest perspective and thought leadership from technology, hardware, software, services, and We agree with the rationale that clearer FedRAMP designations will reduce persistent market confusion between FedRAMP authorized systems and an agency Authorization to Operate (ATO) under FISMA. We believe the proposed changes will make the Marketplace easier to interpret for federal customers and industry, and will help reduce ambiguity in how authorization packages are used to support agency-specific authorization decisions. While the proposed criteria for Certification Levels 1–3 and 5 have the advantage of building on a historical categorization, we believe additional clarity is needed for the newly created Rev5 Certified Levels 4 and 6. The descriptions introduce subjectivity in determining if a cloud service with an existing authorization will be listed as a Certification Level 3 versus 4, or a Certification Level 5 versus 6 under the new authorization designation scheme. This subjectivity is exacerbated by the fact that there is no indication of the criteria defining a "typical" or “significant” amount of information used to determine the appropriate level. We recommend that the PMO define objective thresholds that distinguish Levels 4 and 6 from Levels 3 and 5. Another area which requires additional clarity is the FedRAMP PMO’s adoption of the term “certificate” in conjunction with using Levels 1 – 5. This will lead to even more confusion than already exists as there is a risk of confusion between the DoD FedRAMP+ Impact Levels (aka IL2/IL4/IL5/IL6) and these new FedRAMP levels of certification. In addition, CMMC also uses 3 levels, which may also cause confusion with FedRAMP. With this in mind, we recommend the FedRAMP PMO adopt the terminology that the FedRAMP Joint Authorization Board (JAB) used of a Provisional-ATO (P-ATO), as this still requires an agency to do an ATO to and accept the risk for any cloud service that is FedRAMP authorized. Further, if providers can be moved between levels at the discretion of the PMO, several questions arise: 1) What is the established periodicity for these decisions? 2) What is the communication plan from the PMO regarding such changes? 3) Is there a formal process to appeal a PMO decision? As such, we recommend that the PMO clearly articulate the circumstances and process by which cloud providers would be moved between levels and the timing/periodicity of any reviews that would cause a provider to move between levels. We thank you for your attention to this issue and for your consideration of our comments, Megan Petersen |
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from Salesforce on Thu Feb 19 @ 5:36PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc.
|
Beta Was this translation helpful? Give feedback.
-
|
The following public comment was received via email from The Alliance for Digital Innovation (ADI) on Thu Feb 19 @ 11:34PM. I am copy/pasting into the public comment record on their behalf as required by the FedRAMP public comment process. This is not an endorsement of the commenter or the content within the comment. I have adjusted the formatting so that the email displays properly with the bullets and bolded text included in the original (copy/paste into github strips this out) but have not changed any content. Any remaining oddities in the formatting may be a result of my missing a specific header/etc. RFC 0020 The Alliance for Digital Innovation (ADI) appreciates the opportunity to comment on RFC-0020, Authorization Designations. We understand and support the underlying rationale, particularly the goal of eliminating confusion between FedRAMP “Authorized” systems and an agency’s “Authorization to Operate” for a FedRAMP “Authorized” system. Clarifying that distinction and reinforcing the separation of responsibilities can improve risk management across the federal ecosystem. The published criteria for Certification Levels 1 through 3 and Level 5 are relatively clear. However, uncertainty arises in the descriptions of Certification Levels 4 and 6. Level 4 refers to a “typical amount” of information in the FedRAMP Certification package sufficient for use in a moderate impact authorization decision, while Level 6 refers to a “significant amount” of information sufficient for use in a high impact authorization decision. Because the framework does not define what constitutes a “typical” versus “significant” amount of information, the schema introduces subjectivity in distinguishing Level 3 from Level 4 and Level 5 from Level 6. The absence of objective, measurable criteria may lead to inconsistent application and uncertainty for agencies and providers alike. Moreover, if providers may be moved between levels at the discretion of the PMO, additional transparency would strengthen confidence in the process. We would appreciate clarification on the following: (1) the established periodicity for level determinations; (2) the communication plan the PMO will follow when level changes occur; and (3) whether a formal and transparent appeal process will be available to providers; and if so, what does that process look like. We also recognize the intent behind transitioning from the longstanding Low/Moderate/High construct to a six-level designation model. At the same time, many external frameworks have intentionally aligned policies, acquisition language, and cross-framework mappings to FIPS 199 impact levels to maintain consistency with NIST guidance. Moving to a new level-based structure without a clearly articulated crosswalk and explanation of the policy rationale may introduce interpretive challenges as agencies reconcile FedRAMP designations with existing Risk Management Framework categorizations. Providing additional clarity on how the new levels are defined and how they map to established constructs would reduce confusion, promote consistency, and support smoother adoption across the federal community. Thank you for your consideration on this matter. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
RFC-0020: FedRAMP Authorization Designations
❓ Please note that FedRAMP will not answer questions in this thread as it is reserved for public comment. If you would like to ask a question or generally discuss this RFC informally, please use the General discussion / Q&A for RFC-0019 through RFC-0024 thread. Thank you!
Status: Closed
Start Date: January 13, 2026
Closing Date: February 19, 2026
Summary
This RFC proposes changes to directly tackle the confusion between “FedRAMP authorization” and an agency “authorization to operate” to align with terminology and usage in statute, OMB policy, and NIST materials. The proposed general changes in this RFC include:
This RFC is aligned with other concurrent RFCs that have additional detail on specific topics but have been published separately to encourage topic-specific comments:
Motivation
A FedRAMP authorization indicates that FedRAMP has packaged essential security information from a cloud service provider that can be used by an agency to make a determination whether or not to use that service; it is not a decision by an Authorizing Official that the service has been granted an Authorization to Operate (ATO). The use of “authorization” in a government IT context should be limited to the use outlined in OMB Circular A-130 around Authorization to Operate and the NIST Risk Management Framework’s Authorization Step.
The FedRAMP Board has found that the use of the words “authorized” / “authorization” for a FedRAMP authorization has created significant confusion about the separation of responsibilities for authorizing the use of information systems in government and recommended that FedRAMP establish separate designations for FedRAMP authorizations.
Cloud service providers frequently misunderstand FedRAMP “authorization” to be a government-wide ATO that allows any agency to immediately use their service. Federal employees often mistakenly believe that they can use any FedRAMP “authorized” cloud service without agency oversight. Agency security officials may take inappropriate risks when adopting a FedRAMP “authorized” cloud service in the mistaken belief that FedRAMP or other agencies oversee its security on their behalf, sometimes without even reviewing the materials in the FedRAMP authorization package. These behaviors, even if limited, can result in adverse impacts to federal information and federal information systems.
Similarly, a FedRAMP authorization at a given traditional NIST FIPS 199 security objective (Low, Moderate, High) does not necessarily align with the security objective of an agency information system that reuses that FedRAMP authorization. Only an Agency Authorizing official can identify the security category of an information system for their specific use case; there is an entire Categorize Step in the NIST Risk Management Framework dedicated to this for federal agencies. Agencies regularly use FedRAMP authorization materials in agency information systems with an ATO at a lower or higher security objective than the FedRAMP authorization; this is strongly encouraged.
FedRAMP should, to the greatest extent possible, provide a process to industry and federal agencies that reuses common industry terminology and avoids confusion around government terms. The designations FedRAMP uses should make it easier for all parties to understand the existing separation of responsibilities between FedRAMP, agencies, and cloud service providers. Overlapping, confusing, or duplicative designations should be avoided; therefore, both FedRAMP “authorization” and the terminology around the complexity of the assessment should have easy to understand designations that avoid this type of confusion.
Therefore, this RFC proposes creating FedRAMP Certified (Rev5) and FedRAMP Validated (20x) designations for FedRAMP authorizations, with each designation having 6 levels of increasingly complex assessment and monitoring requirements. To mitigate initial confusion, all current FedRAMP authorizations will be automatically mapped to a specific designation and level.
FedRAMP Certified (Rev5)
The “FedRAMP Certified” authorization designation indicates that a service has completed a point-in-time assessment by FedRAMP, based primarily on a review of filed paperwork, that meets legacy FedRAMP Rev5 requirements. FedRAMP has reviewed and assessed this package for completeness against a legacy FedRAMP Rev5 baseline and certified that there is sufficient information in the assessment materials to be used by agencies following the legacy FedRAMP Rev5 process. All Rev5 Certified services are FedRAMP authorized.
FedRAMP Certification levels do not indicate the security of the cloud service overall! These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP.
Effective Date: March 18, 2026 (tentatively) - on or near this date, all cloud services will be transitioned to their new designation.
Marketplace Lifecycle for Rev5
Cloud services following the legacy FedRAMP Rev5 agency authorization or program authorization processes will transition between the following statuses during their lifecycle on the Marketplace:
Preparation: The provider is carrying out the essential activities to prepare the organization to manage its security and privacy risks following the FedRAMP Rev5 process.
Note: This status has specific requirements outlined in RFC-0021: Expanding the FedRAMP Marketplace.
Agency Authorization In Process: An agency has notified FedRAMP that they have begun an agency authorization for the cloud service in accordance with FedRAMP guidelines.
Assessment by FedRAMP: FedRAMP is performing the final assessment that may result in FedRAMP Certification for the cloud service offering. The target time for this step is less than 30 days if the package is truly complete.
Continuous Monitoring: The cloud service is FedRAMP Certified and is continuously monitoring the security of their service in alignment with FedRAMP Rev5 continuous monitoring requirements.
Note: This is the target end status for Rev5 cloud service offerings.
Remediation: The provider is currently correcting a significant underlying issue with the cloud service.
FedRAMP Validated (20x)
The “FedRAMP Validated” authorization designation indicates that a service has demonstrated to FedRAMP the ability to persistently validate their security posture such that their validation package will always accurately reflect the current status of their service. FedRAMP has assessed the processes used by this service provider and ensured there is sufficient information in the persistent assessment materials to be used by agencies to make ongoing authorization decisions. All 20x Validated services are FedRAMP authorized.
FedRAMP Validation levels do not indicate the security of the cloud service overall! These levels only indicate the coverage and depth of the assessment materials available to agencies via FedRAMP.
Effective Date: March 18, 2026 (tentatively) - on or near this date, all cloud services will be transitioned to their new designation.
Marketplace Lifecycle for 20x
Cloud services following the FedRAMP 20x process for program authorizations will transition between the following statuses during their lifecycle on the Marketplace:
Preparation: The provider is carrying out the essential activities to prepare the organization to manage its security and privacy risks following the FedRAMP 20x process; the cloud service may also be FedRAMP Validated Level 1 in this status.
Note: This status has specific requirements outlined in RFC-0021: Expanding the FedRAMP Marketplace and RFC-0022: Leveraging External Frameworks.
Prioritized: The provider has been accepted into a pilot or other prioritization process where they are working directly with FedRAMP on finalizing a FedRAMP 20x Validation.
Assessment by FedRAMP: The service has submitted a complete 20x Validation package to FedRAMP that meets all FedRAMP 20x requirements for final assessment and processing. The target time frame for this step is less than 30 days if the package is truly complete.
Persistent Validation: The cloud service is FedRAMP Validated and is in the ongoing status of persistent validation in alignment with FedRAMP 20x persistent validation requirements.
Note: This is the target end status for 20x cloud service offerings.
Remediation: The provider is currently correcting a significant underlying issue with the cloud service, typically as part of formal corrective action.
Beta Was this translation helpful? Give feedback.
All reactions