Setup/Configure App Control for Business In Intune

This is a comprehensive guide to setup/configure App Control for Business in Intune that covers the steps to plan, configure and troubleshoot application control policies on Windows devices. App Control for Business is the modern, cloud-managed evolution of Windows Defender Application Control (WDAC). It is designed to secure Windows devices by enforcing device-wide protection that prevents the execution of unapproved applications, DLLs, drivers, scripts, installers, and packaged apps.

By operating at the kernel level and applying strict allow-listing, it offers stronger security than legacy tools like AppLocker, making it far more effective at reducing the attack surface, blocking ransomware, and maintaining system integrity across the enterprise.

App Control for Business was in public preview for quite some time before Microsoft announced its general availability (GA) in August 2025. With GA, several important improvements were introduced, including the ability to assign the Managed Installer to specific groups instead of enforcing it across the entire tenant.

This change gives administrators more flexibility by allowing them to test the solution on a small set of devices before rolling it out broadly. For organizations operating in highly regulated environments, it also makes the approval process easier, since the potential impact is limited to the scoped group rather than the entire tenant.

In comparison with AppLocker, App Control for Business is a more robust application control solution that delivers stronger security and broader coverage. While AppLocker can restrict executables, scripts, and packaged apps at a user or group level, its enforcement is easier to bypass and does not extend to critical areas such as kernel-mode drivers. App Control for Business, on the other hand, applies protection device-wide, ensuring that no user context can weaken policy enforcement.

You can also block apps on macOS devices with Intune. I have written a comprehensive step-by-step guide that will help you create the required policies for this setup. Refer to the link for more details: How to Block Apps on macOS with Intune.

• Collect App Control for Business Event Logs.
• Create Policies with App Control Policy Wizard
• Remove Managed Installer For App Control for Business.

Related guides

Applocker vs. App Control for Business

While AppLocker and App Control for Business both provide application control, there are several key differences between them. One of the most important is that AppLocker is no longer being actively developed, whereas App Control for Business is Microsoft’s recommended solution and continues to receive new features and enhancements. For other differences, refer to the table below:

Category	AppLocker	App Control for Business
First released	Windows 7	Windows 10+ and Windows Server 2016+
New Feature Releases	No new features will be released, Only getting security fixes.	Actively developed with regular improvements.
Approach	Default allow, block only what you don’t want	Default deny, allow only if trusted
Management	Group Policy, AppLocker CSP	Intune (Application Control CSP), Configuration Manager, PowerShell, Group Policy (limited to single policy format).
Security classification	Helps restrict apps, but not serviced as a full security feature	Designed and serviced as a security feature
Enforcement scope	Per-user or per-group policies. Suitable when you need to apply different policies for different users or groups on shared computers.	Device-wide. Applies to all users on the device.
What it can control	EXE, MSI, scripts, DLLs, packaged apps	Executables, DLLs, drivers (kernel), scripts, MSIs, packaged apps, and can enforce PowerShell Constrained Language Mode.
Trust/rule types	Publisher, path, hash	Publisher, hash, catalog, signer allow-lists plus Managed Installer and reputation-based trust (ISG)
Cloud reputation	Not supported	Supports Intelligent Security Graph (ISG) reputation.
Managed installer	Not available	Available. Auto-trusts software deployed by a designated installer like Intune or ConfigMgr.
Multiple policies	Not supported	Supports multiple base and supplemental policies; newer builds allow more than 32 active policies.
OS / edition support	Available on Windows 10/11 and Windows Server; originally required Enterprise/Server editions. Operating system requirements.	Supported on Windows Pro, Enterprise, and Education editions. App control for business requirements.
Logging	AppLocker event logs (e.g., MSI/script)	CodeIntegrity Operational logs (e.g., 3076 audit, 3077 enforce)

Planning for App Control for Business

1. Start in audit mode: Always begin with audit mode to understand impact and collect events before moving to enforcement.
2. Monitoring phase: While in audit mode, gather a baseline of business-critical apps, updaters, and scripts by reviewing Event Viewer logs. Block events (Event ID 3077) are recorded in the Application and Services logs \Microsoft\Windows\CodeIntegrity\Operational log or in the Application and Services logs \Microsoft\Windows\AppLocker\MSI and Script Windows event logs.

