Configuration Management is the family that reveals whether your GCC High environment is actually governed or whether it is just accumulating settings over time. Most organizations do not struggle here because they completely lack configuration controls. They struggle because their baseline exists only in a document, changes are happening without enough review, hardening decisions are inconsistent across devices, and nobody can clearly show which applications, services, and administrative paths are actually authorized.

That is what makes this family so important in a CMMC context. A C3PAO is not just asking whether Intune has configuration profiles or whether Windows devices can be hardened. They are evaluating whether your organization has established a defined configuration standard, enforces it consistently, controls changes to it, and can prove that only approved functionality and software are allowed inside the assessment boundary.

GCC High gives you many of the technical building blocks needed to implement the CM family. Intune supports security baselines, configuration profiles, compliance policies, and application deployment. Microsoft Defender for Endpoint supports attack surface reduction and advanced endpoint security controls. Entra ID and Microsoft Purview provide audit trails for configuration and administrative changes. Azure Government services can extend monitoring and retention. But Microsoft does not implement Configuration Management for you. Of the nine controls in this family, nearly all require customer configuration, customer governance, or both.

This is Part 4 of the NIST 800-171 GCC High Configuration Guide. It assumes you already have a functioning GCC High tenant, understand the shared responsibility model, and are implementing against NIST SP 800-171  Rev. 2.

Configuration Management family overview

The Configuration Management family includes nine controls focused on establishing and maintaining secure baselines, enforcing approved settings, controlling changes, restricting administrative access to change-capable functions, reducing unnecessary functionality, and preventing unauthorized software execution.

At a practical level, the family breaks into three layers. The first is baseline and hardening work, where you define what a compliant GCC High endpoint and tenant should look like. The second is change governance, where you track, review, approve, and assess the impact of modifications before they are made. The third is functionality and software restriction, where you deliberately reduce what systems can do and what code they are allowed to run.

If Audit and Accountability is the memory of the environment, Configuration Management is its discipline. It is the family that answers whether your systems are configured intentionally, whether they stay that way over time, and whether your organization can detect when the environment drifts away from what the SSP says is true.

CM controls and CMMC scope

Configuration Management applies across the full CMMC assessment boundary. Any in-scope endpoint, cloud workload, administrative system, or supporting service must be governed by an established baseline, subject to change control, and restricted to approved capabilities and software.

That matters in enclave architectures. An enclave can reduce the number of systems that need to meet the full set of CMMC requirements, but the systems that remain in scope need especially disciplined configuration control. If CUI is handled on a defined set of Windows endpoints, in Exchange Online, SharePoint Online, Teams, or associated admin planes, the relevant hardening settings, update policies, administrative restrictions, and software controls need to be documented and enforced within that boundary.

This is also where scope drift often shows up. Organizations believe they have standardized a limited set of CUI devices, but then discover unmanaged applications, unreviewed exceptions, standing admin rights, or nonstandard device builds inside the enclave. In the CM family, scoping is not just about where CUI lives. It is also about which systems, users, and tools are allowed to change the environment and how that environment is kept aligned to the documented baseline.

How configuration management works in GCC High

Before walking through the individual controls, it helps to understand the architecture you are actually using in GCC High.

Microsoft Intune is the primary configuration management layer for endpoints. It is where you deploy security baselines, settings catalog profiles, compliance policies, application deployments, account protection controls, firewall settings, and application control policies. If you are managing Windows endpoints inside a CUI boundary, Intune is usually the center of gravity for the CM family.

Microsoft Defender for Endpoint adds another layer for configuration enforcement, especially around attack surface reduction, endpoint detection, and application control reporting. It is also where organizations often surface the practical impact of least functionality decisions.

Entra ID supports the governance side of the family by controlling who can change the environment, how privileged access is activated, and how administrative access is restricted. Purview Audit and Entra audit logs provide the evidence trail for configuration changes, role changes, and policy modifications. Azure Government Log Analytics and Sentinel can extend retention and improve visibility where long-term evidence and cross-source analysis are needed.

One practical note matters here too. In GCC High, the portals and administrative endpoints use .us domains. Intune lives at intune.microsoft.us, Entra at entra.microsoft.us, Microsoft 365 admin at admin.microsoft365.us, Purview at compliance.microsoft.us, and security tooling at security.microsoft.us. PowerShell and Graph connections also need the correct US Government environment parameters. If you are configuring against commercial endpoints out of habit, you are not working in the right environment.

What GCC High configures by default

