NIST SP 800-128 (security-focused configuration management), explained

NIST SP 800-128, "Guide for Security-Focused Configuration Management of Information Systems," gives organizations a process for managing the information-security side of configuration management: establishing a secure baseline for a system, controlling how that baseline changes, and monitoring for drift from it. Its own abstract explains the focus: "NIST SP 800-128 assumes that information security is an integral part of an organization's overall configuration management. The focus of this document is on implementation of the information system security aspects of configuration management," which is why the publication coins the term security-focused configuration management (SecCM) — "the management and control of secure configurations for a system to enable security and facilitate the management of risk." Authored by Arnold Johnson, Kelley Dempsey and Ron Ross of NIST with Sarbari Gupta and Dennis Bailey of Electrosoft Services, it was originally published in August 2011 and received substantive and editorial errata updates on 10 October 2019 (its own front-matter Errata table runs to several pages — terminology changes like "information system" to "system," updated cross-references to newer NIST publications, and a refreshed SCAP version). NIST's publication page lists it as Final, with no later revision as of this guide's research date.

Where SecCM fits: SP 800-53's CM family and the RMF

Section 1.3 is explicit about the publication's role: it "provides guidelines for implementation of the Configuration Management family of controls defined in NIST [SP 800-53] (CM-1 through CM-9)," and separately "provides important supporting information for the Implement Step, Assess Step, and the Monitor Step" of the Risk Management Framework described in NIST SP 800-37. The publication notes that more specific guidance on the RMF's Monitor step itself sits in NIST SP 800-137, Information Security Continuous Monitoring — SP 800-128's own Monitoring phase (below) supports that RMF step by addressing specifically the system's structural architecture and configuration settings, rather than continuous monitoring in general. Chapter One also states the guidelines apply to all federal systems other than national security systems, while noting state/local/tribal governments and private-sector organizations are "encouraged to consider using these guidelines, as appropriate" — and that organizations can use the same concepts to set assurance requirements for external or cloud service providers.

Basic concepts: Configuration Item, baseline, CM Plan

Section 2.1.1 grounds the whole guide in a few core definitions:

• Configuration Management (CM) — "a collection of activities focused on establishing and maintaining the integrity of products and systems, through control of the processes for initializing, changing, and monitoring the configurations of those products and systems."
• Configuration Item (CI) — "an identifiable part of a system (e.g., hardware, software, firmware, documentation, or a combination thereof) that is a discrete target of configuration control processes."
• Baseline Configuration — "a set of specifications for a system, or CI within a system, that has been formally reviewed and agreed on at a given point in time, and which can be changed only through change control procedures," used "as a basis for future builds, releases, and/or changes."
• Configuration Management Plan (CM Plan) — a comprehensive description of roles, responsibilities, policies and procedures, built from four parts: the Configuration Control Board (CCB) charter (a group with authority to control and approve changes), Configuration Item Identification (methodology for selecting and naming CIs), Configuration Change Control (the process for updating baseline configurations), and Configuration Monitoring (assessing/testing compliance with the established baseline and reporting on it).

Section 2.1.3 adds the formal definition of the publication's namesake term: "Security-Focused Configuration Management (SecCM) is the management and control of secure configurations for a system to enable security and facilitate the management of risk," built on general CM concepts but focused on "the implementation and maintenance of the established security requirements of the organization and systems."

The four phases of SecCM

Section 2.2 organizes SecCM activity into four major phases, detailed in Chapter Three:

1. Planning (Sec. 3.1) — developing SecCM policy and procedures, covering areas such as SecCM plans, integration into existing security program plans, the CCB, configuration change control processes, tools, common secure configurations and baseline configurations, monitoring, and compliance metrics. The guide notes it's "typically more cost-effective" to build this at the organizational or mission/business-process risk-management level rather than per-system.
2. Identifying and Implementing Configurations (Sec. 3.2) — developing, reviewing, approving and implementing a secure baseline configuration that represents "the most secure state consistent with operational requirements and constraints," covering configuration settings, software loads, patch levels, physical/logical arrangement, security-control implementation and documentation, automated where possible for interoperability and uniformity.
3. Controlling Configuration Changes (Sec. 3.3) — ensuring changes to the approved baseline are "formally identified, proposed, reviewed, analyzed for security impact, tested, and approved prior to implementation," using access restrictions, process automation, change windows, and verification/audit activities to limit unauthorized or undocumented changes.
4. Monitoring (Sec. 3.4) — validating that the system still adheres to organizational policy, procedure and the approved baseline; identifying undiscovered or undocumented components, misconfigurations, vulnerabilities and unauthorized changes. Per Figure 2-1, "SecCM monitoring activities may loop back to any of the previous phases" — the process is explicitly cyclical, not a one-time sign-off.

