AppLocker and App Control, and why you probably need both

Teams reach for one of these expecting to choose. The question is usually posed as AppLocker or App Control, and it has no good answer, because they are not the same kind of thing.

One is a security boundary. The other is a management control. Most enterprise designs end up running both, and one of them is not optional if you want managed installer to work at all.

Where each one actually enforces #

This is the difference everything else follows from.

App Control for Business enforces in the kernel, through code integrity. The policy is evaluated as code is about to run, below the level at which a user or a local administrator operates. Turning it off means changing the policy through the management channel that deployed it, or in the case of a signed policy, means physical access. That is what makes it a control you can present to an assessor.

AppLocker enforces in user mode, through the Application Identity service. Rules are evaluated by a service running on the device, and they can be scoped per user or per group, which App Control cannot do. If that service is not running, the rules are not applied.

That distinction is not a criticism of AppLocker. It is what makes AppLocker useful for the things it is good at, and it is why it is the wrong tool for the thing App Control is for.

The part that catches everyone #

Managed installer is the mechanism that makes App Control practical at scale. It lets you nominate a deployment tool, so software that tool installs is trusted without a rule per application.

Managed installer identifies that tool using an AppLocker rule collection.

App Control does the enforcing. AppLocker does the identifying. They are two components and you configure both, even though the outcome is an App Control policy behaving differently.

This is the single most common surprise in an App Control deployment, and it produces a specific failure that looks impossible: you deployed the application through Intune, App Control blocked it anyway, and nothing in your App Control policy looks wrong. It usually is not wrong. The AppLocker half is missing, or the Application Identity service is not running on the device.

Intune deployed and still blocked covers the four things that all have to be true, and how to confirm which one you are missing.

What each is good at #

App Control is the right answer when the requirement is enforcement. It survives a local administrator, it covers the whole device rather than a user, and it can be signed so that even the policy itself cannot be replaced. When a framework asks you to restrict which executables, libraries and scripts can run, this is the control that answers it.

AppLocker is the right answer when the requirement is scoping or reversibility. Different rules for different groups of users on the same device is something App Control does not do. Being able to lift a restriction quickly, while a programme is still finding its shape, is easier with a control that is not enforced in the kernel.

There is also a plain practical case: an estate with an existing AppLocker deployment that works has something worth keeping while App Control is being introduced ring by ring, rather than a thing to rip out first.

Running both #

They evaluate independently. A file has to satisfy both to run, so the effective policy is the stricter of the two at every point.

Two consequences worth planning for.

A block can come from either, and the evidence is in different places. App Control decisions appear in the CodeIntegrity log, AppLocker decisions in its own. A troubleshooting process that only reads one of them will eventually spend a day on a block it cannot see. App Control event IDs covers the CodeIntegrity side.

Two policies means two review cycles. If nobody owns keeping them consistent, they drift, and the drift shows up as a block nobody can attribute. That is an operating cost rather than a technical problem, and it is the reason to be deliberate about which control carries which job rather than letting both grow.

What to decide before you build anything #

Three questions, in this order.

Which control is your security boundary? If the answer is anything other than App Control, be clear about why, because a control a local administrator can stop is not a boundary.

Do you need per user scoping? If yes, AppLocker has a job that App Control cannot take. If no, running both costs you a maintenance stream for nothing.

Who owns each policy? Two controls with one owner drift more slowly than two controls with two owners and no agreement between them.

Where PoliEze fits #

PoliEze governs the App Control side, and part of that is keeping the managed installer relationship visible rather than implicit. Every acting installer sits in one approved list with an approval in front of anything joining it, so the AppLocker dependency underneath managed installer is something you can see and review rather than something that surfaces as an unexplained block months later. The platform sets out where that sits in the sequence.