In 2025, FedRAMP processed more than 100 Rev5 authorizations without a single Open Security Controls Assessment Language (OSCAL) submission, a figure RFC-0024 itself cites in its background section to justify the machine-readable mandate (FedRAMP RFC-0024, January 2026).
That number is not a rounding error. FedRAMP published machine-readable packaging requirements years before Rev5 went live. Validation tools exist on fedramp.gov. Template repositories are public. The ecosystem was ready. And still, across an entire calendar year of active authorizations, every single package came in as a static document stack. Reviewers read PDFs. Agencies waited. The machine-readable future sat unused.
RFC-0024 is FedRAMP’s response. Published January 13, 2026, it establishes machine-readable OSCAL requirements for the FedRAMP Rev5 process. The scope is specific: RFC-0024 applies only to Rev5 authorizations. The RFC verbatim states it “does not apply to FedRAMP 20x.” That distinction matters for compliance planning. FedRAMP 20x machine-readable requirements are governed by RFC-0006 and RFC-0014, not RFC-0024. Our FedRAMP 20x requirements guide covers the 20x track separately.
Following the public comment period, FedRAMP issued Notice 0009 on March 25, 2026, narrowing the original RFC-0024 scope. Comprehensive machine-readable authorization data is now required only for Rev5 Class D (High) certifications, who must provide it before or during their next annual assessment by November 1, 2027. Classes A (Pilot), B (Low), and C (Moderate) transition to semi-structured text authorization data by the same November 1, 2027 deadline. Notice 0009 references “machine-readable authorization data” generally rather than mandating OSCAL specifically, though OSCAL is cited as an industry-leading partner format. The binding rules will take effect via CR26 (expected by end of June 2026).
Convert your FedRAMP Rev5 authorization package to the required format by completing four steps: inventory all system components with machine-readable identifiers, re-express every control implementation as a structured assertion with evidence links, validate the package against NIST’s OSCAL-CLI and FedRAMP’s profile validators (Class D / High providers), and confirm your Third-Party Assessment Organization (3PAO) can produce OSCAL-formatted assessment results. 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). RFC-0024 does not apply to the FedRAMP 20x track. The binding rules are published via CR26 (expected end of June 2026).
What RFC-0024 Actually Requires
RFC-0024 machine-readable compliance is not a formatting preference. It is a mandatory packaging standard for the Rev5 process that redefines what a complete FedRAMP Rev5 submission looks like, with scope that Notice 0009 has since differentiated by authorization class.
The Three Documents That Must Convert to OSCAL (Class D Providers)
Three core artifacts drive the compliance obligation for Rev5 Class D (High) providers under Notice 0009. The System Security Plan is the centerpiece: it must be produced and submitted as a machine-readable OSCAL System Security Plan (SSP) in JSON, XML, or YAML format. Component definitions, which describe the security properties of individual system elements, must follow the OSCAL Component Definition Model. Assessment results from annual 3PAO assessments must be encoded in OSCAL Assessment Results format rather than static audit reports.
The implication is total for Class D providers. A provider cannot satisfy RFC-0024 comprehensive OSCAL by converting the SSP and leaving assessment results in PDF. All three must be machine-readable. FedRAMP reviewers will validate packages against the published OSCAL schemas using the validation tools available at fedramp.gov.
For Classes A, B, and C, the requirement is a transition from DOCX/XLSX to semi-structured text formats by the same November 1, 2027 milestone. Full OSCAL document models are not required for these classes.
The Distinction Between Classes and Authorization Types
Notice 0009 introduced class-based differentiation. Class D (High impact level) providers face comprehensive OSCAL requirements. Classes A, B, and C (covering Low and Moderate impact levels) must move off DOCX/XLSX but are not required to produce full OSCAL packages. The distinction matters because most of FedRAMP’s active authorized providers are at Moderate impact level and would have faced the full OSCAL requirement under the original RFC-0024 scope that Notice 0009 revised.
New providers entering the FedRAMP Rev5 process for Class D will be expected to submit native OSCAL packages from initial submission after the November 1, 2027 milestone becomes operative. There is no legacy pathway for Class D once CR26 binding rules take effect.
Annual Assessments After the Compliance Milestone
The requirement does not end at initial conversion. Annual assessments conducted after the November 1, 2027 milestone must include machine-readable updates to the OSCAL package for Class D providers. When a 3PAO completes its annual assessment, the assessment results feed into the OSCAL Assessment Results document. When controls change, the SSP updates in OSCAL format. The package becomes a living, machine-readable record rather than a static snapshot produced at authorization.
The audit fix. Identify your Rev5 authorization class (A, B, C, or D). Class D (High) providers: pull your current authorization package and identify whether your SSP, component definitions, and assessment results exist in OSCAL format. If any document is PDF-only, that gap defines your conversion scope. Assign a technical owner to each document. Set an internal first-draft OSCAL conversion deadline that gives you at least 90 days before your next annual assessment window. Classes A, B, C: identify whether your current package uses DOCX/XLSX and plan the transition to semi-structured text format before November 1, 2027.
Why the Zero-OSCAL Track Record in 2025 Is a Warning Sign
The gap between capability and adoption in 2025 tells you something specific about where the conversion risk lives for most teams.
The Technology Existed. The Process Did Not.
FedRAMP has maintained OSCAL templates, schema definitions, and validation tooling on fedramp.gov for years. The NIST OSCAL project, which underpins FedRAMP’s requirements, produced stable schema versions well before RFC-0024 was published. The technical barrier was not the limiting factor in 2025. The operational barrier was.
Most Cloud Service Providers (CSPs) generate their System Security Plans in Word or a Governance, Risk, and Compliance (GRC) platform that exports to PDF. The FedRAMP 20x first-shell submission walkthrough illustrates why continuous-evidence architecture — rather than static document stacks — is what the PMO evaluates in the 20x cohort. The people who maintain the SSP, typically compliance managers and technical writers, do not work in JSON. The people who could write JSON, typically DevOps or engineering staff, do not own the compliance documentation. RFC-0024 requires these two groups to build a shared workflow they have never needed before.
What the Zero-Submission Data Means for Your Timeline
If the industry as a whole produced zero OSCAL submissions across 100-plus authorizations in 2025, the conversion burden is not incremental. It is structural. Teams are not 80% of the way there and need a final push. They are starting from static documents and need to build OSCAL production capability from scratch.
A realistic conversion timeline for a moderate-complexity system at FedRAMP Moderate impact level, which carries approximately 323 controls under the Rev 5 baseline, runs 90 to 120 days from project kickoff to a validated, schema-compliant package. That estimate assumes access to OSCAL tooling, a technical resource familiar with the format, and a compliance team that can translate existing SSP content into structured data. Add a 3PAO review cycle, and 150 days is a more defensible estimate for first-time conversions.
For Class D providers targeting the November 1, 2027 compliance milestone, the practical conversion window opens approximately 150 days before their next scheduled annual assessment date.
The audit fix. Schedule a conversion kickoff meeting once you have identified your Rev5 class. The meeting has one agenda item: assign ownership. Compliance owns SSP content accuracy. Engineering owns OSCAL schema output. Security engineering owns component definitions. 3PAO engagement for assessment results conversion should be scoped into the next assessment contract before that contract is signed.
RFC-0024 is not a documentation upgrade. It is an infrastructure change for FedRAMP Rev5 providers: specifically, a comprehensive OSCAL mandate for Class D (High) and a semi-structured text format transition for Classes A, B, and C. The organizations that treat it as a filing format project will approach November 2027 unprepared. The organizations that treat it as a data pipeline project, where SSP content flows from an authoritative source into machine-readable output, will meet it and hold a structural advantage in every subsequent annual assessment.
The OSCAL Package Architecture FedRAMP Expects
Understanding what a valid RFC-0024 submission looks like requires knowing the OSCAL document hierarchy and how FedRAMP maps its existing requirements onto that structure.
OSCAL Document Models Required Under RFC-0024
OSCAL defines eight document models (Catalog, Profile, Component Definition, System Security Plan, Assessment Plan, Assessment Results, Plan of Action and Milestones, and Control Mapping, the last added in OSCAL v1.2.0). The full OSCAL compliance standard covers all of them. FedRAMP RFC-0024 requires three for Class D (High) providers:
- System Security Plan (SSP): The primary authorization artifact. Describes the system boundary, data flows, control implementations, and responsible parties. Must reference an approved FedRAMP profile.
- Component Definition: Describes the security properties of hardware, software, and service components that implement controls. Vendors supplying components to FedRAMP systems must eventually provide OSCAL Component Definitions, shifting some of the documentation burden upstream.
- Assessment Results: Produced after each annual 3PAO assessment. Captures test methods, observations, findings, and risk determinations in structured format. This replaces the narrative Security Assessment Report for machine-readability purposes.
Two additional models, the Plan of Action and Milestones (POA&M) and the Assessment Plan, are part of the broader OSCAL ecosystem but RFC-0024’s primary mandate covers the three above. Organizations building toward full OSCAL compliance should scope POA&M conversion into their roadmap even if it falls outside the initial compliance milestone.
Format Choices: JSON, XML, and YAML
RFC-0024 accepts OSCAL packages in JSON, XML, or YAML (FedRAMP RFC-0024, January 2026). The three formats are functionally equivalent for schema validation purposes. FedRAMP validation tools at fedramp.gov process all three.
JSON is the default choice for teams integrating OSCAL into automated pipelines because most modern APIs and tooling handle JSON natively. XML is the better choice if your organization already uses XML-based document management systems or if your 3PAO’s assessment tooling outputs XML. YAML is human-readable and works well for teams that want compliance engineers to edit the files directly without a dedicated tool layer. Choose the format your team can maintain. A valid YAML package beats an abandoned JSON project every time.
FedRAMP Validation Tooling
FedRAMP publishes OSCAL validation tools on fedramp.gov that check packages against the FedRAMP OSCAL profile schemas. These tools verify structural validity, required field presence, and conformance to FedRAMP-specific extensions on top of the base OSCAL schemas.
A package that passes NIST schema validation does not automatically pass FedRAMP validation. FedRAMP extends OSCAL with agency-specific metadata, required fields, and constraint rules not present in the base schemas. Test your package against the FedRAMP-specific validator, not just the NIST reference validator. This distinction trips up first-time submitters who assume cross-schema compliance.
The audit fix. Download the FedRAMP OSCAL validation tools from fedramp.gov before writing your first OSCAL document. Run the validator against a test package during the architecture phase, before investing 60 days in content migration. Failing fast on structural errors costs days. Failing late, after content is complete, costs weeks. Build validation into every sprint checkpoint, not just the final delivery.
The RFC-0024 Compliance Timeline and What Happens If You Miss It
RFC-0024 as modified by Notice 0009 operates on a milestone-based timeline, not two hard dates. Understanding the full milestone sequence matters for risk planning.
CR26: Binding Rules (End of June 2026)
FedRAMP will publish the CR26 compliance rules package by end of June 2026. CR26 is the binding compliance instrument. The original RFC-0024 (January 2026) and Notice 0009 (March 2026) are the policy antecedents; CR26 is where the enforceable requirements are formally published. Providers should not begin formal compliance gap assessments against the November 2027 milestone until CR26 is available.
January 1, 2027: Initial Milestones
FedRAMP published adoption support materials on April 15, 2026 to assist providers with the conversion process. By January 1, 2027, providers must meet the initial implementation milestones: Significant Change Notifications and Minimum Assessment Scope requirements. These apply across Rev5 classes and are distinct from the comprehensive OSCAL or semi-structured text format requirements.
November 1, 2027: Compliance Milestone
The November 1, 2027 milestone is the compliance anchor for all Rev5 classes. Class D (High) providers must have submitted comprehensive machine-readable OSCAL packages. Classes A, B, and C must have transitioned to semi-structured text formats. The enforcement model is progressive quarterly corrective action, not single-date authorization revocation.
The Reauthorization Cost of Missing the Milestone
Loss of FedRAMP authorization means a provider exits the FedRAMP Marketplace. Re-entry requires a new authorization process. Since the Joint Authorization Board (JAB) was sunset in May 2024 and replaced by the FedRAMP Board, new authorizations route through the agency authorization model. At current FedRAMP processing times, a new authorization through the agency model runs 12 to 18 months for a Moderate system — the same timeline the 3PAO assessment preparation guide maps in detail for CSPs entering the Revision 5 path. That is the consequence behind the compliance milestone. The cost is not a fine. The cost is 18 months outside the federal marketplace.
The audit fix. Present the November 1, 2027 compliance milestone risk to executive leadership, framed in contract value terms. Calculate the federal revenue at risk if authorization lapses. Map the 18-month reauthorization window against current federal contract renewal dates. This is a board-level risk, not a compliance team backlog item. Get the budget to staff the conversion before the CR26 binding rules take effect in late June 2026.
| Date | Event | Who Is Affected | Required Action |
|---|---|---|---|
| January 13, 2026 | RFC-0024 published (Rev5 track only; does not apply to 20x) | All Rev5 providers | Begin class determination and gap assessment scoping |
| March 25, 2026 | Notice 0009 published: scope narrowed to Class D for comprehensive OSCAL; Classes A-C to semi-structured text formats | All Rev5 providers | Update gap assessment to reflect class-specific requirements |
| April 15, 2026 | FedRAMP adoption support materials published | All Rev5 providers | Download templates, review validation tools, update conversion plan |
| End of June 2026 | CR26 binding rules published | All Rev5 providers | Review CR26; finalize compliance roadmap against binding requirements |
| January 1, 2027 | Initial milestones: Significant Change Notifications + Minimum Assessment Scope. New Class A/B/C submissions must adopt semi-structured text formats from this date. | All Rev5 providers; new Class A/B/C applicants | Meet Significant Change Notification and Minimum Assessment Scope requirements; new Class A/B/C applicants submit in semi-structured text format |
| May 1, 2027 | New Class D (High) submissions must provide comprehensive machine-readable authorization data | New Class D applicants | New Class D submissions must be machine-readable OSCAL from initial submission; no legacy pathway |
| April 2, 2027 | Collaborative ConMon milestone | All Rev5 providers | Implement Collaborative Continuous Monitoring requirements |
| June 1, 2027 | Vulnerability Detection and Response milestone | All Rev5 providers | Meet Vulnerability Detection and Response requirements |
| August 1, 2027 | Authorization Data Sharing milestone | All Rev5 providers | Meet Authorization Data Sharing requirements |
| November 1, 2027 | Compliance milestone: Class D comprehensive OSCAL / Classes A-C semi-structured text | All Rev5 providers | Class D: submit validated OSCAL package. Classes A-C: submit semi-structured text format package. Progressive quarterly corrective action for non-compliant providers thereafter. |
| Annual (post-Nov 2027) | Annual assessment cycle | Class D providers | Submit updated OSCAL Assessment Results and revised SSP reflecting control changes |
Building the OSCAL Conversion Workflow
A conversion project succeeds or fails based on how the work is structured, not how technically capable the team is. Most teams have the capability. Few have the workflow.
Step One: Inventory and Gap Assessment
Start with your current package inventory. List every document in your active authorization package: SSP sections, attachment files, assessment reports, POA&M entries, and component documentation. For each document, identify whether an OSCAL equivalent exists and who owns the content.
Most SSPs are stored in Word or a GRC platform export. The gap assessment reveals which content is structured enough to migrate programmatically and which requires manual translation. Control implementation statements, system boundary descriptions, and interconnection diagrams each present different migration challenges. Treat the gap assessment as a scoping document, not just a checklist.
Step Two: Select Your Toolchain
Three toolchain approaches work for OSCAL conversion, each with different tradeoffs:
- GRC Platform with OSCAL Export: Several FedRAMP-focused GRC platforms have added OSCAL export capabilities. If your current platform has this feature, evaluate it first. The migration cost is lower, but the output quality varies. Validate every export against the FedRAMP validator before trusting it.
- Direct OSCAL Authoring: Using a text editor or OSCAL-aware IDE to author JSON or YAML directly. This produces the highest-quality output and the most control over the final package. It requires technical staff who understand both OSCAL schemas and your system’s security architecture. Best suited for teams with security engineering capacity.
- OSCAL Conversion Tools: Open-source tools, including those maintained by the NIST OSCAL project and third-party contributors, automate parts of the conversion from common document formats. These accelerate the mechanical work but do not replace the judgment calls required to map existing control implementation statements to OSCAL’s structured fields.
Step Three: Validate Early and Often
Run the FedRAMP OSCAL validator from the first day you produce OSCAL output. Do not wait until the package is complete to test validity. Common first-pass errors include missing required fields in the FedRAMP profile extension, incorrect UUID formatting for component references, and broken links between the SSP and its referenced component definitions.
Each of these errors is straightforward to fix in isolation. Finding twenty of them during a final review two weeks before an assessment deadline is a different problem. Build a validation gate into your workflow at every document boundary: SSP complete, run the validator. Component definitions complete, run the validator. Do not advance to the next document until the previous one passes clean.
The audit fix. Install the FedRAMP OSCAL validation toolchain in your development environment this week. Run it against a sample OSCAL document from the FedRAMP GitHub repository to confirm it works. Schedule validation runs as a recurring sprint task, not a one-time final check. The teams that hit the November 2027 milestone without crisis are the teams that caught their errors months in advance, not weeks out.
RFC-0024 is the most consequential change to FedRAMP packaging requirements in the program’s history for Rev5 providers. Per RFC-0024 verbatim, it does not apply to the FedRAMP 20x track. Among Rev5 providers, Notice 0009 (March 25, 2026) narrowed the comprehensive OSCAL requirement to Class D (High) certifications; Classes A, B, and C transition to semi-structured text formats. The compliance milestone is November 1, 2027. The binding rules publish via CR26 by end of June 2026. The zero-OSCAL submission record from 2025 tells you the industry is starting this conversion behind schedule. File your class determination and gap assessment now, assign OSCAL ownership before CR26 binding rules take effect, and treat the November 2027 milestone as the business risk it actually is: 18 months outside the federal marketplace is not a technical penalty, it is a business-ending consequence for any CSP whose revenue depends on FedRAMP authorization.
Frequently Asked Questions
What is FedRAMP RFC-0024 compliance and who does it apply to?
RFC-0024 applies to the FedRAMP Rev5 process only. RFC-0024 verbatim states it “does not apply to FedRAMP 20x.” Among Rev5 providers, Notice 0009 (March 25, 2026) further differentiated by class: 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. The compliance milestone for all Rev5 classes is November 1, 2027.
What is the compliance deadline under RFC-0024 as modified by Notice 0009?
Notice 0009 (March 25, 2026) sets three distinct deadlines: new Class A/B/C submissions must meet semi-structured text requirements by January 1, 2027; new Class D (High) submissions must provide comprehensive machine-readable data by May 1, 2027; all existing authorized providers must meet class-appropriate format requirements by November 1, 2027. CR26 binding rules expected end of June 2026. Significant Change Notifications and Minimum Assessment Scope milestones begin January 1, 2027. The enforcement model is progressive quarterly corrective action, not a single-date authorization revocation. The original September 30, 2026 milestone from the initial RFC-0024 publication was superseded by Notice 0009.
Which OSCAL document formats does FedRAMP accept under RFC-0024?
FedRAMP accepts OSCAL packages in JSON, XML, and YAML formats (FedRAMP RFC-0024, January 2026). All three formats are equivalent for schema validation purposes. Teams should select the format their technical staff can maintain reliably. The FedRAMP validation tools available at fedramp.gov process all three formats. Note that passing NIST schema validation is not the same as passing FedRAMP’s agency-specific extension validation.
Do annual assessments after the compliance milestone also require OSCAL format?
For Class D (High) providers, yes. Annual assessments conducted after the November 1, 2027 milestone must include machine-readable updates to the OSCAL package. Assessment results from 3PAO evaluations must be encoded in OSCAL Assessment Results format. Control changes must trigger corresponding updates to the OSCAL SSP. The package becomes an ongoing, machine-readable record rather than a static authorization artifact.
Does the SSP need to be completely rewritten for OSCAL conversion?
The content of the SSP does not change, but the format does. OSCAL structures the same information, system boundary, control implementations, and responsible parties, into a machine-readable schema rather than a narrative document. Most conversion projects reuse existing SSP content and map it into OSCAL fields. The judgment work involves translating narrative control implementation statements into structured OSCAL data, which requires both compliance expertise and technical familiarity with the OSCAL schema.
Where are the FedRAMP OSCAL validation tools and adoption support materials?
FedRAMP maintains OSCAL validation tools and template repositories at fedramp.gov. Adoption support materials were published on April 15, 2026, including conversion guidance, revised templates, and tool documentation. The NIST OSCAL project at pages.nist.gov/OSCAL also maintains schema documentation, reference implementations, and conversion resources. Use the FedRAMP-specific validator, not only the NIST base validator, since FedRAMP adds agency-specific extensions and constraints.
What is a realistic timeline for completing OSCAL conversion for an existing Class D provider?
A moderate-complexity system at FedRAMP Moderate impact level carries approximately 323 controls under the Rev 5 baseline. A realistic conversion timeline from project kickoff to a validated OSCAL package runs 90 to 120 days, assuming dedicated technical and compliance resources. Including 3PAO review of OSCAL-format assessment results, a 150-day estimate is more defensible for first-time conversions. With the November 1, 2027 compliance milestone anchored to the next annual assessment cycle, Class D providers should target a conversion kickoff date 150 days or more before their next scheduled assessment.
Can a GRC platform handle the OSCAL conversion automatically?
Several FedRAMP-focused GRC platforms have added OSCAL export capabilities, but platform output quality varies. Automatic exports accelerate the mechanical conversion work but do not replace the judgment required to translate narrative control implementation statements into accurate OSCAL structured fields. Validate every platform-generated export against the FedRAMP OSCAL validator before treating it as submission-ready. Schema validity does not guarantee content accuracy.
Subscribe to The Authority Brief for next week’s analysis.
