FedRAMP 20x Key Security Indicators: Complete Implementation Guide

FedRAMP 20x replaces the traditional 325+ NIST 800-53 controls with 61 Key Security Indicators (KSIs) for Moderate authorization. This guide covers every KSI category with implementation requirements, automation expectations, and practical guidance.

What Are Key Security Indicators?
KSI Categories Overview
KSI-AFR: Authorization by FedRAMP
KSI-IAM: Identity and Access Management
KSI-CNA: Cloud Native Architecture
KSI-SVC: Service Configuration
KSI-MLA: Monitoring, Logging, and Auditing
KSI-CMT: Change Management
KSI-PIY: Policy and Inventory
KSI-RPL: Recovery Planning
KSI-INR: Incident Response
KSI-CED: Cybersecurity Education
KSI-TPR: Third-Party Resources
Cross-Cutting Requirements
Automation Requirements
Getting Started

What Are Key Security Indicators?

Key Security Indicators (KSIs) are measurable security capabilities that replace traditional NIST 800-53 control narratives in FedRAMP 20x. Instead of documenting how you plan to implement a control, KSIs require you to prove the control is working through automated validation.

KSIs vs. Traditional Controls

Aspect	Traditional FedRAMP	FedRAMP 20x KSIs
Focus	Process documentation	Measurable outcomes
Validation	Point-in-time audit	Continuous automation
Evidence	Written narratives	Machine-readable data
Count	325+ controls (Moderate)	61 KSIs (Moderate)
Assessment	3PAO manual review	Automated + 3PAO

Why KSIs Matter

The shift to KSIs reflects a fundamental change in how FedRAMP evaluates security:

Outcomes over process: Does encryption actually work, not just “is there an encryption policy”
Continuous over point-in-time: Ongoing proof, not annual audits
Automated over manual: Machine-readable evidence, not PDF narratives
Capabilities over controls: What your system can do, not what documents exist

KSI Categories Overview

FedRAMP 20x organizes KSIs into 11 thematic categories:

Category	Code	KSIs (Moderate)	Focus
Authorization by FedRAMP	KSI-AFR	5	Government-specific requirements
Identity and Access Management	KSI-IAM	6	Authentication, authorization, zero trust
Cloud Native Architecture	KSI-CNA	8	Infrastructure security, network controls
Service Configuration	KSI-SVC	10	Encryption, hardening, patching
Monitoring, Logging, Auditing	KSI-MLA	8	SIEM, vulnerability management
Change Management	KSI-CMT	5	CI/CD security, configuration baselines
Policy and Inventory	KSI-PIY	7	Asset management, security policies
Recovery Planning	KSI-RPL	4	Backup, RTO/RPO, disaster recovery
Incident Response	KSI-INR	3	Reporting, logging, lessons learned
Cybersecurity Education	KSI-CED	2	Security awareness, role-based training
Third-Party Resources	KSI-TPR	4	Supply chain, SBOM, vendor management

Note: The Moderate baseline includes 5 additional KSIs not in Low (KSI-CNA-08, KSI-MLA-08, KSI-SVC-08, KSI-SVC-09, KSI-SVC-10).

KSI-AFR: Authorization by FedRAMP

Theme: A secure cloud service provider seeking FedRAMP authorization will address all FedRAMP 20x requirements and recommendations, including government-specific requirements.

This category is unique because it ties directly to FedRAMP-specific policies that commercial providers typically don’t implement for commercial customers.

KSI-AFR-01: Minimum Assessment Scope

Requirement: Apply the FedRAMP Minimum Assessment Scope (MAS) to identify and document the scope of the cloud service offering to be assessed for FedRAMP authorization.

What This Means:

Define your authorization boundary clearly
Document all components within scope
Identify inherited controls from IaaS providers
Map data flows for federal information

Implementation:

{
  "authorization_boundary": {
    "system_name": "Platform28 Contact Center",
    "deployment_model": "SaaS",
    "service_model": "multi-tenant",
    "components_in_scope": [
      "web_application",
      "api_gateway",
      "database_cluster",
      "telephony_services",
      "ai_processing_engine"
    ],
    "inherited_from": [
      {
        "provider": "AWS GovCloud",
        "fedramp_authorization": "FedRAMP High",
        "controls_inherited": ["PE-*", "MP-*", "MA-*"]
      }
    ]
  }
}

Related NIST Controls: CA-3, CA-9, PL-2