Automation: Security Content Automation Protocol (SCAP)

Section 3.5 describes SCAP as "a suite of specifications that standardize the format and nomenclature by which information about software flaws and secure configurations can be communicated," enabling SCAP-enabled tools to "automatically verify the installation of patches, check system security configuration settings against an expected baseline, and examin[e] systems for signs of compromise." Federal agencies pair SCAP-enabled tools with SCAP-expressed checklists, customized to organizational requirements, to generate standardized assessment and compliance evidence for SP 800-53 controls — the publication states this can provide "a substantial savings in effort and cost" versus manual checking. The 10 October 2019 update refreshed the documented baseline to SCAP Version 1.3, built from components including the Extensible Configuration Checklist Description Format (XCCDF) 1.2 for authoring and reporting checklists, the Open Vulnerability and Assessment Language (OVAL) 5.11.2 for representing configuration information and machine state, and the Open Checklist Interactive Language (OCIL) 2.0 for checks requiring human input. NIST also encourages vendors to support Common Vulnerabilities and Exposures (CVE), Common Configuration Enumeration (CCE) and Software Identification (SWID) Tags so SCAP tooling can reference consistent identifiers.

Appendix F: best practices tied to specific SP 800-53 controls

The 2019 update added explicit "Associated NIST SP 800-53 Control" lines to each best-practice topic in Appendix F — a detail worth knowing because it turns a list of general advice into a navigable control cross-reference. Examples directly from the publication: patch/change-related checklists tie to CM-6; the overall CM plan/checklist discipline ties to CM-1 and CM-6; least-functionality topics (removing unnecessary services) tie to CM-7; remote access controls tie to AC-17; password/authenticator management ties to IA-2 and IA-5; endpoint protections tie to SC-7, SC-18, SI-3, SI-4; cryptographic protections tie to SC-13; patch and vulnerability management ties to CM-2, CM-3, CM-4, SI-2; and application whitelisting ties to CM-5, CM-7, CM-11, SI-7. Appendix D supplies a sample outline for a SecCM Plan, Appendix E a sample configuration change request template, Appendix G flow charts for SecCM processes, and Appendix H a sample CCB charter.

A workable starting point

1. Write down what counts as a Configuration Item before arguing about baselines. The CI/baseline-configuration distinction only works if the organization has already agreed on the discrete hardware, software, firmware and documentation targets that configuration control applies to.
2. Treat the four phases as a loop, not a checklist. The publication is explicit that monitoring findings feed back into planning, baseline updates, or change control — a SecCM program that only runs Planning → Identify/Implement once and calls Monitoring an annual audit misses the point.
3. Use Appendix F's control cross-references to scope evidence collection. Knowing that endpoint hardening maps to SC-7/SC-18/SI-3/SI-4 (for example) tells an assessor exactly what SecCM artifact should satisfy which SP 800-53 control, instead of re-deriving the mapping from scratch.
4. Automate what SCAP covers, and budget for what it doesn't. SCAP-enabled tooling is strong for machine-checkable configuration settings and patch state; organization-specific policy judgments and human-verified controls still need the Monitoring phase's non-automated reporting path.
5. Confirm which CM family revision a given SP 800-53 baseline uses. This guide's control numbers (CM-1 through CM-9, etc.) reflect SP 800-128's own references — always verify against the current SP 800-53 control catalog before treating a control ID as current.

SoftWSP's firmware and device security assessments help device makers establish and evidence a secure baseline configuration — and detect drift from it — across firmware images and embedded components: see Device & Firmware Security.

This guide summarises NIST SP 800-128 (August 2011, including the October 2019 errata update) and the related SP 800-53 publication page; it is not a substitute for the full text and does not constitute compliance or legal advice.