Unlike some other control families, Configuration Management is not largely handled by the platform for you. Microsoft provides the mechanisms, but most of the CM family still depends on explicit tenant decisions, documented baselines, administrative governance, and continuous review.

There are some platform advantages worth noting. Intune includes Microsoft security baselines for Windows, Edge, and Defender for Endpoint. Defender includes native attack surface reduction and application control capabilities. Entra ID supports Privileged Identity Management and Conditional Access for restricting who can make changes. Audit logs for configuration activity are available across the platform. But none of that satisfies the family by default. A tenant with access to these features but without implemented baselines, documented approvals, or enforced application control is still weak in CM.

In other words, this is a family where Microsoft gives you the tools, not the outcome.

The nine CM controls you must configure yourself

This is where the real implementation work happens. Assessors tend to scrutinize this family heavily because it is one of the clearest indicators of whether your security program is operational or just documented.

3.4.1 Establish and maintain baseline configurations and inventories

CM.L2-3.4.1

This control requires you to establish and maintain baseline configurations and inventories of organizational systems, including hardware, software, firmware, and documentation, throughout the system development life cycle.

In GCC High, that usually starts with Intune security baselines and compliance policies. A baseline is not just a loose collection of settings. It is a versioned, known-good configuration that can be deployed consistently, reviewed periodically, and compared to live system state.

For most organizations, the Windows, Defender for Endpoint, and Edge baselines in Intune form the technical starting point. You should create named and versioned baseline profiles for in-scope devices and assign them to the relevant CUI device groups. Versioning matters. Assessors want to see that the baseline is controlled and evolves deliberately over time rather than existing as a one-time setup artifact.

At the same time, you need a corresponding compliance policy that verifies the baseline is actually being enforced. It is common to find well-built baseline profiles with no compliance enforcement behind them, which makes drift much harder to detect.

You also need inventories. Hardware inventory can be exported from Intune-managed devices, and software inventory can be built from discovered applications. These exports are useful, but they are not the whole control. You still need documented baseline content, an approved software list, and a review process that keeps the inventory aligned with what the organization actually authorizes.

# Connect to GCC High Graph
Connect-MgGraph -Environment USGov -Scopes "DeviceManagementManagedDevices.Read.All"

# Export hardware inventory
Get-MgDeviceManagementManagedDevice -All |
    Select-Object DeviceName, OperatingSystem, OsVersion, Model, Manufacturer,
        SerialNumber, ComplianceState, LastSyncDateTime, EnrolledDateTime |
    Export-Csv -Path "Hardware_Inventory.csv" -NoTypeInformation

# Export discovered applications
Get-MgDeviceManagementDetectedApp -All |
    Select-Object DisplayName, Version, DeviceCount, Platform |
    Export-Csv -Path "Software_Inventory.csv" -NoTypeInformation

The most common findings here are familiar. Baselines were created but never reviewed again. The written baseline does not match the actual Intune settings. Hardware and software inventories exist as exports but are not maintained as governed records. Version history is absent or vague.

3.4.2 Establish and enforce security configuration settings

CM.L2-3.4.2

This control is closely related to 3.4.1, but it is not the same thing. The baseline is the documented standard. Security configuration settings are the hardened values inside that baseline that actually enforce security expectations.

In GCC High, this usually means using Intune settings catalog profiles, security baselines, and compliance enforcement to apply recognized hardening standards such as CIS Benchmarks, DISA STIG guidance, or Microsoft’s security recommendations. The key is not just that settings exist, but that they are selected intentionally and tied to an external benchmark or internal configuration standard the organization can defend.

Typical examples include firewall enforcement across all profiles, restricting anonymous access, disabling insecure legacy behaviors, setting inactivity locks, enforcing BitLocker and Secure Boot, and managing browser and Microsoft 365 Apps security settings. If you cannot explain why a setting is configured the way it is, or what benchmark informed that decision, the implementation starts to look ad hoc.

This is also where managed updates matter. Leaving Microsoft 365 Apps on loosely controlled defaults creates avoidable inconsistency. In a controlled CUI environment, update channel selection and deployment timing should be part of the configuration standard, not an afterthought.

Conditional Access often becomes the practical enforcement layer for this control. Requiring a device to be marked compliant before it can access cloud resources is how many organizations turn configuration expectations into actual control.

The most common weaknesses here are settings that are deployed but not enforced, hardening decisions with no benchmark reference, and update management that was never brought under centralized control.

