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, governed by RFC-0024 as modified by Notice 0009 (March 2026), sets class-specific deadlines: new Classes A/B/C submissions must meet semi-structured text requirements by January 1, 2027; new Class D (High) submissions must provide comprehensive machine-readable authorization data by May 1, 2027; existing authorized providers in all classes must meet their respective requirements by November 1, 2027. Notice 0009 references “machine-readable authorization data” generally, with OSCAL cited as the industry-leading partner format. CR26 binding rules take effect by end of June 2026, with Significant Change Notifications and Minimum Assessment Scope milestones beginning January 1, 2027.
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-0019 (Class A through D authorization bucketing). 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, extending the original September 30, 2026 milestone to November 1, 2027.
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 will be published via CR26 (expected by end of June 2026). Implementation milestones begin January 1, 2027, with the compliance milestone anchored to November 1, 2027 for the next annual assessment cycle.
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 land 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: Class D (High) providers face comprehensive OSCAL requirements by November 1, 2027; Classes A, B, and C face semi-structured text format requirements by the same milestone. 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); tooling (your team needs OSCAL authoring and validation tooling 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 tooling that can produce OSCAL-formatted assessment results on demand, not tooling 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 tooling 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.
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. Notice 0009 establishes three distinct compliance dates rather than a single milestone. New Class A, B, and C submissions must meet semi-structured text format requirements beginning January 1, 2027. New Class D (High) submissions must provide comprehensive machine-readable authorization data beginning May 1, 2027. All existing authorized providers, regardless of class, must meet their respective format requirements by November 1, 2027. 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 will be published via CR26 by end of June 2026. FedRAMP’s enforcement model is progressive quarterly corrective action, not single-date certification revocation. For existing Class D providers, the practical planning horizon is November 1, 2027. For new Class D applicants entering after May 1, 2027, comprehensive machine-readable packages are required from initial submission.
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 tooling. 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 tooling 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 tooling 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 November 1, 2027 compliance milestone for Rev5 Class D, or from the Phase 3 gate for 20x providers, to schedule tooling 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. Notice 0009 (March 25, 2026) sets three distinct deadlines: new Class A/B/C submissions by January 1, 2027 (semi-structured text); new Class D (High) submissions by May 1, 2027 (comprehensive machine-readable); all existing authorized providers by November 1, 2027 (class-appropriate formats). CR26 binding rules expected end of June 2026.
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 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 tooling 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?
FedRAMP is phasing out DOCX/XLSX-format authorization packages for all Rev5 classes by the November 1, 2027 compliance milestone, with Class D (High) requiring full OSCAL and Classes A, B, and C requiring semi-structured text formats. 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 tooling 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.
