Skip to content
Close
SEARCH
Contact Us
Contact Us
High-end managed detection and response center, realistic futuristic SOC environment, modern security operations center with multiple monitors displaying threat intelligence, cybersecurity analysts at workstations, real-time threat detection das...-2

FedRAMP RFC and Policy Tracker

The FedRAMP PMO publishes proposed policy changes as Requests for Comment before finalizing them. The RFC mechanism is the fastest-moving surface of the FedRAMP program. This page tracks each active RFC: what it proposes, what it changes operationally, the comment window, and the program impact for cloud service providers. Updated within days of each new RFC release.
How the RFC process works

The RFC Mechanism

Under FedRAMP 20x, the program publishes proposed policy changes as Requests for Comment before finalizing them. Each RFC describes a proposed change, the rationale, and the operational implications. The PMO opens a structured public comment window (typically 30 days), accepts comments via GitHub discussion threads or email to the program office, and then publishes an Initial Outcome document summarizing the responses, noting which changes were adopted, and explaining the final rule.
The cadence of RFCs accelerated meaningfully through 2025 and 2026. The January 13, 2026 release alone published six RFCs (RFC-0019 through RFC-0024) covering reporting assessment costs, authorization designations, marketplace expansion, leveraging external frameworks, Rev5 program certifications, and Rev5 machine-readable packages. Subsequent RFCs continue to refine the 20x rule set, including continuous monitoring standards, persistent validation requirements, and reciprocity with CMMC Level 2.
Six RFCs published simultaneously

The January 13, 2026 RFC Release

On January 13, 2026, the FedRAMP PMO published six RFCs simultaneously, each addressing a distinct work stream within the 20x modernization program. The six RFCs cover assessment cost reporting, certification class designations, marketplace expansion, external framework leverage, Rev5 program certifications, and the OSCAL machine-readable package mandate.
1
RFC-0019: Reporting Assessment Costs
Introduces standardized reporting of assessment costs across the program. The intent is to give cloud providers and federal agencies a clearer picture of the total spend involved in FedRAMP authorization, both for budget planning and for ongoing program improvement. Operational implication: minimal direct effect on authorization mechanics, but expect to provide cost data as part of standard reporting. The standardized cost data will inform program decisions on assessment scoping and pricing.
2
RFC-0020: Authorization Designations
Codifies the new Certification Class A, B, C, D structure replacing the FIPS 199 impact levels. The terminology shift from FedRAMP Authorized to FedRAMP Certified is part of this RFC, aligning the program's language to the legal reality. Operational implication: cloud providers should update external collateral, marketing language, and sales materials to use the new class terminology and FedRAMP Certified rather than FedRAMP Authorized. Existing authorizations remain valid.
3
RFC-0021: Expanding the FedRAMP Marketplace
Expands the FedRAMP Marketplace to better represent the full cloud provider ecosystem, including services in the Preparation phase and services pursuing Class A certifications through external frameworks. The Marketplace becomes a more comprehensive view of cloud services entering federal participation rather than only services with full Agency-sponsored authorizations. Operational implication: cloud providers earlier in the certification journey have a Marketplace presence sooner, improving visibility to potential agency sponsors and partners.
4
RFC-0022: Leveraging External Frameworks
Establishes the framework for using external security assessment frameworks, starting with SOC 2 Type II, as on-ramps to FedRAMP Class A certifications. The RFC defines the guardrails: which frameworks qualify, what additional evidence is required, and how the transition to a full Class B, C, or D certification works. Operational implication: cloud providers with existing SOC 2 Type II audits can pursue Class A FedRAMP Certification through Program Certification without an agency sponsor, with a two-year window to complete a full Class B, C, or D certification.
5
RFC-0023: Rev5 Program Certifications
Introduces a Program Certification path for Rev5 authorizations, allowing cloud providers to pursue Class B or Class C certifications directly from the FedRAMP PMO without securing an agency sponsor. Addresses the long-standing constraint where agency sponsorship was the only path to initial certification. Operational implication: cloud providers pursuing Class B or C certifications under Rev5 no longer need to identify an agency sponsor as a prerequisite. The sponsorless path remains available throughout the Rev5 end-of-life window. Class D continues to require Agency authorization.
6
RFC-0024: Rev5 Machine-Readable Packages
The most operationally significant RFC of the January 2026 release. Mandates machine-readable submission packages for all FedRAMP providers by September 2026, not just 20x participants. The required format is OSCAL (Open Security Controls Assessment Language). Operational implication: every cloud provider in the FedRAMP program must produce OSCAL packages by the September 2026 deadline. This is a near-term operational requirement that is closer than Phase 3 GA and applies universally.
The most operationally significant RFC

