Configuration Management 3.4.5 (3.4.5)
Define, document, approve, and enforce physical and logical access restrictions associated with changes to organizational systems.
Get Full GuidanceWhat Is This CMMC Control?
This control requires organizations to establish and enforce who can make changes to their systems, both physically (like swapping hardware) and logically (like updating software). Before anyone modifies a system, there must be documented rules about who is authorized, what approval is needed, and how access is controlled. This prevents unauthorized or unqualified individuals from making changes that could compromise security or system stability.
Control Intent
To prevent unauthorized or unqualified modifications to organizational systems by restricting and controlling who can access systems for the purpose of making changes, thereby maintaining system security, integrity, and configuration management discipline.
Who This Control Applies To
- •All organizational systems that process, store, or transmit CUI
- •Physical facilities and locations where system components are housed
- •Software development and deployment environments
- •Change management processes and workflows
- •Media libraries and software repositories
- •Network infrastructure and security devices
- •Endpoints, servers, and cloud-based systems
- •Third-party systems that integrate with CUI environments
Not Applicable When
- •The organization has no systems that process, store, or transmit CUI
- •All systems are fully outsourced to a service provider who maintains complete responsibility for change management (though inheritance must still be documented)
- •Systems are in a decommissioned state with no active CUI processing
Key Objectives
- 1Ensure only authorized and qualified individuals can access systems to initiate changes
- 2Prevent unauthorized modifications to hardware, software, and firmware components that could compromise system security
- 3Maintain documented access restrictions that govern both physical and logical access for system changes
- 4Enforce approval processes before changes are implemented to organizational systems
Sample Self-Assessment Questions (Partial)
Who in your organization is currently authorized to make changes to systems that handle CUI?
Do you have a documented list of people who can physically access server rooms, network closets, or equipment that processes CUI?
Implementation Approaches (High-Level)
Privileged Access Management (PAM) with Role-Based Access Control
Implement a PAM solution that enforces role-based access control for system changes, requiring approval workflows and logging all privileged sessions.
Change Management Platform with Integrated Access Controls
Use a change management platform (like ServiceNow, Jira Service Management) that enforces access restrictions through integrated approval workflows and access provisioning.
Per-System Access Control with Documented Authorization
Implement access controls on each system individually, maintaining documented authorization lists and approval processes for change access.
Cloud-Native IAM with Change Control Policies
Leverage cloud provider IAM capabilities to enforce access restrictions for changes, combined with infrastructure-as-code and approval workflows.
Evidence & Assessment Notes
Expected Evidence
Organizations should maintain documentation and evidence demonstrating compliance with this control. This may include policy documentation, configuration records, audit logs, access reviews, and other relevant artifacts that show how the control is implemented and maintained.
Plan of Action & Milestones (POA&M)
If access restrictions are not yet technically enforced, document the current state (e.g., policy-based only) and provide a timeline for implementing technical controls like PAM or IAM policies If physical access controls are weak, document planned improvements such as badge systems, locks, or facility access management If access restrictions are inconsistent across systems, prioritize high-risk systems first and document a phased approach for full coverage If approval processes are informal, document plans to implement a formal change management platform or workflow automation If audit logging is missing, document plans to enable logging on all systems and establish a log review process Ensure POA&M includes specific milestones such as 'Deploy PAM solution,' 'Configure IAM policies,' or 'Implement change approval workflow' If shared accounts are in use, document plans to eliminate them and implement individual accountability For cloud environments, document plans to implement Service Control Policies or equivalent platform-level restrictions If contractors have unrestricted access, document plans to implement time-limited access grants and approval requirements
Frequently Asked Questions
Does this control require a formal Change Advisory Board (CAB) for all changes?
No, the control does not mandate a CAB. It requires that access for making changes be restricted and approved, but the approval process can be as simple as manager approval via email for low-risk changes. The formality of the approval process should be commensurate with the risk and complexity of the change.
Do access restrictions apply to automated deployment tools and CI/CD pipelines?
Yes, access restrictions must apply to any mechanism that can make changes to systems, including automated tools. This typically means controlling who can trigger deployments, who can modify pipeline configurations, and ensuring that service accounts used by automation have appropriate restrictions and logging.
How do we handle emergency changes that need to happen immediately?
Emergency changes are permitted, but the control requires that access restrictions still apply. Organizations typically implement 'break-glass' procedures where emergency access is granted to authorized individuals, but all emergency access is logged, monitored, and reviewed afterward. The key is maintaining accountability even during emergencies.
Are physical access restrictions really necessary if we have strong logical access controls?
Yes, physical access restrictions are explicitly required by this control. An attacker with physical access to systems can often bypass logical controls (e.g., booting from external media, removing hard drives). Physical access must be restricted to authorized individuals, typically through locked facilities, badge systems, or sign-in logs.
What happens if we use a cloud provider—do we still need to implement this control?
Yes, but implementation looks different. For cloud resources, you control logical access through IAM policies and ensure only authorized individuals can make changes via the cloud console, APIs, or infrastructure-as-code. Physical access is inherited from the provider. You must still document who is authorized, enforce approval processes, and maintain audit logs.
Does 'qualified individuals' mean we need to provide training before granting change access?
The control requires that individuals be 'qualified and authorized.' While formal training is not explicitly required, organizations should ensure that individuals with change access have the necessary skills and knowledge to make changes safely. This is often demonstrated through job roles, certifications, or documented competencies rather than specific training courses.
How ConformatIQ Helps With CMMC Readiness
ConformatIQ is an AI-assisted CMMC readiness platform designed to help organizations prepare for assessments more efficiently. The platform supports document generation such as SSPs and POA&Ms, guided readiness workflows, centralized evidence tracking, and interview preparation for assessments.
Ready to Get Full Guidance?
Access complete implementation details, detailed assessment questions, evidence requirements, and expert guidance for this control.
Request Full GuidanceInformation sourced from NIST SP 800-171 Rev. 2. See full disclaimer.