3.4.3 Track, review, approve or disapprove, and log changes to organizational systems

CM.L2-3.4.3

This control requires changes to be tracked, reviewed, approved or disapproved, and logged. In GCC High, that means combining technical audit logging with a real change management process.

Purview Unified Audit Log captures many administrative changes across Microsoft 365 workloads. Entra audit logs record directory, application, policy, and role changes. Intune has its own audit logging for profile, policy, app, and device management actions. Together, those logs create the technical record of what changed, when, and who made the change.

But that only covers the logging piece. A C3PAO will also want to see evidence that changes were reviewed and approved before implementation, that they were linked to a ticket or request, and that the resulting system state was verified afterward.

Connect-ExchangeOnline -ExchangeEnvironmentName O365USGovGCCHigh

# Verify Unified Audit Log ingestion
Get-AdminAuditLogConfig | Select-Object UnifiedAuditLogIngestionEnabled

# Export recent administrative changes
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
    -RecordType "AzureActiveDirectory" -Operations "Update user.", "Update policy." `
    -ResultSize 500 |
    Select-Object CreationDate, UserIds, Operations, AuditData |
    Export-Csv -Path "Admin_Changes_30Days.csv" -NoTypeInformation

For stronger implementations, Entra and Intune logs should also be routed into Azure Government retention and monitoring workflows rather than being left only in native short-term views.

This control usually breaks down when the environment has good logs but weak process. Changes are made directly in admin portals without documented approval. Tickets exist but are not tied to the actual change. Logs show that a change happened, but nobody can demonstrate prior review or post-change validation.

3.4.4 Analyze the security impact of changes prior to implementation

CM.L2-3.4.4

This is one of the clearest customer-owned controls in the family. Microsoft does not provide a built-in feature that performs a compliant security impact analysis for your GCC High tenant. Your organization has to establish that process itself.

A workable implementation means security impact analysis is required before relevant changes are approved. That includes changes to Conditional Access, Intune baselines, application deployments, identity settings, administrative role assignments, device restrictions, endpoint security policies, and anything else that could materially affect the CUI boundary or weaken control effectiveness.

At minimum, the analysis should identify the systems affected, the risks introduced, the NIST 800-171 controls potentially impacted, the rollback plan, and any compensating safeguards.

A standard template helps, but the quality of the completed analysis matters more than the existence of the form.

Microsoft tools can help with parts of the review. Secure Score can sometimes show posture shifts before and after a change. The Conditional Access What If tool can help model how identity policy changes will affect users. Intune policy conflict reporting can highlight collisions between settings. But those are supporting inputs, not substitutes for a formal impact analysis process.

This control usually fails for one of three reasons. There is no formal process at all. There is a process on paper but no completed examples. Or the security impact analysis exists separately from change approval and is not actually required before implementation.

3.4.5 Define, document, approve, and enforce access restrictions associated with changes

CM.L2-3.4.5

This control focuses on who is allowed to make changes and under what restrictions. In GCC High, this is largely a logical access problem, though any physical access restrictions tied to administrative workstations or privileged access paths should also be documented where relevant.

A strong implementation usually starts with Conditional Access policies that restrict access to Microsoft admin portals. Administrative roles that can modify the environment should not be able to sign in from unmanaged devices or arbitrary locations. Requiring phishing-resistant MFA, compliant devices, and approved access paths materially strengthens this control.

Privileged Identity Management is also one of the most defensible controls here. Standing administrative access is difficult to justify when eligible role assignment, activation justification, approval workflows, and short activation windows are available. If the people who can change the environment hold those permissions permanently, the organization has created unnecessary risk around this control family.

Intune RBAC and scope tags add another layer. They let you separate who can manage standard devices from who can manage CUI baselines and sensitive configuration profiles. Without that scoping, the organization often ends up with broad administrative roles that are hard to defend during an assessment.

Connect-MgGraph -Environment USGov -Scopes "RoleManagement.Read.All"

# Review active directory role assignments
Get-MgRoleManagementDirectoryRoleAssignment -All |
    ForEach-Object {
        $role = Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId
        [PSCustomObject]@{
            RoleDefinitionId = $_.RoleDefinitionId
            Role = $role.DisplayName
            PrincipalId = $_.PrincipalId
            DirectoryScopeId = $_.DirectoryScopeId
        }
    } | Export-Csv -Path "Role_Assignments.csv" -NoTypeInformation

Common findings here include too many permanently active admins, no Conditional Access restrictions on admin portals, and Intune roles that are effectively global even when the organization claims change authority is limited.

3.4.6 Employ the principle of least functionality

CM.L2-3.4.6

Least functionality is about intentionally limiting systems to only the capabilities they actually need. In GCC High, this applies at the tenant level, the endpoint level, and the application level.

At the tenant level, that means reviewing which Microsoft 365 services are truly needed inside the CUI environment and disabling optional services that are not required. In many environments, services like Sway, Bookings, unrestricted user app consent, or other broadly enabled capabilities remain on simply because nobody revisited the defaults.

At the endpoint level, least functionality usually means disabling unnecessary Windows features, protocols, and services through Intune configuration profiles. That includes removing or disabling capabilities that expand attack surface without supporting mission requirements.

At the application layer, it can mean deploying only the Microsoft 365 Apps components users actually need, controlling macros, and removing optional software that serves no approved business purpose.

The most important governance point is that “essential” needs to be defined. Assessors often ask organizations to explain why a capability is enabled. If there is no documented rationale for what is considered essential and why, the implementation looks reactive rather than controlled.

3.4.7 Restrict, disable, or prevent nonessential programs, functions, ports, protocols, and services

CM.L2-3.4.7

This control overlaps with 3.4.6, but it is more specific and more operational. Least functionality is the principle. This control is the practical enforcement of that principle against discrete programs, ports, services, and protocols.

In GCC High, this often means using Intune configuration profiles and endpoint security policies to restrict PowerShell behavior, disable deprecated protocols, block unnecessary services, enforce firewall defaults, and deploy Defender attack surface reduction rules that prevent risky process behavior.

ASR rules are especially important here. They are one of the highest-value technical controls in the Microsoft ecosystem for reducing unnecessary and dangerous execution paths. Office child process blocking, script abuse controls, credential theft prevention, and USB-originated execution restrictions are all highly relevant in CUI environments.

There is a practical deployment pattern that works well. Start in Audit mode long enough to understand impact, review the events, tune legitimate exceptions, and then move the rules to Block mode. The common failure is never making that final move. Audit mode is useful operationally, but it does not satisfy the control by itself when prevention is required.

Macro control also belongs here. If macros are broadly enabled in Office without restrictive policy, assessors will notice quickly.

Common issues include deprecated protocols left enabled, ASR rules never moved beyond Audit mode, unrestricted PowerShell, and no written list of what is considered essential versus prohibited.

3.4.8 Apply deny-by-exception or allow-by-exception software execution policy

CM.L2-3.4.8

This is one of the most technically demanding controls in the family. The requirement allows either a deny-by-exception blacklist or a deny-all, permit-by-exception whitelist. In practice, allow-by-exception is the stronger and more defensible option for CUI environments.

In the Microsoft ecosystem, Windows Defender Application Control is generally the preferred answer. WDAC provides stronger, lower-level application control than AppLocker and is much harder to bypass. For organizations that are not ready for WDAC, AppLocker can still support the control, but it needs to be designed carefully and enforced consistently.

The operational challenge is not just building the policy. It is tuning it, testing it, and moving it into actual enforcement mode. An application control policy that remains in Audit mode indefinitely does not satisfy the requirement. The policy also needs an administrative process behind it so that new software requests are reviewed, approved, and added in a controlled way.

# Example WDAC policy creation on a reference machine
New-CIPolicy -Level Publisher -Fallback Hash `
    -FilePath "C:\Policies\CMMC-BasePolicy.xml" `
    -UserPEs

ConvertFrom-CIPolicy -XmlFilePath "C:\Policies\CMMC-BasePolicy.xml" `
    -BinaryFilePath "C:\Policies\CMMC-BasePolicy.p7b"

