Most configuration-related breaches are not caused by missing hardening guides but by changes nobody reviewed, baselines nobody maintained and drift nobody noticed. NIST Special Publication 800-128, Guide for Security-Focused Configuration Management of Information Systems, is the NIST guidance that turns the CM control family in SP 800-53 into a working process: plan, set baselines, control changes, and monitor. This guide explains what SP 800-128 contains and who uses it, its four phases and roles, how it applies to cloud and infrastructure-as-code estates, how machine identities fit into configuration management, what evidence assessors look for and how it maps to other frameworks. It is written for system owners, platform and infrastructure teams, change managers and GRC staff, especially in organisations using the NIST Risk Management Framework, FedRAMP or SP 800-171.
Key takeaways
- It is the process guide behind the CM family. SP 800-128 supports SP 800-53 and explicitly addresses controls CM-1 to CM-9, describing how to apply security-focused configuration management (SecCM) to information systems.
- Four phases, in a loop. Planning, identifying and implementing configurations, controlling configuration changes, and monitoring, with monitoring results fed back into the earlier phases.
- Security impact analysis is the heart of change control. Changes are proposed, analysed for security impact, tested, approved and then verified after implementation, including emergency changes.
- The text is from 2011, updated in 2019. Its principles hold, but terminology predates SP 800-53 Rev. 5 (where CM-4 is now "Impact Analyses") and cloud-native delivery, so apply it with modern tooling in mind.
- Identities are configuration items too. Service accounts, deployment pipeline credentials and cloud roles that can change configuration are part of the baseline and part of the change control boundary.
What it is and who it applies to
SP 800-128 was published by NIST in August 2011 and the current version carries updates as of 10 October 2019; CSRC lists it as Final, written by L. Johnson, Kelley Dempsey and Ron Ross of NIST with Sarbari Gupta and Dennis Bailey of Electrosoft Services. CSRC showed no draft revision when checked on 27 October 2026. NIST defines SecCM as the management and control of secure configurations for a system to enable security and facilitate risk management.
- US federal agencies and their contractors: the guide was written for federal information systems and supports the CM controls selected through the RMF. See the NIST SP 800-53 Guide.
- Cloud service providers in FedRAMP and similar programmes: CM controls and a configuration management plan are standard authorisation evidence.
- Defence suppliers: SP 800-171 configuration management requirements are derived from the same SP 800-53 family. See the NIST SP 800-171 and CMMC 2.0 Guide.
- Any organisation: the process is vendor-neutral and usable as a model for ISO/IEC 27001 Annex A 8.9 (configuration management) and 8.32 (change management).
Structure and key requirements
Chapter 2 covers fundamentals (overview, the phases, concepts, and roles and responsibilities). Chapter 3 covers the process: 3.1 Planning, 3.2 Identifying and Implementing Configurations, 3.3 Controlling Configuration Change, 3.4 SecCM Monitoring and 3.5 Using the Security Content Automation Protocol (SCAP). Appendices provide practical templates.
| Phase | Main activities in SP 800-128 | Key SP 800-53 Rev. 5 controls | Output |
|---|---|---|---|
| 1 Planning | Policies, procedures and tools; scope of SecCM at organisation and system level; configuration control board (CCB) charter; configuration items identified | CM-1 Policy and Procedures, CM-9 Configuration Management Plan | SecCM policy and plan, CCB charter |
| 2 Identifying and implementing configurations | Develop, review, approve and implement a secure baseline configuration, using common secure configurations where available | CM-2 Baseline Configuration, CM-6 Configuration Settings, CM-7 Least Functionality, CM-8 System Component Inventory | Approved baselines, inventory, deviations recorded |
| 3 Controlling configuration changes | Propose and justify, security impact analysis, test, approve, implement, verify; emergency changes analysed as well | CM-3 Configuration Change Control, CM-4 Impact Analyses, CM-5 Access Restrictions for Change | Change records and impact analyses |
| 4 Monitoring | Compare systems with baselines and inventory; find unknown components, misconfigurations, vulnerabilities and unauthorised changes; report into continuous monitoring | CM-2, CM-3, CM-6, CM-8 with CA-7 Continuous Monitoring | Deviation reports, metrics, input to risk decisions |
Core concepts
- Configuration item (CI): an aggregation of system components designated for configuration management and treated as a single entity. It can be a component, a group of components, firmware or documentation, or a whole system.
- Baseline configuration: a formally reviewed and agreed set of specifications for a system or CI at a point in time, changed only through change control, and the basis for future builds. Previous approved baselines are kept for review or rollback.
- Common secure configurations: recognised benchmarks such as those in the NIST National Checklist Program (SP 800-70, now Rev. 5, published 8 May 2026), CIS Benchmarks and DISA STIGs. See the CIS Benchmarks Guide.
- Automation: SP 800-128 points to SCAP (SP 800-126) to automate assessment of settings against baselines.
Applying it to cloud and infrastructure as code
The phases translate cleanly to modern delivery, provided each SP 800-128 concept is mapped to something real in the toolchain:
- Configuration item: a Terraform module, Helm chart, container image, golden machine image or SaaS tenant configuration export.
- Baseline: the reviewed version of that code in the main branch, plus the policy-as-code rules that every deployment must pass.
- Change request: the pull request, with the plan output attached and a security reviewer required for changes to identity, network exposure, encryption or logging.
- CCB approval: branch protection and required reviewers for normal changes, with a human board reserved for high-impact or non-standard changes.
- Monitoring: drift detection comparing deployed state with code, plus cloud audit logs for changes made by any identity other than the pipeline.
Roles
| Role | SecCM responsibility (SP 800-128) |
|---|---|
| Chief Information Officer | Designates the SecCM programme manager; approves organisational SecCM plan and policies |
| Senior agency information security officer | May act as SecCM programme manager; provides security staff for the CCB and impact analyses |
| Authorising official | Takes part in the CCB for its systems; final decision on whether changes remain acceptable risk |
| System owner | Ensures SecCM is implemented for the system |
| SecCM programme manager | Develops SecCM policies and procedures and oversees the programme |
| System security officer | Assists the owner, conducts configuration monitoring, may sit on the CCB |
| System administrator and developer | Implement approved baselines and secure settings; build settings into applications; support impact analysis |
| Configuration control board | Two or more people with collective authority to review and approve changes against criteria including security impact |
Useful appendices include a sample SecCM plan outline (D), a sample change request (E), best practices for establishing secure configurations (F), process flow charts (G), a sample CCB charter (H) and a security impact analysis template (I). For a ready-made policy, see the Change Management Policy Template.
Identity and NHI requirements
SP 800-128 predates infrastructure as code, but its logic carries over directly: whatever can change a configuration is inside the change control boundary. In a modern estate that is mostly non-human. Pipelines apply Terraform, configuration management agents push settings, GitOps controllers reconcile clusters and cloud roles allow console or API changes. CM-5 Access Restrictions for Change is the control that matters most here.
| SecCM element | Identity question | Expected practice |
|---|---|---|
| Configuration items | Are service accounts, roles, API keys and certificates recorded as CIs or attributes of CIs? | Machine identities in the inventory with owner, purpose and permissions (CM-8) |
| Baselines | Do baselines define which identities may exist on a system and with what rights? | Approved role and account sets, no default or shared accounts (CM-2, CM-6, CM-7) |
| Change control | Which identities can apply changes, and is that access limited to the approved path? | Pipeline identities with scoped, short-lived credentials; human break-glass logged (CM-3, CM-5) |
| Impact analysis | Does a change add permissions or new credentials? | Permission changes flagged for security review before approval (CM-4) |
| Monitoring | Would you see a new role, key or trust policy created outside the pipeline? | Alerts on identity changes outside change windows, mapped to ATT&CK T1098 Account Manipulation |
See the Configuration Drift and Baseline Enforcement Guide for drift tooling and the CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide for safeguard-level detail.
Implementation steps
- Write the SecCM policy and plan. Use the Appendix D outline: purpose, scope, roles, CCB, CIs, change control, monitoring and records. Decide which change types are configuration-controlled, as CM-3 requires.
- Charter the CCB. Set membership, quorum, criteria and a standard-change route so low-risk, pre-approved changes (for example routine patching through a tested pipeline) do not wait for a meeting.
- Identify CIs and build the inventory. Start with internet-facing systems, identity infrastructure and the pipelines that deploy everything else.
- Set baselines from common secure configurations. Select a CIS Benchmark or STIG per platform, document deviations with justification, and express the baseline as code (policy files, templates, golden images) where possible.
- Implement in audit mode first. Run compliance scans or policy-as-code in report-only mode, fix high-impact gaps, then move to enforcement in pilot rings. Keep the previous approved baseline for rollback, as SP 800-128 recommends.
- Embed impact analysis in the change flow. Add security questions to the change template (Appendix E and I), and require reviewers to check permission, network exposure and logging changes.
- Restrict who and what can change production. Remove standing console write access, route changes through the pipeline, and log every exception.
- Monitor and report. Compare running state with baselines continuously, alert on unauthorised changes and unknown components, and feed results into continuous monitoring. See the NIST SP 800-137 ISCM Guide.
Decision guidance
- Small organisation: one combined policy and plan, a weekly change review with two approvers, CIS Benchmarks as baselines and a cloud posture tool for monitoring is a credible SP 800-128 implementation.
- Large or federal organisation: organisation-level SecCM plan plus system-level plans, formal CCBs per authorisation boundary, SCAP or policy-as-code evidence and integration with the RMF continuous monitoring strategy.
- Immutable infrastructure: treat the image or template as the CI and the pipeline as the change control mechanism; monitoring then focuses on detecting anything changed outside the pipeline.
- Mutable legacy servers: rely more on agent-based configuration management and scheduled compliance scanning, with stricter manual change review.
Evidence and assessment
Assessors following SP 800-53A examine the CM controls through documents, interviews and tests. The table lists the evidence an SP 800-128 programme produces.
| Evidence | Control | Metric |
|---|---|---|
| SecCM policy, plan and CCB charter | CM-1, CM-9 | Plan review date within the defined period |
| Approved baselines with deviations | CM-2, CM-6 | Percentage of systems with a current approved baseline |
| Component inventory | CM-8 | Unknown components found by discovery per month |
| Change records with impact analysis | CM-3, CM-4 | Percentage of changes with completed impact analysis; emergency changes reviewed after the fact |
| Access lists for change | CM-5 | Identities with production write access outside the pipeline |
| Compliance scan results | CM-6, CA-7 | Baseline compliance rate; mean time to remediate drift |
Log and alert on configuration changes in cloud audit trails, Windows registry and group policy modifications (ATT&CK T1112 Modify Registry), new cloud accounts and roles (T1078.004 Cloud Accounts) and changes made outside approved windows. Reconcile change tickets with observed changes: an observed change with no ticket is the single most useful signal.
Mapping to other frameworks
| Framework | Reference | Relationship to SP 800-128 |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CM-1 to CM-9; also CM-2(2), CM-3(2), CM-6(1), CM-8(3), SA-10 | Controls the guide implements; enhancements add automation and developer CM |
| NIST CSF 2.0 | PR.PS-01, ID.AM-02, ID.AM-08, DE.CM-09 | Configuration management practices, inventories, life cycle, monitoring of runtime environments |
| CIS Controls v8.1 | Control 4 Secure Configuration of Enterprise Assets and Software; Controls 1 and 2 inventories | Safeguard-level equivalent of phases 2 and 4 |
| ISO/IEC 27001:2022 | Annex A 8.9 Configuration management, 8.32 Change management | ISMS controls that SP 800-128 can implement |
| NIST SP 800-70 Rev. 5 | National Checklist Program | Source of common secure configurations |
| MITRE ATT&CK | T1098, T1078.004, T1112 | Adversary behaviours that configuration monitoring should detect |
Common pitfalls
- A CCB that rubber-stamps: changes approved in bulk with no impact analysis meet the letter of CM-3 and miss its purpose.
- Unreviewed configuration changes: Twitch attributed its 2021 leak to an error in a server configuration change that exposed internal data; the Twitch breach shows why post-implementation verification matters.
- Baselines that exist only in documents: a baseline that is not expressed in code or scanned against cannot show drift.
- Pipelines outside the boundary: the deployment identity has more power than any administrator but is not itself under change control.
- Emergency changes that never get reviewed: SP 800-128 expects impact analysis for emergency changes as well; skipping it turns every outage into a permanent exception.
- Inventory gaps: unmanaged cloud accounts, shadow SaaS and forgotten test environments are never baselined. See the Cloud Misconfiguration Guide.
Practitioner checklist
- Publish a SecCM policy and plan based on the SP 800-128 Appendix D outline.
- Charter a CCB with a standard-change route for pre-approved, low-risk changes.
- Define which change types are configuration-controlled and record that decision.
- Build an inventory that includes machine identities as configuration items or attributes.
- Adopt common secure configurations per platform and record every deviation.
- Express baselines as code and run compliance scans in audit mode before enforcing.
- Require security impact analysis on every change, including emergency changes after the fact.
- Remove standing production write access outside the pipeline and scope pipeline credentials.
- Reconcile observed changes with change records and alert on any mismatch.
- Report baseline compliance and drift remediation time into continuous monitoring.
Standards and references
- NIST: SP 800-128 Guide for Security-Focused Configuration Management of Information Systems
- NIST: SP 800-53 Rev. 5
- NIST: SP 800-70 Rev. 5 National Checklist Program for IT Products
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: Account Manipulation
- MITRE ATT&CK: Cloud Accounts
Related NHI Mgmt Group resources: CIS Control 4 Secure Configuration of Enterprise Assets and Software Guide · Configuration Drift and Baseline Enforcement Guide · NIST SP 800-53 Guide · Change Management Policy Template