Configuration Management Policy

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for configuration management in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers configuration management for every platform the Organization operates. Most exploited weaknesses are known misconfigurations and unauthorized changes. The Organization must keep a hardened baseline for every platform and must control every change with a security impact analysis before deployment. It must keep a complete and current component inventory, including software composition derived from software bill of materialss (SBOMs). It must detect drift from approved baselines automatically.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

• ID.AM — Asset Management (Identify function)
• PR.PS — Platform Security (Protect function)
• DE.CM — Continuous Monitoring (Detect function)

These categories fall under the Detect, Identify, Protect function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every configuration management control in the high baseline of FIPS 200 and NIST SP 800-53B:

• CM-01 — Policy and Procedures
• CM-02 — Baseline Configuration
• CM-02(2) — Automation Support for Accuracy and Currency
• CM-02(3) — Retention of Previous Configurations
• CM-02(7) — Configure Systems and Components for High-risk Areas
• CM-03 — Configuration Change Control
• CM-03(1) — Automated Documentation, Notification, and Prohibition of Changes
• CM-03(2) — Testing, Validation, and Documentation of Changes
• CM-03(4) — Security and Privacy Representatives
• CM-03(6) — Cryptography Management
• CM-04 — Impact Analyses
• CM-04(1) — Separate Test Environments
• CM-04(2) — Verification of Controls
• CM-05 — Access Restrictions for Change
• CM-05(1) — Automated Access Enforcement and Audit Records
• CM-05(5) — Privilege Limitation for Production and Operation
• CM-06 — Configuration Settings
• CM-06(1) — Automated Management, Application, and Verification
• CM-06(2) — Respond to Unauthorized Changes
• CM-07 — Least Functionality
• CM-07(1) — Periodic Review
• CM-07(2) — Prevent Program Execution
• CM-07(5) — Authorized Software — Allow-by-exception
• CM-08 — System Component Inventory
• CM-08(1) — Updates During Installation and Removal
• CM-08(2) — Automated Maintenance
• CM-08(3) — Automated Unauthorized Component Detection
• CM-08(4) — Accountability Information
• CM-09 — Configuration Management Plan
• CM-10 — Software Usage Restrictions
• CM-11 — User-installed Software
• CM-12 — Information Location
• CM-12(1) — Automated Tools to Support Information Location
• CM-14 — Signed Components

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the CM control family. They add to the NIST SP 800-53 control requirements in the Policy section.

CISA BOD 26-04: Prioritizing Security Updates Based on Risk

• The organization must remediate vulnerabilities identified in the CISA Known Exploited Vulnerabilities (KEV) catalog according to risk-based timelines. Vulnerabilities with higher KEV Status, Exploit Automation, Technical Impact, and Asset Exposure scores must be prioritized. Deadline: Risk-based timeline per KEV catalog. (CISA BOD 26-04, §1)

CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices

• The organization must identify all end-of-support (EOS) edge devices on the network and plan to replace or mitigate each one, because these devices no longer receive security patches. (CISA BOD 26-02, §1)

CISA BOD 25-01: Implementing Secure Practices for Cloud Services

• The organization must implement secure configuration baselines for cloud computing environments, including monitoring for configuration drift and enforcing baseline compliance through automated tooling. (CISA BOD 25-01, §2)

CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection

• The organization must maintain continuous and comprehensive asset visibility through active scanning, passive flow monitoring, log queries, or API queries. Asset inventory must be kept current to enable effective vulnerability management. (CISA BOD 23-01, §1)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization must review each provider’s Secure Configuration Guide and set the Organization’s security settings in the cloud service to match it. (FedRAMP Consolidated Rules for 2026, AGU-USE-RSG)

OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures

• The organization must identify the EO-critical software the Organization uses or is acquiring, and apply NIST’s security measures for EO-critical software to it. (OMB M-21-30; EO 14028, §4(g)-(i))

CISA/NSA/FBI 2026 Minimum Elements for a Software Bill of Materials (SBOM)

• The organization should incorporate SBOM data into the system component inventory so that software components and their dependencies are traceable, supporting vulnerability correlation (including KEV catalog matching) and change management. (CISA 2026 SBOM Minimum Elements, Discussion)

NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems

• The organization should analyze the security impact of each proposed change before approval, and check after the change that controls still work as intended. (NIST SP 800-128, §3.3)

3. Policy #

The Organization must implement and maintain its configuration management controls to meet the following requirements:

CM-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.PS (Platform Security)

Requirement:

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business process-level; system-level — to be defined] configuration management policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the configuration management policy and the associated configuration management controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the configuration management policy and procedures; and
3. Review and update the current configuration management:

1. Policy at least annually and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Implementation guidance:

The Organization must keep an organization-level configuration management policy and the procedures that put it into practice. The designated officials manage the development, documentation, and distribution of both documents. They must deliver each approved version to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and the key stakeholders who follow it. The policy must state why the program exists, what it covers, who owns each duty, how organizational units coordinate, and what compliance requires. It must stay consistent with the laws, executive orders, directives, and regulations that apply to the Organization. The designated officials must review and update the policy and the procedures every year. They must also review both documents after a major incident or a major change to applicable policy.

CM-02 — Baseline Configuration #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

1. Develop, document, and maintain under configuration control, a current baseline configuration of the system; and
2. Review and update the baseline configuration of the system:

1. at least annually and when a significant change occurs;
2. When required due to include when directed by the AO; and
3. When system components are installed or upgraded.

Implementation guidance:

System Owners must develop and maintain a current baseline configuration for each system and keep it under configuration control. The baseline must list the system’s components, their placement in the architecture, and the settings the system depends on. System Owners must review and update the baseline every year. They must also update it when the system boundary or architecture changes significantly, when applicable policy directs, and when someone installs or upgrades a component. Administrators must bring each new or rebuilt component to the approved baseline and the current patch level before it joins a production network. Under Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 25-01, the Organization monitors cloud baselines in the cloud platform for drift and enforces them with automated tooling. Administrators deploy the endpoint baseline through the mobile device management (MDM) tool and the domain baseline through group policy. Configuration compliance scans verify that deployed systems still match the approved record. A baseline that no longer matches the running system is a finding.

CM-02(2) — Automation Support for Accuracy and Currency #

Baselines: Moderate / High

Requirement:

Maintain the currency, completeness, accuracy, and availability of the baseline configuration of the system using [Assignment: organization-defined automated mechanisms — to be defined].

Implementation guidance:

The Organization must keep every system baseline current, complete, accurate, and available through the configuration management database (CMDB) in the ticketing system. The CMDB is the authoritative record of components and their approved configurations. System Owners must keep the CMDB entry for their system aligned with the system as built. The Organization must reconcile the record against automated discovery and compliance data on a recurring schedule. System Owners must correct discrepancies through the change process, not by editing the record.

CM-02(3) — Retention of Previous Configurations #

Baselines: Moderate / High

Requirement:

Retain organization-defined number of previous versions of baseline configurations of the previously approved baseline configuration of IS components of previous versions of baseline configurations of the system to support rollback.

Implementation guidance:

The Organization must keep at least one previous version of each system’s baseline configuration alongside the current version. System Owners must keep superseded baselines retrievable until a newer version replaces them. A superseded baseline includes the configuration records, the deployable templates, and the documentation that explains them. With a retained version, the System Owner can reverse a failed change or a compromised build to a known-good state.

CM-02(7) — Configure Systems and Components for High-risk Areas #

Baselines: Moderate / High

Requirement:

1. Issue [Assignment: organization-defined systems or system components — to be defined] with [Assignment: organization-defined configurations — to be defined] to individuals traveling to locations that the organization deems to be of significant risk; and
2. Apply the following controls to the systems or components when the individuals return from travel: [Assignment: organization-defined controls — to be defined].

Implementation guidance:

The Organization must issue a hardened laptop or an organization-managed mobile device to each individual who travels to a location the Organization deems of significant risk. The device must have an encrypted hard drive and must match the Agency Mobile Security Standard configuration. The traveler must take no other organization device. On return, the traveler must not connect the device to an organization network or use it to process sensitive information until the issuing team has inspected it and wiped or reimaged it. Supervisors and the ISSO own the trigger: the traveler must declare travel to a designated location before departure.