RFC-0024: The September 2026 OSCAL Deadline

RFC-0024 is the most operationally significant RFC of the January 2026 release because it imposes a hard deadline that applies to every cloud provider in the FedRAMP program, regardless of which baseline or path they are on. The deadline is September 2026, and the requirement is OSCAL machine-readable submission packages. The RFC's universal scope is what makes it operationally distinctive. The other January 2026 RFCs (RFC-0019 through RFC-0023) affect specific subsets of providers: providers pursuing Class A on-ramps, providers pursuing Rev5 Program Certifications, providers entering through external frameworks. RFC-0024 applies to all providers in the program. Rev5-authorized services in continuous monitoring must produce OSCAL packages by the deadline. New authorizations under Rev5 must be submitted in OSCAL format by the deadline. 20x authorizations are already OSCAL-native by design. The operational lift for providers that have not yet adopted OSCAL tooling is substantial. A Moderate baseline SSP in OSCAL JSON runs thousands of lines with exact cross-references and unforgiving schema validation. Hand-writing OSCAL is slower than producing the equivalent Word document, not faster. The practical path is to generate OSCAL from underlying source-of-truth systems, treating the OSCAL artifact as an output of security operations rather than a separately authored document. NISTCompliance.AI generates OSCAL machine-readable packages across 800-plus NIST SP 800-53 Rev 5 controls, with cross-framework mapping to CMMC Level 2 and FISMA Moderate from a single evidence base. The platform handles SSP generation, POA&M tracking, Component Definition references, Assessment Plan and Assessment Results artifacts, and the schema-validated cross-references the program requires. For providers approaching the September 2026 deadline, the platform converts existing control evidence into the submission package the program requires without requiring the provider to build a separate OSCAL pipeline from scratch.
MDR vs EDR vs SIEM vs MSSP vs XDR comparison
Beyond the January 2026 release

Recent and Ongoing RFC Work Streams

RFC activity continues beyond the January 2026 release. The PMO has multiple active work streams refining the 20x rule set, expanding the 20x baseline coverage, and formalizing reciprocity with adjacent frameworks. The items below cover the major ongoing work streams.
1
Continuous Monitoring Standards
Multiple RFCs cover the continuous monitoring standards under 20x, including the Collaborative Continuous Monitoring Standard (replacing legacy ConMon procedures) and the Persistent Validation and Assessment Standard (targeting 80 percent or higher continuous automated validation across the control set). These standards formalize the operational mechanics of continuous monitoring under 20x.
2
Significant Change Notification Mechanics
Subsequent RFCs detail the operational mechanics of the Significant Change Notice process: what triggers an SCN, what the notification must contain, how SCNs integrate with the OSCAL package, and how the assessor relationship operates under the notify-do-not-ask model.
3
Persistent Validation
The Persistent Validation and Assessment Standard sets continuous automated validation as the default expectation under 20x, with a target of 80 percent or higher continuous validation for security controls in FedRAMP Moderate (Class C). This is the rule that operationalizes the KSI-driven assessment model.
4
FIPS Cryptographic Module Application
Recent RFCs cover the application of FIPS 140-3 cryptographic module requirements to commercial services used by the federal government, clarifying how FIPS applies (or does not apply) to commercial services consumed by agencies. Operational implication for cloud providers: clearer guidance on cryptographic module requirements for federal use cases.
5
RFC-0031 and Continuing Cadence
RFC-0031 and subsequent RFCs continue to refine the 20x rule set. The cadence of RFC releases is sustained, with new RFCs publishing periodically throughout 2026 and beyond. Cloud providers should monitor the FedRAMP changelog at fedramp.gov/changelog for new RFCs as they are released.
6
CMMC Level 2 Reciprocity
Reciprocity between FedRAMP authorization and CMMC Level 2 assessment is an explicit goal of the modernization program, with the detailed reciprocity rules being refined through Phase 4 in 2027. Operationally, a cloud provider authorized under FedRAMP that handles Controlled Unclassified Information for Defense Industrial Base customers can structure inheritance such that the FedRAMP authorization provides substantial coverage of the CMMC Level 2 practices.
What each RFC means for you

