FedRAMP Guide

FedRAMP is the gate every cloud service must pass before US federal agencies can use it for federal information, and in 2026 the gate itself is being rebuilt. The Rev5 process built on NIST SP 800-53 baselines, agency sponsors and long document packages is being replaced by FedRAMP 20x, which certifies services against Key Security Indicators with automated, persistent validation. Providers starting now face different choices from those who began two years ago. This guide explains the legal basis, the 2026 certification classes and paths, how Rev5 and 20x assessments work, continuous monitoring and what agencies still decide themselves. It is written for cloud providers' security and compliance teams, assessors and agency staff, and reflects fedramp.gov as read on 16 October 2026.

Key takeaways

• The 2026 rules change the vocabulary. FedRAMP now issues "certifications" in Classes A to D, while agencies still issue their own authorisations to operate (ATOs) or to use (ATUs).
• New Rev5 applications end on 11 June 2027. FedRAMP says providers without significant Rev5 progress and a guaranteed sponsor "should pivot to FedRAMP 20x immediately".
• Your path follows your architecture and your customers. Services built on FedRAMP certified infrastructure go through 20x Program Certification without a sponsor; self-hosted services and Class D (High-like) needs still go through Rev5 Agency Certification.
• Identity is a measured outcome in 20x. Key Security Indicators require phishing-resistant MFA or passwordless sign-in, just-in-time access for user and non-user accounts, and automated secret rotation.
• Certification is the start of the obligation. Collaborative continuous monitoring, vulnerability response, significant change notification and incident communication rules apply for as long as the service is listed.

What FedRAMP is and where it sits

The FedRAMP Authorization Act (Pub. L. 117-263, section 5921, December 2022, codified in part at 44 U.S.C. 3607 to 3616) put the programme in statute. OMB Memorandum M-24-15 (25 July 2024) rescinded the 2011 cloud authorisation memo and sets current policy. It records that "The Act established FedRAMP within the General Services Administration (GSA)", and scopes FedRAMP to cloud products and services that "create, collect, process, store, or maintain Federal information on behalf of a Federal agency".

• FedRAMP and FISMA: FISMA makes each agency responsible for securing its systems and accepting risk through an ATO. FedRAMP standardises the security assessment of cloud services so that many agencies can rely on one package rather than each assessing the same service.
• Presumption of adequacy: M-24-15 says agencies "must presume the security assessment documented in the authorization package is adequate" for use at or below its level while it is maintained through continuous monitoring. Agencies can depart from that only in limited cases, such as a demonstrable need for added requirements.
• FedRAMP Board: it sets guidelines and requirements but "is not expected to participate in the approval of individual authorization packages". The old Joint Authorization Board and its provisional authorisations (P-ATOs) belong to the earlier model.
• Machine-readable packages: M-24-15 states "Agencies must use OSCAL until such time as NIST formally designates a successor", and the 2026 rules are published as machine-readable rules on GitHub as well as on fedramp.gov.
• Government-wide use: FedRAMP says a service must have "Direct Government-Wide Use" (several agencies use it directly) or "Indirect Government-Wide Use" (it underpins other cloud services that do).

Status as of 16 October 2026

FedRAMP announced its Consolidated Rules for 2026 in June 2026. The Important Dates page lists these milestones:

The 20x programme runs in phases: Phase 1 (Low pilot, April to September 2025) and Phase 2 (Moderate pilot, November 2025 to March 2026) are complete; Phase 3 (wide-scale adoption of Classes A to C) is active; Phase 4 (Class D, High pilot) is estimated for the first half of FY27. On 15 October 2026 FedRAMP published RFC-0036 on Class D cloud-hosted pilot requirements, and on 14 October RFC-0035 on cryptographic module use. The Marketplace showed 544 certified services, 32 of them 20x, on the day this guide was researched. FedRAMP says it expects to publish transition paths for existing Rev5 services by the end of FY27. Treat everything in this section as time-sensitive and check fedramp.gov before acting.

Certification types, classes and paths

FedRAMP describes classes as giving agencies increasing assurance. They "loosely align" with the NIST SP 800-53B low, moderate and high baselines, but FedRAMP says there is "not a direct correlation", because providers tailor controls and agencies combine components of different categorisations.

Agency Certification "requires a federal agency to authorize the service in advance" and then sponsor it; Program Certification "does not require a federal agency to 'sponsor' the service". FedRAMP's own advice is blunt: "You don't really get to choose your Certification Path because it's the result of the choices you've already made."

Choosing a route: decision guidance