CM-03 — Configuration Change Control #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Requirement:

1. Determine and document the types of changes to the system that are configuration-controlled;
2. Review proposed configuration-controlled changes to the system and approve or disapprove such changes with explicit consideration for security and privacy impact analyses;
3. Document configuration change decisions associated with the system;
4. Implement approved configuration-controlled changes to the system;
5. Retain records of configuration-controlled changes to the system for [Assignment: organization-defined time period — to be defined];
6. Monitor and review activities associated with configuration-controlled changes to the system; and
7. Coordinate and provide oversight for configuration change control activities through [Assignment: organization-defined configuration change control element — to be defined] that convenes [Selection (one or more): [organization-defined]; when [organization-defined] — to be defined].

Implementation guidance:

The Organization must define and document which types of system changes are configuration-controlled. No such change may proceed without review. The Configuration Control Board must meet at least [CM-03 parameter 3 — to be defined]. It must also meet on demand for emergency changes and when a significant change to system components is planned. The board approves or disapproves each proposed change with the security and privacy impact analysis in front of it. Implementers must make approved changes exactly as approved. The board must document each decision. A requester who asks for a temporary firewall or boundary rule must give it an end date. The network team must remove the rule on that date unless the board approves an extension. The ISSO must monitor and review change activity for changes that bypassed the process. The Organization must keep records of configuration-controlled changes for at least [CM-03 parameter 1 — to be defined]. The board chair owns the board’s operation. System Owners own the changes they bring to the board.

CM-03(1) — Automated Documentation, Notification, and Prohibition of Changes #

Baselines: High

Requirement:

Use [Assignment: organization-defined automated mechanisms — to be defined] to: (a) Document proposed changes to the system; (b) Notify [Assignment: organization-defined approval authorities — to be defined] of proposed changes to the system and request change approval; (c) Highlight proposed changes to the system that have not been approved or disapproved within organization agreed upon time period; (d) Prohibit changes to the system until designated approvals are received; (e) Document all changes to the system; and (f) Notify organization defined configuration management approval authorities when approved changes to the system are completed.

Implementation guidance:

The Organization must use [CM-03(1) parameter 1 — to be defined] to document, route, and control every proposed system change. Requesters must record each proposed change in that workflow. The workflow must notify [CM-03(1) parameter 2 — to be defined] that the change awaits approval. System Owners must make sure the workflow flags any change left without a decision for organization agreed upon time period. Administrators must not make any change until all required approvals are recorded. After completion, the workflow must record the outcome and notify organization defined configuration management approval authorities.

CM-03(2) — Testing, Validation, and Documentation of Changes #

Baselines: Moderate / High

Requirement:

Test, validate, and document changes to the system before finalizing the implementation of the changes.

Implementation guidance:

Implementers must test and validate each configuration-controlled change before they finalize it, and must record the results in the change record. System Owners must make sure the test exercises the change as it will deploy, without disrupting the operations the system supports. When testing on the operational system is not feasible, the implementer validates the change in a representative environment and verifies it again after deployment.

CM-03(4) — Security and Privacy Representatives #

Baselines: Moderate / High

Requirement:

Require [Assignment: organization-defined security and privacy representatives — to be defined] to be members of the Configuration control board (CCB) or similar (as defined in CM-3).

Implementation guidance:

The Chief Information Security Officer (CISO), or an official the CISO delegates, must hold standing membership on the Change Control Board. The Chief Privacy Officer, or that official’s delegate, must hold standing membership as well. Their review is part of the board’s decision on every configuration-controlled change. This review catches changes with security or privacy side effects while they are still proposals.

CM-03(6) — Cryptography Management #

Baselines: High

Requirement:

Ensure that cryptographic mechanisms used to provide the following controls are under configuration management: All security safeguards that rely on cryptography.

Implementation guidance:

The Organization must place under configuration management the cryptographic mechanisms that support All security safeguards that rely on cryptography. Cryptographic modules, algorithms, key lengths, protocol settings, and certificates must be part of each system’s approved baseline. Changes to any of them must go through change control and receive ISSO review before approval. System Owners must keep these settings current in the baseline and report deviations to the CISO.

CM-04 — Impact Analyses #

