Configuration Management for CMMC: The Control Family That Proves Your Environment Is Under Control

Most defense contractors do not fail CMMC because they lack technology.

They fail because they cannot prove their environment is controlled.

That distinction matters. A company can have endpoint detection, multifactor authentication, encrypted laptops, a firewall, a ticketing system, and a managed service provider, yet still stumble when an assessor asks a basic question:

"Show me the approved baseline for this system, the change history, and evidence that unnecessary services are disabled."

If the answer is a mix of screenshots, tribal knowledge, and "our MSP handles that," the Configuration Management family is not mature enough.

For CMMC Level 2, Configuration Management maps to the NIST SP 800-171 3.4 requirement family. It covers baseline configurations, inventories, change control, security impact analysis, least functionality, restrictions on user-installed software, and control over system changes. In plain English, it asks whether you know what you have, how it is configured, who can change it, why changes are approved, and whether risky functionality has been removed.

That sounds administrative until you see how often weak configuration management creates real security failures. Unapproved remote access tools. Old local admin accounts. Forgotten VPN profiles. Test systems connected to the CUI environment. Workstations with consumer sync clients. Servers running services no one remembers enabling. Firewall rules added during a troubleshooting call and never removed.

In a CMMC assessment, these are not small housekeeping issues. They are evidence that the organization cannot reliably maintain the secure state it claims to have implemented.

Why Configuration Management Matters More in 2026

The CMMC program is no longer a future compliance theory. The final rule is codified in 32 CFR Part 170, and DFARS implementation is pushing CMMC requirements into solicitations, options, and flowdowns. Contractors handling Controlled Unclassified Information need more than a System Security Plan that says controls exist. They need evidence that those controls operate over time.

Configuration Management is one of the clearest places where assessors can tell the difference between a real program and a paper program.

The reason is simple: almost every other control family depends on configuration discipline.

Access control depends on identity settings, conditional access rules, group membership, local administrator restrictions, and remote access configuration. Audit and accountability depends on logging settings, retention configuration, and time synchronization. System and communications protection depends on firewall rules, encryption settings, network segmentation, DNS filtering, and secure protocols. System and information integrity depends on patch settings, endpoint protection configuration, vulnerability scanning coverage, and alerting.

If configurations drift, the rest of the control environment drifts with them.

That is why NIST SP 800-171 treats Configuration Management as a full control family rather than an IT operations footnote. The objective is not perfection. The objective is controlled change, documented baselines, reduced attack surface, and repeatable evidence.

What NIST SP 800-171 3.4 Really Requires

The Configuration Management family in NIST SP 800-171 Revision 2 includes nine requirements. Contractors should read the source text directly, but the practical obligations fall into five buckets.

First, you must establish and maintain baseline configurations and inventories for systems that process, store, or transmit CUI. That includes hardware, software, firmware, and documentation. A baseline is not just a list of devices. It is the approved secure state for the system.

Second, you must control and monitor changes. That means changes are requested, reviewed, approved, tested when appropriate, implemented by authorized personnel, documented, and reviewed after implementation. It also means emergency changes are captured after the fact instead of disappearing into chat messages.

Third, you must analyze security impact before making changes. If a firewall rule, identity policy, endpoint configuration, or cloud storage setting changes, someone must consider whether the change affects CUI protection.

Fourth, you must restrict functionality to what is necessary. Nonessential programs, ports, protocols, and services should be disabled or removed. This is where many contractors discover that "standard build" and "secure build" are not the same thing.

Fifth, you must control user-installed software and enforce configuration restrictions. Users should not be able to install unapproved tools that create unmanaged storage, remote access, file sharing, synchronization, browser extensions, or AI upload risk inside the CUI boundary.

Taken together, the control family asks a blunt question: can the contractor keep the CUI environment in a known, approved, secure state?

The Baseline Is the Starting Point

A baseline configuration is the approved build standard for a class of systems. It tells IT, security, the MSP, and the assessor what "normal and secure" looks like.

For a small or mid-sized defense contractor, useful baselines usually include:

• Windows workstation baseline
• Windows server baseline
• Microsoft 365 or Google Workspace baseline
• Firewall and VPN baseline
• Endpoint protection baseline
• Mobile device baseline, if mobile devices touch CUI
• Backup system baseline
• Cloud storage and collaboration baseline
• Network device baseline for switches, wireless, and routers

