FedRAMP 20x: Key Security Indicators, Classes and Evidence Explained

FedRAMP 20x asks cloud providers to prove that their security works, with measurements, instead of describing controls in a long System Security Plan, and most teams approach it the wrong way. Under the Consolidated Rules for 2026, 20x is the Program Certification path that needs no agency sponsor, built around Key Security Indicators (KSIs), a Security Decision Record (SDR) and persistent validation. This guide goes deeper than the overview in the FedRAMP Guide: it walks through every KSI theme, the identity and non-human identity indicators, the package and assessment rules, effective dates and the evidence an assessor will expect. It is written for cloud provider engineering, security and compliance teams and for the assessors who verify them. All rule text was read from FedRAMP's official machine-readable rules and 2026 documentation repositories on 8 November 2026; FedRAMP updates these often, so confirm details on fedramp.gov before acting.

Key takeaways

• 20x is outcome based: FedRAMP says KSIs ask providers to "demonstrate desired security capabilities instead of telling them to meet specific security requirements", and each KSI maps to NIST SP 800-53 controls rather than replacing them.
• Engineering must lead: FedRAMP warns "Do not attempt to approach Key Security Indicators from a traditional compliance standpoint" and notes that the most successful pilot organisations were led by engineering and product teams.
• The SDR replaces the SSP: for every applicable rule the provider records how it is followed, verification, validation and independent verification and validation, in human-readable and JSON formats.
• Identity is a full KSI theme: six IAM indicators cover automated account lifecycle, passwordless or phishing-resistant MFA, least privilege, just-in-time authorisation for user and non-user accounts, non-user authentication and response to suspicious privileged activity.
• Dates matter: 20x Class A applications opened on 3 August 2026, Class B and C on 31 August 2026, the 2026 rules become mandatory on 1 January 2027 and no new Rev5 applications are accepted after 11 June 2027.

What it is and who it applies to

FedRAMP now issues certifications in two types, 20x and Rev5, and four classes, A to D. 20x certifications use the Program Certification path: FedRAMP certifies the service directly and no federal agency has to sponsor it. Rev5 uses the legacy Agency Certification path, where an agency authorises the service first and then sponsors it. FedRAMP's own phrasing is that "you don't really get to choose your Certification Path because it's the result of the choices you've already made".

FedRAMP stresses there is "not a direct correlation" between class and FIPS 199 impact level, because providers tailor baselines and agencies combine components of different categories. It also notes that commercial cloud services are usually a component used by a federal information system, not a federal information system themselves. For the categorisation background see the NIST SP 800-53 Privacy Controls and FIPS 199/200 Categorisation Guide.

• Who should start with 20x Class A: FedRAMP advises that most providers entering the federal market start with Class A, which is designed for existing commercial products with SOC 2 Type II and a mature security programme. See the How to Read a SOC 2 Report Guide.
• Who should not jump to Class C or D: FedRAMP warns providers not to go straight to these classes unless an existing agency contract requires that commitment.
• Who stays on Rev5 for now: providers with an agency sponsor and those needing Class D. A provider may obtain 20x Class A and later move to Rev5 Class B, C or D via Agency Certification, but FedRAMP will not issue Program Certifications of both types to one provider.

Structure and key requirements

FedRAMP describes the 20x rules as "simple declarative statements" to be addressed one by one. Most providers work through them in this order: Marketplace Listing, FedRAMP Certification, Boundary rulesets, Assurance rulesets, Package rulesets and the Key Security Indicators.

The Key Security Indicator themes

The KSIs are grouped into eleven themes. Each indicator is a short outcome statement with related SP 800-53 controls; several are optional for Class B and required for Class C.

FedRAMP defines "persistently" as activity repeated over a long period, possibly irregular, where the cycle is intentional, understood and documented and "the status of persistent activities will always be known". That definition is what turns most KSIs into monitoring and metrics work rather than annual evidence collection.

Identity and NHI requirements

The IAM theme is where 20x is most explicit about non-human identities. Two indicators name "non-user accounts and services" directly, and the service configuration theme adds secret automation.

• Workload identity first: KSI-IAM-SNU is easiest to evidence when services authenticate with platform-issued, short-lived credentials. See the Cloud Workload Identity Guide.
• Secrets you cannot remove: third-party API keys and database passwords need vaulting, rotation and ownership records for KSI-SVC-ASM. See the Secrets Management Guide.
• Human factors: for KSI-IAM-APM, see the Phishing-Resistant MFA Guide.

Implementation steps