Baselines: Low / Moderate / High / Privacy CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Requirement:

Analyze changes to the system to determine potential security and privacy impacts prior to change implementation.

Implementation guidance:

The ISSO must analyze each proposed configuration-controlled change for its security and privacy impact before anyone implements it, following NIST SP 800-128. The ISSO must coordinate with the Privacy Officer when the change affects personal information. In the analysis, the ISSO must find the change’s vulnerabilities, assess the risk, identify the affected controls, and plan safeguards. The ISSO must also decide whether the change counts as significant under NIST SP 800-37 Rev 2, and the Authorizing Official decides whether a significant change needs reauthorization. No change may reach the Configuration Control Board without its completed analysis.

CM-04(1) — Separate Test Environments #

Baselines: High

Requirement:

Analyze changes to the system in a separate test environment before implementation in an operational environment, looking for security and privacy impacts due to flaws, weaknesses, incompatibility, or intentional malice.

Implementation guidance:

The Organization must test every system change in a test environment kept separate from production before the change goes live. Testers must look for security and privacy effects, including defects, new weaknesses, conflicts with other components, and signs of deliberate harm. System Owners must maintain a test environment that mirrors production settings. The ISSO must review the test results before the change is approved for release.

CM-04(2) — Verification of Controls #

Baselines: Moderate / High

Requirement:

After system changes, verify that the impacted controls are implemented correctly, operating as intended, and producing the desired outcome with regard to meeting the security and privacy requirements for the system.

Implementation guidance:

The ISSO must verify, after each system change, that every control the impact analysis identified as affected still works. The ISSO must confirm that the control remains correctly implemented, operates as intended, and still meets the system’s security and privacy requirements. The verification must rest on evidence, such as configuration checks and scans. If a change degrades a control, the ISSO must open a remediation task or start a rollback through the emergency change path.

CM-05 — Access Restrictions for Change #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system.

Implementation guidance:

System Owners must define and document the physical and logical access restrictions that govern who may modify each system. The CISO must approve those restrictions before anyone enforces them. Only qualified and explicitly authorized individuals may start a configuration-controlled change. Authorization follows the role: the System Owner records it and withdraws it when the person’s duties change. Group policy enforces the logical restrictions for domain resources, and customer-configured access policies in the cloud platform enforces them for cloud infrastructure. Physical restrictions govern access to the spaces where a person can change a system. Any person who can alter a system without an approved restriction that covers them is a gap the System Owner must close.

CM-05(1) — Automated Access Enforcement and Audit Records #

Baselines: Moderate / High

Requirement:

1. Enforce access restrictions using [Assignment: organization-defined automated mechanisms — to be defined]; and
2. Automatically generate audit records of the enforcement actions.

Implementation guidance:

The Organization must enforce change access restrictions through its multi-factor authentication, privileged access management, and security information and event management capabilities. A person who changes a system must authenticate strongly and work in an authorized privileged session, and the Organization must monitor that session. Every enforcement action, whether a grant, a denial, or an elevation, must generate an audit record automatically. These records give the ISSO a complete account of who could change what and when the mechanism denied access.

CM-05(5) — Privilege Limitation for Production and Operation #

Baselines: Moderate / High

Requirement:

1. Limit privileges to change system components and system-related information within a production or operational environment; and
2. Review and reevaluate privileges at least quarterly.

Implementation guidance:

The Organization must limit the privileges to change system components and system-related information in production and operational environments. Only the small set of roles whose duties require those privileges may hold them. Developers and support staff must work through lower environments and the change process, not through direct production access. System Owners must review and reevaluate those privileges on a recurring schedule and withdraw any assignment that current duties no longer justify.

CM-06 — Configuration Settings #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Requirement:

1. Establish and document configuration settings for components employed within the system that reflect the most restrictive mode consistent with operational requirements using [Assignment: organization-defined common secure configurations — to be defined];
2. Implement the configuration settings;
3. Identify, document, and approve any deviations from established configuration settings for [Assignment: organization-defined system components — to be defined] based on [Assignment: organization-defined operational requirements — to be defined]; and
4. Monitor and control changes to the configuration settings in accordance with organizational policies and procedures.