Requirement: Use a FedRAMP-compatible trust center to store and share authorization data with all necessary parties.

What This Means:

Maintain a public trust center
Provide programmatic access to authorization data
Log access for at least six months
Don’t require NDAs for FedRAMP review

Trust Center Requirements:

Direct marketplace links
Service and deployment model documentation
Customer support information
Next authorization report dates
Security objectives and controls

KSI-AFR-03: Government Reporting

Requirement: Report security status and incidents to government customers per FedRAMP requirements.

What This Means:

Monthly continuous monitoring reports
Incident notifications within required timeframes
POA&M updates
Annual assessment results

KSI-AFR-04: Federal Requirements Compliance

Requirement: Address all government-specific requirements that don’t apply to commercial customers.

Examples:

US person requirements for privileged access
Data residency (US-only)
Background check requirements
Specific logging retention periods

KSI-AFR-05: FedRAMP Standards Adherence

Requirement: Demonstrate compliance with all published FedRAMP standards and guidance.

Key Documents to Address:

Vulnerability scanning requirements
Continuous monitoring guidance
Incident response requirements
Security assessment procedures

KSI-IAM: Identity and Access Management

Theme: A secure cloud service offering will protect user data, control access, and apply zero trust principles.

This is one of the most critical KSI categories. IAM failures are involved in the majority of cloud breaches.

KSI-IAM-01: Phishing-Resistant MFA

Requirement: Enforce phishing-resistant multi-factor authentication (MFA) for all user authentication.

What “Phishing-Resistant” Means:

Method	Phishing-Resistant?	Why
FIDO2/WebAuthn	Yes	Cryptographically bound to origin
PIV/CAC smart cards	Yes	Certificate-based, origin-bound
Passkeys (device-bound)	Yes	Cryptographic binding
SMS codes	No	SIM swap, phishing
TOTP (Authenticator apps)	No	User enters code on fake site
Push notifications	No	Push bombing/MFA fatigue
Email codes	No	Phishable

Implementation:

{
  "ksi": "KSI-IAM-01",
  "idp_configuration": {
    "provider": "Okta",
    "mfa_policy": {
      "required": true,
      "allowed_factors": ["webauthn", "fido2"],
      "disallowed_factors": ["sms", "totp", "email", "push"],
      "fallback_allowed": false
    }
  },
  "validation": {
    "method": "automated_policy_export",
    "frequency": "continuous",
    "last_validated": "2026-02-24T00:00:00Z"
  }
}

Common Mistakes:

Allowing SMS/TOTP as fallback methods
Excluding service accounts from requirements
Not covering all entry points (admin consoles, APIs)
Using push notifications and calling it “phishing-resistant”

Related NIST Controls: IA-2, IA-2(1), IA-2(2), IA-2(6), IA-2(8)

KSI-IAM-02: Strong Authentication

Requirement: Implement passwordless methods where feasible; otherwise require strong passwords with MFA.

Passwordless Options:

FIDO2 security keys
Platform authenticators (Windows Hello, Touch ID)
Certificate-based authentication

If Passwords Required:

Minimum 15 characters
No password expiration (per NIST 800-63B)
Breached password detection
MFA always required

KSI-IAM-03: Service Account Security

Requirement: Enforce secure authentication for non-user accounts and services.

Implementation Requirements:

No shared credentials
Short-lived tokens (< 1 hour)
Certificate-based authentication
Managed identities where available
No hardcoded credentials in code

{
  "service_accounts": [
    {
      "name": "api-gateway-service",
      "auth_method": "managed_identity",
      "credential_rotation": "automatic",
      "token_lifetime_seconds": 3600
    },
    {
      "name": "database-connector",
      "auth_method": "certificate",
      "certificate_rotation_days": 90,
      "private_key_storage": "AWS Secrets Manager"
    }
  ]
}

Related NIST Controls: IA-4, IA-5, IA-9

KSI-IAM-04: Least Privilege Authorization

Requirement: Apply least-privilege, role/attribute-based, just-in-time authorization models.

Implementation:

Role-based access control (RBAC)
Attribute-based access control (ABAC) where appropriate
Just-in-time (JIT) access for privileged operations
Regular access reviews (quarterly minimum)
Automatic de-provisioning on termination

JIT Access Example:

{
  "jit_policy": {
    "privileged_roles": ["database_admin", "infrastructure_admin"],
    "max_duration_hours": 4,
    "approval_required": true,
    "approvers": ["security_team", "manager"],
    "justification_required": true,
    "audit_logging": true
  }
}