This control often fails when organizations deploy application control only to part of the enclave, leave it in Audit mode, create overly broad rules that effectively allow everything, or maintain no practical process for approving and updating authorized software.

3.4.9 Control and monitor user-installed software

CM.L2-3.4.9

This control requires a policy, enforcement, and monitoring. If users can freely install software, the organization does not have Configuration Management under control no matter how strong the written baseline looks.

The strongest technical step here is removing local administrator rights from standard users. In most Windows environments, that alone eliminates a huge amount of uncontrolled software installation risk. From there, approved applications should be delivered centrally through Intune or another controlled mechanism, and discovered application inventories should be reviewed regularly against the approved software list.

If 3.4.8 is implemented well, a large part of 3.4.9 is already supported, but it is still not automatic. You need a written software installation policy, evidence that user installation is restricted, and proof that software inventory is actually being reviewed.

Connect-MgGraph -Environment USGov -Scopes "DeviceManagementManagedDevices.Read.All"

Get-MgDeviceManagementDetectedApp -All |
    Select-Object DisplayName, Version, DeviceCount, Platform |
    Sort-Object DeviceCount -Descending |
    Export-Csv -Path "All_Installed_Software.csv" -NoTypeInformation

This control most often fails when users retain local admin rights, software inventories are generated but never reviewed, or the organization cannot produce an approved software list that matches what is installed in the environment.