Operational Implications by Provider Type

The operational implications of each RFC vary by provider type. The items below cover the impact for the most common provider scenarios.
Providers Pursuing First-Time Federal Certification RFC-0022 (External Frameworks) and the Class A on-ramp through SOC 2 Type II offer a faster path to initial federal participation. RFC-0023 (Rev5 Program Certifications) removes the agency-sponsor prerequisite for Class B and Class C. RFC-0024 (OSCAL Mandate) applies once the initial certification is in scope. For these providers, the modernization program substantially lowers the barriers to initial entry.
Providers in Rev5 Continuous Monitoring RFC-0024 (OSCAL Mandate) is the most immediate operational requirement. Continuous monitoring deliverables must be in OSCAL format by September 2026. RFC-0020 (Authorization Designations) updates the terminology providers should use in external materials. RFC-0019 (Cost Reporting) adds standardized cost reporting to continuous monitoring deliverables.
Providers Considering the 20x Path The full RFC suite affects 20x candidates. RFC-0020 codifies the class structure. RFC-0024 mandates OSCAL. Continuous monitoring RFCs and Significant Change Notice RFCs define the operational mechanics. For these providers, comprehensive familiarity with the RFC ecosystem is operationally important.
Defense Industrial Base Contractors DIB contractors benefit most from the CMMC Level 2 reciprocity work stream, refined through Phase 4 in 2027. Cloud providers serving DIB customers can structure inheritance such that the FedRAMP authorization provides substantial coverage of CMMC Level 2 practices. NISTCompliance.AI handles the cross-framework mapping so a single evidence base satisfies FedRAMP, CMMC Level 2, and FISMA Moderate.
Class D (High Baseline) Providers Most January 2026 RFCs apply to Class D providers with the same scope as other classes (RFC-0024 OSCAL mandate, RFC-0020 terminology updates, RFC-0019 cost reporting). However, RFC-0023 (Rev5 Program Certifications) does not extend to Class D; Class D continues to require Agency authorization. No 20x path is currently defined for Class D.
How to Track RFCs in Real Time The FedRAMP changelog at fedramp.gov/changelog publishes RFC announcements as they are released. Comment windows are typically 30 days. Initial Outcome documents follow the comment-window close. This page is updated within days of each new RFC release to track the operational implications for cloud service providers.
How NISTCompliance.AI Tracks RFC Impact NISTCompliance.AI's update cadence tracks RFC-driven changes to the program. When an RFC affects the OSCAL schema, the SSP structure, the POA&M format, or the assessment artifact requirements, the platform's generation logic is updated accordingly. Cloud providers using the platform receive the program updates as platform releases rather than as separate engineering projects.
Quzara Cybertorch federal MDR

Staying Current on FedRAMP RFCs?

