One question before you sign
If you are evaluating a commercial application control product, ask the vendor one question before anything else: what happens to enforcement the day the contract ends?
For agent-based products, the honest answer is that enforcement stops. The agent is the control. Remove the agent — or stop paying for it — and the endpoint is back to allowing everything.
That single answer tells you most of what you need to know about the model. You are not buying a security control. You are renting one.
The rental problem
Application control is not a product you install and forget. It is a body of work. Every rule written, every application assessed, every exception documented represents time your team spent understanding what should run in your environment.
With an agent-based product, that work lives in the vendor's format, in the vendor's console, enforced by the vendor's agent. It is not portable. Migrating to anything else means starting the assessment work again from the beginning.
Vendors understand this perfectly well. It is why renewal pricing looks the way it does. The switching cost is not the licence fee — it is the years of allowlisting decisions you cannot take with you.
The removability problem
The commercial problem is only half of it.
An agent-based control is software running on the machine it protects. That has consequences:
- an agent service can be stopped
- a driver can be unloaded
- an uninstaller exists, because the vendor had to write one
- a lapsed licence or a failed update can degrade enforcement without anyone deciding to degrade it
Attackers know all of this. Disabling security tooling is a standard early step in modern intrusions, and every third-party control adds one more thing that can be switched off. The vendors work hard on anti-tamper, and some of that work is good. But the structural fact remains: the control exists as an addition to the operating system, and additions can be removed.
Where WDAC enforcement lives
WDAC is not an addition to Windows. Enforcement is performed by the Windows code integrity engine — the same kernel component that validates the operating system itself. There is no agent to kill, because there is no agent. There is no uninstaller, because there is nothing to uninstall.
With a signed policy, the properties get stronger again. A signed WDAC policy is validated as part of the boot process and stored where a local administrator cannot simply delete it. Removing it requires the signing certificate, not administrative privilege. It does not care whether any management software is running, and it keeps enforcing when nothing else on the endpoint does.
One honest caveat: an unsigned WDAC policy can be removed by a local administrator. The strong tamper-resistance claims belong to signed policies, and organisations pursuing Essential Eight Maturity Level 3 should be planning for signed policies anyway.
The other property that gets less attention: WDAC policies are Microsoft-native XML. They are yours. They enforce regardless of which tooling produced them, and they keep enforcing if that tooling disappears. The work your team puts into allowlisting decisions accumulates in an open format on a platform you already licence.
Why the agents keep winning deals anyway
If the built-in control is structurally stronger, why does anyone buy an agent?
Because the agent vendors solved the operational problem and Microsoft did not. Building policies, collecting audit telemetry, handling exceptions, giving a user a path forward when something is blocked — the commercial products made that workable, and raw WDAC historically did not. Teams did not choose a weaker enforcement model on purpose. They chose the tooling that let them ship, and the enforcement model came bundled with it.
That trade was understandable. It is no longer necessary.
Tooling should compete on operability, not hold enforcement hostage
This is the premise WDACManager is built on. The enforcement engine already ships in Windows and is maintained by Microsoft. What organisations need is the operational layer around it — policy authoring, audit telemetry, controlled exception workflows, staged rollout.
WDACManager has a client too — and it is optional. In Intune-managed environments with Defender for Endpoint, the platform operates without deploying anything to the endpoint at all. Where the client is deployed, it handles telemetry, OneCode workflows and policy distribution. It is not the enforcement point. Remove it, or never install it, and enforcement continues, because enforcement never belonged to us in the first place.
That is what owning a security control looks like. The tooling earns its keep by making the work easier — and your protection does not expire with the contract.