FedRAMP 20x 10 min read

    FedRAMP 20X: Why 60 KSIs Actually Mean 124 Requirements for Cloud Service Providers

    If you've read anything about FedRAMP 20X, you've probably heard the headline: traditional FedRAMP made cloud service providers grind through hundreds of NIST SP 800-53 controls, and FedRAMP 20X replaces all of that with 60 Key Security Indicators (KSIs). It sounds like a dramatic simplification — and in many ways, it is.

    But there's an important detail that catches almost every CSP off guard the first time they read the actual FedRAMP 20X documentation: behind the 60 KSIs sit ~156 underlying requirements. If you miss those, the KSIs themselves don't hold up under assessment.

    This post unpacks how the KSIs and the 156 requirements fit together, why the framing matters for any cloud provider planning a 20X authorization, and how to think about the work in a way that won't blow up your timeline.

    Note: This is current based on the most up-to-date FedRAMP 20X Low and Moderate KSIs from April 8, 2026.

    The mental model for FedRAMP 20X: passing the test vs. keeping your license

    Think about FedRAMP 20X like getting a driver's license.

    The KSIs are the driving test. They prove you can actually drive — turn safely, parallel park, obey traffic laws. The sub-requirements associated with the KSI are everything else that comes with having a license — renewing it on schedule, updating your address when you move, carrying insurance, following the rules of the road every day, not just the day of the test.

    Passing the driving test once doesn't make you a safe driver forever. The license stays valid because you keep meeting all the surrounding obligations — these are the things that make your "I can drive" claim trustworthy over time.

    FedRAMP 20X works the same way. The 60 KSIs prove your cloud service is secure right now. The 156 underlying requirements are how you keep proving it — every few days, every month, every quarter — to the federal agencies who depend on you.

    What the KSIs actually are

    The KSIs are organized into 11 themes, each describing a security capability the cloud service offering must demonstrate:

    • AFR — Authorization by FedRAMP: how the provider engages with FedRAMP itself
    • CMT — Change Management: how changes get logged, validated, and deployed
    • CNA — Cloud-Native Architecture: segmentation, attack surface, host hardening
    • CED — Cybersecurity Education: training across staff, privileged users, developers, and IR teams
    • IAM — Identity and Access Management: phishing-resistant MFA, least privilege, automated lifecycle
    • INR — Incident Response: procedure review, pattern analysis, after-action reports
    • MLA — Monitoring, Logging, and Auditing: SIEM, log review, configuration evaluation
    • PIY — Policy and Inventory: real-time inventories, vulnerability disclosure, secure SDLC alignment
    • RPL — Recovery Planning: RTO/RPO, backups, recovery testing
    • SVC — Service Configuration: encryption, automated config management, secret rotation
    • SCR — Supply Chain Risk: third-party risk identification and upstream vulnerability monitoring

    Ten of those 11 themes describe the security of the cloud service itself. The first theme — Authorization by FedRAMP (AFR) — is different. It's where the 156 underlying requirements actually come from.

    Where the 156 requirements come from: the AFR family

    Most CSPs read the AFR KSIs once, see "process and engagement with FedRAMP," and skim past them. That's the mistake. The AFR family isn't a procedural footnote — it's the connective tissue of the whole framework. Each AFR indicator points to a specific underlying requirement set that the provider must build, operate, and maintain.

    There are 10 AFR indicators that name the underlying requirements directly. Each requirement set contains a different number of individual sub-requirements, and those sub-requirements aren't all directed at the CSP. Here's the breakdown:

    Requirement Set
    Minimum Assessment Scope (MAS)
    CSP Reqs
    5
    Other Actors
    0
    Total
    5
    Requirement Set
    Secure Configuration Guide (SCG)
    CSP Reqs
    9
    Other Actors
    0
    Total
    9
    Requirement Set
    Using Cryptographic Modules (UCM)
    CSP Reqs
    3
    Other Actors
    0
    Total
    3
    Requirement Set
    Persistent Validation and Assessment (PVA)
    CSP Reqs
    8
    Other Actors
    10 (Assessors)
    Total
    18
    Requirement Set
    Vulnerability Detection and Response (VDR)
    CSP Reqs
    33
    Other Actors
    4 (Agencies), 2 (FedRAMP)
    Total
    39
    Requirement Set
    Authorization Data Sharing (ADS)
    CSP Reqs
    9
    Other Actors
    7 (Trust Centers)*
    Total
    16
    Requirement Set
    Collaborative Continuous Monitoring (CCM)
    CSP Reqs
    17
    Other Actors
    7 (Agencies)
    Total
    24
    Requirement Set
    FedRAMP Security Inbox (FSI)
    CSP Reqs
    8
    Other Actors
    8 (FedRAMP)
    Total
    16
    Requirement Set
    Incident Communications Procedures (ICP)
    CSP Reqs
    9
    Other Actors
    0
    Total
    9
    Requirement Set
    Significant Change Notifications (SCN)
    CSP Reqs
    16
    Other Actors
    1 (FedRAMP)
    Total
    17
    Requirement Set
    Total
    CSP Reqs
    117
    Other Actors
    39
    Total
    156

    * The 7 Trust Center requirements technically apply to the trust center itself, but they're effectively CSP responsibilities. ADS-CSX-UTC requires CSPs to use a FedRAMP-compatible trust center, and the 7 Trust Center requirements are what define "FedRAMP-compatible." If you self-host your trust center, those 7 are your direct responsibility. If you use a third party, you're still on the hook for ensuring the platform meets them.

    This is the number every CSP planning a 20X authorization should anchor on: 117 direct provider requirements, plus 7 trust-center requirements you must ensure are met — for a working total of 124 requirements that land on you. The other 32 fall on Assessors (3PAOs), Agencies, and FedRAMP itself.

    So you're not looking at 60 things to implement. You're looking at 60 outcomes to demonstrate, and 124 underlying requirements you have to meet to keep demonstrating them.

    What this means strategically

    Engineering investment is bigger than the KSI count suggests

    If your security organization has scoped the work as "60 KSIs," double that estimate to account for the management system. The persistent validation engine in particular is a sustained engineering commitment, not a one-time project.

    Your security organization needs an operating model, not just a compliance team

    The cadences in 20X — 3–7 day persistent validation, monthly vulnerability reports, quarterly OARs and reviews, 1-hour incident reports — are operational requirements. Whoever owns FedRAMP 20X needs to run it as an ongoing program, not deliver it as a milestone.

    The tradeoff is favorable for cloud-native, automation-friendly providers

    The whole framework is designed around continuous, automated proof. Providers who already run infrastructure-as-code, immutable deployments, and continuous configuration validation are positioned to satisfy 20X with significantly less per-agency overhead than the legacy Rev5 process required.

    The bottom line

    FedRAMP 20X really is a simpler framework than its predecessor, but "simpler" doesn't mean "smaller." The 60 KSIs are the visible outcomes your service must demonstrate. Behind them sit 124 requirements that land directly on the cloud service provider, and the harder, more distinctive half of 20X is the operating model those requirements define.

    The 124 CSP requirements group naturally into four clusters by what they do. We break each one down in detail in the four posts of this series: