Editor’s Note (Updated July 16, 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. Read RFC-0024 and the CR26 timeline together.
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 its proposed machine-readable requirements (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 on January 13, 2026 as a Request for Comment, it proposes 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 folded RFC-0024 into the Consolidated Rules for 2026 (CR26), the single standard that every Rev5 submission is now measured against. CR26 is mandatory on January 1, 2027. Under it, the machine-readable requirement is differentiated by class: Rev5 Class D (High) certifications move to full machine-readable OSCAL, while Classes A (Pilot), B (Low), and C (Moderate) transition from DOCX and XLSX to semi-structured text formats. Those requirements are phased across 2027 under CR26. The specific dates RFC-0024 and its follow-on notice proposed are not among CR26’s published Important Dates, so read the operative schedule in the CR26 timeline rather than treating any single 2027 date as fixed.
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. The binding standard is the Consolidated Rules for 2026 (CR26), mandatory on January 1, 2027; the machine-readable requirements are phased across 2027 under CR26, so confirm your target dates against the CR26 timeline rather than the dates RFC-0024 originally proposed. RFC-0024 does not apply to the FedRAMP 20x track.
What RFC-0024 Actually Requires
RFC-0024 machine-readable compliance is not a formatting preference. It is a packaging change for the Rev5 process, now carried into the binding CR26 standard, that redefines what a complete FedRAMP Rev5 submission looks like, with scope differentiated by authorization class.
The Three Documents That Must Convert to OSCAL (Class D Providers)
Three core artifacts drive the machine-readable obligation for Rev5 Class D (High) providers under CR26. 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 the full OSCAL requirement 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 and XLSX to semi-structured text formats, phased across 2027 under CR26. Full OSCAL document models are not required for these classes.
The Distinction Between Classes and Authorization Types
CR26 carries class-based differentiation. Class D (High impact level) providers face full OSCAL requirements. Classes A, B, and C (covering Low and Moderate impact levels) must move off DOCX and 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 broader scope RFC-0024 originally proposed.
New providers entering the FedRAMP Rev5 process for Class D will be expected to submit native OSCAL packages from initial submission once the CR26 machine-readable requirements take effect. There is no legacy pathway for Class D under the binding CR26 standard.
Annual Assessments After the Compliance Milestone
The requirement does not end at initial conversion. Once the CR26 machine-readable requirements are in force, annual assessments 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 or XLSX and plan the transition to semi-structured text format ahead of the CR26 phase-in; confirm your target dates on the CR26 timeline.
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 the PMO evaluates continuous-evidence architecture in the 20x cohort rather than static document stacks. 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. Machine-readable production 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, the practical conversion window opens approximately 150 days before their next scheduled annual assessment date, since the machine-readable package must be ready for that assessment cycle.
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: a full OSCAL requirement for Class D (High) and a semi-structured text format transition for Classes A, B, and C, now carried into the binding CR26 standard. Providers that treat it as a filing-format project tend to be unprepared when the standard takes effect. The durable move is to treat it as a data pipeline project, where SSP content flows from an authoritative source into machine-readable output. That approach produces a package that meets the standard and holds up 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 requirement 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 Machine-Readable Timeline Under CR26 and What Happens If You Miss It
The machine-readable transition operates on a phased timeline under CR26, not a single hard date. Understanding the sequence matters for risk planning, and the operative dates live on the CR26 timeline.
CR26: The Binding Standard (Mandatory January 1, 2027)
CR26 is the binding compliance instrument, mandatory on January 1, 2027. RFC-0024 (January 2026) and its follow-on notice are the policy antecedents; CR26 is where the enforceable requirements are formally published. Providers should run their compliance gap assessments against CR26 and the dates on the CR26 timeline, not against the dates RFC-0024 originally proposed.
January 1, 2027: CR26 Becomes Mandatory
FedRAMP has published adoption support materials to assist providers with the conversion process. On January 1, 2027, CR26 becomes mandatory, and every Rev5 provider operates under it from that date. The machine-readable format requirements, full OSCAL for Class D and semi-structured text for Classes A, B, and C, phase in across 2027 on the schedule published in the CR26 timeline.
Machine-Readable Requirements Phased Across 2027
Across 2027, the machine-readable requirement takes effect for all Rev5 classes under CR26. Class D (High) providers must submit full machine-readable OSCAL packages. Classes A, B, and C must transition to semi-structured text formats. The enforcement model is progressive quarterly corrective action, not single-date authorization revocation. Confirm the phase-in dates that apply to your class on the CR26 timeline.
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. That is the same timeline the 3PAO assessment preparation guide maps in detail for CSPs entering the Revision 5 path. That is the consequence behind the machine-readable milestone. The cost is not a fine. The cost is 18 months outside the federal marketplace.
The audit fix. Present the CR26 machine-readable 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 CR26 becomes mandatory on January 1, 2027.
| Date | Event | Who Is Affected | Required Action |
|---|---|---|---|
| January 13, 2026 | RFC-0024 published as a Request for Comment (Rev5 process only; does not apply to 20x) | All Rev5 providers | Review the proposal; begin class determination and gap assessment scoping |
| In 2026 | RFC-0024 folded into the Consolidated Rules for 2026 (CR26); FedRAMP publishes adoption support materials | All Rev5 providers | Track CR26; download templates and validation tools; update the conversion plan |
| January 1, 2027 | CR26 becomes the mandatory standard for the Rev5 process | All Rev5 providers | Operate under CR26; run gap assessments against CR26 and the CR26 timeline |
| Phased across 2027 (see the CR26 timeline) | Machine-readable format requirements take effect: Class D full OSCAL; Classes A, B, and C semi-structured text; DOCX and XLSX retired | Rev5 providers, by class | Class D: submit validated OSCAL packages. Classes A, B, and C: submit semi-structured text. Confirm your class date on the CR26 timeline |
| Annual (ongoing under CR26) | 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. Teams that reach the CR26 machine-readable milestone without a crisis catch their errors months in advance, not weeks out.
RFC-0024 is one of the most consequential changes 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. Its proposal has been folded into the Consolidated Rules for 2026 (CR26), the binding standard, mandatory on January 1, 2027. Under CR26, Class D (High) certifications move to full OSCAL, while Classes A, B, and C transition to semi-structured text formats, phased across 2027; the operative dates live on the CR26 timeline. 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 takes effect, and treat the machine-readable 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.” Its proposal is now folded into the Consolidated Rules for 2026 (CR26). Under CR26, the machine-readable requirement is differentiated by class: full machine-readable OSCAL for Rev5 Class D (High) certifications, and a transition from DOCX and XLSX to semi-structured text formats for Classes A, B, and C. Those requirements are phased across 2027; CR26 is mandatory on January 1, 2027, and the operative dates are on the CR26 timeline.
What is the machine-readable compliance timeline for Rev5 providers?
The binding standard is the Consolidated Rules for 2026 (CR26), mandatory on January 1, 2027. RFC-0024 originally proposed a September 30, 2026 effective date for the Rev5 process, but that was a proposal: it is not an operative deadline and does not appear in CR26’s published Important Dates. Under CR26, the machine-readable format requirements are phased across 2027, with Class D moving to full OSCAL and Classes A, B, and C moving to semi-structured text. The enforcement model is progressive quarterly corrective action, not a single-date authorization revocation. For the operative dates that apply to your class, read the CR26 timeline rather than the dates RFC-0024 or its follow-on notice proposed.
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 CR26 machine-readable milestone also require OSCAL format?
For Class D (High) providers, yes. Once the CR26 machine-readable requirements are in force, annual assessments 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. FedRAMP has published adoption support materials, 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. Because the machine-readable package must be ready for the annual assessment cycle under CR26, 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.