Related NIST Controls: AC-2, AC-3, AC-6

KSI-IAM-05: Zero Trust Design

Requirement: Implement zero trust design principles that assume resources will be compromised.

Zero Trust Principles:

Never trust, always verify: Authenticate every request
Assume breach: Design as if attackers are inside
Verify explicitly: Use all available data points
Least privilege access: Minimum necessary permissions
Micro-segmentation: Limit lateral movement

Implementation Evidence:

Network segmentation documentation
Identity verification at every layer
Encrypted communications everywhere
Continuous session validation
Device health checks

KSI-IAM-06: Suspicious Activity Response

Requirement: Automatically disable or secure privileged accounts upon suspicious activity detection.

Automated Responses:

Trigger	Response
Multiple failed logins	Temporary lockout, alert
Impossible travel	Session termination, step-up auth
Unusual access patterns	Alert, require re-authentication
Privileged action anomaly	Block, require approval
Credential leak detected	Force password reset

Related NIST Controls: AC-2(4), SI-4

KSI-CNA: Cloud Native Architecture

Theme: A secure cloud service offering will use cloud native architecture and design principles to enforce and enhance confidentiality, integrity, and availability.

KSI-CNA-01: Traffic Controls

Requirement: Configure all information resources to restrict inbound and outbound traffic.

Implementation:

Security groups with deny-by-default
Network ACLs for subnet-level control
Web Application Firewall (WAF)
Outbound traffic filtering (egress controls)

{
  "security_group": {
    "name": "web-tier-sg",
    "inbound_rules": [
      {"port": 443, "source": "0.0.0.0/0", "description": "HTTPS"},
      {"port": 80, "source": "0.0.0.0/0", "description": "HTTP redirect"}
    ],
    "outbound_rules": [
      {"port": 443, "destination": "api-tier-sg", "description": "API calls"},
      {"port": 5432, "destination": "db-tier-sg", "description": "Database"}
    ],
    "default_action": "deny"
  }
}

Related NIST Controls: SC-7, AC-4

KSI-CNA-02: Attack Surface Minimization

Requirement: Design systems to minimize the attack surface and lateral movement if compromised.

Implementation:

Remove unnecessary services and ports
Micro-segmentation between services
Container isolation
Immutable infrastructure
Principle of least functionality

KSI-CNA-03: Logical Networking

Requirement: Use logical networking and related capabilities to enforce traffic flow controls.

Implementation:

Virtual Private Clouds (VPCs)
Private subnets for internal services
VPC peering with explicit routes
PrivateLink for AWS services
No direct internet access for databases

KSI-CNA-04: Immutable Infrastructure

Requirement: Use immutable infrastructure with strictly defined functionality and privileges by default.

Implementation:

Infrastructure as Code (Terraform, CloudFormation)
Immutable container images
No SSH access to production
Blue-green deployments
Automated rollback capabilities

{
  "deployment_config": {
    "strategy": "blue-green",
    "immutable_artifacts": true,
    "ssh_access": "disabled",
    "instance_replacement": "on_config_change",
    "rollback_automatic": true,
    "rollback_trigger": "health_check_failure"
  }
}

KSI-CNA-05: DoS Protection

Requirement: Protect against denial of service attacks and unwanted spam.

Implementation:

AWS Shield or equivalent
Rate limiting at edge
Geographic blocking (if appropriate)
Auto-scaling for legitimate traffic spikes
CDN with DDoS mitigation

Related NIST Controls: SC-5

KSI-CNA-06: High Availability

Requirement: Design systems for high availability and rapid recovery.

Implementation:

Multi-AZ deployment
Auto-scaling groups
Health checks and automatic replacement
Database replication
Defined RTO/RPO

KSI-CNA-07: Provider Best Practices

Requirement: Ensure cloud-native resources are implemented based on host provider’s best practices and documented guidance.

Evidence:

AWS Well-Architected review results
Compliance with CIS benchmarks
Security Hub findings addressed
Trusted Advisor recommendations

KSI-CNA-08: Automated Security Posture (Moderate Only)

Requirement: Use automated services to persistently assess security posture and enforce secure operations.

Implementation:

AWS Security Hub or equivalent
Automated compliance scanning
Drift detection
Auto-remediation for common issues

KSI-SVC: Service Configuration

Theme: A secure cloud service offering will follow FedRAMP encryption policies, continuously verify information resource integrity, and restrict access to third-party information resources.