• SaaS on a certified platform, new to federal: start with 20x Class A. FedRAMP recommends Class A for most providers new to the federal market and advises against starting at Class C or D without an agency contract that requires it.
• SaaS on a certified platform, Moderate data: 20x Class C through Program Certification. Budget for engineering work on automated validation rather than for long narrative documents.
• Self-hosted or hybrid infrastructure: Rev5 with an agency sponsor until 20x rulesets for self-hosted and hybrid services arrive, which FedRAMP lists as an FY27 goal.
• High-impact workloads: Rev5 Agency Certification for Class D now; 20x Class D only after the Phase 4 pilot.
• Existing Rev5 certification: keep continuous monitoring current and plan for transition, but wait for the published transition paths rather than restarting under 20x.
• Small providers: 20x removes the sponsor dependency and much of the document burden, which suits smaller teams with mature cloud-native automation. Larger providers with government-only environments often stay on Rev5 for now.
• State and local buyers: GovRAMP (formerly StateRAMP), a non-profit for state, local, tribal and education governments, runs its own verification statuses from Security Snapshot to Authorized. It is a separate programme with its own requirements.
• Defence contractors: FedRAMP says it does not support or provide "equivalency" and that CMMC questions go to the Department of War. If your service handles CUI for defence contractors, see the CUI Guide.

Rev5: baselines, package and assessment

Rev5 certification uses the NIST SP 800-53 Rev. 5 control catalogue with baselines drawn from SP 800-53B (low, moderate and high, plus a privacy baseline), extended by FedRAMP parameters and additional controls. NIST's August 2025 Release 5.2.0 made no baseline changes. FedRAMP's legacy documentation page, dated 24 June 2026, says its templates are "intended only for reference" and that FedRAMP is "actively transitioning away from these processes and materials". The package still built today contains:

FedRAMP only accepts assessments from "FedRAMP Recognized independent assessment services", which it notes were formerly called Third-Party Assessment Organizations (3PAOs) and are listed in the Marketplace. It also states that 20x independent verification and validation needs different skills from Rev5 assessment.

FedRAMP 20x: Key Security Indicators

20x replaces narrative control descriptions with Key Security Indicators (KSIs) that a provider proves through automated, machine-readable evidence. FedRAMP's principle is that "Security should be continuously enforced, monitored, and reported", not staged for a point-in-time audit, and Phase 1 showed that "Key Security Indicators can demonstrate security posture in near real time". The Class C KSIs fall into ten themes. The NIST SP 800-53 families column is an NHI Mgmt Group orientation aid, not an official FedRAMP mapping.

Alongside the KSIs, Class C has fifteen rulesets, including Collaborative Continuous Monitoring (CCM), Certification Data Sharing (CDS), Cryptographic Module Use (CMU), Incident Evaluation and Communication (IEC), Independent Verification and Validation (IVV), Minimum Assessment Scope (MAS), Secure Configuration Guide (SCG), Significant Change Notification (SCN), Security Decision Record (SDR), Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER).

Where identity fits

The IAM KSIs are where 20x is most specific, and several explicitly cover non-human identities:

• KSI-IAM-APM: "Secure passwordless methods are used for user authentication and authorization when feasible", "otherwise strong passwords with phishing-resistant MFA is used." See the Passwordless and Passkeys Guide.
• KSI-IAM-JIT: a least-privileged, role and attribute-based, just-in-time model "for all user and non-user accounts and services". See the JIT Access Guide.
• KSI-IAM-SNU: "Appropriately secure authentication methods are used and persistently reviewed for non-user accounts and services." Workload identity federation and short-lived credentials are easier to evidence than static keys. See the NHI Authentication Guide.
• KSI-IAM-AAM and KSI-IAM-ELP: account, role and group lifecycles managed by automation, with access persistently reviewed so each user or device reaches only what it needs.
• KSI-IAM-SUS: "Accounts with privileged access are disabled or otherwise secured in response to suspicious activity", which needs detection wired to automated response.
• KSI-SVC-ASM: "Management, protection, and regular rotation of digital keys, certificates, and other secrets is automated". The Microsoft Storm-0558 key breach, in which a stolen signing key forged access to government email, shows why key custody matters even for certified providers. See the Secrets Management Guide.

Continuous monitoring and change

Under Rev5, continuous monitoring is a monthly cycle: vulnerability scanning results, an updated POA&M and a monthly executive summary go to agency customers, with vulnerability deviation requests for false positives, operational requirements or risk adjustments, and an annual assessment of a selected subset of controls by the independent assessor. Under the 2026 rules the same obligations are organised as rulesets:

• Collaborative Continuous Monitoring (CCM): how providers share ongoing security information with agencies and FedRAMP.
• Vulnerability Detection and Response (VDR) and Vulnerability Evaluation and Reporting (VER): detection, evaluation, remediation and reporting of vulnerabilities. Read the current ruleset text for timeframes before designing SLAs.
• Significant Change Notification (SCN): which changes must be notified and how, replacing the legacy significant change request process. M-24-15 asks for a framework that lets providers keep an agile deployment lifecycle without advance government approval.
• Incident Evaluation and Communication (IEC): how incidents are assessed and communicated to FedRAMP and agencies. Align it with your incident response plan. See the Incident Response Guide.
• Certification Data Sharing (CDS): how agencies obtain the package and monitoring data they need to issue and maintain their ATOs.

What agencies still decide

