Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Quietly Mandates Enterprise App Control Policies
Transcript
- Lucas: Luna, I want to talk about something that's been landing in enterprise IT admin inboxes over the past few weeks. It's not a flashy security headline — it's a quiet mandate buried inside the Windows 11 24H2 feature update. Luna: I've seen the memos. App Control for Business is no longer optional for certain licensing tiers, right? Lucas: Exactly. Microsoft has been nudging enterprises toward Windows Defender Application Control, or WDAC, since Windows 10. But with 24H2, they've flipped a switch. For devices running Windows 11 Enterprise or Education editions, a baseline WDAC policy is now enforced by default at initial boot. Luna: So if you're deploying fresh images — say from Microsoft Endpoint Manager or a standard provisioning package — that policy is already there, blocking unsigned executables and scripts. Lucas: Correct. And the key detail is that it's not just a recommended baseline anymore. Microsoft's security baseline for 24H2 includes a specific policy GUID — I've got it here: {1284E6C2-2E1C-4F6C-B3E4-9F8E4B5C6D7E}. That policy is labeled 'Microsoft Recommended Block Rules'. It blocks things like VBA macros from Office, unsigned PowerShell scripts, and even some legacy installer executables. Luna: That's a big deal for shops that still rely on a handful of old line of business apps signed with expired certificates, or no certificate at all. Lucas: Huge deal. And Microsoft's rollout isn't one-and-done. They've published a phased timeline. From June 2026 — which is now — new Enterprise devices receive the policy enforced. Starting in Q4 2026, existing devices that upgrade to 24H2 will also get it automatically unless IT has explicitly disabled it via a custom policy. Luna: So there's a window for IT to audit their app inventory and sign their internal tools, or configure file path rules as exceptions. Lucas: Exactly. And the recommended approach from Microsoft is actually not to disable WDAC entirely — that weakens your security posture. Instead, they want you to create a supplemental policy that allows your specific internal apps. That supplemental policy can be signed by your own internal certificate authority, or you can use file publisher rules. Luna: But here's the thing that a lot of smaller IT teams might miss: if you have an app that was signed with a SHA-1 certificate — very common for software developed before 2016 — WDAC's default block rules will reject it. SHA-1 signatures are on the block list. Lucas: Right. And the block list also covers any binary that's unsigned, any script that's not signed by a trusted publisher, and any MSI that uses a custom action without a signature. So the classic scenario of an internal developer building a small utility and distributing it via a network share — that tool just stops working. Luna: I've talked to a couple of IT admins at mid-size firms. One told me his team spent three weeks just cataloging every executable and script that runs across their fleet. They found over 400 unsigned tools, most of them internally developed. Lucas: Three weeks sounds about right for a company with maybe five thousand endpoints. And that's the hidden cost of this mandate — the audit and remediation work. Microsoft provides tools like the WDAC wizard and the PowerShell cmdlets to help generate a baseline policy from an existing reference machine, but you still have to test. Luna: And testing is where things get tricky. If you deploy a policy that blocks a critical app used by finance during close, you've got a production incident on your hands. Lucas: Precisely. That's why Microsoft recommends a phased audit mode first. You deploy the policy in audit mode — where violations are logged but not blocked — then review the event logs under Event Viewer > Applications and Services > Microsoft > Windows > CodeIntegrity > Operational. You collect those logs, identify the blocked files, add allowed rules, and only then switch to enforced mode. Luna: And the clock is ticking for enterprises on older Windows 10 builds that will eventually upgrade. The policy applies when they cross into 24H2. Lucas: Yes. And one more nuance: this mandate is tied to the device's license. If you're running Windows 11 Pro, you don't get the enforced default. But if you're on Enterprise or Education — which most organizations in our audience are — you're affected. Luna: So if you're an IT admin listening, what's your first step today? Lucas: First, check if any of your devices are already running 24H2. You can run 'Get-CimInstance -Namespace root/Microsoft/Windows/DeviceGuard -ClassName Win32_DeviceGuard' in PowerShell to see if WDAC is enabled. If it's in audit mode, start collecting logs. If it's enforced and you haven't prepared, you may already be seeing help desk tickets. Luna: Second step: inventory your unsigned or SHA-1 signed executables, scripts, and MSIs. Use the WDAC wizard or the 'New-CIPolicy' cmdlet to generate a policy from a clean reference system. Lucas: And third, think about a long-term strategy. Sign your internal tools. Even a self-signed certificate from your internal PKI will work if you distribute the root certificate via Group Policy or Intune. That way you're not relying on file path exceptions, which are less secure. Luna: Speaking of security, I want to come back to something you mentioned earlier about the policy being called 'Microsoft Recommended Block Rules'. It doesn't just block scripts and macros — it also blocks some kernel drivers and boot components that aren't signed properly, right? Lucas: Yes. The block list includes a set of known vulnerable drivers — the ones Microsoft has been tracking through the driver block list update via Windows Update. So if you've got an old printer driver or a VPN adapter that hasn't been updated in years, it might not load at all after the policy takes effect. Luna: That's another audit item. Check all your kernel-mode drivers against Microsoft's block list. Lucas: And this is where I think the friction really shows. A lot of IT teams have been running the same image for years, adding apps layer by layer. This mandate forces a clean-slate approach to application trust. Luna: It's a shift from 'allow by default' to 'deny by default'. And honestly, it's been a long time coming from a security standpoint. But the execution timeline is tight. Lucas: Speaking of execution, this is exactly the kind of practical deep dive we love to bring you, and it's only possible because we keep this show ad-free and independent. If these episodes save you an hour of research or one production outage, that's the goal. And if you want to help keep it going, you can support the show at buy me a coffee dot com slash fexingo. It's a small gesture that goes a long way to covering hosting and research costs. No pressure, just an option if you find value here. Luna: Yeah, completely agree. A lot of listeners have told us these deep dives help them plan their IT roadmaps, and that feedback means a lot. Lucas: Alright, back to the mandate. One more important detail: the policy is enforced via Windows Update as a security intelligence update. So even if you've locked down your endpoints with strict WSUS or Intune update rings, Microsoft is pushing this as a critical update for 24H2. You can't opt out without actively modifying the Windows Defender configuration. Luna: So admins need to be aware that if they haven't created a custom WDAC policy, the default enforced policy will apply on first boot after the 24H2 feature update installs. Lucas: Correct. And the default policy is not permissive — it blocks everything that isn't explicitly allowed by Microsoft's own signed components or by the Windows Store. So any line of business app installed via a traditional MSI or a script — unless it's signed by Microsoft or the Store — will fail. Luna: That's why I think the biggest takeaway for IT teams today is: start your audit now. Don't wait for the Q4 enforcement wave. Lucas: Absolutely. And if you've already deployed 24H2 in a pilot, check your CodeIntegrity event logs immediately. You might be surprised at what's being blocked silently. Luna: We'll link to the official Microsoft documentation and the WDAC wizard download in the show notes. In the meantime, keep your endpoints signed and your policies tested. Lucas: Next episode, we'll look at what this means for third-party security software that used to install kernel drivers. Spoiler: a lot of endpoint detection and response agents are going to need updates too. Luna: Looking forward to that. Thanks for listening, everyone.