Key takeaways

1. FedRAMP's RFC-0024 requires Cloud Service Providers to submit authorization packages in OSCAL, a machine-readable format, starting September 30, 2026, with enforcement penalties, including loss of certification, beginning September 30, 2027.
2. The mandate specifically requires structured, machine-readable mapping of third-party and open source components, SBOMs, and vulnerability status, not narrative descriptions of them.
3. Reconstructing that evidence by hand from scanner exports and spreadsheets does not scale to a continuous, machine-readable evidence model.
4. Software provenance and structured SBOM data, generated automatically at build time, are becoming the raw material engineering teams need to feed an OSCAL mapping effort, rather than something assembled after the fact.

Your compliance team used to own the FedRAMP submission. They wrote the System Security Plan, described your controls in narrative form, and your job was to answer their questions when they came knocking.

That division of labor is ending.

‍‍Starting September 30, 2026, new FedRAMP authorization packages, System Security Plans, and annual assessment updates have to be submitted in OSCAL, a machine-readable format built on structured JSON. Non-compliant services face enforcement penalties, up to and including loss of FedRAMP certification, starting September 30, 2027. The rule comes from RFC-0024, and it has been folded into the 2026 FedRAMP Consolidated Rules.

That's more than a documentation change. It's a data problem, and it lands on engineering.

In this article, we explore what RFC-0024 actually requires, why the open source and third-party component mapping buried inside it is the part that will land hardest on engineering teams, and what it takes to have that data ready before your next submission window.

The narrative document is going away

For most of FedRAMP's history, an authorization package was a set of long-form documents. A human wrote them, a human reviewed them, and the review cycle took months. RFC-0024 replaces that model with structured data: system architecture, control implementation, and component inventories mapped directly into OSCAL's JSON schema, not described in prose.

The 2026 Consolidated Rules extend the same logic to ongoing operations. Instead of a written explanation of your security posture submitted once a year, FedRAMP's 20x model expects automated Key Security Indicators fed by continuous monitoring: evidence over narrative, as the standing requirement. An annual assessment used to be a project. Under this model, it's closer to a data pipeline that runs all the time.

The open source line item is not optional

Buried inside the machine-readable requirement is a specific ask that lands directly on whoever owns your build pipeline: structured, machine-readable mapping of third-party software, dependencies, and SBOMs, including information flows and vulnerability status.

That's a different task than what most teams have today. A scanner report tells you what CVEs exist in your dependency tree at the moment you ran it. It doesn't tell an OSCAL mapper, in a format it can ingest automatically, where a component came from, how it was built, or what its current remediation status is. Turning scan output into that structured record has historically been manual work: someone exports a report, cross-references it against a spreadsheet, and reformats it by hand before a compliance tool can use it.

That approach doesn't survive a continuous evidence model. If the data has to stay current and machine-readable at all times, it can't depend on someone remembering to run an export before the annual assessment window opens.

Why this lands on engineering, not just compliance

Compliance teams don't generate build provenance. They don't know which packages were pulled from an upstream registry versus built from source, and they shouldn't have to reconstruct that history from Slack threads and Jira tickets when an auditor asks. That information lives in your build pipeline, and turning it into structured, exportable evidence is now an engineering responsibility, whether or not it shows up in anyone's job description yet.

It's tempting to assume this is a one-time lift: map the data once, hand it to compliance, move on. That's not quite right either. FedRAMP's 20x model treats evidence as continuous, not point-in-time, which means the mapping has to stay current as your dependency tree changes, not get refreshed once a year under deadline pressure.

This is the same shape of problem AI-assisted development has already created for engineering teams: a volume and velocity of dependency intake that outpaces the governance process built to track it by hand. The OSCAL mandate doesn't create that gap. It just puts a regulatory deadline and an enforcement penalty behind closing it.

What structured-at-the-source actually looks like

The alternative to reconstructing evidence after the fact isn't generating it more carefully. It's not generating it by hand at all.

When a component is built from source inside a SLSA level 3 build environment, the provenance record, what went into the build, how it was built, and what its current vulnerability status is, exists as structured data from the moment the component exists. It doesn't need to be assembled later. ActiveState builds every component in the ActiveState Library this way and ships a complete SBOM and provenance record with it, across 12 language ecosystems. That data isn't an OSCAL package on its own, but it's the structured, verifiable input an OSCAL mapping effort needs instead of a scanner export and a set of manual notes.

Remediation status works the same way. When a critical CVE has a community-approved fix available upstream, ActiveState's contractual SLA is 5 business days to deliver the rebuilt component. That commitment gives your evidence pipeline a documented, dated remediation record instead of an open item sitting in a backlog with no clear resolution date.

The deadline is closer than the enforcement penalty suggests

September 30, 2027 is when the penalties start. September 30, 2026 is when new authorization packages are required to already be in OSCAL format. If your organization has an authorization in progress, or plans to submit one in the next year, the format requirement isn't a future problem. Existing authorizations move to machine-readable packages at their next annual assessment after the September 2026 date, which for many teams is sooner than a year out.

Waiting for the enforcement deadline to start building the pipeline that produces this data means starting during, not before, your next submission cycle.

How ActiveState helps teams get ahead of the OSCAL mapping problem

ActiveState isn't an OSCAL authoring tool, and it doesn't submit your authorization package for you. What it gives your engineering team is the upstream data an OSCAL mapping effort actually depends on: built-from-source provenance, a complete SBOM per component, and a contractual, dated remediation record, generated automatically instead of reconstructed under deadline pressure.

If you're already thinking about what AI-assisted development is doing to your FedRAMP posture more broadly, that's worth reading together with this one: How Is AI-Assisted Development Reshaping FedRAMP Open Source Security?

See how build-from-source provenance and SBOM data map to your OSCAL evidence requirements. Book a Walkthrough.