KSI-AFR-SCG—Secure Configuration Guide
Formerly KSI-AFR-07
>Control Description
>FRMR Requirements12
Normative requirements from the FedRAMP Requirements and Recommendations document — 3 mandatory, 8 recommended, 1 optional.
Recommended Secure Configuration
Providers MUST create, maintain, and make available recommendations for securely configuring their cloud services (the Secure Configuration Guide) that includes at least the following information:
- Required: Instructions on how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering.
- Required: Explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications.
- Recommended: Explanations of security-related settings that can be operated only by privileged accounts and their security implications.
These requirements and recommendations refer to this guidance as a Secure Configuration Guide but cloud service providers may make this guidance available in various appropriate forms that provide the best customer experience.
This guidance should explain how top-level administrative accounts are named and referred to in the cloud service offering.
Use Instructions
Providers MUST include instructions in the FedRAMP authorization package that explain how to obtain and use the Secure Configuration Guide.
Implementation Summaries
Providers MUST maintain simple high-level summaries of at least the following for each Key Security Indicator:
- Goals for how it will be implemented and validated, including clear pass/fail criteria and traceability
- The consolidated _information resources_ that will be validated (this should include consolidated summaries such as "all employees with privileged access that are members of the Admin group")
- The machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- The non-machine-based processes for _validation_ and the _persistent_ cycle on which they will be performed (or an explanation of why this doesn't apply)
- Current implementation status
- Any clarifications or responses to the assessment summary
Public Guidance
Providers SHOULD make the Secure Configuration Guide available publicly.
Secure Defaults
Providers SHOULD set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned.
Comparison Capability
Providers SHOULD offer the capability to compare all current settings for top-level administrative accounts and privileged accounts to the recommended secure defaults.
Export Capability
Providers SHOULD offer the capability to export all security settings in a machine-readable format.
API Capability
Providers SHOULD offer the capability to view and adjust security settings via an API or similar capability.
Machine-Readable Guidance
Providers SHOULD also provide the Secure Configuration Guide in a machine-readable format that can be used by customers or third-party tools to compare against current settings.
Versioning and Release History
Providers SHOULD provide versioning and a release history for recommended secure default settings for top-level administrative accounts and privileged accounts as they are adjusted over time.
Application within MAS
Providers SHOULD apply ALL Key Security Indicators to ALL aspects of their cloud service offering that are within the FedRAMP Minimum Assessment Scope.
1 optional guidance (MAY)
AFR Order of Criticality
Providers MAY use the following order of criticality for approaching Authorization by FedRAMP Key Security Indicators for an initial authorization package:
- Minimum Assessment Scope (MAS)
- Authorization Data Sharing (ADS)
- Using Cryptographic Modules (UCM)
- Vulnerability Detection and Response (VDR)
- Significant Change Notifications (SCN)
- Persistent Validation and Assessment (PVA)
- Secure Configuration Guide (RSC)
- Collaborative Continuous Monitoring (CCM)
- FedRAMP Security Inbox (FSI)
- Incident Communications Procedures (ICP)
>Trust Center Components4
Ways to express your implementation of this indicator — approaches vary by organization size, complexity, and data sensitivity.
From the field: Mature implementations express configuration security through policy-as-code — OPA/Rego policies, AWS Config rules, or Azure Policy enforcing baselines automatically, with drift detection dashboards showing compliance in real time. Configuration hardening becomes a continuously verified property rather than an initial setup step documented in a PDF.
Configuration Drift Detection Dashboard
Dashboard expressing configuration compliance against approved baselines with drift detection and auto-remediation status
Configuration Policy Enforcement
Automated enforcement of configuration baselines — policy engines prevent non-compliant resources from deploying
Secure Defaults Documentation
How the platform ships in a hardened state — security-by-default settings and configuration baselines
Secure Configuration Guides
Human-readable hardening guides covering baseline configurations aligned to CIS/DISA STIGs — reference material supporting automated enforcement
>Programmatic Queries
CLI Commands
gh api repos/{owner}/{repo}/contents/docs/hardening --jq '.[].name'gh api repos/{owner}/{repo}/contents/docs --jq '.[].name' | grep -i "secur\|harden\|config">20x Assessment Focus Areas
Aligned with FedRAMP 20x Phase Two assessment methodology
Completeness & Coverage:
- •Does the Secure Configuration Guide cover every customer-configurable feature, or are there settings not yet documented?
- •How do you ensure secure-by-default configurations apply to all deployment models (single-tenant, multi-tenant, hybrid)?
- •Are there customer-facing features where the default is not the most secure option, and how are those exceptions documented and justified?
- •When new features or configuration options are released, how do you ensure the SCG is updated before or at the time of release?
Automation & Validation:
- •What automated checks validate that default configurations shipped to new customers actually match the documented secure baselines?
- •How do you detect when a customer overrides a secure default, and does the system warn or block insecure configuration choices?
- •What happens if a secure-by-default setting causes a functional regression for customers — how is the failure detected and resolved without weakening security?
- •Do you run automated compliance scans against customer environments to measure adherence to the SCG?
Inventory & Integration:
- •How does the SCG integrate with your deployment automation (Terraform modules, Helm charts, CloudFormation templates) so secure defaults are enforced at provisioning time?
- •What tools track which customers are running configurations that deviate from the SCG?
- •Is the SCG published as machine-readable configuration policies (OPA, Sentinel, Config Rules), or only as a human-readable document?
- •How do you correlate security incidents with customer configurations that deviated from the SCG?
Continuous Evidence & Schedules:
- •How often is the Secure Configuration Guide reviewed and updated, and how do you prove the review schedule is followed?
- •What evidence shows customers are notified when SCG recommendations change?
- •How do you measure customer adoption of secure configuration recommendations over time?
- •Is there a mechanism for continuously validating that your own production environment follows the same SCG you publish to customers?
Update History
Ask AI
Configure your API key to use AI features.