Implementing App Control requires careful planning, time, and a well-defined strategy. It is not a one-time configuration but an ongoing process that involves continuous monitoring and refinement. As you deploy policies in audit mode, make it a priority to monitor events closely and record all applications that are being blocked across different devices. This helps create a comprehensive inventory of applications, updaters, and scripts in use within the environment.

Event data should be collected regularly from the CodeIntegrity and AppLocker logs in Event Viewer, as these provide critical insights into what is being blocked or flagged by the policy.

In addition to reviewing logs locally, set up a process to centralize and aggregate events from endpoints into a reporting solution such as Microsoft Defender for Endpoint, Intune reporting, or a SIEM system. This makes it easier to identify trends, detect false positives, and adjust your policies accordingly.

By following this structured approach, you can gradually refine your App Control policies, minimize disruption for end users, and ensure that only approved and trusted applications run within your organization.

About App Control Implementation in general

• Inventory of Applications: Create an inventory of applications which are in use in your organization. Continue to build the list by monitoring the events when App control is running in audit mode.

• Decide Policies and its structure: Starting with Windows 10, version 1903, multiple base and supplemental policies can be assigned to each device. Start with creating a simple base policy allowing managed installer, Microsoft publisher or any other third-party app which is used across all organization. You can add supplemental policies to allow specific apps/files for specific groups (Helpdesk, Finance, HR, IT etc.)

• Managed Installer: Managed installer can now be scoped to a group. Use pilot groups or test devices first; avoid applying tenant-wide policies until validated.

• Document Policies: Store and maintain all App Control policies in a central repository that is regularly backed up. For example, you can use SharePoint or GitHub to manage version control of the policies.

• Help Desk Support: Define clear processes and create support documentation for the help desk or the team responsible for managing App Control. This will help them troubleshoot application access issues.

• End user communication: Communicate with end users about what to expect and any potential impact of this change. Create a dedicated service request form for users to report issues related to app control events or to request approval for access to blocked applications.

• Decide on Intelligent Security Graph (ISG): Pre-plan whether you are going to utilize ISG. Enabling this allows a list of apps that are recognized by Microsoft Intelligent Security Graph (ISG) as having good reputation. For more information, refer to the link: App control with ISG.

• Rollback options: Always have a rollback plan ready in case anything goes wrong. Document rollback approach. Just to give you an idea on this, you can write steps for when to rollback from enforced to audit mode, how to whitelist a false positive or how to reduce helpdesk calls related to app control etc.

Below is an App Control for Business Workflow diagram which shows its various phases:

1. Planning stage – Define objectives and scope the pilot for Managed Installers.
2. Create a base policy in Audit mode – Deploy the initial policy configuration.
3. Collect and review events – Use Advanced Hunting or Event Viewer to analyze audit data.
4. Refine policies – Adjust the base policy and add supplemental policies until business apps are not blocked.
5. Switch to Enforcement mode – Move the policy from Audit to Enforced once validation is complete.
6. Post-enforcement phase – Continue monitoring and maintaining policies to ensure ongoing compatibility and security.

Base Policies vs. Supplemental Policies

Before understanding base and supplemental policies, first let’s understand the type of policy formats available in App control for Business.

• Single-policy format: This is the legacy single-policy format for older builds (a .p7b file, C:\Windows\System32\CodeIntegrity\SiPolicy.p7b, which replaces the entire policy and requires a reboot). This format is pre Windows 10, version 1903 and supports only one active policy at one time on the device. For newer OS versions, use Multiple-policy format.

• Multiple-policy format: This is the recommended approach for Windows 10, version 1903 and later, because it lets you load several base policies alongside targeted supplemental policies on the same device. Each policy is a compiled .cip named with its PolicyGUID and placed under C:\Windows\System32\CodeIntegrity\CiPolicies\Active\

Base Policies

Base policies are the foundational App Control rules that define which apps, code, scripts, and files are allowed or denied on target devices. It also defines policy enforcement mode (Audit or Enforced), Managed Installer, ISG trust and other policies which we will see later.

There must be at least one base policy deployed on the device which defines these settings. You can also create multiple base policies and assign it to the devices.

Supplemental Policies

A supplemental policy is an additional policy linked to a specific base policy that expands its allow list without overriding any of its restrictions. It is typically used to permit applications, drivers, or scripts that are blocked by the base policy but are required for business needs. Supplemental policies make it easier to fine-tune deployments, add exceptions, or roll out new app approvals without modifying or replacing the original base policy.