KSI-SVC-01: Configuration Hardening

Requirement: Harden and review network and system configurations.

Implementation:

CIS benchmark compliance
Automated configuration scanning
Hardened AMIs/container images
Regular configuration reviews

{
  "hardening_baseline": "CIS_AWS_Foundations_v1.5",
  "compliance_score": 98.5,
  "findings": {
    "critical": 0,
    "high": 0,
    "medium": 2,
    "low": 5
  },
  "last_scan": "2026-02-24T00:00:00Z"
}

Related NIST Controls: CM-2, CM-6, CM-7

KSI-SVC-02: Network Traffic Encryption

Requirement: Encrypt or otherwise secure network traffic.

Implementation:

TLS 1.2+ for all external communications
TLS 1.3 preferred
Internal service mesh with mTLS
No plaintext protocols

Required Evidence:

Certificate inventory
TLS configuration audits
No deprecated cipher suites

KSI-SVC-03: Encryption at Rest

Requirement: Encrypt all federal and sensitive information at rest by default.

Implementation:

AWS KMS or equivalent for key management
AES-256 encryption minimum
Customer-managed keys (CMK) where required
Encrypted EBS volumes, S3 buckets, RDS instances

{
  "encryption_at_rest": {
    "databases": {
      "encryption": "AES-256",
      "key_management": "AWS KMS",
      "key_type": "customer_managed"
    },
    "object_storage": {
      "default_encryption": "SSE-KMS",
      "bucket_policy_enforced": true
    },
    "block_storage": {
      "encryption": "AES-256",
      "encrypted_by_default": true
    }
  }
}

Related NIST Controls: SC-28, SC-28(1)

KSI-SVC-04: Centralized Configuration Management

Requirement: Manage machine-based resource configurations using automation.

Implementation:

Infrastructure as Code
Configuration drift detection
Automated remediation
Version-controlled configurations

KSI-SVC-05: Cryptographic Integrity

Requirement: Enforce system and information resource integrity through cryptographic means.

Implementation:

Signed container images
Code signing
Artifact verification
Integrity monitoring (file integrity monitoring)

KSI-SVC-06: Automated Key Management

Requirement: Use automated key management systems to manage, protect, and regularly rotate digital keys and certificates.

Implementation:

AWS KMS or HashiCorp Vault
Automatic key rotation
Certificate auto-renewal (Let’s Encrypt, ACM)
Key usage logging

{
  "key_management": {
    "provider": "AWS KMS",
    "rotation": {
      "enabled": true,
      "frequency_days": 365
    },
    "certificates": {
      "provider": "AWS ACM",
      "auto_renewal": true
    },
    "audit_logging": true
  }
}

KSI-SVC-07: Security Patching

Requirement: Use a consistent, risk-informed approach for applying security patches.

Implementation:

Critical patches: 24-72 hours
High patches: 7 days
Medium patches: 30 days
Low patches: 90 days
Automated patching where possible

Related NIST Controls: SI-2

KSI-SVC-08: Residual Data Prevention (Moderate Only)

Requirement: Prevent changes from introducing residual elements damaging confidentiality, integrity, or availability.

Implementation:

Secure deletion procedures
Memory sanitization
Ephemeral compute instances
Data lifecycle management

KSI-SVC-09: Communication Integrity (Moderate Only)

Requirement: Continuously validate authenticity and integrity of communications between resources.

Implementation:

Mutual TLS (mTLS) for service-to-service
Message signing
API authentication
Certificate pinning where appropriate

KSI-SVC-10: Data Removal (Moderate Only)

Requirement: Promptly remove unwanted information, including from backups.

Implementation:

Data retention policies
Automated data deletion
Backup expiration
Right to deletion procedures

KSI-MLA: Monitoring, Logging, and Auditing

Theme: A secure cloud service offering will monitor, log, and audit all important events, activity, and changes.

KSI-MLA-01: SIEM Operation

Requirement: Operate a centralized, tamper-resistant SIEM or equivalent system.

Implementation:

Centralized log aggregation
Tamper-evident storage
Real-time alerting
Correlation rules
Retention per FedRAMP requirements

{
  "siem_configuration": {
    "platform": "Splunk Cloud",
    "log_sources": [
      "cloudtrail", "vpc_flow_logs", "waf_logs",
      "application_logs", "database_audit_logs"
    ],
    "retention_days": 365,
    "tamper_protection": true,
    "real_time_alerting": true
  }
}

