If you've been following the FedRAMP 20x rollout, you've probably encountered the term "Key Security Indicators" more than once. KSIs are the technical foundation of the entire 20x model and the mechanism that makes faster, automation-driven authorization possible. Understanding what they are, how they differ from traditional FedRAMP requirements, and what they mean for your compliance program is essential groundwork for any CSP planning to pursue 20x authorization.

What are Key Security Indicators?

Key Security Indicators are a set of security capabilities that a cloud service provider must implement and continuously validate to achieve FedRAMP 20x authorization. Think of them as a modernized alternative to the traditional NIST 800-53 control framework designed from the ground up for cloud-native environments where security needs to be measurable, automatable, and verifiable in real time.

The core idea behind KSIs is straightforward: rather than asking CSPs to produce extensive narrative documentation describing how they've implemented security controls, KSIs ask a more direct question. Is this system secure right now? And can you prove it automatically?

Each KSI is built around a specific security capability: things like enforcing phishing-resistant multi-factor authentication, encrypting network traffic, or maintaining a centralized logging system. The expectation is that CSPs implement these capabilities and then validate them continuously using automated processes, producing machine-readable evidence that can be reviewed by assessors and agencies without relying on point-in-time documentation or manual review cycles.

This is a meaningful departure from how FedRAMP has historically worked, and it's worth understanding why FedRAMP made this shift before getting into the specifics of what KSIs cover.

KSIs vs. traditional NIST 800-53 controls

Under the traditional FedRAMP Rev5 process, CSPs were assessed against a fixed set of NIST 800-53 controls: 156 for Low, 323 for Moderate. Meeting these controls typically involved producing a System Security Plan that documents, in narrative form, how each control is implemented across the system. That documentation is then reviewed by a 3PAO and, ultimately, the sponsoring agency.

That process works, but it has well-known limitations. It's slow, expensive, and heavily dependent on the quality of the documentation rather than the actual security of the system. A CSP can write a thorough SSP and still have meaningful security gaps. On the other hand, a well-secured cloud-native system can struggle to translate its security posture into the comprehensive documentation the traditional process requires.

KSIs address this by shifting the focus from documentation to real-time validation. Instead of describing how a control is implemented, a CSP demonstrates that a security capability is in place and functioning, ideally through automated, production-derived evidence that can be continuously regenerated rather than assembled once and submitted.

A few practical differences worth understanding:

• Outcomes over process. NIST controls often specify how something should be done, while KSIs focus on whether the intended security outcome is being achieved. This gives CSPs more flexibility in how they implement security requirements as long as the capability can be validated.
• Continuous over point-in-time. Traditional assessments capture a snapshot of your security posture at a specific moment. KSIs are designed to reflect your security posture on an ongoing basis, which means gaps surface in real time rather than during periodic assessments.
• Machine-readable over narrative. KSI-based authorization packages must be structured in a format that can be automatically consumed and evaluated, rather than submitted as static documents. This is what enables the faster review timelines that 20x has demonstrated in practice.

The KSI themes and what they cover

KSIs are organized into themes, each covering a distinct area of cloud security. Here's a clear overview of what each theme is asking for, based on the current Phase Two framework:

Cloud Native Architecture (KSI-CNA)

This theme is about how your system is built. It covers things like minimizing your attack surface, restricting network traffic, using logical network segmentation, and designing for high availability. The underlying expectation is that your infrastructure is built with security baked in from the start, not bolted on afterward.

Service Configuration (KSI-SVC)

This theme covers how your system is configured and maintained over time. It includes encrypting network traffic and data at rest, managing configurations through automation, validating the integrity of system components using cryptographic methods, and rotating keys and secrets on a regular basis. The emphasis is on keeping your environment in a known, secure state rather than discovering configuration drift after the fact.

Identity and Access Management (KSI-IAM)

This theme covers how your system controls who can access what. It includes enforcing phishing-resistant MFA for all user authentication, using a least-privilege and just-in-time access model, securing non-user account authentication, automating account lifecycle management, and responding automatically to suspicious activity. Zero trust principles run throughout this theme.

Authorization by FedRAMP (KSI-AFR)

This theme is unique to the 20x framework and represents the government-specific requirements that go beyond general cloud security best practices. It covers how CSPs share authorization data with agencies, how they handle significant change notifications, how they maintain collaborative continuous monitoring with agency customers, and how they manage incident communications. This is the theme that most directly reflects the shift toward transparency and ongoing risk sharing that defines 20x.

Change Management (KSI-CMT)

