WDAC and Intune for CMMC Level 2 Application Control

A WDAC Intune rollout can lock down CUI endpoints, or block payroll at 8 a.m. The difference is rarely the tool. It is the policy design, the pilot ring, and the way I handle exceptions.

For defense contractors and the MSPs that support them, application control matters because CMMC Level 2 expects approved software only on in-scope systems. WDAC deployed through Intune can support that goal well, but it does not replace scoping, documentation, or assessor evidence. That practical line matters.

Where WDAC in Intune fits for CMMC Level 2

Microsoft now calls WDAC “App Control for Business” in current documentation and much of the Intune UI. Most admins still say WDAC. Either way, it supports CM.L2-3.4.8 by limiting which apps and scripts can run on Windows devices that handle CUI. Microsoft’s CMMC guidance makes the same point, configuration and operations still matter.

Intune fits well because the policy is centralized and device-scoped. I create it under Endpoint security > App Control for Business, assign it to device groups, and start in audit mode. Microsoft’s deployment guidance for Intune points admins toward an audit-first rollout, and I do the same.

I like WDAC because it sits lower in the stack than older allowlisting tools. It can control user-mode apps, scripts, and drivers with less room for local drift. Still, an assessor will also want scope, policy, training, change records, and exception handling.

I do not sell it as a compliance shortcut. I place it inside Endpoint Security, Device Hardening, Cybersecurity Services, and Business Continuity & Security. For MSPs handling Small Business IT, Cloud Infrastructure, Office 365 Migration, Data Center Technology, Restaurant POS Support, or Kitchen Technology Solutions, this control has to fit broader Tailored Technology Services, Innovative IT Solutions, Cloud Management, Infrastructure Optimization, Technology Consulting, Secure Cloud Architecture, IT Strategy for SMBs, Managed IT for Small Business, and the client’s Digital Transformation. That is how I work as a Business Technology Partner.

How I build the policy without breaking line-of-business apps

My default build is a lean base policy plus supplemental policies. In 2026, I start with Intune’s native App Control for Business profile for modern clients and use custom OMA-URI only for edge cases. The base trusts Windows, Microsoft-signed code, core business software, and software installed through Intune as a Managed Installer. That keeps the circle of trust tight and lets me add exceptions without rebuilding everything. Microsoft’s policy design guidance pushes the same lifecycle thinking.

Rule choice decides how much pain you feel at patch time.

Rule type	Best use	Tradeoff
FilePublisher or signer	Signed apps that update often	Depends on a stable signing chain
Path	Locked-down folders only	Risky if users can write there
Hash	Fixed binaries or short-term exceptions	Breaks on each update

In most environments, FilePublisher rules are the best balance.

Rule choice matters more than most teams expect. I prefer FilePublisher or signer rules for apps that update often. For unsigned LOB apps, I avoid path rules unless the folder is locked down and users cannot write there. If a vendor will not sign, I prefer internal signing or catalog signing. Hash rules work, but each update forces a policy edit. Microsoft’s rule reference is worth keeping open while I build.

I also split policy by device role. Engineering workstations, shared kiosks, admin laptops, and jump boxes rarely need the same trust model. Because WDAC is device-based, I assign policies to device groups only. I keep one pilot ring, one test-enforcement ring, and then production.

Move from audit to enforcement with clear safeguards

I never jump straight to block mode. First, I deploy audit-only to a pilot that reflects real work, VPN clients, remote support tools, browser updaters, CAD tools, and old line-of-business apps. Then I review CodeIntegrity Operational events on the endpoint and centralize them in Defender if that data path is available.

1. Start with 10 to 20 pilot devices that represent each Windows build and job role.
2. Fix audit hits, record business owners, and decide whether to sign, allow, repackage, or remove the app.
3. Move a small subset to enforcement, then confirm reboot, sign-in, VPN, printing, and core workflows.
4. Expand ring by ring, and retire older policies only after the replacement policy lands and the device reboots.

Remove the policy before you unenroll or reimage a device. If you skip that step, you can strand the endpoint.

Rollback is not optional. I keep an emergency exclusion group, tested admin access, and a known-good prior policy ready. For evidence, I save the policy files, Intune assignments, approvals, exception tickets, blocked-event samples, and validation notes. Microsoft’s deployment guide is strong here because it treats WDAC as an operating control, not a one-time task. As of 2026, that discipline matters even more because a bad policy can scale fast.

Final thoughts

WDAC in Intune gives me a solid way to support CMMC Level 2 application control on Windows endpoints. The win comes from a tight trust model, a slow move from audit to enforcement, and clean evidence.

When I treat it as part of everyday operations, not a one-time project, I reduce risk without freezing the business. That is the standard I want on every CUI system.