Related NIST Controls: AU-6, SI-4

KSI-MLA-02: Log Reviews

Requirement: Conduct regular log reviews and audits.

Implementation:

Automated anomaly detection
Weekly manual reviews for high-priority events
Monthly audit log reviews
Documented review procedures

KSI-MLA-03: Vulnerability Response

Requirement: Rapidly detect and remediate/mitigate vulnerabilities per FedRAMP’s Vulnerability Response standard.

Required Timeframes:

Severity	Detection	Remediation
Critical	24 hours	15 days
High	24 hours	30 days
Medium	Weekly	90 days
Low	Monthly	180 days

KSI-MLA-04: Authenticated Scanning

Requirement: Perform authenticated vulnerability scanning.

Implementation:

Credentialed scans for deeper analysis
Weekly infrastructure scans
Container image scanning in CI/CD
Database vulnerability assessment

KSI-MLA-05: IaC Evaluation

Requirement: Execute Infrastructure as Code and configuration evaluation/testing.

Implementation:

Pre-deployment security scanning
Terraform/CloudFormation validation
Policy as code (Sentinel, OPA)
Drift detection

{
  "iac_security": {
    "scanner": "Checkov",
    "integration": "CI/CD pipeline",
    "policy_framework": "OPA",
    "drift_detection": {
      "enabled": true,
      "frequency": "hourly",
      "auto_remediate": false
    }
  }
}

KSI-MLA-06: Centralized Vulnerability Tracking

Requirement: Centrally track and prioritize vulnerability mitigation.

Implementation:

Vulnerability management platform
Risk-based prioritization
SLA tracking
Remediation workflows

KSI-MLA-07: Audit Log Protection

Requirement: Protect audit logs from unauthorized access and modification.

Implementation:

Write-once storage
Separate log accounts
Access logging for logs
Encryption at rest

KSI-MLA-08: Log Access Controls (Moderate Only)

Requirement: Apply least-privileged, role/attribute-based, just-in-time access for log data.

Implementation:

RBAC for log access
Audit trail for log queries
Data masking for sensitive fields
Time-limited access grants

KSI-CMT: Change Management

Theme: A secure cloud service provider will ensure that all changes are properly documented and configuration baselines are updated accordingly.

KSI-CMT-01: Modification Logging

Requirement: Log and monitor all system modifications.

Implementation:

Infrastructure change logging (CloudTrail)
Application deployment logging
Configuration change tracking
User activity monitoring

KSI-CMT-02: Version-Controlled Deployment

Requirement: Deploy changes through immutable, version-controlled resources rather than direct modifications.

Implementation:

Git-based workflows
No manual production changes
Immutable deployments
Rollback capabilities

{
  "deployment_policy": {
    "method": "gitops",
    "manual_changes_allowed": false,
    "approval_required": true,
    "rollback_enabled": true,
    "version_control": "GitHub",
    "artifact_registry": "ECR"
  }
}

KSI-CMT-03: Automated Testing

Requirement: Implement persistent automated testing and validation of changes throughout their lifecycle.

Implementation:

Unit tests in CI
Integration tests
Security scanning (SAST/DAST)
Compliance validation
Performance testing

KSI-CMT-04: Change Procedures

Requirement: Consistently follow a documented change management procedure.

Implementation:

Change advisory board (CAB) for significant changes
Emergency change procedures
Change request documentation
Post-implementation reviews

KSI-CMT-05: Risk Evaluation

Requirement: Evaluate risk and impact for all changes.

Implementation:

Change impact assessment
Risk categorization
Approval workflows based on risk
Rollback planning

KSI-PIY: Policy and Inventory

Theme: A secure cloud service offering will have intentional, organized, universal guidance for how every information resource, including personnel, is secured.

KSI-PIY-01: Asset Inventory

Requirement: Generate inventories of information resources from authoritative sources.

Implementation:

Automated asset discovery
Infrastructure as Code as source of truth
Container/service inventory
Software inventory (SBOM)

{
  "inventory_sources": [
    {"type": "infrastructure", "source": "Terraform state"},
    {"type": "containers", "source": "EKS API"},
    {"type": "software", "source": "SBOM generation"},
    {"type": "certificates", "source": "ACM"}
  ],
  "sync_frequency": "hourly",
  "last_updated": "2026-02-24T00:00:00Z"
}

Related NIST Controls: CM-8

KSI-PIY-02: Security Objectives

Requirement: Document security objectives for all resources.

Implementation:

Security policies per resource type
Data classification
Access requirements
Encryption requirements

KSI-PIY-03: Vulnerability Disclosure

Requirement: Maintain a vulnerability disclosure program.

Implementation:

Public security.txt
Bug bounty or VDP program
Response procedures
Researcher communication process

KSI-PIY-04: Secure SDLC

Requirement: Integrate security into Software Development Lifecycle; align with CISA Secure By Design.

Implementation:

Security requirements in design
Threat modeling
Secure coding training
Security testing in CI/CD
Security sign-off before release

KSI-PIY-05: Evaluation Documentation

Requirement: Document implementation evaluation methods.

Implementation:

Security control testing procedures
Validation criteria
Evidence collection methods
Audit procedures

KSI-PIY-06: Security Resources

Requirement: Allocate dedicated security staff and budget with executive support.

Implementation:

Defined security roles
Security budget allocation
Executive sponsorship
Security team reporting structure

KSI-PIY-07: Supply Chain Documentation

Requirement: Document risk management decisions for software supply chain security.

Implementation:

Vendor security assessments
Third-party risk management
Supply chain risk decisions
Dependency management

KSI-RPL: Recovery Planning

Theme: A secure cloud service offering will define, maintain, and test incident response plan(s) and recovery capabilities to ensure minimal service disruption.

KSI-RPL-01: RTO/RPO Definition

Requirement: Define Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO).

Implementation:

{
  "recovery_objectives": {
    "tier_1_critical": {
      "services": ["core_api", "database", "auth"],
      "rto_hours": 1,
      "rpo_hours": 0.25
    },
    "tier_2_important": {
      "services": ["reporting", "analytics"],
      "rto_hours": 4,
      "rpo_hours": 1
    },
    "tier_3_standard": {
      "services": ["admin_portal", "documentation"],
      "rto_hours": 24,
      "rpo_hours": 24
    }
  }
}

Related NIST Controls: CP-2, CP-10

KSI-RPL-02: Recovery Plan

Requirement: Develop and maintain a recovery plan that aligns with defined recovery objectives.

Implementation:

Documented recovery procedures
Runbooks for common scenarios
Communication plans
Escalation procedures

KSI-RPL-03: Backup Alignment

Requirement: Perform system backups aligned with recovery objectives.

Implementation:

Backup frequency matches RPO
Backup testing
Offsite/cross-region storage
Encryption of backups

KSI-RPL-04: Recovery Testing

Requirement: Regularly test the capability to recover from incidents and contingencies.

Implementation:

Quarterly recovery drills
Annual full DR test
Documented test results
Lessons learned integration

KSI-INR: Incident Response

Theme: A secure cloud service provider will document, report, and analyze security incidents for compliance and improvement.

KSI-INR-01: Incident Reporting

Requirement: Report incidents per FedRAMP requirements and provider policies.

FedRAMP Reporting Timeframes:

Incident Type	Notification
Data breach	1 hour
Significant incident	24 hours
Security incident	72 hours

Implementation:

Automated incident detection
Escalation procedures
FedRAMP notification templates
Agency notification lists

KSI-INR-02: Incident Logging

Requirement: Maintain incident log with periodic pattern/vulnerability reviews.

Implementation:

Incident tracking system
Root cause documentation
Trend analysis
Quarterly reviews

KSI-INR-03: After-Action Reports

Requirement: Generate after-action reports and integrate lessons learned.

Implementation:

Post-incident reviews
Lessons learned documentation
Process improvements
Training updates

KSI-CED: Cybersecurity Education

Theme: A secure cloud service provider will educate their employees on cybersecurity measures, testing them persistently to ensure their knowledge is satisfactory.

KSI-CED-01: Security Awareness Training

Requirement: Ensure all employees receive security and privacy awareness training, incident response training, and are familiar with all relevant policies and procedures.

Implementation:

Annual security awareness training
Phishing simulations
Policy acknowledgment
New hire training
Refresher training

{
  "training_program": {
    "security_awareness": {
      "frequency": "annual",
      "completion_required": true,
      "topics": [
        "phishing", "social_engineering", "data_handling",
        "incident_reporting", "password_security"
      ]
    },
    "phishing_simulations": {
      "frequency": "quarterly",
      "remedial_training": true
    }
  }
}

KSI-CED-02: Role-Based Training

Requirement: Deploy role-specific training for high-risk positions, including privileged access roles.

Implementation:

Developer secure coding training
Admin security training
Incident responder training
Compliance training for relevant roles