Implementation guidance:

System Owners must configure every system component to the most restrictive settings that still meet explicit mission and business requirements. The CISO sets the approved baseline for each kind of component, the deviation approvers, the scan thresholds, and the time to fix drift in the Secure Configuration Baseline Standard (STD-CFG-001). System Owners must implement the approved settings. The System Owner must identify and document each deviation, and get it approved under that standard before it exists in production. Administrators must apply the baseline settings and current patches to each new or rebuilt component, and confirm them with a compliance scan, before it joins a production network. Administrators apply and hold the settings through the MDM tool and group policy, and configuration compliance scans verify them. Under CISA BOD 25-01, System Owners apply the mandatory secure configuration policies to each in-scope cloud tenant. An undocumented deviation is an unauthorized change.

CM-06(1) — Automated Management, Application, and Verification #

Baselines: Moderate / High

Requirement:

Manage, apply, and verify configuration settings for [Assignment: organization-defined system components — to be defined] using [Assignment: organization-defined automated mechanisms — to be defined].

Implementation guidance:

The Organization must manage, apply, and verify configuration settings for all system components through its approved automated configuration tools, not through manual administration. The MDM tool and group policy push the approved settings and reapply them continuously. The vulnerability scanner verifies the settings independently. When someone changes a setting outside the process, the tooling corrects it or reports it. System Owners must keep every component enrolled in the automated tooling. An unmanaged component is out of compliance.

CM-06(2) — Respond to Unauthorized Changes #

Baselines: High

Requirement:

Take the following actions in response to unauthorized changes to [Assignment: organization-defined configuration settings — to be defined]: [Assignment: organization-defined actions — to be defined].

Implementation guidance:

The Organization must respond to every unauthorized change to the [CM-06(2) parameter 1 — to be defined] The System Owner must make sure the response covers the following steps. [CM-06(2) parameter 2 — to be defined].

The ISSO must confirm that each response is complete. The CISO must treat repeated unauthorized changes as a security incident.

CM-07 — Least Functionality #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Requirement:

1. Configure the system to provide only [Assignment: organization-defined mission-essential capabilities — to be defined]; and
2. Prohibit or restrict the use of the following functions, ports, protocols, software, and/or services: [Assignment: organization-defined prohibited or restricted functions, system ports, protocols, software, and/or services — to be defined].

Implementation guidance:

System Owners must configure each system to provide only the capabilities its mission requires. The System Owner must document the permitted ports, protocols, software, and services in the System Security and Privacy Plan (SSPP) and the authorization package. No system may run the auto-execute function or peer-to-peer file sharing services unless the CISO authorizes them. High-risk services and protocols that an approved benchmark restricts stay restricted. System Owners decide which functions are mission-essential for their systems, and the ISSO verifies that the running system matches that decision. The Organization treats function creep as configuration drift: the ISSO finds it and opens a ticket, and the System Owner removes it.

CM-07(1) — Periodic Review #

Baselines: Moderate / High

Requirement:

1. Review the system at least annually to identify unnecessary and/or nonsecure functions, ports, protocols, software, and services; and
2. Disable or remove [Assignment: organization-defined functions, ports, protocols, software, and services within the system deemed to be unnecessary and/or nonsecure — to be defined].

Implementation guidance:

The System Owner and ISSO must review each system at least every year to find functions, ports, protocols, software, and services that the system does not need or that are not secure. They must disable or remove what the review finds. The review is binding: the System Owner removes unneeded or nonsecure items through the change process. If the System Owner keeps an item anyway, the System Owner must document the justification where the CISO can see it.

CM-07(2) — Prevent Program Execution #

Baselines: Moderate / High

Requirement:

Prevent program execution in accordance with [Selection (one or more): [organization-defined]; rules authorizing the terms and conditions of software program usage — to be defined].

Implementation guidance:

The Organization must prevent program execution under the authorized software list and the rules that govern the terms and conditions of software use. Programs outside the authorized list must not execute, and auto-execution features must stay disabled. The Organization enforces this technically through group policy script and execution policies and the MDM tool application controls, so the restriction does not depend on the user.

CM-07(5) — Authorized Software — Allow-by-exception #

Baselines: Moderate / High