Each baseline should define security-relevant settings. For workstations, that might include disk encryption, local admin restrictions, password and lock settings, screen timeout, endpoint protection, USB restrictions, logging, patch cadence, remote access restrictions, approved software, and browser hardening. For Microsoft 365, it might include MFA, conditional access, external sharing, retention, audit logging, privileged role assignments, mailbox forwarding restrictions, and data loss prevention settings.

The common mistake is treating a vendor default as the baseline. Defaults are not baselines. Defaults are what the vendor shipped. A baseline is what your organization reviewed, approved, documented, and maintains.

Contractors do not need a 90-page document for each system type. In fact, smaller teams usually do better with concise baselines that map settings to implementation evidence. A practical baseline might be a controlled spreadsheet, policy document, endpoint management profile export, secure configuration benchmark, or configuration-as-code repository. The format matters less than consistency, approval, and evidence.

TalonPoint PolicyPack includes policy language that helps define roles, approvals, and documentation expectations, but the real value comes when those policies are connected to your actual tools: Intune, Group Policy, firewall management, RMM platforms, EDR, vulnerability scanners, ticketing systems, and cloud admin portals.

Inventory Must Be More Than a Device List

Configuration Management starts with knowing what exists.

A CMMC-ready inventory should cover every asset in scope for the CUI environment and every asset that can affect the security of that environment. That usually includes endpoints, servers, virtual machines, cloud services, network devices, security tools, backup platforms, SaaS applications, privileged accounts, and externally managed systems.

At minimum, the inventory should identify:

• Asset owner
• Asset type
• Location or hosting environment
• System purpose
• CUI relevance
• Operating system or platform
• Approved software or service role
• Security tool coverage
• Patch or update responsibility
• Configuration baseline applied
• External service provider involvement, if any
• Retirement or review status

The inventory should reconcile to reality. If the asset list says 64 workstations exist but the endpoint console shows 71, an assessor will ask why. If a cloud service stores CUI but does not appear in the system boundary, the issue becomes larger than inventory. It becomes a scoping problem.

The strongest contractors perform periodic inventory reconciliation. They compare endpoint management, EDR, vulnerability scanner, identity provider, firewall, and procurement records. They investigate mismatches. They document the result. That evidence shows the assessor that the organization is actively managing the environment rather than preserving a stale spreadsheet.

Change Control Is Where Paper Programs Break

Configuration change control is not bureaucracy for its own sake. It is how leadership knows that changes to the CUI environment are intentional, reviewed, and recoverable.

A strong CMMC change process does four things.

It defines what counts as a controlled change. For example: firewall rules, VPN settings, identity policies, privileged access, endpoint baseline changes, server configuration, cloud sharing settings, audit logging, backup configuration, vulnerability scanner scope, and security tool exclusions.

It routes changes through an approval path. Not every change needs a committee, but security-relevant changes need documented review by someone accountable for the CUI environment.

It includes security impact analysis. The question does not need to be complicated: could this change weaken CUI protection, expand access, reduce logging, expose data externally, affect backup integrity, or create a new dependency? If yes, the risk should be reviewed before implementation.

It preserves evidence. Tickets, approvals, test notes, implementation records, screenshots, configuration exports, rollback plans, and post-change validation all become part of the compliance story.

The most common failure pattern is informal change control. A technician gets a Teams message from a project manager, opens a firewall port, fixes the immediate problem, and moves on. Six months later, nobody remembers why the rule exists. In an assessment, that unmanaged change becomes a control failure and potentially an attack path.

Emergency changes are allowed, but they still need discipline. Document the emergency, who approved it, what was changed, why it was necessary, how risk was evaluated, and when the change was reviewed afterward.

Least Functionality: The Attack Surface Test

NIST SP 800-171 3.4.6 requires organizations to employ the principle of least functionality by configuring systems to provide only essential capabilities. This is one of the most practical security requirements in the entire framework.

Ask a simple question: what is running that does not need to run?

For defense contractors, high-risk examples include:

• Unapproved remote access tools
• Consumer file synchronization clients
• Local web servers on workstations
• Legacy SMB settings
• Unused VPN profiles
• Unneeded administrator tools
• Personal cloud storage applications
• Browser extensions that can read sensitive pages
• Unapproved AI or transcription tools
• Open inbound ports that no business process requires
• Default services on network devices

Least functionality is not just a hardening exercise. It is a business discipline. Every unnecessary capability creates operational convenience for someone and risk for everyone. The organization needs a process for deciding what is allowed, what is prohibited, and how exceptions are approved.

A good assessor will not expect every system to look identical. Engineering workstations, accounting systems, servers, and executive laptops have different needs. But the assessor will expect the contractor to explain why differences exist and show that exceptions are approved, time-bound when appropriate, and reviewed.

User-Installed Software Is a CUI Leakage Problem

User-installed software is often treated as a helpdesk issue. In a CMMC environment, it is a CUI leakage issue.

If users can install any software they want, they can introduce unmanaged storage, remote access, browser plugins, screen recorders, file transfer tools, synchronization clients, or AI tools that move sensitive information outside the approved boundary. Even well-intentioned employees can create compliance exposure by using tools that make their jobs easier.

Contractors should define an approved software list and a request process for exceptions. Endpoint management or application control should enforce the policy where practical. Administrative rights should be limited. Software inventories should be reviewed for unauthorized applications. When an unapproved tool is found, the response should be documented.

The key is not to block productivity blindly. The key is to make software decisions visible, reviewable, and aligned with CUI handling rules.

What Evidence an Assessor Will Expect

For Configuration Management, evidence usually needs to show both design and operation.

Design evidence shows that the program exists:

• Configuration management policy
• Change management procedure
• Secure baseline documents or tool profiles
• Asset inventory procedure
• Approved software list
• Roles and responsibilities
• Exception handling process
• System Security Plan references

Operational evidence shows that the program is actually running:

• Current asset inventory exports
• Endpoint management profiles
• Group Policy or MDM settings
• Firewall configuration exports
• Change tickets with approvals
• Security impact analysis notes
• Vulnerability or configuration scan results
• Evidence of disabled services or restricted ports
• Software inventory reports
• Unauthorized software remediation records
• Periodic review meeting notes
• Baseline review and approval history

The evidence should line up across sources. If the SSP says Intune enforces workstation baselines, the Intune profile should support that claim. If the policy says all firewall changes require approval, sample firewall changes should have approved tickets. If the approved software list excludes personal cloud storage, endpoint inventory should not show consumer sync clients on CUI systems.

This alignment is where many contractors gain or lose credibility.

A Practical 30-Day Configuration Management Sprint

If your Configuration Management program is weak, do not start by writing a 40-page policy. Start by bringing reality under control.

In the first week, define the CUI system boundary and collect inventories from your identity provider, endpoint management tool, EDR, vulnerability scanner, firewall, backup platform, and cloud admin portals. Reconcile obvious mismatches and identify unknown assets.

In the second week, document baseline configurations for the highest-risk system types: workstations, servers, firewall/VPN, and cloud collaboration. Keep the baselines practical. Include the settings that materially protect CUI and that you can verify.

In the third week, tighten change control. Define which changes require approval, add a security impact field to the ticket process, and make sure emergency changes have after-action review. Pull three recent changes and see whether the evidence would survive an assessment.

In the fourth week, attack least functionality and software control. Remove unnecessary services, review open ports, restrict local admin rights, clean up unauthorized tools, and publish an approved software process.

By the end of 30 days, you may not have a perfect program. But you should have a defensible baseline, a better inventory, a working change process, and evidence that your environment is moving from informal to controlled.

The Bottom Line

Configuration Management is not glamorous. It will not sell like a new security platform. It will not impress a board with a colorful dashboard.

But for CMMC, it is foundational.

It proves that your CUI environment is known, documented, approved, monitored, and maintained. It reduces the chance that one rushed troubleshooting change becomes next year's assessment finding. It gives your MSP clear rules instead of vague expectations. It gives leadership confidence that technical risk is being managed instead of inherited through drift.

Most importantly, it gives assessors what they are looking for: evidence that the secure state of the environment is not accidental.

For defense contractors preparing for CMMC Level 2, that is the real test. Not whether you can secure a system once. Whether you can keep it secure, prove it, and repeat the process every time the environment changes.