Base and supplemental App Control policies, and how they really combine

The most expensive misunderstanding in App Control policy design is thinking a supplemental policy is a smaller version of a base policy. It is not. It can do one thing, and knowing exactly what that thing is changes how you structure delegation across an organisation.

Supplementals expand, they never narrow #

A supplemental policy adds allow rules to the base policy it is attached to. That is the entire capability.

It cannot remove an allow rule from the base. It cannot add a deny rule that takes effect. It cannot narrow anything, for its own devices or anyone else's.

The failure mode is what makes this worth writing down. A deny rule written into a supplemental is not rejected when you deploy it. There is no error. The policy applies, the deny rule is simply ignored, and you now have a policy that reads as though it blocks something and does not. Somebody will read that XML in six months and believe it.

If you need to block something, the rule goes in a base policy.

To allow supplementals at all, the base has to set option 17 Enabled:Allow Supplemental Policies, which requires Windows 10 version 1903 and later, or Windows Server 2022 and later.

The precedence order, exactly #

Microsoft documents the order the App Control engine applies when evaluating a file against the active set of policies. Once a file matches, processing stops.

1. Any file matching an explicit deny rule is blocked, even if other rules try to allow it.
2. Any file matching an explicit allow rule runs.
3. Any file with a managed installer or Intelligent Security Graph extended attribute runs, if the policy enables the matching option.
4. Any file not allowed by the above is checked for reputation using the ISG, when that option is enabled. It runs if the ISG decides it is safe, and a new ISG extended attribute is written on the file.
5. Anything left is blocked implicitly.

Two things fall out of step 1 that matter more than they look.

A deny beats everything. Not just allow rules in the same policy. Allow rules in supplementals too. This is the mechanism that makes delegation safe: a business unit can be handed a supplemental and cannot use it to undo a central deny.

It is also the mechanism that catches people. You cannot block a binary centrally and then hand a team a supplemental that gives it back. It stays blocked. If one group has a legitimate need for something the rest of the fleet should never run, the difference has to be in the base policy assigned to those devices, not in an exception layered on top.

Use the most specific deny you can. Microsoft's guidance on step 1 is to "use the most specific rule level practical when creating deny rules to avoid blocking more than you intend". A deny at certificate authority level will take out far more than the one product you were thinking about, and because deny wins, nothing you add later will bring any of it back.

More than one base policy is an intersection #

When a device has multiple base policies applied, a file has to be allowed by all of them.

That is a useful property and a confusing one. Useful, because you can layer an organisation wide baseline with a stricter policy for a particular device group and get the stricter result automatically. Confusing, because a block then has no single policy that explains it. Each policy looks reasonable in isolation and the effective result is the overlap.

This is the origin of the block nobody can account for. Someone reads the policy they own, confirms the file is allowed in it, and concludes App Control is broken. The file is being refused by a policy they did not know was applied. Event 3099 tells you which policies are actually loaded on the device, and it is the first thing to check.

Microsoft's own recommendation for keeping this tractable: "maintain separate ALLOW and DENY policies on Windows versions that support multiple App Control policies". Two policies with one job each are easier to reason about than one policy where you have to hold both intentions in your head.

The policy count limit #

There is a hard ceiling worth knowing about, particularly if you are planning a policy per business unit.

Until the Windows security update released on or after 9 April 2024, a device is limited to 32 active policies. Exceeding it does not produce a warning. The device bluescreens referencing ci.dll with a bug check value of 0x0000003b.

Two details:

• Inbox Windows policies count. Policies that ship with Windows and are active on the device consume part of the 32.
• Windows 11 21H2 is still capped. The limit was not removed there and remains 32.

Installing the April 2024 or later security update and restarting removes the limit on supported versions. If you cannot, keep the count down rather than finding the ceiling.

What this means for delegating policy #

Put the three properties together and the architecture is largely decided for you.

Common applications belong in the shared base. Everything every device runs, allowed once, by signer or publisher so it survives updates. Allowing the same browser and the same security agent separately in eight business unit policies is duplicated work that then drifts apart.

Line of business applications belong in a supplemental per business unit. This is what supplementals are good at. A unit can widen what its own devices trust, cannot loosen anything for anyone else, and cannot touch a central deny. That is why handing it out is safe.

The deny set belongs in a base policy, and only there. Including the binaries you never want executing anywhere.

Where a group genuinely needs something the deny set removes, it needs its own base policy variant, assigned to that device group. Not a supplemental, because a supplemental cannot undo a deny. This is the step people get wrong, and it is expensive because you find out after the policy is built.

That last point is why the profile has to be decided before the policy is created. Working out that your developers need build and debug tooling after you have blocked it fleet wide means restructuring, not adding an exception.

Signing changes the shape of this #

If you are signing policies, supplementals stop being independent.

When you sign a base policy that has existing supplementals, all of the supplementals must be signed too, and the base has to authorise them with a <SupplementalPolicySigner> rule. The certificates trusted for supplemental policies are identified in the SupplementalPolicySigners section, in the same way certificates trusted for policy updates go in UpdatePolicySigners.

So a signed estate is a more tightly coupled estate. Every party who can publish a supplemental needs to be able to sign it with a certificate the base trusts. That is a governance decision as much as a technical one, and it is worth making deliberately rather than discovering when a business unit's supplemental stops applying. Our piece on signed and unsigned policies covers where signing is worth that cost.

A structure that holds up #

For an organisation with several business units:

• One shared base carrying the common application allowlist and the universal deny set. Option 17 enabled so it can be expanded.
• Base policy variants only where a device group has a legitimate need for something the shared deny set removes. Assigned by device group.
• One supplemental per business unit, allow rules only, for the applications only that unit needs.
• Separate allow and deny policies where the Windows version supports multiple policies, because it makes the intent readable.
• A count of how many policies land on any one device, kept comfortably under 32 unless every device has the April 2024 update.

None of that is exotic. It follows directly from three rules: supplementals only add, deny always wins, and multiple bases intersect.

The part that does not follow automatically is knowing what the effective policy on a given device actually is once authoring is delegated. That is a reporting problem rather than a policy design problem, and it is what we built to answer.

These rules are unforgiving because nothing warns you when you get them wrong. With PoliEze you can see the whole structure at once and where the effective policy lands for any group, so a deny placed somewhere it will be ignored is something you notice rather than something a user discovers for you.

Sources #

• Understand App Control for Business policy rules and file rules
• Deploy multiple App Control for Business policies
• App Control admin tips and known issues, for the file rule precedence order and the active policy limit
• Use signed policies to protect App Control for Business against tampering