Requirement:

1. Identify [Assignment: organization-defined software programs — to be defined];
2. Employ a deny-all, permit-by-exception policy to allow the execution of authorized software programs on the system; and
3. Review and update the list of authorized software programs at least quarterly or when there is a change.

Implementation guidance:

The Organization must maintain the defined list of software authorized to execute on each system. The Organization must enforce a deny-all, permit-by-exception policy against that list: software the list does not authorize does not run. The CISO owns additions to the list, and each addition requires a documented business need. The System Owner and ISSO must review and update the authorized software list at least every quarter and remove entries whose need has lapsed.

CM-08 — System Component Inventory #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security), DE.CM (Continuous Monitoring)

Requirement:

1. Develop and document an inventory of system components that:

1. Accurately reflects the system;
2. Includes all components within the system;
3. Does not include duplicate accounting of components or components assigned to any other system;
4. Is at the level of granularity deemed necessary for tracking and reporting; and
5. Includes the following information to achieve system component accountability: [Assignment: organization-defined information — to be defined]; and

2. Review and update the system component inventory at least monthly.

Implementation guidance:

System Owners must keep a component inventory for each system that accurately reflects the system and includes every component in it. Each component belongs to exactly one system, with no duplicates and no orphans. Each record must carry, at a minimum, the hostname, Internet Protocol (IP) address, manufacturer, type, model, name, serial number, version number, and logical location. Physical hardware records must also carry the item and barcode. System Owners must review and update the inventory at least every month and after each significant system change. Under CISA BOD 23-01, the inventory must reflect the network as scanned. System Owners must include SBOM data that meets the CISA 2026 SBOM Minimum Elements. Under OMB M-21-30, System Owners must flag each product that meets NIST’s definition of critical software under Executive Order 14028. The Chief Information Officer (CIO) sets the rules for the same assets across their life cycle, for software licenses, and for the yearly physical inventory in the IT Asset Management Policy (POL-ITAM-001).

CM-08(1) — Updates During Installation and Removal #

Baselines: Moderate / High

Requirement:

Update the inventory of system components as part of component installations, removals, and system updates.

Implementation guidance:

The Organization must update the system component inventory as part of every component installation, removal, and system update. The implementer must make the update within the implementing change itself, not in a later sweep. System Owners must make sure no installation or removal ticket closes while the inventory still describes the prior state.

CM-08(2) — Automated Maintenance #

Baselines: High

Requirement:

Maintain the currency, completeness, accuracy, and availability of the inventory of system components using [Assignment: organization-defined automated mechanisms — to be defined].

Implementation guidance:

The Organization must use automated tools to maintain the system component inventory. It must use [CM-08(2) parameter 1 — to be defined] to keep the inventory current and [CM-08(2) parameter 2 — to be defined] to keep it complete. It must use [CM-08(2) parameter 3 — to be defined] to keep it accurate and [CM-08(2) parameter 4 — to be defined] to keep it available to authorized staff. System Owners must reconcile automated discovery data with the inventory, per CISA BOD 23-01.

CM-08(3) — Automated Unauthorized Component Detection #

Baselines: Moderate / High

Requirement:

1. Detect the presence of unauthorized hardware, software, and firmware components within the system using automated mechanisms with a maximum five-minute delay in detection continuously; and
2. Take the following actions when unauthorized components are detected: [Selection (one or more): disable network access by unauthorized components; isolate unauthorized components; notify [organization-defined] — to be defined].

Implementation guidance:

The Organization must detect unauthorized hardware, software, and firmware continuously with automated mechanisms. When the mechanism detects an unauthorized component, the Organization must disable its network access and notify the Incident Response Team. Containment comes first and investigation second. The ISSO must treat recurring unauthorized components as a sign that a process has failed.

CM-08(4) — Accountability Information #

Baselines: High

Requirement:

Include in the system component inventory information, a means for identifying by position and role, individuals responsible and accountable for administering those components.

Implementation guidance:

The Organization must record, for each component in the system inventory, who administers it and who answers for it. Each record must identify those people by position and role. System Owners must assign an accountable administrator before a component enters service. System Owners must update the record when that person changes. The ISSO must check that every component has a current assignment.

