The deadline is real.
FedRAMP's RFC-0024 — the FedRAMP 20x program — mandates that all new authorization packages submitted on or after September 30, 2026 must be machine-readable OSCAL. CSPs whose ATOs are not transitioned to OSCAL-format submissions by September 30, 2027 face certification revocation.
This is not a recommendation. The date is set, the templates are published (FedRAMP OSCAL SSP, SAP, SAR, POA&M templates exist in XML, JSON, and YAML at the GSA/fedramp-automation GitHub repository), and the validation tooling is production-grade. Major commercial GRC platforms have been shipping OSCAL output through 2025 and into 2026. The window for “wait and see” closed when 2026 started.
What the mandate covers.
- System Security Plan (SSP) — the largest artifact, describing your system's control implementation.
- Security Assessment Plan (SAP) — what the 3PAO will assess.
- Security Assessment Report (SAR) — what the 3PAO found.
- Plan of Action and Milestones (POA&M) — open gaps with remediation plans.
Each artifact must validate against the FedRAMP-published OSCAL schemas. Submission tooling rejects non-validating output. The bar on output correctness is much higher than the previous Word-document era.
What it means for the DIB.
FedRAMP and CMMC are different programs, but they share architectural DNA — both are built on NIST 800-53 (FedRAMP) and 800-171 (CMMC, derived from 800-53 controls). The same OSCAL Catalog underlies both. As FedRAMP's OSCAL adoption matures and DoD CIO observes the operational gains, pressure to formalize CMMC OSCAL grows. The CMMC AB hasn't announced a roadmap, but the direction is unambiguous — likely 18 to 36 months behind FedRAMP.
For DIB customers pursuing FedRAMP authorization (or FedRAMP-equivalent under DoD requirements), OSCAL output is table stakes by Q4 2026 at the latest. For CMMC-only customers, it's a hedge — generate OSCAL today, be ready when DoD formalizes.
What “OSCAL-native” should mean.
Vendors will increasingly market themselves as “OSCAL-ready” or “OSCAL-compatible.” The terms are doing a lot of work. Three honest questions to ask any vendor:
- Is the data model OSCAL-shaped, or are you transforming an internal schema at export time? Transform-on-export breaks down at scale and on edge cases. OSCAL-native data models round-trip cleanly.
- Do generated artifacts validate against FedRAMP schemas? Not just NIST baseline OSCAL — FedRAMP extensions, profile-specific identifiers. If they don't validate, they won't submit.
- Is OSCAL output included or is it a paid add-on? Charging extra for OSCAL in 2027 will look anachronistic — like charging extra for TLS 1.3.
FORCE's position.
FORCE is OSCAL-native from Day 1. Profile, SSP, POA&M, and Assessment Results are downloadable from every assessment page. Included in L2 Standard pricing at no additional cost. See the artifacts FORCE generates →
If you're a CSP pursuing FedRAMP authorization, the September 2026 deadline is your forcing function. If you're a DIB customer, it's your hedge. Either way: this is the architecture decision the next 24 months will validate.