CMMC Level 2Implementation GuideJune 11, 2026· 12 min read
How to Actually Implement CMMC Level 2 Configuration Management: A Practitioner's Guide
Configuration management is the practice that makes everything else defensible. You can have strong access controls, but if you don't know what's running on your network, what each system's approved configuration looks like, and who changed what and when, you're neither compliant nor actually secure. This guide walks through all 9 CM practices with plain-language explanations and real implementation guidance.
Why Configuration Management Is Harder Than It Looks
The CM domain sits at a peculiar intersection of technical discipline and process discipline. Practice 3.4.1 (establish baseline configurations) sounds simple until you realize it requires documenting the approved state of every system type in scope, enforcing those configurations, and detecting when systems drift from the baseline. That's not a one-afternoon project, it's an ongoing operational process.
The good news: once the foundational pieces are in place (asset inventory, baseline documentation, change management process), the remaining practices build on top of them systematically. Build the foundation first.
Start here: Before implementing any of the 9 practices below, build your asset inventory. You cannot baseline, configure, or control what you don't know about. A complete list of in-scope systems, every workstation, server, network device, and cloud resource, is the prerequisite for the entire CM domain.
Practice 3.4.1, Establish and Maintain Baseline Configurations
3.4.1
Know what a correctly configured system looks like, and document it
A baseline configuration is a documented, approved set of settings for a specific system type. Every workstation, server, and network device in scope should have a documented baseline it's expected to match.
How to implement:
Choose a baseline standard: the CIS Benchmarks (free at cisecurity.org) and DISA STIGs (free from public.cyber.mil) are the two most common for CMMC environments. CIS Level 1 is a reasonable starting point for most organizations
Create a baseline document for each system type: Windows 11 workstation, Windows Server 2022, network switches, firewalls, whatever's in scope
Pair the baseline with your asset inventory, every in-scope asset should have an associated baseline type
Periodically compare live system configurations against the baseline to detect drift, quarterly at minimum, monthly is better
Document exceptions: if a system requires a deviation from the baseline for a legitimate business reason, that exception must be approved and documented
Common mistake: Treating "baseline" as equivalent to "we installed Windows and turned on Defender." An assessment-ready baseline is a specific, documented configuration state with defined settings, not a general description of what you use. The assessor may ask you to pull up your baseline document and compare it to a live system.
Practice 3.4.2, Establish and Enforce Security Configuration Settings
3.4.2
Harden your systems. Then enforce the hardening.
This practice goes beyond documenting a baseline, it requires actually applying security configuration settings and enforcing them so systems can't easily drift back to an insecure state.
How to implement:
Apply CIS Benchmark settings via Group Policy or Microsoft Intune Configuration Profiles, this is how you enforce settings at scale rather than manually configuring each machine
Critical settings to enforce: account lockout policy, Windows Firewall enabled on all profiles, BitLocker encryption on workstations, audit policy settings, PowerShell execution policy, and disabling legacy protocols like SMBv1
Disable SMBv1 explicitly, it's the primary ransomware propagation vector and serves no legitimate purpose in modern environments
For servers: disable services not required for the server's role. A file server doesn't need IIS; a web server doesn't need SNMP enabled with default community strings
For network devices: change default credentials, disable unneeded management interfaces, enable syslog to a central log collector
Use CIS-CAT Lite (free from CIS) to run a benchmark assessment and see how your systems score before your CMMC assessment
Common mistake: Building GPOs in a test OU and never linking them to production. The settings exist in Group Policy, but they've never been applied to actual machines. Pull a GPO Resultant Set of Policy report on a production workstation to verify settings are actually landing.
Practices 3.4.3 and 3.4.4, Change Management and Security Impact Analysis
3.4.3 – 3.4.4
Changes go through a process. That process includes a security review.
Practice 3.4.3 requires that changes to in-scope systems are tracked, reviewed, approved, and logged. Practice 3.4.4 requires analyzing the security impact of changes before they're made. Together, these define your change management process.
How to implement:
Establish three change categories: standard changes (pre-approved, routine, like monthly patching), normal changes (require review and approval before implementation), and emergency changes (expedited approval for urgent issues, documented retroactively)
Use a ticketing system to log all changes, what changed, who requested it, who approved it, who implemented it, and when. A shared ServiceNow, Jira Service Management, or even a structured SharePoint list works for smaller organizations
Add a security impact field to your change request: "What are the security implications of this change?" For most changes, this is a paragraph. For significant architectural changes, it may require a more formal review
Normal and emergency changes require approval from someone other than the implementer, this overlaps with the separation of duties requirement in the AC domain
Review your change log monthly, look for unauthorized changes (changes that happened without a corresponding ticket)
Common mistake: Verbal approval documented as "approved by manager." An assessor reviewing your change log needs to see who approved each change and when. "Joe said it was fine" doesn't hold up. The approval needs to be recorded in the ticket.
Practice 3.4.5, Access Restrictions Associated with Changes
3.4.5
Separate who can request, approve, and implement changes
Not everyone should be able to make changes to production systems. This practice requires defining and enforcing access restrictions for the change process itself.
How to implement:
Define change roles in your ITSM tool: Requester, Change Approver, Change Implementer
The person requesting a change should not be the same person approving it
Restrict production environment access to a defined set of authorized implementers, not all IT staff need rights to push changes to every system
For source code and scripts used in system configuration, restrict who can commit changes to production branches
Document these roles and restrictions in your Configuration Management Plan
Common mistake: One IT administrator who has full access to everything with no formal authorization documentation. This person requests changes, approves them, implements them, and reviews them. That's a single point of control with no oversight, and it's exactly what this practice is designed to prevent.
Practices 3.4.6 and 3.4.7, Least Functionality and Port/Service Restrictions
3.4.6 – 3.4.7
Systems run only what they need. Ports and services that aren't needed are closed.
Practice 3.4.6 (least functionality) says configure systems to provide only essential capabilities. Practice 3.4.7 goes deeper, restrict, disable, or prevent the use of nonessential programs, ports, protocols, and services.
How to implement:
Audit each in-scope server for its actual role and remove Windows Server roles and features not required for that role, a file server doesn't need the Web Server (IIS) role installed
Run a port scan against your in-scope systems (Nmap or your vulnerability scanner) and document every open port, anything without a documented business justification should be closed
Disable legacy protocols at the OS and application level: SMBv1, TLS 1.0, TLS 1.1, LLMNR, NetBIOS where not required
Block unnecessary outbound traffic at the perimeter, most workstations have no legitimate reason to initiate connections on arbitrary high ports
For workstations: restrict PowerShell execution policy, consider disabling Windows Script Host if not needed, and audit startup programs
For network devices: remove unused interfaces from active VLANs, disable Telnet in favor of SSH, disable SNMP v1/v2 in favor of v3 or disable entirely
Common mistake: Firewall rule sets that have accumulated over years with no review, dozens of "any/any" or overly broad rules that nobody remembers creating. An assessor may ask you to explain the business justification for specific firewall rules. If you can't, those rules are a finding.
Practice 3.4.8, Application Allow-listing and Deny-listing
3.4.8
Control what software can execute. Allow-listing is the stronger approach.
This practice requires either a deny-by-exception approach (block known bad software) or a deny-all, permit-by-exception approach (only allow-listed software can run). The allow-list approach is significantly stronger and is what most assessors expect to see at mature CMMC implementations.
How to implement:
Start with an audit: before implementing any controls, run an inventory of all software currently in use across in-scope systems. Implementing allow-listing without a complete inventory causes immediate operational disruption
Build your initial allow-list from the audit results, document approved applications, their versions, and their business justification
Tool options by maturity level:
Built-in, free: Windows Defender Application Control (WDAC), policy-based, managed via Intune or GPO. Steeper learning curve but no additional cost
Built-in, moderate complexity: Microsoft AppLocker, path, publisher, or hash rules. Available on Windows 10/11 Pro and Enterprise
Purpose-built, easier management: ThreatLocker, cloud-managed, application ring-fencing, very assessment-friendly. Requires paid licensing but significantly reduces implementation complexity
Implement in audit mode first, then enforcement, audit mode lets you see what would be blocked without actually blocking it
Define a process for adding new approved applications: request, review, approval, deployment
Common mistake: Jumping straight to enforcement without an audit phase. The result is legitimate business applications getting blocked, frustrated users, and an emergency rollback on day one. Audit first, it usually takes two to four weeks of observation to get a clean allow-list before enforcement is viable.
Practice 3.4.9, Control and Monitor User-Installed Software
3.4.9
Remove local admin from standard users. Build a software approval process.
This practice is about preventing users from installing unauthorized software on systems that handle CUI. It's closely related to 3.4.8, allow-listing controls what executes, but 3.4.9 controls what gets installed in the first place.
How to implement:
Remove local administrator rights from standard user accounts, this is the single most impactful control for this practice. Without local admin rights, most software installation attempts simply fail
Establish a software request and approval process: users submit a helpdesk ticket for software they need, IT reviews against the approved software list, approves or denies, and deploys through Intune/SCCM if approved
Enable software installation logging, Windows Event IDs 11707 (product installed) and 1033 (installation completed) capture installation activity
Run periodic audits of installed software using Intune, SCCM, PDQ Inventory, or similar, compare against the approved software list and investigate anomalies
For software that requires elevation to install but is otherwise approved, use Intune or SCCM to deploy it with system-level privileges rather than granting users local admin
Common mistake: Local admin rights granted to all users because the helpdesk "got tired of software requests." This is the most common CM finding. Users with local admin can install anything, browsers with extensions, remote access tools, unapproved cloud sync clients. Removing local admin immediately strengthens 3.4.8, 3.4.9, and several other practices.
Quick Reference: Tools for CM Implementation
Need
Tool Options
Notes
Baseline standards
CIS Benchmarks, DISA STIGs, Microsoft Security Baseline
CIS Benchmarks are free and well-documented; STIGs are required for some DoD contracts
Baseline assessment
CIS-CAT Lite (free), Tenable Nessus, Qualys
CIS-CAT Lite scores a system against the CIS Benchmark at no cost
Asset inventory
Lansweeper, PDQ Inventory, Qualys, Intune
Intune provides inventory for enrolled devices at no additional cost if already licensed
Configuration enforcement
Group Policy (GPMC), Microsoft Intune, SCCM
GPO is free with Windows Server; Intune is included in M365 Business Premium
Change management
ServiceNow, Jira Service Management, Freshservice
Even a structured SharePoint list can satisfy the requirement for small organizations
Application control
ThreatLocker, WDAC, AppLocker
ThreatLocker is the most assessment-friendly; WDAC/AppLocker are built into Windows
Port and service auditing
Nmap, Nessus, Qualys
Nmap is free; run against in-scope systems to identify unexpected open ports
Software inventory and deployment
Intune, SCCM, PDQ Deploy
PDQ Deploy is useful for on-premise environments without full Intune rollout
The CM-AC connection: Several CM practices depend on AC controls to be effective. Allow-listing (3.4.8) and user software control (3.4.9) both require that users can't elevate privileges to bypass controls, which comes from AC least privilege (3.1.5–3.1.7). Change access restrictions (3.4.5) overlap directly with separation of duties (3.1.4). If your AC controls aren't implemented, CM controls will have gaps. Implement these domains together, not independently.
Building the Evidence Package
The CM domain requires documentation that goes beyond just the policy. Assessors will typically want to see your baseline configuration documents, a sample change request ticket showing the full workflow (request, security analysis, approval, implementation), evidence that your baseline is actually enforced on live systems (a GPO Resultant Set of Policy report or an Intune compliance report), your approved software list, and your asset inventory.
Build this evidence package as you implement, it's far easier to capture screenshots and export reports during implementation than to reconstruct everything the week before your assessment.
Need the Policy Document That Covers These Practices?
Our CMMC Level 2 Configuration Management Plan template covers all 9 CM practices in formal policy language with fill-in-the-blank placeholders for your organization's specific tools, baselines, and change management process. Written for defense contractors by practitioners who have built CM programs for real CMMC engagements.
A baseline configuration is a documented, approved set of configuration settings for a specific type of system, defining what a correctly configured workstation, server, or network device should look like. For CMMC, common baselines include the CIS Benchmarks and DISA STIGs. The baseline must be documented, deployed to in-scope systems, and enforced, meaning systems are regularly compared against it and deviations are corrected or formally approved as exceptions.
Practice 3.4.8 requires either a deny-by-exception (deny-list) or deny-all, permit-by-exception (allow-list) approach. While deny-listing technically satisfies the practice, the allow-list approach is the stronger control and what most C3PAOs expect to see at a mature implementation. Tools like ThreatLocker, Windows Defender Application Control, and AppLocker all satisfy the requirement. If you choose deny-listing only, be prepared to explain the approach and demonstrate how it's maintained.
Practice 3.4.3 requires tracking, reviewing, approving, and logging changes. The level of formality scales with organizational size, a small contractor can use a simple ticketing system with a defined approval step, while larger organizations use ITIL-based change management. The key requirements are that changes are requested, reviewed for security impact (3.4.4), approved by someone other than the implementer, and logged with enough detail to reconstruct what changed and when.
Yes, this is one of the most impactful single controls for the CM domain. Practice 3.4.9 requires controlling user-installed software, and 3.4.8 requires controlling software execution. Both are significantly harder to satisfy when users have local admin rights, because admin users can install and run most anything. Removing local admin from standard user accounts is foundational to software control and is an expected control by assessors.
Practice 3.4.6 (least functionality) is about systems overall, configure systems to provide only essential capabilities, removing unnecessary roles and features. Practice 3.4.7 is more specific, it targets ports, protocols, and services, requiring that nonessential ones are restricted or disabled. Together they address both the macro level (what does this server do?) and the micro level (what is this server listening on?). A server can satisfy 3.4.6 by having only the File Server role installed while still failing 3.4.7 if it has unnecessary ports open or legacy protocols enabled.