CM-09 — Configuration Management Plan #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

Develop, document, and implement a configuration management plan for the system that: a. Addresses roles, responsibilities, and configuration management processes and procedures; b. Establishes a process for identifying configuration items throughout the system development life cycle and for managing the configuration of the configuration items; c. Defines the configuration items for the system and places the configuration items under configuration management; d. Is reviewed and approved by [Assignment: organization-defined personnel or roles — to be defined]; and e. Protects the configuration management plan from unauthorized disclosure and modification.

Implementation guidance:

Each system must have a documented configuration management plan. The plan must assign roles and responsibilities, define how a change moves from proposal to production, and set out how the System Owner identifies configuration items and places them under configuration control. The plan must cover configuration status accounting, meaning how the System Owner records the approved state of every configuration item. It must also cover configuration audits, meaning how the System Owner confirms that the deployed system matches its approved baseline and change records, as NIST SP 800-128 describes. The plan must state how the Organization protects the plan from unauthorized disclosure and modification. The board chair, System Owner, CISO, and Authorizing Official (AO) are the accountable parties. The System Owner develops and carries out the plan. The board chair operates the change processes the plan defines. The CISO and AO approve the plan.

CM-10 — Software Usage Restrictions #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

1. Use software and associated documentation in accordance with contract agreements and copyright laws;
2. Track the use of software and associated documentation protected by quantity licenses to control copying and distribution; and
3. Control and document the use of peer-to-peer file sharing technology to ensure that this capability is not used for the unauthorized distribution, display, performance, or reproduction of copyrighted work.

Implementation guidance:

All personnel must use software and its documentation under the contract agreements and copyright law that govern it. The Organization must track software protected by quantity licenses to control copying and distribution. System Owners must not permit deployment beyond the entitlements the Organization holds. The Software Manager keeps the agency-wide license inventory and runs the monthly true-up under the IT Asset Management Policy (POL-ITAM-001). Where the Organization authorizes peer-to-peer file sharing, it must control and document that use so no one distributes copyrighted work without authorization. The Organization prohibits unauthorized peer-to-peer use and treats it as a policy violation.

CM-11 — User-installed Software #

Baselines: Low / Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

1. Establish [Assignment: organization-defined policies — to be defined] governing the installation of software by users;
2. Enforce software installation policies through the following methods: [Assignment: organization-defined methods — to be defined]; and
3. Monitor policy compliance Continuously (via CM-7 (5)).

Implementation guidance:

The Organization Rules of Behavior govern how users install software, and every user must accept them before receiving access. The Organization must enforce installation rules technically, at a minimum through the approved whitelist and blacklist. Software the whitelist does not authorize, or the blacklist names, does not install. The CISO must make sure the Organization monitors compliance continuously. System Owners must treat an unauthorized installation as a configuration incident: they remove it, open a ticket, and trace it to the control that should have prevented it. A user who needs software the list does not cover must request it. The request process is the only sanctioned path to a new installation.

CM-12 — Information Location #

Baselines: Moderate / High CSF 2.0: ID.AM (Asset Management), PR.PS (Platform Security)

Requirement:

1. Identify and document the location of [Assignment: organization-defined information — to be defined] and the specific system components on which the information is processed and stored;
2. Identify and document the users who have access to the system and system components where the information is processed and stored; and
3. Document changes to the location (i.e., system or system components) where the information is processed and stored.

Implementation guidance:

For each system, the System Owner must identify and document where Controlled Unclassified Information (CUI) resides, down to the specific components that process and store it. CUI here includes personally identifiable information (PII), Sensitive PII, Business Identifiable Information, Law Enforcement Information, and Increased Sensitive Data. The System Owner must also identify and document the users who have access to those components. When the information moves because of a new component, a migration, or a redesign, the System Owner must document the change through the change process so the record stays current. The Organization handles an information type found on a component with no documented record as a data handling incident.

CM-12(1) — Automated Tools to Support Information Location #

Baselines: Moderate / High

Requirement:

Use automated tools to identify Federal data and system data that must be protected at the High or Moderate impact levels on [Assignment: organization-defined system components — to be defined] to ensure controls are in place to protect organizational information and individual privacy.