KSI-TPR: Third-Party Resources

Theme: A secure cloud service provider will understand, monitor, and manage supply chain risks from third-party services or components.

KSI-TPR-01: Third-Party Identification

Requirement: Follow FedRAMP’s Minimum Assessment Standard for third-party resources.

Implementation:

Inventory all third-party dependencies
Classify by risk level
Document data flows
Identify FedRAMP-authorized services

KSI-TPR-02: FedRAMP Authorization Verification

Requirement: Regularly confirm FedRAMP authorization and secure configuration of services handling federal information.

Implementation:

Verify via FedRAMP Marketplace
Annual re-verification
Monitor authorization status changes
Document authorization levels

KSI-TPR-03: Supply Chain Risk

Requirement: Identify and prioritize supply chain risk mitigation.

Implementation:

Vendor security assessments
Software composition analysis
Dependency vulnerability monitoring
Risk-based vendor tiering

KSI-TPR-04: Upstream Monitoring

Requirement: Monitor third-party software for upstream vulnerabilities with contractual notification or active monitoring.

Implementation:

SBOM maintenance
Dependency scanning (Dependabot, Snyk)
Vendor security notification subscription
Vulnerability tracking

{
  "supply_chain_monitoring": {
    "sbom_generation": "automatic",
    "dependency_scanning": {
      "tool": "Snyk",
      "frequency": "continuous"
    },
    "vendor_notifications": true,
    "critical_vuln_sla_hours": 24
  }
}

Cross-Cutting Requirements

Three cross-cutting KSIs apply across all categories:

KSI-CSX-MAS: Minimum Assessment Scope

Requirement: Apply all KSIs to all aspects within the FedRAMP Minimum Assessment Scope.

Every KSI must be applied to every component within your authorization boundary. No exceptions.

KSI-CSX-SUM: KSI Summaries

Requirement: Maintain summaries for each KSI including:

Goals for implementation
Validation process
Pass/fail criteria
Traceability to evidence

KSI-CSX-ORD: Implementation Order

Recommendation: Address KSIs in priority order in authorization packages.

Suggested Priority:

KSI-IAM (Identity) - Most critical for risk
KSI-MLA (Monitoring) - Enables visibility
KSI-SVC (Configuration) - Encryption, hardening
KSI-CNA (Architecture) - Foundation
Remaining categories

Automation Requirements

Phase 2 Automation Mandate

For Moderate authorization, FedRAMP requires:

70% of KSIs must have automated validation
Evidence in machine-readable format
Continuous validation, not point-in-time

What “Automated” Means

Level	Description	Acceptable?
Manual documentation	Written narratives	No
Manual evidence collection	Screenshots, exports	Partial
Automated collection	Scripted evidence gathering	Yes
Continuous validation	Real-time compliance checks	Yes (preferred)

Automation Tooling

Category	Tools
IaC Security	Checkov, tfsec, Terrascan
Policy as Code	Open Policy Agent, Sentinel
Compliance Platforms	Drata, Vanta, Secureframe
CSPM	AWS Security Hub, Prisma Cloud
Vulnerability Management	Qualys, Tenable, Rapid7
SIEM	Splunk, Sumo Logic, Datadog

Evidence Format

FedRAMP expects machine-readable evidence. Example structure:

{
  "ksi_evidence": {
    "ksi_id": "KSI-IAM-01",
    "validation_method": "automated",
    "tool": "Okta Policy Export",
    "timestamp": "2026-02-24T00:00:00Z",
    "result": "pass",
    "evidence": {
      "policy_id": "mfa-phishing-resistant",
      "allowed_factors": ["webauthn"],
      "enforcement": "required"
    },
    "next_validation": "2026-02-25T00:00:00Z"
  }
}

Getting Started

Assessment Checklist

Inventory your environment
- List all components in scope
- Identify inherited controls from IaaS
- Map data flows
Gap analysis against each KSI
- Document current state
- Identify gaps
- Prioritize by risk
Build automation
- Select tooling
- Implement continuous validation
- Generate machine-readable evidence
Document everything
- KSI summaries
- Validation procedures
- Pass/fail criteria

Timeline Considerations

Phase 2 Pilot: Through March 2026
General Availability: Expected Q3-Q4 2026
Traditional Rev5 EOL: H2 2027

Summary

FedRAMP 20x’s 61 Key Security Indicators represent a fundamental shift from documentation-based compliance to capabilities-based authorization. The key changes:

Outcomes over process: Prove security works, don’t just document policies
Automation required: 70%+ of KSIs need automated validation for Moderate
Continuous over point-in-time: Ongoing proof, not annual audits
Machine-readable evidence: JSON/OSCAL packages, not PDFs

For organizations with strong security practices, KSIs are often easier than traditional controls because you’re demonstrating what you already do rather than writing narratives about what you plan to do.

The transition requires investment in automation tooling and process changes, but the result is a more efficient, more secure authorization process that benefits everyone.

Last updated: February 2026. KSI requirements may change as FedRAMP finalizes Phase 2 standards. Always refer to official FedRAMP documentation for current requirements.

Table of Contents

What Are Key Security Indicators?

KSIs vs. Traditional Controls

Why KSIs Matter

KSI Categories Overview

KSI-AFR: Authorization by FedRAMP

KSI-AFR-01: Minimum Assessment Scope

KSI-AFR-02: Authorization Data Sharing

KSI-AFR-03: Government Reporting

KSI-AFR-04: Federal Requirements Compliance

KSI-AFR-05: FedRAMP Standards Adherence

KSI-IAM: Identity and Access Management

KSI-IAM-01: Phishing-Resistant MFA

KSI-IAM-02: Strong Authentication

KSI-IAM-03: Service Account Security

KSI-IAM-04: Least Privilege Authorization

KSI-IAM-05: Zero Trust Design

KSI-IAM-06: Suspicious Activity Response

KSI-CNA: Cloud Native Architecture

KSI-CNA-01: Traffic Controls

KSI-CNA-02: Attack Surface Minimization

KSI-CNA-03: Logical Networking

KSI-CNA-04: Immutable Infrastructure

KSI-CNA-05: DoS Protection

KSI-CNA-06: High Availability

KSI-CNA-07: Provider Best Practices

KSI-CNA-08: Automated Security Posture (Moderate Only)

KSI-SVC: Service Configuration

KSI-SVC-01: Configuration Hardening

KSI-SVC-02: Network Traffic Encryption

KSI-SVC-03: Encryption at Rest

KSI-SVC-04: Centralized Configuration Management

KSI-SVC-05: Cryptographic Integrity

KSI-SVC-06: Automated Key Management

KSI-SVC-07: Security Patching

KSI-SVC-08: Residual Data Prevention (Moderate Only)

KSI-SVC-09: Communication Integrity (Moderate Only)

KSI-SVC-10: Data Removal (Moderate Only)

KSI-MLA: Monitoring, Logging, and Auditing

KSI-MLA-01: SIEM Operation

KSI-MLA-02: Log Reviews

KSI-MLA-03: Vulnerability Response

KSI-MLA-04: Authenticated Scanning

KSI-MLA-05: IaC Evaluation

KSI-MLA-06: Centralized Vulnerability Tracking

KSI-MLA-07: Audit Log Protection

KSI-MLA-08: Log Access Controls (Moderate Only)

KSI-CMT: Change Management

KSI-CMT-01: Modification Logging

KSI-CMT-02: Version-Controlled Deployment

KSI-CMT-03: Automated Testing

KSI-CMT-04: Change Procedures

KSI-CMT-05: Risk Evaluation

KSI-PIY: Policy and Inventory

KSI-PIY-01: Asset Inventory

KSI-PIY-02: Security Objectives

KSI-PIY-03: Vulnerability Disclosure

KSI-PIY-04: Secure SDLC

KSI-PIY-05: Evaluation Documentation

KSI-PIY-06: Security Resources

KSI-PIY-07: Supply Chain Documentation

KSI-RPL: Recovery Planning

KSI-RPL-01: RTO/RPO Definition

KSI-RPL-02: Recovery Plan

KSI-RPL-03: Backup Alignment

KSI-RPL-04: Recovery Testing

KSI-INR: Incident Response

KSI-INR-01: Incident Reporting

KSI-INR-02: Incident Logging

KSI-INR-03: After-Action Reports

KSI-CED: Cybersecurity Education

KSI-CED-01: Security Awareness Training

KSI-CED-02: Role-Based Training

KSI-TPR: Third-Party Resources

KSI-TPR-01: Third-Party Identification

KSI-TPR-02: FedRAMP Authorization Verification

KSI-TPR-03: Supply Chain Risk

KSI-TPR-04: Upstream Monitoring

Cross-Cutting Requirements

KSI-CSX-MAS: Minimum Assessment Scope