1. Confirm the class and path: use FedRAMP's decision workflow (existing certification, existing agency customers, otherwise Class A). Check that your service runs where 20x applies today; self-hosted and hybrid rulesets are still being developed.
2. Define the Minimum Assessment Scope: list every information resource that handles or could affect federal customer data, with information flows, security categories and third-party resources. Publish the service list with names that match your marketing material, as Certification Data Sharing requires.
3. Map each KSI to real activities: FedRAMP's starter questions are how the activity is performed, where it lives in the stack, what is already measured, why there are gaps, when it happens and where the data comes from. Assign an engineering owner per KSI.
4. Instrument before you document: build the queries, pipelines and dashboards that produce each measure, such as configuration drift from infrastructure as code, MFA coverage, static secret age and backup restore results.
5. Write the SDR from the data: for each KSI, record the measures and their objectives, the cycle for persistent measures, verification that automation is accurate and validation that measures work. Class C must include 30-day and up to one-year metric summaries plus daily metric data including persistent validation status.
6. Prepare the package: Certification Package Overview, Secure Configuration Guide for customers and the SDR, shared through a FedRAMP-compatible trust center with automation keeping human-readable and machine-readable versions consistent.
7. Run the independent assessment: engage a FedRAMP Recognized independent assessment service; Class B, C and D must complete one at least once a year.
8. Operate: keep VDR timeframes, notify significant changes under SCN, maintain the availability status page Classes B to D require, and keep metrics flowing. If something breaks, record it in the SDR rather than hiding it.

Evidence and assessment

The IVV ruleset separates two kinds of evidence. Verification shows the documented measure is implemented (FedRAMP's example: firewall rules exist, preferably shown from the source of truth). Validation shows it is effective (traffic is actually blocked, shown with metrics). Assessors also expect technical explanations and demonstrations, documented use of any representative samples, and assessment results included in the package "without inappropriate modification".

Vulnerability detection frequencies scale by class. For example, FedRAMP says Class C providers should run detection on resources likely to drift at least every 14 days and Class D at least every 7 days. For the monitoring model behind this, see the Continuous Authorisation and Ongoing Authorisation Guide.

Measuring whether it works

• Persistent validation pass rate: share of KSI measures reporting a current, passing status each day.
• Drift time: median time from configuration drift detection to redeployment of the intended state.
• Static credential exposure: count and maximum age of non-user static secrets in scope.
• Standing privilege: number of identities with permanent administrative roles.
• Recovery evidence: last successful restore test against RTO and RPO per critical service.
• Vulnerability timeliness: share of findings mitigated within the VDR timeframe for your class.

Mapping to other frameworks

Every KSI lists related SP 800-53 Rev. 5 controls, which is the bridge to Rev5, CMMC and ISO work. The mapping below uses controls FedRAMP lists for the KSIs and CSF 2.0 outcomes that match.

• SOC 2: a SOC 2 Type II report within 12 months is one of the routes into Class A, but it does not satisfy the KSIs by itself. See the SOC 2 Guide.
• CMMC: FedRAMP does not provide equivalency with CMMC. See the NIST SP 800-171 and CMMC 2.0 Guide.
• Machine-readable formats: the SDR has a published JSON schema; teams with OSCAL tooling can reuse much of their control data. See the OSCAL Guide.
• Cryptography: the CMU ruleset governs cryptographic module use. See the FIPS 140-3 and Cryptographic Module Validation Guide.

Common pitfalls

• Treating KSIs as a questionnaire: writing narrative answers without measures. FedRAMP explicitly warns against a traditional compliance approach, and the SDR requires validation that measures work.
• Screenshots instead of sources of truth: point-in-time screenshots satisfy neither persistent validation nor the IVV preference for showing configuration from where it is deployed.
• Forgetting non-user accounts: KSI-IAM-JIT and KSI-IAM-SNU cover services and machine accounts. A long-lived CI/CD deploy key with administrator rights undermines both.
• Scoping too narrowly: omitting logging pipelines, identity providers or support tooling that can affect federal customer data breaks the Minimum Assessment Scope rule.
• Starting at Class C without a customer: FedRAMP advises against it; Class C adds mandatory daily metric history and more required indicators.
• Missing deadlines that already passed: AFC and SCG had earlier effective dates than the rest, and VDR and VER apply to new applications from 7 December 2026.

Practitioner checklist

• Confirm class and path with FedRAMP's decision workflow and check current dates on fedramp.gov.
• Publish a Minimum Assessment Scope with information flows, security categories and third-party resources.
• Assign an engineering owner and at least one automated measure to every applicable KSI.
• Inventory every non-user account, workload identity and secret in scope, and move services to short-lived federated credentials.
• Remove standing administrative access and enforce phishing-resistant MFA or passwordless sign-in for people.
• Generate the SDR in human-readable and JSON formats from live data, with the cycle and validation status for each measure.
• Stand up a FedRAMP-compatible trust center and the availability status page if you target Class B or above.
• Book a FedRAMP Recognized independent assessment service and plan the annual cycle.
• Track VDR timeframes and SCN categories in your change and vulnerability workflows.

Standards and references

• FedRAMP: FedRAMP 20x
• FedRAMP: Key Security Indicators
• FedRAMP: Important Dates for the Consolidated Rules for 2026
• FedRAMP: Machine-Readable Rules repository
• FedRAMP: Consolidated Rules for 2026 documentation (Markdown)
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• NIST: FIPS 199 Standards for Security Categorization

Related NHI Mgmt Group resources: FedRAMP Guide · Continuous Authorisation and Ongoing Authorisation Guide · Cloud Workload Identity Guide · Compliance Automation Guide · NIST SP 800-53 Guide