A supplemental policy can expand only one base policy, but multiple supplemental policies can expand the same base policy. Supplemental policies must be in XML format and must reference the Policy ID of their associated base policy.

Note

Prerequisites for App Control for Business

Following are the prerequisites for implementing App Control for Business via Intune.

• Microsoft Intune license (Included in Microsoft 365 E3/E5, Enterprise mobility + security (EMS) E3/E5, as a standalone license).
• Windows 10/11 Pro, Enterprise and Education editions. (Windows 10 will reach end of support in October 2025, so App Control for Business (ACfB) may no longer receive updates on that OS). Refer to this link for find more information: Windows edition and licensing requirements.
• Windows devices enrolled in Intune.
• Intune administrator role for creating and enabling Managed installer. To manage ACfB policies, a user/admin would require App control for business permissions which includes Delete, Read, Assign, Create, Update, and View Reports. Create a custom role in Intune.
• Microsoft Defender for Endpoint P2 – Only if you want to use Advanced hunting queries for discovering the applications while operating ACfB in Audit or enforced mode.

Step 1: Create Managed Installer Policy

In Intune, the Intune Management Extension (IME) can be configured as a Managed Installer. When this setting is enabled, all apps, scripts, and Win32 packages deployed through Intune using the IME are treated as trusted by App Control for Business. This reduces admin effort to manually allow application that are deployed via Intune.

Before August 2025, you could only create a Managed Installer policy which applied to the tenant level. This meant that, once enabled, Intune Management Extension (IME) would get designated as a Managed Installer across all Intune-managed devices. With the recent update, the policy can now be scoped to specific groups, allowing admins to test it on a small set of devices before rolling it out to production Windows endpoints.

• After IME is set as a managed installer, any app deployed via Intune will be get Managed installer tag assigned.

• In future if the Managed installer policy is removed or you set Enable Intune Managed Extension as Managed Installer to disabled for the devices, IME will not be removed as managed installer. Also the applications which were tagged with managed installer will not be untagged. You can manually clean it up using a PowerShell script.

• Any app deployed via Intune before you configured IME as managed installer will not get Managed installer tag and therefore are not automatically trusted and could be blocked by your base policy. Ensure that you proactively allow those apps explicity in the base or supplemental policy to avoid any issues.

To create a Managed installer policy, follow below steps:

• Sign in to the Intune admin center > Endpoint Security > App Control for Business > Managed Installer tab. Click + Create.
• Basics tab: Provide a name and description of the policy. For example: Managed Installer Policy.
• Settings: Use the toggle switch to Enable Intune Managed Extension as Managed Installer.

• Scope tags (optional): A scope tag in Intune is an RBAC label you add to resources (policies, apps, devices) to limit which admins can see and manage them. For more Information, read: How to use Scope tags in Intune.
• Assignments: Assign the policy to Entra security groups that contain the target devices. Managed installer policies only apply to device scope. For further guidance on assignment strategy, see Intune assignments: User groups vs. Device groups.
• Review: Review the deployment summary and click Save.

Sync Intune Policies

The device check-in process might not begin immediately. If you’re testing this policy on a test device, you can manually kickstart Intune sync from the device itself or remotely through the Intune admin center.

Alternatively, you can use PowerShell to force the Intune sync on Windows devices. Restarting the device is another way to trigger the Intune device check-in process.

Monitoring Managed Installer Deployment

• Sign in to the Intune admin center > Endpoint security > App Control for Business.
• Go to the Managed installer tab and click on the Managed installer policy.
• From the Overview page, find the status of the policy.

• You can also check the status of the Managed Installer under the Managed Installer tab to see whether the configuration to set IME as a Managed Installer succeeded or resulted in an error.

Step 2: Creating App Control for Business Policies

Start by creating a base policy that defines the core App Control settings. This includes configuring a Managed Installer, allowing Windows OS components, allowing Microsoft-signed apps, and enabling or disabling script enforcement etc. When the base policy is in Enforced mode, any app not explicitly allowed by the policy is blocked. In Audit mode, apps are allowed to run, and an event is logged in Event Viewer (Event ID 3076).

When you create an App Control for Business policy in Intune, you must choose the format for the configuration settings. You can either use an XML file or built-in controls. Built-in controls are easier to configure but offer limited customization. For more flexibility, you can use the App Control Policy Wizard.

