Managed installer is not a convenience flag. It is a trust channel

Managed installer is what makes App Control practical at scale. Without it, a large application can mean rules for every binary, library and component it ships, and the policy becomes something nobody maintains.

It is also the one place in an App Control design where trust can be manufactured rather than granted, and that part gets far less attention than it should.

What you are actually trusting #

Designating a managed installer does not trust a program. It trusts an origin.

Windows watches the designated process, and the processes that process launches, and tags the files they write to disk as having come from a managed installer. The policy then permits those files because of where they came from, not because of anything about the files themselves.

Read that again with an adversary in mind. You are trusting everything that process and its children can write.

That is the right model when the process is a governed deployment channel. It is a very different proposition when the process is an application's own updater.

Microsoft's own caveat is stronger than most people realise #

This is not an inference. Microsoft states that managed installer is heuristic based and does not provide the same security guarantees as explicit allow and deny rules, and that users with administrator privileges, or malware running as an administrator, may be able to circumvent the intent of a policy where managed installer is allowed.

A feature the vendor describes as heuristic should not be carrying the same weight in your design as a rule that names a signer.

Worth knowing too that the identification half of this runs on AppLocker even though App Control does the enforcing, which is the single most common surprise in a deployment. AppLocker and App Control covers that dependency, and Intune deployed and still blocked covers what it looks like when a piece of it is missing.

The question it quietly changes #

Application control asks whether a file is trusted. Managed installer adds a second question underneath it.

Can a trusted installer be persuaded to create a trusted file?

An attacker who can influence a designated process does not have to defeat App Control at all. They do not need a signing certificate, a policy change or administrative access to your management platform. They need the trusted installer to write something on their behalf, and the origin tag does the rest.

That is the risk in one sentence. A badly chosen managed installer is a bridge between untrusted input and trusted execution.

Why updaters are usually the wrong candidate #

The reasoning that leads here is entirely understandable. An application will not sit still, its updater is what keeps it current, so make the updater a managed installer and the problem disappears.

The trouble is that application updaters are built for convenience, not as enterprise trust boundaries. Across the ones you will meet, some run in user context. Some accept command line arguments. Some read update content from writable paths. Some launch child processes. Some fetch packages from vendor controlled locations. Some load plug ins, scripts or helper files.

Each of those is a way for something other than the vendor to influence what gets written, and once written, the file carries an origin your policy honours.

A separate argument applies to how many of these you end up with, and it is covered in an application that updates itself. This one is about whether a given candidate belongs at all, and that is a question about the channel rather than the count.

Questions to put to any candidate #

Before a process is designated, it is worth answering these honestly.

• Can a standard user start it, or influence when it runs?
• Can a standard user influence what it writes, or where?
• Does it launch child processes?
• Can it write executables, libraries, scripts or installers?
• Does it accept paths or arguments from outside?
• Does it read packages from a location somebody could write to?
• Does it download content from outside your control?
• Is there already a deployment path that could carry this instead?

Uncertainty on any of these is an answer. A trust channel you cannot describe precisely is not one you should be designating.

The model that holds up #

Keep the trust channel narrow and make it the one you already govern.

Your deployment platform is the managed installer. Microsoft names Intune and Configuration Manager as the intended examples, and the reason is not brand preference. Those are channels where the package source, the approval, the deployment scope and the update lifecycle are all things somebody owns.

Turn off application self update where you can, so releases arrive by the route you chose rather than the route the vendor chose.

Then make that route fast, because the reason self update gets tolerated is a real one. Falling behind on patches is its own risk, and no security team wins the argument by being slower.

That last point is where these two pressures usually collide, and it is the collision worth designing for rather than choosing a side in.

Where PoliEze fits #

Speed is what makes the narrow model sustainable. PoliEze Flow exists so releases can be picked up, approved and delivered through the deployment channel you already trust, quickly enough that nobody needs to argue for letting applications update themselves.

The result is the trade most estates assume they cannot have. Software stays current, and managed installer trust stays with one governed channel instead of spreading to every updater that asked.

Sources #

• Allow apps installed by a managed installer, Microsoft
• App Control for Business design guide, Microsoft