Implementation guidance:

The Organization must use automated tools to identify Controlled Unclassified Information by information type across all system components. The information types include PII, Sensitive PII, Business Identifiable Information, Law Enforcement Information, and Increased Sensitive Data. Discovery verifies the documented locations. The System Owner must reconcile the tool’s findings with the documented location records. The System Owner must correct and investigate any information found outside its documented locations.

CM-14 — Signed Components #

Baselines: High

Requirement:

Prevent the installation of [Assignment: organization-defined software and firmware components — to be defined] without verification that the component has been digitally signed using a certificate that is recognized and approved by the organization.

Implementation guidance:

The Organization must block installation of [CM-14 parameter 1 — to be defined] and [CM-14 parameter 2 — to be defined] unless the component carries a valid digital signature. The signing certificate must trace to a publisher or certificate authority the Organization has approved. The CISO must maintain the list of approved signing certificates and publishers. System Owners must configure their systems to check signatures automatically before installation.

Administrators must not install unsigned components or components signed with an unapproved, expired, or revoked certificate. Administrators must obtain firmware only from the manufacturer or another approved source. Any exception requires a documented risk acceptance that the CISO approves and the System Owner keeps on file.

Security Impact Analysis and Significant Change #

The ISSO must analyze the security and privacy impact of every proposed change to a system before the Configuration Control Board decides on it. A significant change is a change that is likely to substantively affect the security or privacy posture of a system, as NIST SP 800-37 Rev. 2 defines it.

• The ISSO must complete a security impact analysis for each proposed change and record it in the change ticket in the ticketing system.
• The ISSO must follow the five analysis steps in NIST SP 800-128.
• The Configuration Control Board must not approve a change until the analysis is complete.
• When the analysis finds a significant change, the Security Control Assessor must review it and record whether the current authorization still holds.
• The Authorizing Official must then decide whether the change needs a new assessment or a new authorization. The Authorizing Official must decide before the change goes into production.
• The System Owner must sign each completed analysis. The ISSO must store the signed analysis with the system’s authorization records in the governance, risk, and compliance (GRC) system.

The ISSO must treat each of these changes as significant:

• a new or upgraded operating system, middleware component, or application;
• a change to the system’s ports, protocols, or services;
• a new or upgraded hardware platform;
• a change to how the system processes information, including personally identifiable information (PII);
• a change to cryptographic modules or services;
• a change to security or privacy controls;
• a move to a new facility or to a new hosting or cloud provider;
• a change to the authorization boundary, a new subsystem, or a merger with another system;
• a new connection to another system, or a new public-facing IP address or URL;
• a change to the system’s information types or security category;
• a new Authorizing Official for the system;
• the loss of a cloud provider’s Federal Risk and Authorization Management Program (FedRAMP) authorization.

Source: NIST SP 800-37 Rev. 2, Appendix F (significant change and reauthorization); NIST SP 800-128 with Update 1 (2019), section 3.3 (security impact analysis); NIST SP 800-53 Rev. 5, CM-04 and CA-06.

Related Required Processes #

• The ISSO reviews significant change notices from FedRAMP authorized cloud providers under Using FedRAMP and FedRAMP 20x Authorized Cloud Services in the Assessment, Authorization, and Monitoring procedure.

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of configuration management controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves configuration management through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Enforce configuration baselines as code with automated remediation of drift, reducing mean time from detection to correction.
6. Integrate SBOM ingestion into the CMDB so software composition updates automatically with each release.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• 2026 Minimum Elements for a Software Bill of Materials (SBOM) — CISA/NSA/FBI joint guidance: CISA/NSA/FBI joint guidance, July 29, 2026.
• CISA BOD 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks, October 3, 2022.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA BOD 26-02: Mitigating Risk From End-of-Support Edge Devices, February 5, 2026.
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk, June 10, 2026.
• CISA Known Exploited Vulnerabilities Catalog, updated continuously.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-128: Guide for Security-Focused Configuration Management of Information Systems, August 2011.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-21-30: Protecting Critical Software Through Enhanced Security Measures, August 10, 2021.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-26-05: Adopting a Risk-based Approach to Software and Hardware Security, January 23, 2026.