I will demonstrate how to create a base policy using both built-in controls and App Control Policy Wizard. You can choose either method depending on your requirements.

Option 1: Creating App Control Policy using Built-in Controls

• Sign in to the Intune admin center > Endpoint Security > App Control for Business > Under Policies tab, click + Create.
• Basics tab: Provide a name and description of the policy. For example: ACfB – Base Policy.

• Configuration settings:
  • Policy creation type: Select Built-in controls
  • Audit mode: Use the toggle switch to enable or disable Audit mode. When you disable Audit mode setting, the policy will be enforced and any apps which are not allowed by this policy will be blocked.
  • Trust apps from managed installer: Set this to Enabled so that any apps deployed via Intune are automatically trusted and allowed to run on the device.
  • Trust apps with good reputation: Enable this if you want to also allow applications which are in the Microsoft’s Intelligent Security Graph (ISG) list. If you want tighter control and only allow users to run the apps deployed via Intune, then disable this option.

• Scope tags (optional): A scope tag in Intune is an RBAC label you add to resources (policies, apps, devices) to limit which admins can see and manage them. For more Information, read: How to use Scope tags in Intune.
• Assignments: Assign the policy to Entra security groups that contain devices. App control for business policies only apply to the device scope. As a best practice, pilot with a small set first; once validated, roll it out more broadly. For guidance on assignment strategy, see Intune assignments: User groups vs. Device groups.
• Review + create: Review the deployment summary and click Create.

Please note that if you create a Base policy using built-in controls then it will have one of the four possible Policy IDs. Its important to note this information because if you are creating a supplemental policy, you must supply the Policy ID of the base policy you are expanding.

Policy ID of base policy	Selected built-in control
{A8012CFC-D8AE-493C-B2EA-510F035F1250}	Enable app control policy to trust Windows components and Store apps
{D6D6C2D6-E8B6-4D8F-8223-14BE1DE562FF}	Enable app control policy to trust Windows components and Store apps And Trust apps with good reputation
{63D1178A-816A-4AB6-8ECD-127F2DF0CE47}	Enable app control policy to trust Windows components and Store apps And Trust apps from managed installers
{2DA0F72D-1688-4097-847D-C42C39E631BC}	Enable app control policy to trust Windows components and Store apps And Trust apps with good reputation And Trust apps from managed installers

Option 2: Creating App Control Policy using App Control Policy Wizard

Built-in controls options is quick and easy but lacks the flexibility in terms of adding or removing custom rules and creating an advanced version of the policy that meets business requirements. You can use App Control Policy Wizard to create base and supplemental policies.

When you use the App Control Policy Wizard, it generates both an .xml file and a .cip file. For Intune deployments, you need the XML policy file. Refer to my other post (Create Policies with App Control Policy Wizard) for the steps to create base and supplemental policies. Once your XML is ready, return to this post for for the steps to deploy the XML fil via Intune.

• Sign in to the Intune admin center > Endpoint Security > App Control for Business > Under Policies tab, click + Create.
• Basics tab: Provide a name and description of the policy. For example: ACfB – Base Policy.

• Configuration settings:
  • Policy creation type: Select XML upload (Default)
  • XML upload: Click on Browse and select your base policy XML file.
  • XML value: Preview the .xml file contents and click Next.

• Scope tags (optional): A scope tag in Intune is an RBAC label you add to resources (policies, apps, devices) to limit which admins can see and manage them. For more Information, read: How to use Scope tags in Intune.
• Assignments: Assign the policy to Entra security groups that contain devices. App control for business policies only apply to the device scope. As a best practice, pilot with a small set first; once validated, roll it out more broadly. For guidance on assignment strategy, see Intune assignments: User groups vs. Device groups.
• Review + create: Review the deployment summary and click Save.

Sync Intune Policies

The device check-in process might not begin immediately. If you’re testing this policy on a test device, you can manually kickstart Intune sync from the device itself or remotely through the Intune admin center.

Alternatively, you can use PowerShell to force the Intune sync on Windows devices. Restarting the device is another way to trigger the Intune device check-in process.

Monitoring Base Policy Deployment

• Sign in to the Intune admin center > Endpoint security > App Control for Business.
• Go to the Policies tab and click on the ACfB – Base Policy (or the name you have given to the base policy). At the top of the page, you’ll see a quick view of the Success, Failure, Conflict, Not Applicable, and In Progress status. Click on View report to access more detailed information.