This theme covers how your system handles change. It includes logging and monitoring all modifications, executing changes through redeployment of version-controlled immutable resources rather than direct modification, and automating testing and validation throughout the deployment process. The expectation is that changes are traceable, controlled, and continuously validated.

Monitoring, Logging, and Auditing (KSI-MLA)

This theme covers your visibility into what's happening in your system. It includes operating a centralized SIEM or equivalent for tamper-resistant logging, persistently reviewing and auditing logs, evaluating infrastructure-as-code configurations, and maintaining a list of information resources and event types being monitored. Strong monitoring is foundational to continuous validation, so this theme underpins much of the rest of the KSI framework.

Policy and Inventory (KSI-PIY)

This theme covers organizational governance and asset management. It includes automatically generating real-time asset inventories, maintaining a vulnerability disclosure program, building security into the software development lifecycle, and reviewing executive support for security objectives. The emphasis is on intentional, documented, and continuously reviewed security governance rather than policies that exist on paper but aren't actively maintained.

Cybersecurity Education (KSI-CED)

This theme covers your security training program. It includes general security awareness training for all employees, role-specific training for high-risk roles like privileged access holders and developers, and training for staff involved in incident response and recovery. Crucially, the expectation isn't just that training exists; it's that CSPs persistently review the effectiveness of that training over time.

Recovery Planning (KSI-RPL)

This theme covers your ability to recover from incidents and contingencies. It includes defining Recovery Time Objectives and Recovery Point Objectives, aligning backups with those objectives, maintaining and reviewing recovery plans, and regularly testing your actual recovery capabilities. Like the other themes, the emphasis is on continuous review and testing rather than documentation that's updated once a year.

Incident Response (KSI-INR)

This theme covers how your organization detects, responds to, and learns from security incidents. It includes reviewing the effectiveness of your incident response procedures, analyzing past incidents for patterns, and generating after-action reports that incorporate lessons learned. The goal is a response capability that improves continuously, not one that's exercised only when an incident occurs.

Supply Chain Risk (KSI-SCR)

This theme covers the risks that come from third-party components and services in your environment. It includes continuously monitoring third-party software for upstream vulnerabilities, identifying and mitigating supply chain risks, and confirming that services handling federal information are FedRAMP authorized and securely configured.

What does persistent validation mean in practice?

One term you'll encounter throughout the KSI documentation is "persistently" — as in, CSPs must persistently validate, persistently review, persistently monitor. It's worth pausing on what this actually means in practice.

Persistent validation is the expectation that security capabilities are continuously verified from production environments, not just checked at assessment time. For many KSIs, this means having automated systems that regularly confirm a control is in place and functioning, and that can regenerate that evidence on demand rather than relying on a screenshot taken six months ago.

This is one of the areas where the operational shift of 20x becomes concrete. Persistent validation requires clear ownership of each KSI, a reliable asset inventory so you know what needs to be validated, and disciplined processes for catching and remediating drift before it becomes a finding. For CSPs used to the traditional model of building toward an assessment and then maintaining, the shift to genuinely continuous validation represents a meaningful change in how compliance programs need to operate day to day.

How to prepare for KSI-based authorization

If you're planning to pursue FedRAMP 20x authorization when the formal paths open in Phase Three, here's where to focus your preparation efforts.

Evaluate your automation capabilities

KSIs assume that a significant portion of your security validation is automated. Walk through each KSI theme and ask honestly: can we validate this automatically from our production environment? Where the answer is no, that's where your readiness work starts.

Invest in your logging and monitoring foundation

The Monitoring, Logging, and Auditing theme is foundational to nearly everything else in the KSI framework. If your centralized logging, SIEM configuration, and alerting aren't solid, it will be difficult to produce the kind of continuous, machine-readable evidence the 20x model requires.

Tighten your identity and access management posture

The IAM theme has some of the most concrete and verifiable requirements in the KSI framework. Phishing-resistant MFA, least-privilege access, just-in-time authorization, and automated account lifecycle management are all areas where gaps are easy to identify and, in most cases, addressable with existing tooling.

Build KSIs into your development process, not just your compliance program

The change management and cloud native architecture themes in particular reflect security practices that need to be embedded in how your engineering team works, not layered on top afterward. Version-controlled immutable deployments, automated testing throughout the deployment pipeline, and infrastructure built on cloud-native best practices are as much engineering decisions as compliance ones.

Get familiar with the Authorization by FedRAMP theme

The KSI-AFR theme covers the government-specific requirements that are most distinct from general commercial security best practices. Things like authorization data sharing, collaborative continuous monitoring, and significant change notifications require understanding the 20x ecosystem beyond your own environment. Getting familiar with these requirements early gives you more time to build the processes and infrastructure they require.