FedRAMP & CMMC in 2026: what actually changed for your Authority to Operate (ATO)

If you sell software to the U.S. government, the last few months have been a lot. FedRAMP rev5 still holds until September 2027 but FedRAMP 20x moves to be the new standard. CMMC Phase 2, the requirement for third-party C3PAO certifications, got put on pause. Two of the biggest compliance frameworks a contractor has to track both changed shape within 2 weeks of each other, and neither change is cosmetic. That’s a hard moment to plan around. It’s also, underneath the acronyms, a moment where the actual engineering work required hasn’t moved at all.

FedRAMP CR26 and the CMMC Phase 2 suspension, explained

On June 25, 2026, FedRAMP finalized its Consolidated Rules for 2026 (CR26), effective July 1. The changes are more than naming, but the naming is the most visible part: “Authorization” becomes “Certification,” and the old Low/Moderate/High Impact Levels become Certification Classes A through D. If you’ve spent years describing your posture as “FedRAMP Moderate Authorized,” that specific phrase is being retired, and vendors, integrators, and agencies all need to relearn the same vocabulary at the same time.

Two weeks later, on July 13, 2026, the Department of War announced the immediate suspension of CMMC Phase 2, the third-party assessment requirement that had been scheduled to take effect November 10, 2026. A newly formed CMMC Reform Task Force is running a 60-day review of the program. What often gets lost in coverage of the pause: Phase 1 self-assessment requirements and the underlying DFARS 252.204-7012 safeguarding obligations remain fully in force during the suspension. Nothing about the pause lowers the actual security bar; it pauses how that bar gets independently verified.

Neither change touches the technical work an Authority To Operate (ATO) has always required: continuous vulnerability scanning, an accurate SBOM, DISA STIG compliance, and a documented plan for anything that doesn’t yet pass. Whatever CMMC’s review concludes in September, it’s very unlikely to conclude that continuous evidence of those controls was a bad idea. The safest position for a contractor right now is to keep building that evidence regardless of which label ends up on top of it.

How Anchore Enterprise maps to NIST 800-53, STIG, and POA&M controls 

An ATO isn’t one gate. It’s a set of controls that all need continuous, current evidence behind them, and the quickstart for achieving one reflects that: it’s closer to a reference architecture than a linear walkthrough.

SBOM generation and storage is the starting point, and it maps directly to a specific, named control: NIST 800-53’s CM-8 (Information System Component Inventory). An assessor isn’t asking whether you believe your inventory is accurate. They’re asking you to produce it, matched to a control number, on demand.

Vulnerability data has to go further than a CVE and a severity score. Anchore Enterprise’s policy engine incorporates CISA’s Known Exploited Vulnerabilities (KEV) list and EPSS exploit prediction scores alongside CVSS, which matters because an assessor increasingly expects risk-based prioritization, not a raw vulnerability count. Anchore’s current policy bundle, v2026.1, added a dedicated STOP gate specifically for CISA KEV-listed vulnerabilities, mapped to NIST 800-53’s SI-2 (Flaw Remediation): if a vulnerability is confirmed as actively exploited, it fails the build, full stop, distinct from a vulnerability that’s merely severe.

Containers running in DoD environments have an additional layer: DISA STIG compliance. Automated STIG scanning against container images turns a manual, per-image checklist into something that runs on every build instead of once before an audit.

Not everything will pass on the first try, and that’s expected rather than disqualifying. POA&M enforcement, through policies, gates, and time-bound allowlists, is how Anchore Enterprise represents that reality: a finding that doesn’t yet meet policy can be allowlisted with an explicit remediation date rather than either silently ignored or blocking every build indefinitely. That’s the actual mechanic behind an ATO: managed risk with a documented timeline, not a demand for instant perfection.

Getting non-compliant images caught before they reach production is where CI/CD policy gates come in. The same mechanism covered earlier in this series, anchorectl image check <image> --detail -f, applies here directly: a failing policy check returns the specific control and finding that failed, not just a pass/fail count, which is what turns a gate into something an assessor can trace back to a specific requirement instead of a black box.

Access itself is a control category on its own. Least-privilege, need-to-know, RBAC is something an assessor checks independently of your vulnerability posture, since who can see or change compliance data is a distinct question from whether that data looks good.

And because none of this stops mattering once an image is deployed, the Kubernetes runtime inventory and admission controller covered earlier in this series extends the same policy enforcement from build time into what’s actually running in a live cluster, and into blocking non-compliant workloads before they’re scheduled at all.

The outcome: continuous compliance evidence 

Go back to where this started: two major frameworks changed their names and structure within two weeks of each other, and that’s genuinely disorienting if your compliance posture is built around the specific labels rather than the underlying controls. But CM-8, SI-2, and DISA STIG requirements didn’t get suspended or renamed. They’re the same controls they were before FedRAMP became CR26 and before CMMC Phase 2 got paused.

The technical outcome is compliance evidence generated continuously, as a byproduct of normal build and deployment activity, mapped to control numbers rather than to whichever program name happens to be current this quarter. The business outcome is walking into an assessment, under FedRAMP CR26, under whatever CMMC becomes after its review, or under both, with evidence that was already being produced rather than assembled under deadline pressure.

Mattermost is a good illustration of what that looks like in practice. Serving defense agencies and critical infrastructure operators meant strict adherence to NIST 800-53 was foundational to their business, not optional, and they needed to be ready for DISA STIG requirements on top of it. By adopting Anchore Enterprises’ out-of-the-box NIST 800-53 policy pack and integrating scanning directly into their GitHub Actions release pipeline, Mattermost moved from ad-hoc manual reviews to automated policy-as-code, closing a real compliance blind spot while eliminating the false-positive noise that had been costing their engineering team time on every release.

Learn more

This is the same policy-as-code approach Anchore Enterprise customers rely on to stay audit-ready regardless of which framework, or which version of a framework, they’re being measured against. If you’re already running Anchore Enterprise, our Federal ATO quickstart walks through the full control mapping, from SBOM generation through POA&M enforcement. If you’re evaluating how this would hold up under CR26, a post-review CMMC, or both, request a demo and bring your current ATO timeline to the conversation.