Step 3: Collect App Control for Business Event Logs

When a base policy is deployed in Audit mode, App Control for Business records detailed logs in the Code Integrity Operational log. These events (3076) show exactly which applications, DLLs, or scripts would have been blocked if the policy were in Enforcement mode.

In Enforcement mode, you will see blocked enforcement events (3077) instead of 3076. These events indicate that applications were launched on the device, but were blocked by an active App Control policy.

These events will help you build an application inventory for all the apps which are in use in your organization. Based on this application inventory, you can create supplemental rules to allow these apps if required.

I have written a detailed guide on how to collect App control events using Event viewer, PowerShell and Advanced hunting. Refer to the link to know more: Collect App Control for Business Event Logs.

Step 4: End User Experience

If you are an administrator and want to check if the App control policy has been downloaded on the device, you can go to C:\Windows\System32\CodeIntegrity\CiPolicies\Active\ location and match the policy ID with the policy you deployed. Below screenshot highlights the policy location and the base policy .CIP file I deployed via Intune.

This highlighted base policy (CEC5CF54-57C7-45CD-9757-EED01DD2CADE) is in Enforcement mode. It allows only Microsoft-signed applications (excluding ISG apps) and trusts applications deployed through the Managed Installer. A few apps were deployed via Intune before the Intune Management Extension (IME) was configured as a Managed Installer on the device, so those applications are expected to be blocked from running. Let’s launch one of them to confirm this behavior.

If someone tries to launch an application that is not explicitly allowed by an App Control policy, a pop-up message will appear, as shown in the screenshot below.

Your organization used App Control for Business to block this app and then path of the application. Click on Close button to exit from this pop-up.

Using Multiple Base and Supplemental Policies

This is a supported scenario: you can deploy multiple base and supplemental policies to the same device. If you deploy a new base policy with a different PolicyID, Windows adds it alongside the existing policies. The old policy remains active until you explicitly remove it. If you update and redeploy a base policy using the same PolicyID, the new version replaces the old one.

You might, for example, have one base policy in Enforced mode on a device and then deploy a second base policy in Audit mode to test specific apps or settings. The Audit-mode policy records events in Event Viewer but does not block any applications. The Enforced-mode base policy continues to block any apps that are not allowed to run.

Multiple Base Policies (Intersection rule)

You might create multiple base policies for different needs: a standard policy for all users, a stricter policy for high-security systems, a policy for IT admins that allows a few additional tools, and another for lab environments.

When multiple base policies are applied to the same device, the intersection rule applies. All base policies must allow an app for it to run; otherwise the app is blocked. Think of it as an AND rule.

Example:

• Base Policy A allows Zoom.
• Base Policy B does not allow Zoom.
• Result: Zoom is blocked. It will run only if both Base Policy A and Base Policy B allow it.

Note: An explicit deny in any base policy always takes precedence and blocks the app.

Base Policy + Supplemental Policy (Union rule)

A supplemental policy only expands what a base policy allows. It cannot weaken or override base policy blocks. If a base policy explicitly denies an application, that deny has higher priority than any allow in a supplemental policy, so the app remains blocked even if the supplemental policy would allow it.

• If the base policy allows the file and the supplemental policy is silent, the file runs.
• If the base policy is silent and the supplemental policy allows the file, the file runs.
• If any base policy explicitly denies the file, the file is blocked, even if a supplemental policy allows it.
• With multiple base policies, an app must be allowed by all base policies. Any explicit deny in any base policy blocks execution.

Intune Management Extension (IME) as Managed Installer

In the previous sections, we discussed how to set the Intune Management Extension (IME) as a managed installer. Enabling IME as a managed installer and trusting it in the App Control for Business policy (by setting Trust apps from managed installer to Enabled) ensures that all applications deployed via Intune are tagged as originating from a managed installer. When you run any file on your device, app control will check managed installer origin information to decide on if the app should be allowed or denied execution.

This applies only to applications deployed after IME has been enabled as a managed installer. For applications deployed before IME was enabled as a trusted managed installer, you’ll need to identify those apps and create supplemental rules to allow them.

You can easily identify if a file is related to managed installer or not by querying the extended attributes of a file using fsutil command line utility. When you retrieve the extended attributes, look for the entry $KERNEL.SMARTLOCKER.ORIGINCLAIM, and then review the first row of data that begins with 0000.

