The missing control plane for App Control for Business

Microsoft has already done the hard engineering. App Control for Business is the gold standard for application control on Windows. It enforces in the kernel, below the level a user or a local administrator operates at, and it is deny by default, so code runs only when the policy names it.

That engine is on every Windows device you own and it costs nothing extra. What it does not do is keep pace with an enterprise that changes every week. A policy is a fixed statement about what is trusted. The estate it describes is not fixed at all.

So the question is not whether Windows can enforce application control. It is why so few large estates have it enforced.

The engine denies by default. You decide what to allow #

You never write a rule to block anything. Deny by default handles that, perfectly, without a person being involved.

All the work sits on the other side. Which software should be allowed, on what evidence, approved by whom, at what scope, for how long, and when the approval should be taken away again.

None of those are enforcement questions. Windows does not answer them, because answering them was never its job.

That is where programmes stall, and it is almost never the technology. It is the point where the audit queue reaches three hundred items, half of them have no owner, and nobody can say whether enforcement is safe to turn on.

The engine decides about files. You decide about applications #

App Control reasons about files. A hash, a signer, a path, a version, an origin claim. That is correct for an enforcement engine, because a file is what executes.

Nobody runs an organisation at that level. An engineer does not want to approve four hundred libraries. They want to approve an application, at a version, from a vendor, with an owner, a business reason, a deployment ring and a review date.

Somebody has to reconcile those two views. Without a layer that does it, the reconciliation lives in spreadsheets, ticket queues, and the heads of two or three people.

Every one of these needs an owner #

Hash rules and their lifecycle. Publisher rule scope. Managed installer trust boundaries. Origin claims. Supplemental policies. Policy options written as double negatives. Audit events that need correlating. Exceptions that need an expiry.

Microsoft documents all of it correctly. Each one is also a decision that needs an owner, an approval, a reason and a review date before it is safe at scale.

• Choosing rule levels, and what each costs to maintain
• Managed installer is a trust channel, not a convenience flag
• Policy options that mean the opposite of what they read
• Base and supplemental policies
• Reading the CodeIntegrity log properly
• Audit mode to enforcement

Each is solvable by a competent engineer. None is solvable once. They have to keep being solved as the estate changes underneath them.

Audit events are evidence, not a decision #

Audit shows what enforcement would have refused. It does not answer the only question anybody is asking, which is whether it is now safe to enforce.

Getting from one to the other means resolving events to applications, attributing those to owners, and being able to show your working when somebody senior asks why you are confident. That is an accountability problem sitting on top of a telemetry problem.

Where this leaves the decision #

The enforcement engine is the right one to use, and you already have it. Adding a vendor agent buys you a weaker enforcement point in user mode, a licence and a migration you will one day reverse. Agent based application control, or the engine already in Windows sets out that trade.

What is missing is the layer above it. Not more rules. A control plane that turns file level enforcement into governed trust, so the estate is operated by a team rather than carried by an individual.

That is what PoliEze is. The platform sets out how.