CM-5: Access Restrictions for Change

Quick-reference card

What this control requires

CM-05 requires organizations to define, document, approve, and enforce physical and logical access restrictions for changes to information systems. In practice, this means that only qualified and authorized individuals can modify hardware, software, firmware, or operational procedures that affect system security and privacy.

Specifically, the scope extends beyond traditional user access controls. Specifically, when you consider the range of change vectors in a modern environment, CM-05 covers software libraries, media libraries, abstract interface layers, workflow automation tools, and designated change windows. Each of these vectors must have documented restrictions that specify who can initiate changes, under what conditions, and through which approval workflows. Organizations operating under NIST SP 800-53 must treat this control as foundational to their configuration management program.

But in most environments, satisfying CM-05 means implementing a combination of role-based access controls, formal change request workflows, and time-bound change windows. The control applies across all three baselines (LOW, MODERATE, and HIGH), which signals that NIST considers unrestricted change access a fundamental risk regardless of system categorization.

Why it matters

Unrestricted or poorly governed change access is one of the most common root causes of security incidents in enterprise environments. When anyone with system access can modify production configurations, deploy code, or alter firmware, the organization loses the ability to maintain a known-good state. Audit trails become unreliable, and accountability gaps emerge across every layer of the technology stack.

In practice, this means that organizations face both audit risk and potential certification withdrawal when CM-05 deficiencies surface. Federal agencies subject to the Federal Risk and Authorization Management Program (FedRAMP), the Federal Information Security Modernization Act (FISMA), or DoD authorization frameworks face material consequences, including authorization-to-operate (ATO) delays and conditional findings that require remediation within fixed timelines. For organizations pursuing or maintaining a NIST 800-53 compliance posture, CM-05 gaps are among the most frequently cited in assessor reports.

But the risk isn’t limited to audit outcomes. Uncontrolled change access creates exploitable conditions that adversaries actively target.

What attackers exploit

• Compromised privileged accounts used to push unauthorized configuration changes to production systems, bypassing change advisory boards entirely
• Insider threats where employees or contractors with excessive change privileges modify system settings to exfiltrate data or create persistent backdoors
• Supply chain compromise through uncontrolled access to software libraries and build pipelines, allowing malicious code injection before deployment
• Lateral movement from development environments to production systems where change restrictions aren’t enforced across environment boundaries
• Exploitation of unmonitored change windows where attackers time unauthorized modifications to coincide with legitimate maintenance periods, blending malicious activity with approved changes

How to implement

Implementing CM-05 requires bridging the gap between documented access policies and enforced technical controls. Most organizations have change management policies on paper, but the challenge is ensuring those policies translate into enforceable restrictions across all change vectors.

For your organization

1. Inventory all change vectors

Start by identifying every pathway through which changes can reach production systems. This includes direct system access, CI/CD pipelines, database administration tools, infrastructure-as-code repositories, firmware update mechanisms, and physical access to hardware. You can’t restrict what you haven’t mapped.

2. Define role-based change privileges

Establish roles that separate who can request changes, who can approve them, and who can execute them. Align these roles with your existing access enforcement policies under AC-03 and least privilege principles under AC-06. Document each role’s scope, the systems it covers, and the approval chain required before changes are authorized.

3. Implement technical enforcement

Deploy access controls that enforce your documented restrictions. This means configuring repository branch protection rules, requiring multi-party approval for production deployments, enforcing change windows through scheduling controls, and restricting physical access to server rooms and network infrastructure. Logical access controls (AC-03) and physical access controls (PE-03) must work in concert.

4. Establish change windows and workflow automation

Define approved change windows for each system tier. Configure workflow automation to route change requests through the appropriate approval chain, log every action, and block out-of-window modifications unless an emergency change process is invoked. Every emergency change should still require after-the-fact review and documentation.

5. Monitor and audit change activity

Implement continuous monitoring that captures all change events, flags unauthorized modifications, and generates alerts when someone attempts changes outside approved windows or without proper authorization. Retain audit records that map each change to an approved request, an authorized individual, and a defined change window.