I ran the following fsutil command against a FileZilla executable. Let’s review the output to determine whether it was created and managed by the managed installer. You can run below command against any executable. Replace the path with the file you want to check:

fsutil file queryEA "C:\Program Files\FileZilla FTP Client\filezilla.exe"

Understanding the Output

Every four sets form a group known as a ULONG (b1,b2,b3,b4...and so on)

0000:  [1] b1 b2 b3 b4   [2] b5 b6 b7 b8   [3] b9 b10 b11 b12   [4] b13 b14 b15 b16
           ULONG1              ULONG2             ULONG3               ULONG4

- After the label 0000: you will find 16 two-character sets, Every 4 sets form a group called ULONG.
- b5 is the first byte of the second ULONG.
- b9 is the first byte of the third ULONG.

Example layout:

0000:  01 00 00 00 00  00 00 00   00 00 00 00 01 00 00 00
0000:  b1 b2 b3 b4 b5  b6 b7 b8   b9 b10 b11 b12 b13 b14 b15 b16

Interpretation guide:

b5 = 00 means that this EA (extended attribute) belongs to the Managed Installer.
b9 = 00 means that the file was directly written by a managed installer process and will run if your App Control policy trusts managed installers.
if b9 = 02 it means that its a "child of child". The file was created later by something that the MI installed. It is not automatically trusted by MI and will need another allow rule (supplemental rule) to run.

Below is a screenshot of the output of fsutil.exe command to query the extended attribute of filezilla.exe.

I ran the fsutil command-line utility against another executable file that is not tagged by the managed installer. The extended attribute set on this executable is $KERNEL.PURGE.APPID.HASHINFO, and the first row of output differs from what we observed earlier. This confirms that the application executable is not tagged by the managed installer and could be blocked if App Control for Business policies do not explicitly allow it in the rules.

fsutil file queryEA "C:\Program Files\Foxit Software\Foxit PDF Reader\FoxitPDFReader.exe"

Another interesting example is an application where the extended attribute is set to $KERNEL.SMARTLOCKER.ORIGINCLAIM, but the first row’s fifth byte is 01. This indicates it isn’t associated with the managed installer. As a result, the file could be blocked if it isn’t explicitly trusted by your App Control for Business policies.

fsutil file queryEA "C:\Users\jatin.AzureAD\AppData\Local\Programs\RingCentral\RingCentral.exe"

• To confirm the managed installer on your device, you can navigate to %windir%\System32\AppLocker folder and check if AppCache.dat file is existing along with other *.Applocker files . This confirms that the applocker policy is correctly applied.

• Check Applocker effective policies for managed installer using below command. Run it on an elevated Powershell console.

Get-AppLockerPolicy -Effective -XML > C:\temp\AppLocker.xml

• Check if Applocker services are running. Run below command from elevated PowerShell console.

1. sc.exe query appidsvc

2. sc.exe query AppLockerFltr

General App Control for Business Troubleshooting

For troubleshooting issues related to App Control for Business, check the Event Viewer logs on the target device. Below is a quick summary (with Event IDs) of the steps you can take, and for complete details, refer to the guide: Collect App Control for Business Event Logs.

• Sign in to one of the target Windows device where you have deployed App control base policy.
• Open Event viewer > Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational. Right-click on it and click Filter Current log. Use below Event IDs to filter the Events.
  • 3076 – Audit event (application would have been blocked)
  • 3077 – Enforcement event (application blocked when in Enforcement mode)
  • 3089 – Signing information associated with a block/audit event
  • 3099 – Policy successfully loaded

• Check Event viewer > Applications and Services logs > Microsoft > Windows > AppLocker > MSI and Script for AppLocker logs related to MSI installer files and scripts. Below are some of the common event IDs.
  • 8004 – Script/MSI was blocked.
  • 8003 – Script/MSI was allowed.
  • 8007 – Script/MSI would have been blocked (Audit mode).
  • 8006 – Script/MSI would have been allowed (Audit mode).

Conclusion

In this post, we have learnt about App Control for Business implementation via Intune. This is the recommended approach when you want to implement App control security in your organization when compared with Applocker. Applocker is still supported with security fixes but no new features are being released for this service. You can also also use both Applocker and App control for business together as an application control solution.