The text of the Secure Configuration Baseline Standard
Approval #
| Role | Name | Signature |
|---|---|---|
| Chief Information Security Officer (CISO) |
Revision History #
| Date | Version | Description | Reviewer |
|---|---|---|---|
| 2026-10-31 | 1.0 | Initial issuance | [Reviewer name] |
Review cycle: Every year, under the Policy and Procedure Management Policy.
Mandate. National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 control CM-6 requires the Organization to set each component to the most restrictive settings that still meet its operational needs, using common secure configurations. CM-2, CM-7, and SI-2 add a baseline for each system, least functionality, and current patches. These federal sources set more:
- Federal Acquisition Regulation (FAR) 39.101(c) directs agencies to use the common security configurations NIST publishes when they buy IT.
- Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 25-01 requires the mandatory Secure Cloud Business Applications (SCuBA) policies for each in-scope cloud tenant, assessment tools, and reports to CISA.
- The Federal Risk and Authorization Management Program (FedRAMP) Consolidated Rules for 2026 require agencies to review each provider’s Secure Configuration Guide and configure the settings it names.
The CISO owns this standard and approves it. The Configuration Management Policy (POL-CM) and the Configuration Management Procedures (PROC-CM) apply it, and they name it instead of repeating it.
1. Purpose and Scope #
This standard tells staff how the Organization chooses, approves, applies, checks, and fixes the secure configuration of each component. It covers every component in every system the Organization owns or that others run for it:
- Operating systems, network devices, databases, web servers, and middleware.
- Browsers and office software.
- Cloud infrastructure, platform accounts, containers, and machine images.
- Software as a service (SaaS) tenants.
- Mobile devices, and Internet of Things (IoT) and operational technology (OT) devices.
A contractor system that holds Organization data follows this standard, or the contractor gives the Authorizing Official (AO) its own hardening guides to approve.
2. Roles #
| Role | Responsibilities |
|---|---|
| CISO | Approves this standard and each baseline the Organization adopts. Reviews deviations that go to the AO. |
| AO | Approves a deviation from a Center for Internet Security (CIS) Level 1 setting, a Defense Information Systems Agency (DISA) Security Technical Implementation Guide (STIG) setting, or a mandatory setting. Accepts risk for a deviation from a mandatory SCuBA policy. |
| Configuration management team | Proposes the baseline for each component type and keeps the baseline register. Builds the settings into the deployment tools. |
| System Owners | Apply the approved baselines to their systems. Request deviations and fix drift by the due dates. |
| Information System Security Officers (ISSOs) | Check each deviation request and record approved deviations. Approve, with the Information System Security Manager (ISSM), a deviation from a CIS Level 2 setting. |
| Information System Security Manager (ISSM) | Approves, with the ISSO, a deviation from a CIS Level 2 setting or a recommended SCuBA policy. |
| Administrators | Apply settings, scan new components before production, and fix drift. |
| Vulnerability management team | Runs the compliance scans and reports the results. |
| Change Control Board | Approves each change that adopts a new baseline or a new baseline version. |
| Contracting Officer (CO) and Contracting Officer’s Representative (COR) | Put the configuration requirements of this standard in contracts. |
3. How Staff Select a Baseline #
- The configuration management team must pick a baseline for each component type, in the order of preference the table below shows. (NIST SP 800-53 CM-6; NIST SP 800-70 Rev. 5)
- The team takes CIS Benchmarks, DISA STIGs, CISA and the National Security Agency (NSA) guides, and vendor guides from the NIST National Checklist Program where it holds them. DISA STIGs are written for defense systems, so the team changes a STIG setting that does not fit a civilian system only through an approved deviation. (FAR 39.101(c); NIST SP 800-70 Rev. 5)
- A federal mandatory configuration comes before every other source. For an in-scope SaaS tenant, that is each mandatory SCuBA policy CISA lists under BOD 25-01. (CISA BOD 25-01)
- For a FedRAMP authorized service, the team reviews the provider’s Secure Configuration Guide and sets the customer settings it names. (FedRAMP Consolidated Rules for 2026)
- Where no checklist or guide exists, the Enterprise Security Architect writes a baseline from NIST guidance, and the CISO approves it. (NIST SP 800-128)
- Staff may make a baseline stricter for a system. They may not make it weaker without an approved deviation. (NIST SP 800-53 CM-6)
- NIST has retired the United States Government Configuration Baseline (USGCB), which covers only products their vendors no longer support. Staff use the National Checklist Program instead. (NIST SP 800-70 Rev. 5)
- Each baseline also sets least functionality: the ports, protocols, services, and software the component may run. (NIST SP 800-53 CM-7)
Baseline sources by component type.
| Component type | Baseline source, in order of preference | Applied with | Checked with |
|---|---|---|---|
| Workstation and server operating systems | CIS Benchmark Level 1 or DISA STIG from the National Checklist Program; then the vendor’s security baseline | Group policy and the mobile device management (MDM) tool | Configuration compliance scans |
| Network and security devices | DISA STIG or CIS Benchmark; then the vendor’s hardening guide | Change tickets in the ticketing system | Configuration compliance scans |
| Databases, web servers, and middleware | CIS Benchmark or DISA STIG; then the vendor’s hardening guide | Build scripts and change tickets | Configuration compliance scans |
| Browsers and office software | CIS Benchmark or DISA STIG; then the vendor’s security baseline | Group policy and the MDM tool | Configuration compliance scans |
| Cloud infrastructure and platform accounts | The provider’s Secure Configuration Guide; then the CIS Benchmark for the platform | Approved templates in the cloud platform | The cloud security posture tool |
| Containers and machine images | CIS Benchmark for the container platform; hardened base images the configuration management team approves | Image pipeline in the cloud platform | The cloud security posture tool and vulnerability scans |
| Software as a service (SaaS) tenants | CISA SCuBA baselines, whose mandatory policies BOD 25-01 requires for in-scope tenants; then the provider’s Secure Configuration Guide | Tenant administration settings | CISA’s SCuBA assessment tools and the cloud security posture tool |
| Mobile devices | The baseline the Mobile Device Policy sets, using NIST SP 800-124 Rev. 2 | The MDM tool | The MDM tool compliance reports |
| Internet of Things (IoT) and operational technology (OT) devices | The vendor’s hardening guide, checked against NIST SP 800-213; network isolation where the device cannot be hardened | Change tickets in the ticketing system | Vulnerability scans |
4. How Baselines Are Approved and Kept #
- The CISO approves each baseline and each new version before administrators deploy it. The Change Control Board approves the change that deploys it. (NIST SP 800-53 CM-6; NIST SP 800-53 CM-3)
- The configuration management team keeps a baseline register in the document management system. Each entry lists the component type, the source and version, the profile or level, the approval date, and the tool that applies it. (NIST SP 800-53 CM-2)
- The team adopts each new version of an approved benchmark within the time the table of Organization values sets. (NIST SP 800-53 CM-2)
- Each System Owner records the system’s baselines and approved deviations in the system’s SSPP. (NIST SP 800-53 CM-6)
5. How Deviations Are Documented and Approved #
- A System Owner who cannot meet a setting opens a deviation request in the ticketing system. The request names the setting, the components, the operational reason, the compensating controls, and the risk. (NIST SP 800-53 CM-6; NIST SP 800-70 Rev. 5)
- The approver in the table below decides the request. A setting that is not approved stays at the baseline value. (NIST SP 800-53 CM-6)
- The ISSO records each approved deviation, its approver, and its end date in the GRC system. Each approval lasts no longer than the longest deviation period. (NIST SP 800-53 CM-6)
- For a mandatory SCuBA policy, the ISSO identifies and explains the deviation in the assessment output the Organization reports to CISA. (CISA BOD 25-01)
- Compliance scans measure each component against its baseline plus its approved deviations. A deviation with no approval is an unauthorized change. (NIST SP 800-53 CM-6)
Who approves a deviation.
| Setting the deviation weakens | Who approves |
|---|---|
| A mandatory SCuBA policy under CISA BOD 25-01 | The AO accepts the risk. The ISSO explains the deviation in the assessment output the Organization reports to CISA. |
| A setting a law, an Office of Management and Budget (OMB) memorandum, or another CISA directive requires | Nobody, unless that source allows a deviation. Then the official it names approves. |
| A CIS Level 1 setting, a DISA STIG setting, or a setting the CISO marks mandatory | The AO, after the CISO reviews it. |
| A CIS Level 2 setting, or a recommended SCuBA policy | The ISSO and the ISSM, with a written reason. |
6. Scanning and Compliance Thresholds #
- Administrators must scan each new or rebuilt component against its baseline, and apply current patches, before it joins a production network. (NIST SP 800-53 CM-2; NIST SP 800-53 SI-2)
- The vulnerability management team scans each production component at the frequency the table below sets, with configuration compliance scans or the cloud security posture tool. (NIST SP 800-53 CM-6(1))
- The team sends the results to the System Owner and the ISSO, and to the CDM Agency Dashboard where the CDM program collects them. (NIST SP 800-53 CM-6)
- For each in-scope SaaS tenant, the team runs CISA’s SCuBA assessment tools. It sends the results to CISA through CISA’s continuous monitoring feed, or by hand each quarter. (CISA BOD 25-01)
Organization values.
| Value | Setting | What it controls |
|---|---|---|
| Compliance scan frequency | [Assignment: organization-defined frequency, at least monthly — to be defined] | How often staff scan each production component against its baseline. |
| Production compliance score | [Assignment: organization-defined minimum percent of baseline settings met — to be defined] | The share of settings, after approved deviations, that each production component must meet. |
| New component gate | 100 percent, with no unapproved deviation | What a new or rebuilt component must meet before it joins a production network. |
| Fix time for a high-risk setting | [Assignment: organization-defined number of days — to be defined] | Days to fix drift on a setting the baseline marks high risk, or that guards an internet-facing service. |
| Fix time for other settings | [Assignment: organization-defined number of days — to be defined] | Days to fix any other drift. |
| New benchmark version | [Assignment: organization-defined number of days — to be defined] | Days to adopt a new version of an approved benchmark after its release. |
| Longest deviation period | [Assignment: organization-defined number of months, one year or less — to be defined] | How long an approval lasts before the approver must review it again. |
7. Fixing Drift #
- The vulnerability management team opens a ticket in the ticketing system for each setting that differs from the baseline, assigned to the owning administrator. (NIST SP 800-53 CM-6)
- The administrator restores the setting within the fix time the table of Organization values sets, and a rescan confirms the fix. (NIST SP 800-53 CM-6)
- For an unauthorized change, the administrator also finds out who made it and why, and takes the actions the Configuration Management Procedures set. (NIST SP 800-53 CM-6(2))
- Staff apply each new mandatory SCuBA policy by the date CISA sets. (CISA BOD 25-01)
- The ISSO records drift that cannot be fixed by its due date as a POA&M item in the GRC system, or the System Owner requests a deviation. (NIST SP 800-53 CA-5)
8. Cloud and SaaS Baselines #
- The System Owner uses the provider’s customer responsibility matrix to find each setting the Organization must make. (FedRAMP Consolidated Rules for 2026)
- The System Owner applies the mandatory SCuBA policies to each new in-scope tenant, and starts continuous monitoring, before the AO grants the authorization to operate. (CISA BOD 25-01)
- The CISO reports the in-scope tenants to CISA and updates that list in the first quarter of each year. (CISA BOD 25-01)
- Administrators build cloud infrastructure only from approved templates in the cloud platform. The cloud security posture tool checks the running settings against them. (NIST SP 800-53 CM-2)
9. Mobile, IoT, and OT Devices #
- Mobile devices follow the baseline the Mobile Device Policy sets, applied through the MDM tool. (NIST SP 800-124 Rev. 2)
- Before buying an IoT device, the System Owner checks that it meets the device security requirements of NIST SP 800-213. (IoT Cybersecurity Improvement Act; NIST SP 800-213)
- Administrators change every default password and turn off unused services before an IoT or OT device joins a network. (NIST SP 800-53 CM-6; NIST SP 800-53 CM-7)
- A device that cannot meet its baseline sits on a separate network segment that the network engineering team approves. (NIST SP 800-53 SC-7)
10. Change Control #
Every change to a baseline, a deviation, or a deployed setting goes through the change process in the Configuration Management Procedures. The Change Control Board reviews the security impact analysis before it approves the change.
Evidence: the change tickets in the ticketing system, with the impact analysis and the approval.
11. Records #
The configuration management team, the System Owners, and the ISSOs keep these records:
- The baseline register and each approved baseline version, in the document management system.
- Approved deviations, with their approvals and end dates, in the governance, risk, and compliance (GRC) system.
- Pre-production scan results, compliance scan reports, and SCuBA assessment results.
- Drift tickets, with the rescan that confirms each fix, in the ticketing system.
Evidence: the records above, found by system, component type, or ticket number.
12. Related Documents #
- Configuration Management Policy (POL-CM) and Configuration Management Procedures (PROC-CM): baseline configuration, change control, and impact analysis.
- Vulnerability Management Policy (POL-VM-001): patch timelines, which this standard does not repeat.
- Mobile Device Policy and Mobile Device Procedure: mobile device settings.
- Using FedRAMP and FedRAMP 20x Authorized Cloud Services, in the Assessment, Authorization, and Monitoring Policy (POL-CA): the rules for each authorized cloud service.
- Zero trust and identity, credential, and access management (ICAM): the Zero Trust and ICAM Implementation Plan (PLAN-ZT-001) sets the device compliance checks that use these baselines.
13. Derived Governance Requirements #
- Implement each update to the mandatory SCuBA policies by the dates on CISA’s BOD 25-01 Required Configurations page. (CISA BOD 25-01)
- Apply the mandatory SCuBA baselines and start continuous monitoring for each new in-scope cloud tenant before granting its authorization to operate. (CISA BOD 25-01)
- Identify and explain each deviation from a mandatory SCuBA policy in the assessment tool output reported to CISA. (CISA BOD 25-01)
- Update the inventory of in-scope cloud tenants for CISA in the first quarter of each year. (CISA BOD 25-01)
- Review the Secure Configuration Guide each FedRAMP provider supplies and configure the relevant security settings. (FedRAMP Consolidated Rules for 2026, AGU-USE-RSG)
- Include IT security requirements in IT acquisitions, including use of the common security configurations NIST publishes. (FAR 39.101(c))
Other sources: NIST SP 800-128; Security Technical Implementation Guides from DISA.
14. References #
These are the sources this document cites, with a link to each official text.
- CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
- Federal Acquisition Regulation (FAR), current text.
- FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
- Internet of Things Cybersecurity Improvement Act of 2020 (Pub. L. 116-207; 15 U.S.C. §§ 278g-3a to 278g-3e), December 4, 2020.
- NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
- NIST SP 800-70 Rev. 5: National Checklist Program for IT Products: Guidelines for Checklist Users and Developers, May 8, 2026.
- NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise, May 2023.
- NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
- NIST SP 800-213: IoT Device Cybersecurity Guidance for the Federal Government: Establishing IoT Device Cybersecurity Requirements, November 2021.
- Secure Cloud Business Applications (SCuBA) Project: Secure Configuration Baselines.
- Security Technical Implementation Guides (STIGs).