For your vendors

1. Assess vendor change management maturity

Request evidence that your vendors maintain documented access restrictions for changes to systems that process, store, or transmit your data. Review their configuration management plans and change control records to verify that restrictions exist beyond policy statements.

2. Require contractual change notification

Include contractual provisions that require vendors to notify you of significant changes to systems within your shared responsibility boundary. Define what constitutes a significant change, the notification timeline, and your right to review change control records during audits.

3. Validate technical controls during assessments

During vendor assessments, verify that logical access approvals and physical access approvals are enforced through technical controls rather than relying solely on procedural compliance. Request evidence of role-based access to change management systems, branch protection configurations, and audit logs showing change approval workflows in action.

4. Monitor vendor change activity continuously

Where possible, integrate vendor change notifications into your own monitoring workflows. Track whether vendors maintain separation of duties between change requestors, approvers, and implementers. Continuous vendor risk monitoring platforms can automate this visibility, alerting you when a vendor’s change management posture degrades.

Evidence examples

Cross-framework mapping

Related controls

• AC-03 — Access Enforcement: provides the logical access control mechanisms that CM-05 relies on to restrict who can initiate system changes
• AC-05 — Separation of Duties: ensures that no single individual can both approve and execute a change, reinforcing CM-05’s restriction model
• AC-06 — Least Privilege: limits change access to the minimum permissions necessary, reducing the blast radius of compromised accounts
• CM-09 — Configuration Management Plan: defines the overarching strategy for managing configurations, within which CM-05’s access restrictions operate
• PE-03 — Physical Access Control: governs physical entry to facilities where hardware changes occur, complementing CM-05’s logical restrictions
• SC-28 — Protection of Information at Rest: protects stored data from unauthorized modification, supporting the integrity goals that CM-05 enforces through access restrictions
• SC-34 — Non-modifiable Executable Programs: prevents runtime modification of critical executables, providing a technical backstop for CM-05’s change restrictions
• SC-37 — Out-of-band Channels: establishes secure communication paths for change approvals and notifications that bypass potentially compromised primary channels
• SI-02 — Flaw Remediation: requires that patches and fixes follow controlled change processes, making CM-05 restrictions essential to safe remediation workflows
• SI-10 — Information Input Validation: ensures that data entering systems during change processes is validated, preventing injection of malicious configurations

Frequently asked questions

What is NIST SP 800-53 CM-05

CM-05 is the NIST SP 800-53 control that governs who can make changes to information systems and how those restrictions are enforced. Auditors evaluate it against six distinct assessment objectives, covering both physical and logical access restrictions across three stages: definition and documentation, formal approval, and active enforcement. Its inclusion in all three baselines (LOW, MODERATE, and HIGH) reflects NIST’s position that unrestricted change access is a foundational risk regardless of system impact level.

What happens if CM-05 is not implemented

Without CM-05, organizations lose the ability to attribute system changes to authorized individuals, creating accountability gaps that auditors consistently flag. Federal agencies risk authorization-to-operate delays or conditional findings requiring remediation. The absence of enforced access restrictions also means that configuration management plans lack a foundational enforcement layer, leaving change vectors open to both insider threats and external compromise.

How do you audit CM-05

Auditors assess CM-05 against six specific objectives that test whether physical and logical access restrictions are each defined, documented, formally approved, and actively enforced. The examination phase involves reviewing configuration management policies alongside physical access approvals and logical access approvals to verify that restriction procedures exist and have received formal sign-off. Assessors then test enforcement by examining system configuration settings, access credentials, and change control records to confirm that the documented restrictions are technically enforced and that system audit records capture every change event with attribution to an authorized individual.

What is the difference between CM-05 and CM-03

CM-03 (Configuration Change Control) governs the process for requesting, evaluating, and approving changes before they happen. CM-05 focuses specifically on restricting who has access to make those changes and enforcing those restrictions through physical and logical controls. In practice, CM-03 defines your change control records workflow, while CM-05 ensures only authorized individuals can execute approved changes through enforced access credentials and role-based restrictions.