FedRAMP processed more than 100 Rev5 authorizations in 2025. Not one included an Open Security Controls Assessment Language (OSCAL) submission.
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 ends that. Published January 13, 2026, the rulemaking mandates OSCAL-formatted packages for every FedRAMP provider — a sweeping shift in how FedRAMP 20x requirements are enforced. The deadline is September 30, 2026. Miss it, and you are in a grace period with a hard stop: non-compliant providers lose FedRAMP authorization on September 30, 2027. The clock started in January. Most teams have not started the conversion.
Convert your FedRAMP authorization package to OSCAL by completing four steps: inventory all system components with machine-readable identifiers, re-express every control implementation as a structured OSCAL assertion with evidence links, validate the package against NIST’s OSCAL-CLI and FedRAMP’s profile validators, and confirm your Third-Party Assessment Organization (3PAO) can produce OSCAL-formatted assessment results. Start the conversion at least six months before the September 30, 2026 deadline. The timeline is not forgiving for large systems.
What RFC-0024 Actually Requires
RFC-0024 is not a formatting preference. It is a mandatory packaging standard that redefines what a complete FedRAMP submission looks like.
The Three Documents That Must Convert to OSCAL
Three core artifacts drive the compliance obligation. 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. A provider cannot satisfy RFC-0024 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.
The Distinction Between Existing and New Providers
RFC-0024 treats existing providers and new authorizations differently. New providers entering the FedRAMP process after September 30, 2026 must submit native OSCAL packages from day one. There is no legacy pathway.
Existing providers with active authorizations face a conversion requirement. Every package currently on file as a static document must be migrated to OSCAL format by the September 30, 2026 deadline. This is not a prospective requirement that applies only to the next annual assessment. The obligation covers the current authorization package.
Annual Assessments After the Deadline
The requirement does not end at initial conversion. Annual assessments conducted after September 30, 2026 must include machine-readable updates to the OSCAL package. 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.
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 deadline of June 30, 2026 for first-draft OSCAL conversion, leaving 90 days for validation and remediation before the September 30 deadline.
Why Zero OSCAL Submissions 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 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+ 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, typically a Moderate impact level with 200-300 controls, 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.
With the September 30, 2026 deadline fixed, the window for a 150-day conversion opened in April 2026 and closes in May 2026.
Schedule a conversion kickoff meeting before May 15, 2026. 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. The organizations that treat it as a filing format project will miss the deadline. 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 seven document models — the full OSCAL compliance standard covers all of them. FedRAMP RFC-0024 requires three:
- 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 September 30 deadline.
Format Choices: JSON, XML, and YAML
RFC-0024 accepts OSCAL packages in JSON, XML, or YAML. 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.
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 Enforcement Timeline and What Happens If You Miss It
RFC-0024 has two critical dates. Understanding the difference between them matters for risk planning.
September 30, 2026: The Compliance Deadline
By September 30, 2026, every active FedRAMP provider must have submitted an OSCAL package. New authorizations initiated after this date require native OSCAL from submission. Existing providers who have not converted enter a non-compliant status.
FedRAMP published adoption support materials on April 15, 2026 to assist providers with the conversion process. These materials include conversion guidance, updated templates, and tool documentation. The April 15 release marks the point at which FedRAMP considers providers to have had adequate support resources to meet the September 30 deadline.
September 30, 2027: The Authorization Termination Date
Non-compliance by September 30, 2026 does not result in immediate authorization loss. FedRAMP allows a one-year remediation period. However, providers that remain non-compliant through September 30, 2027 lose their FedRAMP authorization.
That one-year window is not a grace period to treat as additional runway. An agency customer holding an Authorization to Operate (ATO) based on your FedRAMP authorization will receive notice of your non-compliant status. Federal procurement teams are not likely to renew or expand contracts with non-compliant cloud providers during the remediation window. The business risk precedes the technical deadline by months.
The Reauthorization Cost of Missing the Deadline
Loss of FedRAMP authorization means a provider exits the FedRAMP Marketplace. Re-entry requires a new authorization process. At current FedRAMP processing times, a new authorization through the Joint Authorization Board runs 12 to 18 months for a Moderate system. That is the consequence behind the September 30, 2027 date. The cost is not a fine. The cost is 18 months outside the federal marketplace.
Present the September 30, 2027 authorization termination risk to executive leadership now, 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 May 2026 window closes.
| Date | Event | Who Is Affected | Required Action |
|---|---|---|---|
| January 13, 2026 | RFC-0024 published | All FedRAMP providers | Begin gap assessment and project scoping |
| April 15, 2026 | FedRAMP adoption support materials published | All FedRAMP providers | Download templates, review validation tools, update conversion plan |
| May 2026 (recommended) | Internal conversion deadline to allow 150-day window | Existing providers | Assign OSCAL owners for SSP, component definitions, and assessment results |
| September 30, 2026 | OSCAL compliance deadline | All FedRAMP providers | Submit validated OSCAL package; new authorizations require native OSCAL from submission |
| September 30, 2027 | Authorization termination for non-compliant providers | Non-compliant providers | FedRAMP authorization revoked; re-entry requires new authorization process (12-18 months) |
| Annual (post-Sept 2026) | Annual assessment cycle | All authorized 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 the 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.
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 September 30 deadline without crisis are the teams that caught their errors in April and May, not September.
RFC-0024 is the most consequential change to FedRAMP packaging requirements in the program’s history. The September 30, 2026 deadline is real, the enforcement mechanism has teeth, and the zero-OSCAL submission record from 2025 tells you the industry is starting this conversion behind schedule. File your gap assessment this week, assign OSCAL ownership before May 15, and treat the one-year remediation window as the 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?
FedRAMP RFC-0024 compliance requires all FedRAMP-authorized Cloud Service Providers to submit machine-readable OSCAL packages for their authorization documentation by September 30, 2026. The requirement applies to every active FedRAMP provider, including those with existing Moderate and High authorizations under Rev5. New providers entering the authorization process after September 30, 2026 must submit native OSCAL from the initial submission.
What happens if a provider misses the September 30, 2026 deadline?
Providers who miss the September 30, 2026 deadline enter a non-compliant status with a one-year remediation window. If the provider remains non-compliant through September 30, 2027, FedRAMP revokes the authorization and removes the listing from the FedRAMP Marketplace. Re-entry requires a full new authorization process, which runs 12 to 18 months for a Moderate system at current FedRAMP processing times.
Which OSCAL document formats does FedRAMP accept under RFC-0024?
FedRAMP accepts OSCAL packages in JSON, XML, and YAML formats. All three formats are equivalent for schema validation purposes. Teams should select the format their technical staff can maintain reliably. A valid package in any accepted format satisfies the requirement. The FedRAMP validation tools available at fedramp.gov process all three formats.
Do annual assessments after the deadline also require OSCAL format?
Yes. Annual assessments conducted after September 30, 2026 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, 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. The April 15, 2026 adoption support materials release included updated 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 provider?
A moderate-complexity system at FedRAMP Moderate impact level typically requires 90 to 120 days from project kickoff to a validated OSCAL package, 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 September 30, 2026 deadline fixed, providers who have not started conversion by early May 2026 face meaningful schedule risk.
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.
Get The Authority Brief
Weekly compliance intelligence for security leaders. Frameworks decoded. Audit strategies explained. Regulatory updates analyzed.
