Updated September 1, 2026. September 30, 2026 was the proposed effective date in FedRAMP RFC-0024, a Request for Comment; it is not an operative deadline and does not appear in the final CR26 Important Dates. The machine-readable two-lane priority mechanism (RFC-0024 clause LMR-FRX-PRM) applies only to the FedRAMP Rev5 process and does not apply to FedRAMP 20x. The single standard every submission is measured against is the Consolidated Rules for 2026 (CR26), mandatory on January 1, 2027. The specific Rev5 machine-readable dates described below come from Notice 0009 (March 2026), which FedRAMP has not withdrawn. They do not appear in the CR26 Important Dates, and Notice 0009 itself defers its timelines to CR26, so treat them as Notice 0009 milestones rather than as CR26 deadlines; for the binding dates, read RFC-0024 and the CR26 timeline together.
FedRAMP has been running essentially the same authorization process for fifteen years. Cloud service providers submit narrative security packages, assessors review documentation, the Program Management Office (PMO) validates controls, and an agency issues an Authorization to Operate (ATO). The system worked at government scale when the federal cloud market was small. It does not work now, and the program’s leadership knows it.
FedRAMP 20x is the program’s modernization initiative: a wholesale replacement of the underlying assumption that human-readable documentation, reviewed by humans, is how you verify cloud security at scale. Two parallel rulemakings govern the transition. For providers on the FedRAMP 20x track, RFC-0006 and RFC-0014 define Key Security Indicator (KSI) validation and continuous monitoring requirements. For providers on the legacy Rev5 track, RFC-0024, published January 13, 2026, mandates machine-readable Open Security Controls Assessment Language (OSCAL) packages. The two programs run on separate tracks. RFC-0024 explicitly does not apply to FedRAMP 20x.
Most cloud service providers are still treating the modernization initiative as a documentation reformatting exercise, and when I look at the gap assessments coming out of the field, that framing is costing them time they do not have. The ones who understand what is actually changing are already building toward continuous, automated validation. Phase 3 of FedRAMP 20x is now active per fedramp.gov/20x/phases/.
FedRAMP’s modernization runs on two parallel tracks. The FedRAMP 20x track, governed by RFC-0006 and RFC-0014, requires Key Security Indicator (KSI) validation at 70% automated threshold and continuous compliance dashboards that agencies can query directly. The Rev5 track’s machine-readable requirement began as RFC-0024, a proposal, later adjusted by Notice 0009 (March 2026). Those Rev5 machine-readable requirements are now folded into the Consolidated Rules for 2026 (CR26), which take mandatory effect on January 1, 2027; the specific class-by-class dates are governed by CR26 rather than by the earlier proposal, so consult the CR26 timeline for the operative schedule. RFC-0024 applies only to Rev5 and does not apply to FedRAMP 20x.
FedRAMP 20x and RFC-0024: Two Programs on Parallel Tracks
The authorization process CSPs have used since FedRAMP’s founding is built on a documentation model. A provider produces a System Security Plan (SSP), a Controls Implementation Summary, and a body of evidence. A Third-Party Assessment Organization (3PAO) reviews those documents. The PMO validates the package. An authorizing official grants the ATO.
Every element of that model depends on humans reading, interpreting, and judging narrative text. At a program scale of hundreds of providers, human review is manageable. At a program scale of thousands of providers across a federal government running on cloud infrastructure, it creates a verification bottleneck that no amount of additional PMO staff will clear.
FedRAMP is solving the bottleneck from two directions simultaneously. The FedRAMP 20x initiative is governed by RFC-0001 (program foundation), RFC-0006 (Phase 1 KSI framework), RFC-0014 (Phase 2 KSI expansion), and RFC-0020 (FedRAMP Authorization Designations), whose outcome, Notice 0004, established the Class A through D scheme. RFC-0024 is a separate, parallel rulemaking that applies exclusively to the Rev5 process. Per RFC-0024 verbatim: “This RFC applies only to the FedRAMP Rev5 process and does not apply to FedRAMP 20x.” Our RFC-0024 compliance guide covers the Rev5 OSCAL conversion in detail.
OSCAL, the Open Security Controls Assessment Language developed by NIST, represents security control implementations as structured, machine-readable data. When a provider’s security posture is expressed in OSCAL, it can be validated programmatically, compared against baselines automatically, and monitored continuously without a human reviewer reading a PDF. Our OSCAL compliance standard guide explains the format in detail.
What RFC-0024 Actually Requires (Rev5 Track Only)
RFC-0024 was published as a Request for Comment on January 13, 2026, close date March 11, 2026. It applies to the FedRAMP Rev5 process only. Following the public comment period, FedRAMP issued Notice 0009 on March 25, 2026, which significantly modified the scope of the original proposal. Those Rev5 machine-readable requirements are now governed by CR26; the September 30, 2026 date was a proposal and does not appear in the final CR26 Important Dates.
Under Notice 0009, comprehensive machine-readable OSCAL is required only for Rev5 Class D (High) certifications. Classes A, B, and C must transition from DOCX/XLSX to semi-structured text formats, but they are not required to produce full OSCAL packages. The Rev5 control baseline itself remains active across all classes. What is retiring is the DOCX/XLSX package format. The binding compliance rules are the Consolidated Rules for 2026 (CR26), mandatory on January 1, 2027; the specific Rev5 machine-readable dates are governed by CR26 rather than by the earlier proposal. Consult the CR26 timeline for the operative schedule.
FedRAMP has not finalized the Rev5 retirement schedule. Phase 3 of FedRAMP 20x is now active, expanding the 20x pathway to qualifying providers.
The OSCAL Gap in Current Practice
Public information from the FedRAMP marketplace suggests that the vast majority of 2025 Rev5 authorizations were submitted in narrative format without OSCAL packages. The PMO accepted Rev5 packages because the policy allowed it. RFC-0024, as modified by Notice 0009, will change that requirement for Class D providers.
In my experience, the scope of the conversion problem does not register until a provider opens their first OSCAL template and looks back at five years of narrative documentation. Every CSP that went through a Rev5 authorization in 2025, and most that went through authorizations in prior years, has never produced an OSCAL package. They have SSPs written in Word. They have evidence in SharePoint. They have control narratives that a skilled human can interpret but that a validation engine cannot parse.
Converting that existing documentation to OSCAL is not a find-and-replace exercise. OSCAL requires explicit relationships between components, controls, and evidence. A narrative paragraph that says “MFA is implemented via Azure Entra ID for all privileged accounts” becomes a machine-readable assertion with component identifiers, control mappings, implementation status fields, and links to validation artifacts. Every control. Every component. Every system boundary.
The audit fix. Determine which RFC-0024 class applies to your system: Under Notice 0009, already-certified Class D (High) providers face comprehensive OSCAL requirements by November 1, 2027, and already-certified Classes A, B, and C face semi-structured text format requirements by the same milestone. New certification submissions run earlier: Classes A, B, and C from January 1, 2027, and Class D from May 1, 2027. Confirm against the CR26 timeline before you plan to either date. Class D providers should verify: current SSP format (Word, PDF, or OSCAL); component inventory completeness (OSCAL validation requires explicit component definitions for every system element); evidence linking (each control implementation assertion references specific evidence artifacts); tools (your team needs OSCAL authoring and validation tools from fedramp.gov/resources/oscal); and 3PAO alignment (your assessor must produce OSCAL assessment results, not narrative reports).
Key Security Indicators: Replacing Narratives With Testable Metrics
OSCAL handles the package format problem for Rev5 providers. Key Security Indicators handle the verification problem for FedRAMP 20x. KSIs are the structural core of the 20x program, and they represent a more fundamental shift than format conversion.
Traditional FedRAMP control assessment asks whether a control is implemented and whether the implementation is documented. KSIs ask whether security outcomes are measurable and continuously verified. The distinction matters because a well-written narrative can describe a control that does not exist. A KSI that requires automated validation of MFA enforcement cannot be satisfied by description.
How KSIs Work in Practice
A Key Security Indicator is a specific, testable security metric tied to a control domain. Where the traditional approach asks “describe your MFA implementation,” a KSI asks “what percentage of privileged accounts have MFA enforced, as of today, verified by automated query to your identity provider?”
Phase 2 of the 20x pilot requires 70% automated KSI validation. That threshold means that 70% of applicable KSIs, across the full set of roughly 63 KSIs defined in Phase 2 per RFC-0014, must be satisfied by automated evidence collection, not manual attestation. The remaining 30% can use human-verified evidence, but the direction of travel is clear: the program intends to reach 100% automation.
The KSI domains defined in Phase 1 (RFC-0006) include: Configuration of Network Access (KSI-CNA), System Configuration (KSI-SC), Identity and Access Management (KSI-IAM), Malware and Log Analysis (KSI-MLA), Configuration Management (KSI-CM), Protection of Information (KSI-PI), Third-Party and Incident Response (KSI-3IR), Continuous Evaluation (KSI-CE), and Incident Response (KSI-IR). Providers building toward the 20x track should confirm their automated data sources against these domains.
What Continuous Monitoring Looks Like Under 20x
FedRAMP has always required continuous monitoring. Under the legacy process, Continuous Monitoring (ConMon) meant monthly vulnerability scans, annual penetration tests, and quarterly report submissions. Providers could satisfy ConMon requirements with a human-intensive review cycle that produced reports nobody read in real time.
A rule I keep coming back to: if your security posture requires a human to assemble it before an agency can see it, it is not continuous monitoring. Under 20x, continuous monitoring means automated KSI validation feeding a machine-readable dashboard that authorizing agencies can query at any time. The shift from periodic reporting to continuous ATO implementation is not optional. Providers whose security posture requires manual assembly to be visible will not satisfy 20x ConMon requirements.
The operational implication: CSPs pursuing the 20x track need tools that can produce OSCAL-formatted assessment results on demand, not tools that produces PDFs for quarterly submissions. That is a different procurement decision, a different integration architecture, and a different staff capability than most authorized providers currently have.
The audit fix. Assess your current KSI posture if you are pursuing the FedRAMP 20x track: identify which KSI domains from RFC-0006 and RFC-0014 apply to your system; map each KSI to an existing data source (identity provider, SIEM, vulnerability scanner); measure your current automated validation rate; evaluate your ConMon tools for OSCAL assessment output capability; and align with your 3PAO on their defined 20x assessment process.
The Phase Timeline and What Each Gate Requires
FedRAMP 20x is rolling out in phases. The gate requirements for each phase determine which CSPs can participate and when. Understanding the phase structure is more useful than tracking individual deadline dates, because the phases define what “ready” means at each stage.
Phase 1: Foundation (Completed)
Phase 1 established the technical and policy foundation for 20x. OSCAL profiles for FedRAMP Low, Moderate, and High baselines were published. The KSI framework was defined via RFC-0006. RFC-0024 was published for Rev5 OSCAL requirements. The program office committed to publishing adoption support materials.
FedRAMP published adoption support materials on April 15, 2026 to assist Rev5 providers with OSCAL conversion. Providers planning OSCAL conversion should not wait to begin assessment, but the materials package clarifies requirements currently described at a policy level without full implementation detail.
The CR26 certification pipelines have since opened: FedRAMP began accepting Class A applications on August 3, 2026 and Class B and Class C applications on August 31, 2026 (fedramp.gov/2026/timeline). Phase 2: Pilot (Ongoing)
Phase 2 is the active pilot with a select group of CSPs operating under 20x methodology. The 70% automated KSI validation threshold is the Phase 2 gate requirement. Providers in the pilot are demonstrating that the technical approach is viable before the program opens to general participation.
Phase 2 findings will directly shape Phase 3 requirements. CSPs that follow the pilot closely, through the fedramp.gov public updates and RFC comment periods, will have advance visibility into what Phase 3 will require.
Phase 3: Open Participation (Now Active)
Phase 3 is now active per fedramp.gov/20x/phases/. Qualifying means OSCAL-ready packages and demonstrated KSI validation capability, not being an existing authorized provider. Providers who have not yet completed their OSCAL foundation work and KSI gap assessment should treat Phase 3 activation as the signal to accelerate preparation.
Rev5 Package Format Retirement and the Compliance Milestone
FedRAMP is phasing out traditional DOCX/XLSX-format authorization packages for all Rev5 classes. The earlier Notice 0009 proposal set class-specific machine-readable dates, but those requirements are now folded into CR26; the specific compliance dates are governed by the Consolidated Rules for 2026 rather than by the earlier proposal, so consult the CR26 timeline for the operative schedule. Rev5 as a control baseline remains active. The DOCX/XLSX submission format is what is retiring, not the underlying control framework.
The binding compliance rules are the Consolidated Rules for 2026 (CR26), mandatory on January 1, 2027. FedRAMP’s enforcement model is progressive corrective action, not single-date certification revocation. The specific Rev5 machine-readable milestones are governed by CR26; consult the CR26 timeline for the operative dates.
The providers that treat FedRAMP modernization as a documentation reformatting project will spend 2026 converting Word documents into OSCAL XML without understanding which track they are on. The providers that treat it as a security architecture project will spend 2026 building continuous validation pipelines that produce OSCAL output as a byproduct, regardless of whether they pursue 20x or Rev5-class-D compliance. Only the second group will be positioned for the continuous monitoring requirements of Phase 3 and beyond.
Building the 20x-Ready Architecture
FedRAMP 20x compliance is a systems engineering problem, not a documentation problem. The providers who arrive at Phase 3 ready are building an architecture that generates compliance evidence continuously, not one that produces it on demand for assessments.
The Four Components of a 20x-Ready Stack
Four architectural components determine whether a CSP can satisfy 20x requirements at the Phase 3 gate. These apply to the 20x track; Rev5 Class D providers building toward OSCAL compliance follow the same architecture for the OSCAL output components.
OSCAL authoring and maintenance tools. The SSP, control implementation statements, and system component inventory must be maintained in OSCAL format. Tools like NIST’s OSCAL-CLI, the FedRAMP OSCAL templates, and commercial GRC platforms with OSCAL export capability are the options.
Automated KSI data collection. Each applicable KSI requires an automated data source. Identity providers, configuration management databases, vulnerability scanners, and Cloud Security Posture Management (CSPM) tools are the typical sources. The gap analysis question is not whether these tools exist in your environment but whether they can produce KSI-formatted output that feeds into OSCAL assessment results.
OSCAL assessment results generation. The 3PAO assessment under 20x produces OSCAL assessment results, not narrative reports. CSPs need tools that can receive and store OSCAL assessment outputs and a 3PAO that has the capability to produce them.
Continuous monitoring integration. The ConMon pipeline under 20x feeds KSI metrics into a posture dashboard that agencies can query. The integration between automated data collection, OSCAL packaging, and dashboard visibility is the operational heart of 20x.
The 3PAO Alignment Problem
The 3PAO question is the one I tell CSP security teams to ask before they build a single OSCAL template. Third Party Assessment Organizations are adapting to 20x methodology at different rates. Some large 3PAOs have invested in OSCAL tools and KSI validation methodologies. Others are still producing Rev5-style narrative reports.
Before building an OSCAL conversion roadmap, confirm three things with your current 3PAO: whether they have completed OSCAL-formatted assessments, whether they have a defined KSI validation methodology, and what their backlog looks like for Phase 3 window assessments. If the answers are no, undefined, and six months, the 3PAO is the bottleneck.
The audit fix. Complete this review before Phase 3 planning begins: identify your OSCAL authoring platform and confirm it produces valid FedRAMP OSCAL profiles; for each KSI domain (reference RFC-0006 for Phase 1 domains, RFC-0014 for Phase 2 expansion), identify the authoritative data source and confirm automated export capability; confirm your 3PAO can produce OSCAL assessment results; map the data flow from KSI collection through OSCAL packaging to agency-visible dashboard; and work backward from the Notice 0009 November 1, 2027 compliance milestone for Rev5 Class D, or from the Phase 3 gate for 20x providers, to schedule tools procurement, OSCAL conversion, internal validation, and 3PAO assessment.
Looking at the full arc of FedRAMP’s history, 20x is the most significant change to federal cloud authorization since the program launched. The providers who understand the shift from narrative documentation to continuous automated validation, and who build the architecture to support it, will hold durable positions in the federal market. RFC-0024, as modified by Notice 0009 (March 2026), establishes a Rev5-side OSCAL requirement with the compliance milestone anchored to November 1, 2027 for Class D (High). The 20x track, now active at Phase 3, operates on KSI validation requirements governed by RFC-0006 and RFC-0014, separate from RFC-0024. Understanding which track applies to your system is the first decision. Both tracks require continuous validation infrastructure. The time to build it is now.
Frequently Asked Questions
What are the FedRAMP 20x requirements for cloud service providers?
FedRAMP 20x (governed by RFC-0001, RFC-0006, RFC-0014, and RFC-0019) requires providers on the 20x track to demonstrate automated Key Security Indicator validation at 70% or higher threshold and maintain continuous monitoring through automated posture dashboards that agencies can query directly. Phase 3 is now active. RFC-0024 governs a separate Rev5-side OSCAL requirement and explicitly does not apply to FedRAMP 20x.
Does RFC-0024 apply to existing authorized providers or only new applicants?
RFC-0024 applies to the FedRAMP Rev5 process only. It does not apply to FedRAMP 20x. The Rev5 machine-readable requirements that Notice 0009 (March 25, 2026) adjusted are now folded into the Consolidated Rules for 2026 (CR26), which take mandatory effect on January 1, 2027. The specific class-by-class dates are governed by CR26 rather than by the earlier proposal; consult the CR26 timeline for the operative schedule.
What happens if a Class D provider misses the November 2027 compliance milestone?
FedRAMP’s enforcement model under Notice 0009 is progressive quarterly corrective action, not single-date certification revocation. Class D providers who are non-compliant at the Notice 0009 November 1, 2027 milestone enter a corrective action cycle. Providers should not treat the progressive corrective action model as reduced urgency: agency customers and contracting officers will have visibility into non-compliant status well before authorization termination.
What is an OSCAL package?
An OSCAL package is a structured data representation of security control implementations, expressed in XML, JSON, or YAML format according to the NIST OSCAL schema. Unlike narrative SSPs, OSCAL enables automated validation, programmatic baseline comparison, and machine-readable evidence linking. For Rev5 Class D providers, the three required OSCAL document models are the System Security Plan, Component Definition, and Assessment Results.
What are Key Security Indicators?
Key Security Indicators are specific, testable security metrics that replace narrative control descriptions in the FedRAMP 20x framework. Phase 1 KSI domains (RFC-0006) include KSI-CNA (network access configuration), KSI-SC (system configuration), KSI-IAM (identity and access management), KSI-MLA (malware and log analysis), KSI-CM (configuration management), KSI-PI (protection of information), KSI-3IR (third-party and incident response), KSI-CE (continuous evaluation), and KSI-IR (incident response). Phase 2 (RFC-0014) expanded to approximately 63 KSIs. The Phase 2 gate requires 70% automated validation of applicable KSIs.
Can existing GRC platforms produce OSCAL output?
Some commercial GRC platforms have developed OSCAL export capabilities, but quality and completeness vary significantly. Validate any platform’s OSCAL output against NIST’s validation rules and FedRAMP OSCAL profiles before relying on it for authorization packages. FedRAMP provides validation tools at fedramp.gov. A platform that passes NIST schema validation does not automatically pass FedRAMP’s agency-specific extension validation.
When does FedRAMP plan to retire Rev5 authorization?
Notice 0009 retires DOCX and XLSX as acceptable authorization-package formats. For services already certified, the milestone is November 1, 2027, with Class D (High) requiring comprehensive machine-readable data and Classes A, B, and C requiring semi-structured text formats. For new certification submissions the same requirements come earlier: January 1, 2027 for Classes A, B, and C, and May 1, 2027 for Class D. Rev5 as a control baseline remains active. FedRAMP has not published a formal end-of-life date for the Rev5 control baseline itself.
What should CSPs do right now to prepare?
Three actions are on the critical path. First, determine which track applies: FedRAMP 20x (KSI validation, RFC-0006/0014) or Rev5 OSCAL compliance (RFC-0024 as modified by Notice 0009, class-specific requirements). Second, complete a gap assessment against the applicable requirements: current package format, OSCAL tools availability, KSI validation rate, and 3PAO capability. Third, confirm 3PAO alignment on 20x methodology or Rev5 OSCAL assessment capability before committing to a timeline. Phase 3 of FedRAMP 20x is now active. The preparation window is not closing, but the competitive advantage for early movers is real.
Subscribe to The Authority Brief for next week’s analysis.