The RFC cadence is sustained and accelerating. NISTCompliance.AI tracks program changes as platform updates so cloud providers receive RFC-driven changes as feature releases rather than as separate engineering projects. Cybertorch's continuous validation telemetry remains aligned to the evolving program standards. Request a consultation to map your RFC exposure.
Schedule a FREE Consultation

Common Questions About FedRAMP RFCs

What is a FedRAMP RFC? A FedRAMP Request for Comment is a proposed policy change published by the FedRAMP PMO for structured public review. Each RFC describes a proposed change, the rationale, and the operational implications. The PMO accepts public comments via GitHub discussions or email, then publishes an Initial Outcome document summarizing responses and explaining the final rule.
How often does FedRAMP publish RFCs? The cadence has accelerated through 2025 and 2026. The January 13, 2026 release alone published six RFCs simultaneously (RFC-0019 through RFC-0024). Additional RFCs publish periodically; cloud providers should monitor the FedRAMP changelog at fedramp.gov/changelog for new releases.
What was in the January 13, 2026 release? Six RFCs: RFC-0019 (Reporting Assessment Costs), RFC-0020 (Authorization Designations and the Class A through D structure), RFC-0021 (Expanding the FedRAMP Marketplace), RFC-0022 (Leveraging External Frameworks for Class A on-ramps), RFC-0023 (Rev5 Program Certifications without agency sponsors), and RFC-0024 (Rev5 Machine-Readable Packages, the OSCAL mandate).
What is the most operationally significant RFC right now? RFC-0024 (Rev5 Machine-Readable Packages). The RFC mandates OSCAL machine-readable submission packages for all FedRAMP providers by September 2026, regardless of which baseline or path. The mandate applies universally, not just to 20x participants. Every cloud provider in the program is on the OSCAL clock.
What does RFC-0020 change about terminology? RFC-0020 codifies the Class A through D certification structure replacing the FIPS 199 impact-level labels (Low, Moderate, High) and the FedRAMP Authorized to FedRAMP Certified terminology shift. Class B replaces Low. Class C replaces Moderate. Class D replaces High. Class A is a transitional designation through external frameworks.
Does RFC-0023 apply to Class D? No. RFC-0023 introduces a Program Certification path for Rev5 Class B and Class C, allowing certification directly from the FedRAMP PMO without an agency sponsor. Class D continues to require Agency authorization; there is no Program Certification path at Class D.
What is the comment window for an RFC? Typically 30 days from publication. Comments are accepted via GitHub discussion threads on the FedRAMP community repository or by email to the program office. After the window closes, the PMO publishes an Initial Outcome document explaining the final rule.
What happens after the comment window? The PMO reviews the public comments, adopts changes where appropriate, and publishes an Initial Outcome document summarizing the responses and explaining the final rule. The RFC then becomes part of the FedRAMP rule set with a specified effective date.
How can a cloud provider submit comments on an RFC? Through the GitHub discussion thread for the specific RFC on the FedRAMP community repository, or by email to the FedRAMP PMO. Comments should reference the specific RFC and the section being addressed, with concrete operational concerns or proposed alternatives.
Are RFCs binding? RFCs are proposals during the comment window. The PMO's Initial Outcome document and subsequent rule changes are binding. Cloud providers should treat the final rules as binding once published; the RFC stage is where input is solicited and incorporated.
How does the modernization program affect existing authorizations? Existing FedRAMP Authorized services retain their status under their current authorizations. RFC-0020 updates terminology going forward but does not invalidate existing authorizations. RFC-0024 applies to existing authorizations through their continuous monitoring obligations (OSCAL by September 2026). Other RFCs may apply to existing authorizations at their renewal cycles.
How does NISTCompliance.AI handle RFC-driven changes? NISTCompliance.AI's update cadence tracks RFC-driven changes to the program. When an RFC affects the OSCAL schema, the SSP structure, the POA&M format, or the assessment artifact requirements, the platform's generation logic is updated accordingly. Cloud providers using the platform receive program updates as platform releases rather than as separate engineering projects.