One unsigned executable is all it takes to turn a hardened endpoint into an open door.
Modern Windows environments rely on layered defenses, but most of them still operate on a "detect and respond" model. App Control for Business, the evolution of Windows Defender Application Control, flips that logic. Instead of trying to recognize malicious code, it defines exactly what is allowed to run and blocks everything else by default.
Attackers thrive in the gap this leaves open when it is not enforced. Living-off-the-land binaries, renamed executables, and unsigned drivers routinely slip past signature-based tools because they never resemble known malware. They simply run.
The ConfigCIPolicy setting is how Windows enforces this model at the operating system level. When configured, it deploys a signed Code Integrity policy file to the device and restricts what can execute in both kernel mode and on the desktop, based strictly on that policy.
Deploying this control through Microsoft Intune matters because Code Integrity policies must be identical across the fleet to be effective. Manual copying of policy files invites drift, version mismatches, and silent gaps in enforcement.
The result is an environment where only trusted, signed code executes, consistently, on every managed endpoint.
Why This Policy Matters
Attackers do not need a zero-day when a device will happily execute anything placed on disk. Code Integrity enforcement closes exactly that gap by shifting from reactive detection to proactive allowlisting.
This is particularly relevant for organizations handling regulated data or high-value intellectual property, where a single unauthorized binary can be the difference between a contained incident and a full breach.
Without this policy:
- Unsigned or attacker-modified binaries can execute freely, with no baseline preventing them from running.
- Living-off-the-land binaries can be abused to launch malicious scripts, invisible to signature-based antivirus engines.
- Malicious or unsigned drivers can load into the kernel, giving attackers privileged, hard-to-remove persistence.
- Users can be tricked into running unauthorized or unlicensed software, silently expanding the attack surface.
With this setting enforced through Intune:
- Only binaries covered by trusted signatures or hashes in the deployed policy are permitted to execute.
- Kernel-mode integrity is enforced, blocking unsigned or unauthorized drivers before they load.
- LOLBin abuse is significantly reduced, since execution is scoped to what the policy explicitly allows.
- Every managed device runs the same version of the Code Integrity policy, eliminating configuration drift.
This configuration aligns with modern security principles such as defense in depth, endpoint hardening, proactive threat detection, and Zero Trust architecture.
Security Governance
Security governance ensures that hardening controls are consistently applied, monitored, and aligned with organizational standards.
Without centralized governance, settings such as this one can drift across devices, leaving blind spots that attackers can exploit.
Managing the Deploy App Control for Business setting through Microsoft Intune brings several governance benefits:
- Centralized enforcement of the control across all managed Windows endpoints
- Consistent configuration aligned with corporate security baselines
- Clear visibility into deployment status and configuration compliance
- Defined ownership and accountability through scope tags and role-based administration
- An auditable policy lifecycle from creation to enforcement and validation
This level of governance ensures that the control is handled in a controlled and transparent manner, reinforcing compliance with internal security policies and regulatory frameworks.
Windows CSP Overview
This section explains how the setting is exposed at the operating system level and how Microsoft Intune interacts with it. The configuration is powered by the Windows Policy Configuration Service Provider (CSP) framework, specifically the ADMX_DeviceGuard area.
| Scope | Editions | Applicable OS |
|---|---|---|
| ✅ Device ❌ User | ✅ Pro ✅ Enterprise ✅ Education ✅ IoT Enterprise / IoT Enterprise LTSC | ✅ Windows 10, version 2004 with KB5005101 [10.0.19041.1202] and later; Windows 10, version 20H2 with KB5005101 [10.0.19042.1202] and later; Windows 10, version 21H1 with KB5005101 [10.0.19043.1202] and later; Windows 11, version 21H2 [10.0.22000] and later |
Deploy App Control for Business.
This policy setting lets you deploy a Code Integrity Policy to a machine to control what's allowed to run on that machine.
If you deploy a Code Integrity Policy, Windows will restrict what can run in both kernel mode and on the Windows Desktop based on the policy. To enable this policy the machine must be rebooted.
The file path must be either a UNC path (for example, \ServerName\ShareName\SIPolicy.p7b), or a locally valid path (for example, C:\FolderName\SIPolicy.p7b). The local machine account (LOCAL SYSTEM) must have access permission to the policy file.
If using a signed and protected policy then disabling this policy setting doesn't remove the feature from the computer. Instead, you must either:
1. first update the policy to a non-protected policy and then disable the setting, or
2. disable the setting and then remove the policy from each computer, with a physically present user.
Description Framework Properties
This section defines how the configuration behaves at a technical level within the CSP framework.
| Property name | Property value |
|---|---|
| Format | chr (string) |
| Access Type | Add, Delete, Get, Replace |
Group Policy Mapping
For organizations operating in hybrid environments, this CSP setting maps to a corresponding Group Policy configuration.
| Name | Value |
|---|---|
| Name | ConfigCIPolicy |
| Friendly Name | Deploy App Control for Business |
| Location | Computer Configuration |
| Path | System > Device Guard |
| Registry Key Name | SOFTWARE\Policies\Microsoft\Windows\DeviceGuard |
| Registry Value Name | DeployConfigCIPolicy |
| ADMX File Name | DeviceGuard.admx |
Security Considerations
Before enabling this policy, administrators should understand how it behaves and plan for its impact.
- The referenced Code Integrity policy file must exist at the specified path and be properly signed; a missing or corrupted file can cause enforcement failures on the device.
- Deploying the policy directly in enforced mode, without first validating in audit mode, can block legitimate line-of-business applications and disrupt end-user workflows.
- The setting requires Windows 10 version 2004 with KB5005101 or later, or Windows 11 version 21H2 or later; older builds do not support this CSP.
- Removing a signed and protected policy is not immediate: it requires either replacing it with a non-protected version first, or physically removing it from each device.
A phased, pilot-first deployment is recommended to validate the behavior in a controlled group and avoid unexpected impact before rolling the setting out across production devices.
How to Configure Deploy App Control for Business Using Intune (Settings Catalog)
You can enforce this policy centrally using the Intune Settings Catalog, ensuring that only trusted, signed code is permitted to execute is applied consistently across all managed Windows devices.
To begin, sign in to the Microsoft Intune admin center and follow the steps below, as illustrated in the screenshots.
Create the Configuration Profile
In the Microsoft Intune admin center:
- Navigate to Devices › Windows › Configuration
- Select + Create policy
In the Create a profile pane:
- Platform: Windows 10 and later
- Profile type: Settings catalog
Click Create to continue.
At this stage, you have created the foundation of a Settings Catalog policy. In the next steps, you will search for and configure the setting that restricts execution to trusted, signed binaries defined in a Code Integrity policy.
Define Basic Profile Details
After clicking Create, the next step is to define the basic details of the configuration profile. This stage is essential for long-term management, clarity, and governance within Microsoft Intune, especially in environments with multiple endpoint hardening policies and security baselines.
Providing a clear Name and a concise but meaningful Description ensures that the purpose of the policy is immediately understood by administrators and security teams in the future. As shown in the screenshot, configure the fields as follows.
The Platform field is already pre-selected as Windows, so no changes are required. Once the name and description are defined, click Next to proceed to the configuration settings.
Configure the Setting Using the Settings Picker
With the profile basics defined, the next step is to configure the policy using the Settings picker, where you select the exact Windows setting you want to enforce. To open the Settings picker panel, click Add settings.
By default, this policy is not configured, meaning Windows applies no additional Code Integrity restrictions beyond the built-in kernel-mode signing requirements.
In the search field at the top of the Settings picker, type App Control, and then click Search to filter the results.
From the returned results, select the category Administrative Templates\System\Device Guard, and then choose the setting Deploy App Control for Business. Once selected, the setting is automatically added to the configuration profile. Back on the configuration page, change the value from its default state to C:\Windows\System32\CodeIntegrity\SIPolicy.p7b, the local path to the signed policy file previously staged on the device.
When enabled, Windows loads the referenced Code Integrity policy and restricts execution in both kernel mode and on the desktop to what that policy explicitly permits. This ensures that:
- Only binaries covered by the signed policy are allowed to run, in kernel mode and user mode alike.
- Attempts to execute unauthorized or unsigned code are blocked and generate visible enforcement events.
- The restriction persists across reboots, providing continuous, tamper-resistant enforcement.
This configuration aligns with modern endpoint hardening practices and supports Zero Trust security principles.
Configure Scope Tags (Optional)
Scope tags are used to control who can view and manage this policy within the Microsoft Intune admin center. They are particularly useful in environments with delegated administration, multiple IT teams, or regional management models.
As shown in the screenshot, the Default scope tag is selected. This is the standard and recommended configuration for most environments, as it ensures the policy is visible to all administrators who have access to Intune.
Optionally, custom scope tags can be assigned if you need to:
- Restrict policy visibility to specific IT roles or teams
- Enforce administrative separation of duties
- Support delegated or region-based Intune management
If no additional scope tags are required, keep the Default selection and click Next to continue.
Assignments – App Control for Business Enforcement
After configuring the policy settings, the next step is to assign the policy to the appropriate target group. Assignments define which devices will receive and enforce this configuration, ensuring the policy is applied in a controlled and intentional manner.
In the Assignments tab, click Add groups under Included groups and search for the group you want to target. This approach allows you to deploy the policy gradually, starting with test devices before expanding to production.
As shown in the screenshot, the policy is assigned to the following group: GRP – MS365Education – Test Computers.
Once the group is selected, verify the following:
- The group appears under Included groups
- The group status is Active
- No assignment filters are applied (unless explicitly required)
At this stage, no Excluded groups are configured, which is appropriate for controlled test deployments.
After confirming the assignment, click Next to proceed to the Review + Create step.
Review + Create – Final Validation
The Review + Create step is the final checkpoint before deploying the policy. This is where you validate that all configurations are correct and aligned with your intended endpoint hardening objective.
Pay special attention to the following items:
- Policy name and description: confirm that the policy clearly reflects its purpose, restricting execution to trusted, signed binaries only
- Configuration settings: verify that Deploy App Control for Business is set to C:\Windows\System32\CodeIntegrity\SIPolicy.p7b, under Device Guard
- Scope tags: ensure the correct scope tag is assigned. In this example, the Default scope tag is used
- Assignments: confirm the policy is assigned to the intended group, GRP – MS365Education – Test Computers, and that no unintended exclusions are configured
Once everything has been validated, click Create to finalize and deploy the policy to the assigned devices.
Monitor Policy Deployment Status
After creating and assigning the WIN – Endpoint Hardening – App Control for Business configuration profile, the next step is to verify its deployment status. This validation confirms that the policy has been successfully applied and that only trusted, signed applications and drivers are permitted to run on the targeted devices.
Although Microsoft Intune can take up to 8 hours to automatically deliver configuration profiles, deployment often occurs much faster. If needed, you can accelerate the process by:
- Triggering a manual device sync from the Company Portal
- Initiating a sync directly from the Microsoft Intune admin center
Intune provides clear indicators to evaluate the policy deployment status: Succeeded (devices have applied the policy), In progress (devices are still processing), Error (the policy failed and requires investigation), and Not applicable (the device does not support the configuration).
When devices report Succeeded, it confirms that the Code Integrity policy is loaded and actively enforced, ensuring that unauthorized code cannot execute on the endpoint even if it bypasses antivirus detection.
Client-Side Verification via Event Viewer
After the device has synced with Intune, you can perform a client-side verification to confirm that the policy was successfully applied. Windows records Intune policy processing events locally, allowing administrators to confirm policy enforcement without relying only on the Intune portal.
- Open Event Viewer on the target device
- Navigate to Applications and Services Logs › Microsoft › Windows › DeviceManagement-Enterprise-Diagnostics-Provider › Admin
- Select Filter Current Log
- Look for Event ID 813 or Event ID 814, which indicate successful processing of Intune configuration policies
- Open the event details and confirm that the ADMX_DeviceGuard setting was applied
For deeper validation, you can confirm the effective setting directly on the device. Open PowerShell as Administrator and inspect the Microsoft-Windows-CodeIntegrity/Operational event log for Event ID 3076 (audit mode block) or Event ID 3089 (signature information), and confirm that a .cip policy file matching the deployed policy is present under C:\Windows\System32\CodeIntegrity\CIPolicies\Active.
Remember that switching from audit mode to enforced mode requires a policy update and a device reboot; plan a maintenance window and validate application compatibility before flipping the policy to enforcement.
Why This Matters for Endpoint Security
Application allowlisting is one of the strongest defenses available in modern endpoint security, because it does not depend on recognizing what is malicious. It simply defines what is allowed, and blocks everything else.
Without it, defenses depend entirely on detecting known bad patterns, leaving zero-day payloads, fileless attacks, and abused system tools free to execute undetected.
By enforcing Deploy App Control for Business through Microsoft Intune and validating the configuration locally, organizations ensure that:
- Malware and unauthorized tools cannot execute, even when delivered through phishing or removable media.
- Kernel-mode threats, including malicious drivers, are blocked before they can load and establish persistence.
- Security teams gain a verifiable, centrally managed record of exactly what is permitted to run across the fleet.
- The organization moves closer to a true Zero Trust execution model, where trust in code is explicit rather than assumed.
This configuration provides strong security value without disrupting standard user workflows when properly validated and deployed.
Key Takeaway
Trust in code execution must be explicit, never assumed.
Enforcing Deploy App Control for Business through Microsoft Intune guarantees that every managed endpoint runs the same signed Code Integrity policy, without manual intervention on each device.
Combined with centralized deployment and client-side validation, the organization gains a verifiable, auditable allowlisting layer across the entire Windows estate.
And in modern security architecture, application allowlisting is not optional, it is essential.
More Information
For additional technical details, refer to the official Microsoft documentation below:
- https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-deviceguard#configcipolicy
- https://learn.microsoft.com/en-us/mem/intune/configuration/settings-catalog
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profiles
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-monitor
- https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot
Thank you for reading!
🖥️ Ricardo Barbosa
🏆️ Microsoft MVP | 📘 Microsoft Certified Trainer (MCT)
☁️ Intune & Cloud Architect | 💼 Technology Director at Altelix.com
💬 Follow me for more Windows endpoint hardening and Intune content.