What evidence a C3PAO will usually want to see

For the CM family, evidence needs to show alignment between documented standards, deployed settings, and operating process.

That usually includes baseline configuration documents with version history, Intune exports for baseline and hardening profiles, compliance policies that verify required settings, hardware and software inventories, approved software lists, change management procedures, sample change records, completed security impact analyses, audit logs for recent configuration changes, administrative role assignment exports, PIM settings, Conditional Access restrictions for admin portals, and evidence that application control is in enforce mode rather than audit mode.

For least functionality and nonessential services controls, assessors usually want to see not just that settings were deployed but also how the organization decided what was essential. That means written rationale, exception handling, and records showing that exceptions are approved rather than informal.

The most common CM findings in real assessments

One of the most common weaknesses in this family is a baseline that looks complete in documentation but does not match the live environment. Organizations often have a written standard, but when an assessor compares that document to actual Intune settings or endpoint state, the differences become obvious. In many cases, the baseline was created during initial deployment and then never meaningfully reviewed again.

Application control is another frequent issue. Organizations may spend time piloting WDAC or AppLocker, collect useful audit data, and even build a reasonable authorized software list, but never move the policy into enforce mode. That leaves them with visibility into unauthorized execution attempts without actually preventing them, which is not enough to satisfy the control.

Administrative access around configuration changes is also often broader than the SSP suggests. Standing privileged roles, weak portal access restrictions, and insufficient scoping in Intune make it difficult to show that only approved personnel can modify the in-scope environment. This becomes especially visible when role assignments are reviewed against the organization’s documented change authority model.

Change management evidence is another recurring gap. Audit logs may clearly show that a policy, profile, or setting was changed, but there is no matching request, approval, or security impact analysis to support it. In other cases, the procedural artifacts exist, but they are so thin or inconsistent that they do not convincingly show that changes were reviewed before implementation.

Organizations also run into trouble when unnecessary functionality remains enabled simply because it was never revisited after onboarding devices into the enclave. Legacy protocols, unneeded services, permissive macro settings, and user software installation pathways often persist not because they were deliberately approved, but because nobody fully reconciled default configurations with the organization’s documented standard.

And finally, software control issues tend to compound. If users retain local administrator rights, if approved software lists are incomplete or outdated, or if discovered application inventories are exported but never meaningfully reviewed, the organization may have fragments of a control in place without a defensible end-to-end implementation.

How the CM family supports other control families

Configuration Management is tightly connected to the rest of the framework.

Access Control depends on CM because administrative roles, portal restrictions, and endpoint settings all shape who can do what in the environment. Audit and Accountability depends on CM because changes to logging, retention, and monitoring systems need to be controlled and reviewable. System and Information Integrity depends on CM because many protective technologies, including Defender and attack surface reduction, are only effective when configured deliberately and maintained over time. Identification and Authentication also intersects here because privileged change paths are much easier to defend when they rely on controlled identities, strong MFA, and just-in-time access.

That is why this family matters so much in practice. Configuration Management is not just about hardening settings. It is the operational proof that the environment is governed in a repeatable, defensible way.

Get started

Configuration Management is where your documented security program either becomes real or starts to unravel. Baselines, hardening profiles, change controls, admin restrictions, and application policies all need to point to the same conclusion: your GCC High environment is configured the way you say it is, and you can prove it.

Secureframe Defense connects directly to your GCC High environment and continuously monitors the configurations that support the CM family, including baseline enforcement for 3.4.1 and 3.4.2, application control coverage for 3.4.8, privileged role assignments tied to 3.4.5, and configuration drift across in-scope systems. When a C3PAO asks how you know your environment still matches the approved baseline, the goal is not to start collecting screenshots from five different portals. The goal is to already have that evidence organized and ready.

See how Secureframe Defense automates CMMC evidence collection by scheduling a demo with a product expert.