This year, FedRAMP has gone through its most significant overhaul since the program launched in 2011. The FedRAMP 20x initiative, launched March 2025 and now the program’s preferred authorization path, replaces static narrative documentation with continuous, automated, machine-readable evidence. If your organization is pursuing or maintaining FedRAMP certification, the fundamental questions asked by assessor’s have shifted from “what does your policy say?” to “show me the current state of your systems.”
This page covers what FedRAMP 20x changed, what the 2026 Consolidated Rules mean for configuration management specifically, and where CHS fits in a FedRAMP authorization package.
What Is FedRAMP?
FedRAMP (Federal Risk and Authorization Management Program) is the US government’s standardized security assessment and authorization program for cloud services used by federal agencies. Any cloud service provider (CSP) that wants to sell to the federal government needs FedRAMP certification without it, agencies cannot procure or deploy the service.
FedRAMP is built on NIST SP 800-53, the federal government’s comprehensive security control catalog. CSPs must implement, document, and continuously demonstrate those controls before and after certification. Authorization is not a point-in-time event — it’s an ongoing operational obligation.
The program is administered by GSA, with the FedRAMP Board setting policy and Third-Party Assessment Organizations (3PAOs) conducting the independent assessments that underpin certification.
What FedRAMP 20x Changed
The legacy FedRAMP process, now called Rev5, required CSPs to produce extensive written narrative documentation: a System Security Plan (SSP) that could run to hundreds of pages, narrative control descriptions, evidence packages assembled for periodic assessments. The average authorization took 18–22 months and cost between $500K and $5 million. In 15 years, roughly 400 CSPs became FedRAMP authorized.
FedRAMP is sunsetting the Rev5 path on June 11, 2027. After that date, 20x is the only route to certification.
Most companies that tried and failed to get FedRAMP authorized under the old system did so because the paperwork and timeline were impossible to sustain. The process took eighteen months of documentation work, millions of dollars in consulting fees, and a requirement to find a sponsoring agency before you could even get started.
FedRAMP 20x is a direct response to that problem. The goal of the program is a 20x reduction in authorization time (from 22 months to roughly 90 days) by replacing static documentation with machine-readable OSCAL submissions and continuous streaming monitoring rather than periodic point-in-time checks.
Under FedRAMP 20x, a CSP has to show an assessor the current state of their systems, automatically and continuously. Configuration enforcement and automated evidence generation are how authorization works now.
The 2026 Consolidated Rules
On June 26, 2026, FedRAMP released the Consolidated Rules for 2026 (CR26). It’s the first time in the program’s history that all requirements have been consolidated into a single authoritative ruleset, replacing a decade’s worth of guidance documents, FAQs, templates, and informal memos.
Key timelines:
CR26 took effect July 4, 2026 for new 20x certifications. Existing Rev5 certifications and new Rev5 certifications transition to CR26 on January 1, 2027. FedRAMP will stop accepting new Rev5 certifications on June 11, 2027, making 20x the only path for new authorizations going forward.
What FedRAMP Requires for Configuration Management
FedRAMP’s configuration management requirements sit primarily in two NIST SP 800-53 control families:
CM-6 (Configuration Settings) Requires cloud service providers (CSPs) to define secure configuration settings for their systems, apply those settings, track any exceptions, and monitor changes over time. Under FedRAMP 20x, “documentation” now means machine-readable evidence that shows the system’s current configuration, not just provide written descriptions of how it is supposed to be configured.
CM-7 (Least Functionality) Requires CSPs to configure systems so they only provide essential functions. This includes disabling or restricting unnecessary ports, protocols, software, services, and other features. The goal is to reduce the attack surface by ensuring only the components needed for the system’s purpose are running.
Under 20x, both controls are assessed through Key Security Indicators (KSIs) measurable, automatable signals of security posture rather than document reviews. The FedRAMP 20x Key Security Indicators for Configuration Management (KSI-CMT) must be updated in alignment with the Significant Change Notification Standard, effective June 2025 for Phase One participants.
Beyond CM-6 and CM-7, configuration management intersects with:
- AU-2 / AU-3 (Audit and Accountability) — log settings are part of the configuration baseline; what gets logged and retained is a configuration decision with direct assessment implications
- SI-2 (Flaw Remediation) — patch management and configuration management are linked; a patch that resets a hardened setting is a configuration event, not just a patch event
- AC-3 (Access Enforcement) — who can modify system configurations is an access control question; privileged access to configuration settings needs to be controlled and logged
What Assessors Actually Check
3PAOs conducting FedRAMP assessments have always asked for evidence, but under 20x the nature of that evidence shifts. Previously, a 3PAO might review a configuration policy document, sample a subset of systems, and accept a screenshot as evidence. Under 20x continuous monitoring, the expectation is that configuration state is demonstrable at any point in the authorization lifecycle not just during the assessment window.
In practice, assessors are checking:
- Configuration baselines exist and are specific. Not “systems will be hardened” but a defined baseline mapped to system roles — what settings, what values, applied to which system types. Generic CIS Benchmark references without role-specific implementation are a gap.
- Baselines are enforced in production, continuously. The 20x model requires CSPs to demonstrate that what’s in the baseline is what’s actually running on systems — and that it stays that way between assessments. A configuration that was correct at initial assessment and has since drifted is a finding under continuous monitoring, not something that waits for the next annual review.
- Changes are controlled and logged. Every change to a configuration setting should be authorized, documented, and traceable. Ad hoc changes made during incident response or troubleshooting that were never reviewed or reverted are exactly the kind of drift 20x continuous monitoring is designed to surface.
- Evidence is machine-readable and current. Under 20x and CR26’s machine-readable package requirements, evidence needs to be in formats that can be ingested by agency tools and the FedRAMP PMO — not PDFs assembled manually for each assessment.
FedRAMP Certification Classes (Formerly Impact Levels)
As of May 2026, FedRAMP uses certification classes rather than impact levels:
- Class A (formerly Low) — systems where compromise would have limited adverse effect
- Class B (formerly Moderate) — systems where compromise would have serious adverse effect; covers most federal systems handling sensitive but unclassified data
- Class C (formerly High) — systems where compromise would have severe or catastrophic adverse effect; law enforcement, financial systems, health data
- Class D — specific high-sensitivity systems
The configuration management requirements scale with class. Class B systems (the most common target for commercial CSPs pursuing federal business) carry a full CM-6/CM-7 control set. Class C adds additional configuration assurance requirements.
Checklist: Configuration Management Evidence for FedRAMP Authorization
- Configuration baselines defined per system role, not a single generic policy applied to all system types
- Baselines mapped to a recognized standard: NIST SP 800-53 CM-6 parameters, CIS Benchmarks, or DISA STIGs as applicable
- Evidence that baselines are enforced in production systems including current state data, not policy descriptions
- Change management process for configuration modifications: authorization, implementation, and post-change verification
- Change log with timestamp, account, setting modified, and before/after value for every configuration change on in-scope systems
- Drift detection with documented remediation workflow with configuration anomalies flagged, escalated, and resolved with audit trail
- Privileged access to configuration settings controlled, logged, and reviewed
- Log configuration settings aligned to AU-2/AU-3 requirements including what gets logged, retained, and reviewed
- Evidence organized for machine-readable submission where CR26 requirements apply
- Continuous monitoring process that sustains evidence between assessments, not just at assessment time
For ISVs and Cloud-Native Companies
FedRAMP 20x was built with modern cloud-native companies in mind. The legacy Rev5 process was designed around traditional enterprise IT architectures. It assumed relatively static system configurations documented in long-form SSPs. Cloud-native CSPs running containerized workloads, infrastructure-as-code deployments, and CI/CD pipelines found Rev5’s documentation model fundamentally misaligned with how their systems actually work.
20x addresses this directly. Machine-readable OSCAL submissions, Key Security Indicators as automatable signals, and continuous monitoring aligned to cloud-native operational patterns are all designed for how modern cloud systems actually run. The configuration management implication: if your infrastructure is defined and deployed as code, your configuration evidence should be generated the same way.
CHS operates at the OS and server level rather than the infrastructure-as-code layer — it’s relevant where your FedRAMP boundary includes Windows or Linux servers, whether on-premises, in a cloud IaaS environment, or in a hybrid setup. For containerized environments managed entirely through IaC tooling, configuration evidence typically comes from the IaC pipeline rather than an agent-based tool.
How FedRAMP Relates to CMMC
Although FedRAMP and CMMC (Cybersecurity Maturity Model Certification) are separate programs with separate requirements, they share a control lineage. Both trace back to NIST SP 800-53. FedRAMP targets cloud service providers selling to federal agencies; CMMC targets defense contractors handling Controlled Unclassified Information. An organization subject to both needs to satisfy each independently.
The good news is that FedRAMP 20x has explicitly identified CMMC reciprocity as a goal. If you hold a FedRAMP authorization, parts of the configuration management evidence it produces may carry over to a CMMC assessment.
How CHS Helps
CHS addresses the server and system configuration enforcement layer within a FedRAMP authorization package: enforcing baseline configurations aligned to NIST SP 800-53 CM-6 and CM-7, detecting and logging drift, maintaining change records with before/after values, and generating the configuration state evidence that 3PAOs and, under 20x, continuous monitoring require.
For FedRAMP specifically, CHS is relevant where the system boundary includes servers running Windows or Linux. Learning Mode lets teams preview configuration changes before applying them to production systems, which matters for FedRAMP’s change control requirements.
FedRAMP 20x means configuration evidence needs to exist continuously, not be assembled when a 3PAO shows up. If you want to see what CHS produces automatically versus what your team is still generating by hand contact us to speak to an expert.
