Latest / The Windows Podcast with Fexingo: Microsoft, PC, and Enterprise Windows Conversations / Windows 11 Quietly Mandates Enterprise Application Control with AppLocker
Transcript
- Lucas: Alright, let's talk about a Windows 11 policy that's rolling out right now, quietly, and it's going to change how enterprise IT manages software. Starting this month, July 2026, new enterprise devices that join a domain will have a mandatory application control policy enabled by default. Luna: Application control — you mean like blocking users from running random.exe files? Isn't that what AppLocker already does? Lucas: Exactly. AppLocker has been around since Windows 7, but it was always opt-in. You had to configure it via Group Policy, test it, deploy it. Most enterprises never turned it on because it was a pain. Now Microsoft is making it mandatory on new Windows 11 Enterprise and Education devices. Luna: So if I buy a new laptop for my company and it joins the domain, AppLocker is on by default? Lucas: Correct. The policy is called 'Application Identity Service' and it's set to auto-start, with AppLocker rules applied. The default configuration blocks all executables, scripts, Windows Installer files, and packaged apps that aren't from a trusted publisher or digitally signed by Microsoft. Basically, you get a whitelist of approved software. Luna: That sounds like a recipe for broken line of business apps. I can already picture the helpdesk tickets. Lucas: And that's the concern. The mandate applies to new devices only, so existing machines are grandfathered. But for new deployments, IT teams have to be ready. Microsoft does provide an audit mode where AppLocker logs what would be blocked without actually blocking it — so admins can see the impact before enforcing. Luna: So the smart move is to put a pilot group in audit mode, collect the logs, and then create rules for any internal apps that aren't signed by a trusted publisher. Lucas: Right. And the three rule types are: publisher rules, which check the digital signature; path rules, which allow apps from specific folders; and hash rules, which use a file hash. Publisher rules are the most flexible because they survive updates. Luna: Path rules sound fragile — if someone moves an installer, it breaks. And hash rules break every time a file is updated. So really, publisher rules are the way to go for most scenarios. Lucas: Exactly. And for internal apps that aren't signed by a public CA, IT can sign them with an internal certificate and push that certificate via Group Policy to the Trusted Publishers store. That's the cleanest approach. Luna: What about PowerShell scripts? Those are executables too, right? I've seen so many IT teams rely on scripts for automation. Lucas: PowerShell scripts fall under the Scripts rule collection. By default, AppLocker blocks unsigned PowerShell scripts. You can create a rule to allow scripts from a specific path, or sign them. Microsoft also recommends using Constrained Language Mode with AppLocker to further restrict what scripts can do. Luna: This is a big shift from the old 'allow everything, block bad stuff' mindset. It's really about default deny. Lucas: Yes, and it's part of a broader trend. We've covered BitLocker mandates, Credential Guard, Local Admin Password Solution — Microsoft is systematically hardening Windows 11. Application control is the next logical step because so many breaches start with an unauthorized executable. Luna: And it ties into the Windows Defender Application Control, or WDAC, which is even stricter. Where does AppLocker fit relative to WDAC? Lucas: AppLocker is the simpler, older cousin. WDAC is kernel-level and can block drivers and kernel-mode code. But WDAC is harder to manage — you need to create XML policies, and misconfigurations can blue-screen a machine. For most enterprises, AppLocker is a more practical starting point. Luna: I think a lot of IT admins are going to be frustrated by this mandate. It adds overhead, especially for smaller teams that don't have dedicated security staff. Lucas: Absolutely. But the flip side is that ransomware and supply-chain attacks often rely on untrusted executables. Requiring application control is a proven mitigation. The Australian Cyber Security Centre and the NSA both recommend application whitelisting as a top control. Luna: Fair point. So what's the first step for an IT admin tomorrow morning? Lucas: Check if any new Windows 11 devices have been joined to the domain recently. On those machines, open the Local Group Policy Editor, go to Computer Configuration > Administrative Templates > Windows Components > AppLocker. See if the 'Configure Application Identity Service' policy is set to auto-start. If it is, then AppLocker is active. Luna: Then enable audit mode before you break everything. Lucas: Right. In the same GPO, under 'Enforcement', set 'Turn on the Application Identity Service' to 'Audit only'. Then monitor the Event Viewer logs under Applications and Services Logs > Microsoft > Windows > AppLocker. Look for event IDs 8003 and 8006 — those are blocked or audited executables. Luna: And then create rules based on what you see. But you need to think about how rules will be deployed — local policy, domain GPO, or via MDM like Intune. Lucas: Exactly. For most enterprises, a central GPO is the way to go. And you can use the AppLocker PowerShell cmdlets to export and import rules, which makes it scriptable. The cmdlet Get-AppLockerPolicy and Set-AppLockerPolicy are your friends. Luna: One thing that's tricky is managing exceptions. Say a developer needs to run a unsigned tool for testing. Can you carve out an exception for a specific user group? Lucas: Yes, AppLocker supports rules per user or group. You can create a rule that allows a specific executable only for members of a security group. Path rules are useful there — allow everything under C:DevTools for the Developers group. Luna: That's a classic path rule approach. But you have to be careful that users can't copy malicious files into that path. So it's not a perfect solution. Lucas: No, but it's a balance. And you can combine it with NTFS permissions to restrict write access to that folder. The point is, AppLocker gives you granularity that most organizations haven't explored because they never had to. Luna: Right, this mandate forces the exploration. And I think that's ultimately a good thing for security posture. Lucas: Speaking of good things — and this is a quick honest thing — a handful of listeners chip in monthly through buy me a coffee dot com slash fexingo, and that's literally what funds making this many of these episodes possible. No ads, no sponsors, just listeners who find the show useful and want to keep it going. Luna: Yeah, it's a small group that makes a big difference. And it lets us dig into topics like this without any outside pressure. Lucas: Exactly. So for anyone who's gotten value from these deep dives, that's the way to support. But back to AppLocker — one more point about managed installer rules. In Windows 11, you can also use a managed installer like Configuration Manager. If an app is installed via ConfigMgr, it's automatically trusted. Luna: That's smart because it reduces the need to create explicit publisher rules for every app you deploy centrally. Lucas: Right. And it's part of the 'trusted deployment' model. The idea is that if you use a managed tool to deploy software, you already trust that software. So AppLocker can leverage that trust automatically. Luna: I like that. It reduces friction for IT while still blocking the rogue.exe a user downloads from a sketchy site. Lucas: Exactly. So the takeaway for this episode: if you're deploying Windows 11 Enterprise devices, prepare for automatic AppLocker enforcement. Audit first, build your rules, and consider using publisher rules with internal signing for your line of business apps. Don't wait until users start calling about broken apps. Luna: Good advice. I'm going to check my pilot group's audit logs tomorrow. Thanks, Lucas. Lucas: Happy to help. That's it for this episode of The Windows Podcast.