A FedRAMP certification does not authorise any agency's use of a service. Each agency still issues its own ATO or ATU (FedRAMP counted 760 new agency ATOs or ATUs in FY26) under its FISMA responsibilities.

• Reuse, not reassessment: under M-24-15 the agency starts from the presumption that the FedRAMP assessment is adequate at or below its level, and adds requirements only where it can show a specific need.
• Customer controls: the agency operates the controls the CRM assigns to it, typically its own user provisioning, MFA policy on its tenant, data classification and log review.
• Fit to the use case: because classes do not map one to one to impact levels, the agency checks that the class and the documented security objectives match its data and mission.
• Ongoing monitoring: the agency reviews monitoring data shared under the CDS and CCM rules and decides whether to continue use when risk changes. FedRAMP lists an Agency Cloud Use Framework for 20x among its FY27 goals.

Implementation: a phased approach

1. Confirm scope: check the service meets M-24-15 scope and the direct or indirect government-wide use test, and identify the federal data types involved.
2. Pick type and class: use the Choose a Path, Class and Type pages; record the decision and the evidence (hosting, customers, sponsor) in a decision record.
3. Define the boundary: inventory every component, external service and identity provider in scope, including service accounts, CI/CD identities and administrative access paths.
4. Gap assessment: for 20x, test each KSI against what your tooling can prove automatically; for Rev5, map controls against the SP 800-53B baseline and FedRAMP parameters.
5. Build evidence pipelines: generate machine-readable evidence (OSCAL for Rev5 packages) from configuration, identity and logging systems rather than screenshots. Run new enforcement (for example phishing-resistant MFA or JIT for admins) in report-only mode with a pilot group first, then enforce, keeping the prior configuration so it can be rolled back.
6. Engage a Recognized assessor: agree assessment scope against the Minimum Assessment Scope rules and fix findings before submission.
7. Submit and list: for Rev5, coordinate with the sponsoring agency; for 20x, apply through the Program Certification pipeline.
8. Operate: run continuous monitoring, change notification and incident communication as business processes with named owners, and track RFCs on fedramp.gov because the rules are still moving.

Detection and measurement

Feed identity provider sign-in logs, cloud control plane audit logs, secrets manager and key service logs, vulnerability scanner output and CI/CD deployment records into the same pipeline that produces your evidence, so monitoring and compliance draw on one data set. Useful measures:

• KSI validation pass rate: percentage of automated KSI checks passing in each run, with failures open longer than the agreed window.
• POA&M age: number of open items past their target date, by severity.
• Phishing-resistant coverage: share of human sign-ins in the boundary using passwordless or phishing-resistant MFA.
• Standing privilege: count of persistent privileged human and non-user accounts, trending to zero under JIT.
• Secret age: oldest unrotated key, certificate or token in the boundary.
• Change notification timeliness: significant changes notified on time as a percentage of all significant changes.

Common failure patterns

• Boundary drift: a new SaaS tool, logging service or support platform handles federal data but sits outside the documented boundary.
• Chasing a retired status: planning around FedRAMP Ready or a JAB P-ATO after those routes have closed, instead of Class A or agency sponsorship.
• Starting too high: pursuing Class C or D with no agency demand, consuming budget that a Class A certification would have turned into revenue sooner.
• Screenshots as evidence: 20x expects automated validation; manual evidence does not scale to persistent validation and slows assessor review.
• Forgotten non-human access: CI/CD tokens, support tooling and long-lived cloud keys bypass the JIT and MFA controls applied to people.
• Ignoring the CRM: agencies assume the provider covers controls that the Customer Responsibility Matrix assigns to them.

Practitioner checklist

• Record the date you last checked fedramp.gov rules, timelines and open RFCs, and review them monthly.
• Document your certification type, class and path decision with the evidence behind it.
• Draw the authorisation boundary including every identity provider, service account and pipeline identity.
• Enforce passwordless or phishing-resistant MFA for all human access in the boundary.
• Move privileged human and non-user access to just-in-time, and automate secret and key rotation.
• Generate evidence automatically from source systems and keep it machine-readable.
• Select a FedRAMP Recognized assessor early and agree the minimum assessment scope.
• Assign owners for continuous monitoring, change notification and incident communication.
• Publish a clear customer responsibility matrix to agency customers.

Standards and references

• FedRAMP: Consolidated Rules for 2026
• FedRAMP: Important Dates
• FedRAMP: FedRAMP 20x
• FedRAMP: 20x Class C Key Security Indicators
• OMB: M-24-15 Modernizing the Federal Risk and Authorization Management Program
• NIST: SP 800-53B Control Baselines for Information Systems and Organizations
• FedRAMP: Legacy Documentation Reference
• FedRAMP: From Foundation to Implementation, FY26 review

Related NHI Mgmt Group resources: Public Sector Identity Security Guide · CUI Guide · NHI Authentication Guide · Secrets Management Guide · JIT Access Guide. This guide summarises FedRAMP requirements and programme status as published on fedramp.gov on 16 October 2026, and is not legal advice.