WDAC Managed Installers: The Game-Changer for Application Control

Kim & Tom
2 days ago
8 min read

How one feature transforms WDAC from impossible to practical

If you've ever tried to deploy Windows Defender Application Control (WDAC) in a real enterprise environment, you've probably hit the same wall everyone else does: the sheer impossibility of managing application allow rules at scale. You start with good intentions, catalog a few applications, and then reality hits. Before you know it, you're drowning in a sea of file hashes, certificate rules, and exceptions that seem to multiply faster than you can document them.

We've heard of countless security teams give up on application control after spending months cataloging their environment, only to realize they've barely scratched the surface. The problem isn't WDAC itself—it's one of the most powerful security controls available in Windows. The problem is two-fold, the traditional approach to implementing it, that uses a mix of file, path & cert based rules and the absence of easy operational practices.

That's where Managed Installers, combined with the security catalogs we previously mentioned, change everything. Well, not everything—but they do fundamentally shift the economics and feasibility of WDAC deployment in ways that make it actually achievable for most organizations.

The Traditional Application Control Nightmare

Let's talk about what application control looks like without Managed Installers. Imagine you're tasked with deploying WDAC across your organization. You have 100 applications that need to run. Sounds manageable, right?

Here's the reality:

Do the math: 100 applications × 500 files average = 50,000 policy entries you need to create and maintain.

The traditional workflow looks like this:

Install application in test environment
Enable WDAC in audit mode and run the application
Find all blocked files in event logs (hundreds of entries per application)
Create allow rules for each file (hash rules, certificate rules, path rules)
Test to ensure nothing breaks
Deploy updated policy to production
Repeat for every application
Application updates? Start over at step 3

This is why organizations say "application control is too hard." And honestly, they're right—if this is your approach.

The Paradigm Shift: Trust the Process, Not the Files

Managed Installers flip the entire model on its head. Instead of trusting individual files, you trust the process that installs them.

Think about it: In your organization, how do applications get onto endpoints?

Configuration Manager (ConfigMgr/SCCM)
Microsoft Intune
PDQ Deploy
Internal deployment tools
Package managers like Chocolatey

These are controlled, managed processes. Your IT team decides what gets deployed through these tools. So why not just trust everything those tools install?

That's exactly what Managed Installer does.

How the Math Changes with Managed Installer

Let's revisit that 100-application scenario:

The result: Dramatically reduced policy management overhead—potentially 80-90% less work for applications deployed through managed channels.

This assumes your applications are deployed through these managed channels and don't have characteristics that break the managed installer model (more on that later).

This isn't a silver bullet that eliminates all WDAC complexity, but it does remove the most impossible parts—the individual file-by-file policy work that makes traditional approaches unscalable.

How Managed Installer Actually Works

Now that you're (hopefully) convinced this sounds too good to be true, let's talk about how it actually works under the hood. Understanding the mechanism is crucial because it helps you recognize when and why things might not work as expected.

Managed Installer relies on three interconnected components:

Component 1: The AppLocker Policy

You define which processes are "managed installers" using an AppLocker policy. This seems odd at first—why AppLocker for a WDAC feature? Historical reasons. Microsoft built Managed Installer functionality on top of existing AppLocker infrastructure.

The AppLocker policy is a simple XML file that says: "These specific processes (like CCMExec.exe from ConfigMgr) are trusted installers."

Here's the key: You're not deploying AppLocker for application control. You're just using AppLocker's policy format to define which processes are managed installers. WDAC handles the actual enforcement.

Component 2: NTFS Extended Attributes

This is where the magic happens. When a process designated as a managed installer writes a file to disk, Windows automatically tags that file with an NTFS Extended Attribute called

$kernel.smartlocker.originclaim.

Extended Attributes are metadata stored in the NTFS Master File Table. They're:

Kernel-level: Only the Windows kernel can write them, not user processes
Persistent: They stick with the file (as long as it's not modified)
Invisible to most users: Standard file properties won't show them

You can view Extended Attributes using the fsutil command:

fsutil file queryea "C:\Program Files\MyApp\application.exe"

If you see $KERNEL.SMARTLOCKER.ORIGINCLAIM in the output, that file was installed by a managed installer and WDAC will trust it.

In the screenshot above you can see the $KERNEL.SMARTLOCKER.ORIGINCLAIM (yellow arrow) and if you look into the green highlighted box, you'll notice that it was CCMEXEC.EXE that wrote chrome.exe to disk as the managed installer.

Component 3: WDAC Policy with Rule Option 13

Finally, your WDAC policy needs to know that it should trust files with these Extended Attributes. That's what Rule Option 13 does.

When Rule Option 13 ("Enabled: Managed Installer") is set in your WDAC policy, WDAC checks for the Extended Attribute before blocking a file. If the Extended Attribute is present, the file is trusted—even if there's no explicit allow rule for it.

The Complete Flow

Let's walk through what happens when you install an application:

ConfigMgr (a defined managed installer) starts the installation process
The installer extracts files and writes them to disk
Windows kernel sees: "This write operation came from a managed installer process"
Kernel adds Extended Attribute ($kernel.smartlocker.originclaim) to each file
User tries to run the application
WDAC checks if the file is allowed
WDAC sees the Extended Attribute and trusts the file
Application runs successfully

All of this happens transparently. No user intervention, no manual policy updates, no catalog generation.

Process Trees and Trust Propagation

One crucial aspect of Managed Installers: trust flows down the process tree.

When you designate a process as a managed installer, not only are files written by that process trusted, but files written by any child processes it launches are also trusted.

For example:

CCMExec.exe (Managed Installer) 
└─> Application_Installer.exe (child process) 
	└─> Setup.exe (grandchild process) 
		└─> Writes application files 
			→ All get Extended Attributes

This is powerful because most installations are complex multi-step processes. The managed installer starts the process, but many child processes actually write the files. Trust propagation ensures all of those files get properly tagged.

However, this also means that if the process tree breaks (we'll cover troubleshooting in a later blog post), files won't get the Extended Attributes they need.

The Trust Hierarchy

It's important to understand where Managed Installer fits in WDAC's decision-making process. WDAC evaluates rules in this order:

Deny rules - Always processed first (nothing overrides a deny)
ESBCache - Performance optimization cache
Extended Attributes - Managed Installer and Intelligent Security Graph
Allow rules - Certificate signatures, hashes, file attributes
Blocked - If nothing matched, the file is blocked

This means:

A deny rule will block even files installed by managed installers
Extended Attributes are checked before your explicit allow rules
This makes Managed Installer very efficient (fast trust decisions)

Why This Makes WDAC Actually Deployable

Let's be honest: application control has historically been something organizations attempt and then abandon. The administrative overhead was simply unsustainable. Traditional WDAC deployments required either:

Months of cataloging work with dedicated staff
Accepting constant policy maintenance overhead
Living with frequent operational disruptions

Managed Installer changes the economics by eliminating the need to catalog every file of every managed application. Instead:

Initial configuration is measured in hours or days (not months)
Ongoing maintenance is minimal for applications deployed through managed channels
New applications and updates are automatically trusted when deployed properly

Does this mean WDAC deployment is now "easy"? No. But it does mean it's achievable for organizations with modern systems management infrastructure. The impossible parts—cataloging tens of thousands of individual files—are replaced with a manageable trust-the-process model.

That said, you'll still need to handle:

Applications not deployed through managed channels
The "backlog" of applications already installed before enabling MI
Applications with characteristics that break the MI model
Security considerations around what you're trusting

We'll cover these challenges in depth in our upcoming blog posts, but it's important to set realistic expectations upfront.

The Limitations You Need to Know

Managed Installer is powerful, but it's not magic. Understanding these limitations upfront is critical for planning a successful deployment:

1. Only Works After Deployment

This is the big one. Managed Installer only tags files that are installed after the managed installer policy is active. Applications already on your endpoints won't magically get Extended Attributes.

This is called "the backlog problem" and it's critical enough that we're dedicating our entire next blog post to solving it. For most organizations, this backlog represents hundreds of applications and tens of thousands of files that still need to be handled through traditional means.

2. Self-Updating Applications

If an application updates itself (not through your managed installer), those updated files won't have Extended Attributes. The original installation gets trusted, but self-updates break the trust.

Solutions exist (security catalogs, code signing), but this is a consideration for apps like Chrome, Firefox, or any LOB application with built-in update mechanisms. In practice, many common applications fall into this category, so you can't rely on MI alone.

3. Process Tree Breaks

When the installation process breaks the parent-child relationship (new parent process, scheduled tasks, or early exits), files won't get Extended Attributes even though they were "installed" by your managed installer. These scenarios are more common than you'd expect, and troubleshooting them requires understanding process trees and Windows internals.

4. Security Considerations

By trusting a process, you're implicitly trusting everything that process writes to disk. If your managed installer has vulnerabilities or can be manipulated to write arbitrary files, you've created a bypass. This is especially relevant for:

Managed installers with file browse capabilities
Processes that can be influenced by standard users
Scripts or tools with broad write permissions

We'll explore these security implications in a future post, but they're important to consider when designing your MI strategy.

5. MSIX/APPX on Windows 10

Packaged applications (MSIX/APPX) weren't supported by Managed Installer on Windows 10. This was fixed in Windows 11, but it's a consideration if you're still supporting Windows 10 endpoints.

Requirements and Prerequisites

To use Managed Installer, you need:

Operating System:

Windows 10 version 1709 or later (workstations)
Windows Server 2019 or later (servers)

Services:

Application Identity Service (AppIDSvc) running
AppLocker filter driver enabled

Configuration:

AppLocker policy defining managed installers
WDAC policy with Rule Option 13 enabled

Management Solution:

ConfigMgr, Intune, or another deployment tool to act as the managed installer

Most organizations already have these requirements met—you're likely running ConfigMgr or Intune already, and the Windows versions are standard in modern environments.

What's Next

We've covered why Managed Installer matters and how it works at a technical level. You should now understand:

The impossible economics of traditional application control
How Managed Installer flips the model to trust processes instead of files
The technical mechanism (AppLocker policy + Extended Attributes + WDAC Rule Option 13)
How process trees propagate trust
The limitations and edge cases where MI doesn't solve the problem

Managed Installer doesn't eliminate all WDAC complexity, but it does make WDAC deployment feasible by removing the most impossible part: cataloging every file. However, you'll still face challenges:

The backlog: What about applications already installed?
Edge cases: Applications that don't fit the MI model
Security concerns: What risks come with trusting processes?
Operational practices: How do you monitor and maintain this?

That's what we're covering in our next blog post: "The Managed Installer Backlog Problem (And How to Solve It)." We'll talk about why this is the critical blocker most organizations hit, the three approaches to solving it, and how AppControl.AI can help automate the solution.

Ready to learn how to handle the backlog challenge? Read our next post in this series: "The Managed Installer Backlog Problem (And How to Solve It)."

Have questions about Managed Installers? Reach out to us at info@appcontrol.ai