The failure happens before the first policy
Most application control projects that stall do not stall on tooling. They stall on environment. The policy engine works. The rules are technically valid. Enforcement breaks anyway — because the five or six things that application control depends on were not in place before the project started.
This is not a post about WDAC syntax or policy structure. It is a post about what needs to be true upstream of any application control implementation if you want it to hold.
a defined software intake process
Application control is fundamentally an allowlist. It trusts what has been explicitly approved and blocks everything else. That model only works if there is a defined, consistent way for software to get onto that list.
If software arrives informally — an email to IT, a support ticket, a verbal request — then your application control program will spend most of its time processing exceptions rather than enforcing posture. Every informal path becomes a pressure point the moment enforcement is on.
Before you start, answer this: what is the gate that new software passes through? Who reviews it? What does the vendor risk assessment look like? What happens if the request is denied?
If those questions do not have answers, you are not ready to enforce. You are building a process that will immediately need to absorb whatever the absence of that process has been producing.
a managed patching process — ideally automated
Every software update is a new binary. A new binary means new hashes, potentially new publishers, potentially new files that your policy has never seen. If your patching process is manual, inconsistent, or ad hoc, your allowlist will break every time a major application updates.
The teams that handle this well have automated patching running before they introduce application control. The logic then becomes straightforward: when a patch is deployed, the updated binaries are captured, validated against the new version, and the policy is updated as part of the same pipeline.
Without that, every update cycle becomes a reactive allowlist maintenance exercise. That is technically manageable for one or two systems. It does not scale.
The patching discipline that makes software updates reliable is the same discipline that makes application control maintainable. If the first is not in place, the second is going to be painful.
a Standard Operating Environment
Application control works best when you know what the fleet looks like. A well-defined SOE — consistent base images, consistent installed software, consistent configuration — gives you a meaningful baseline. Your policy covers the known-good state. Deviations are visible. Exceptions are exceptions, not noise.
A poorly standardised fleet gives you thousands of unexplained audit events and no clear way to know which ones represent risk and which ones represent the entropy that has accumulated over years of ad hoc provisioning.
The SOE does not need to be perfect. But it needs to exist. Workstations should look roughly the same. Servers should have defined roles with defined software sets. If you are starting from a state where every device is meaningfully different, audit mode will teach you something, but it will take a long time.
non-administrative users
This one is not negotiable.
If end users have local administrator rights on their workstations, application control is not a security control — it is an inconvenience with an escape hatch. A user with local admin can disable the policy engine, modify registry configuration, or install software directly in ways that bypass enforcement.
Application control assumes that code execution is something that happens within a policy boundary, not outside it. Local admin breaks that assumption entirely.
This means removing local admin from users before enforcement goes on, not as a parallel workstream, and not after. Elevation for legitimate support and administrative tasks should be restricted to identified personnel with a defined process. In environments with higher security requirements, even those elevation paths should be logged and time-bounded.
The relationship is straightforward: until users cannot install software freely, application control is measuring intent, not enforcing it.
separation of duties across the administration team
For environments with serious security requirements, the final pre-condition is structural.
Consider what full control over an application control program looks like: the ability to write a new allow rule, deploy a policy update, and approve the exception that created both. In an environment where one person can do all three, the control has a single point of bypass.
Separation of duties means splitting those responsibilities. Policy authoring, deployment approval, and exception review should sit with different people, or at minimum require two people to act together. In practice this often means a security team owns policy authoring and approval, while operations handles deployment without the ability to modify what they are deploying.
This is less relevant for small teams. For government, defence, financial services, and regulated environments more broadly, it is the difference between a control that is auditable and one that is not.
what happens when these are missing
None of the above are application control problems. They are hygiene problems that application control makes visible.
A poorly designed software intake process does not become obvious until enforcement blocks something that arrived through the informal channel. Inconsistent patching does not become obvious until the allowlist breaks twice in a week. Undocumented local admin accounts do not surface until audit logs stop making sense.
This is why application control projects that move through audit and into enforcement quickly tend to share a common trait: they were not the first security project the organisation had taken seriously. The foundations were there. The control had something to sit on.
The projects that stall tend to be the first attempt at disciplined endpoint control in environments that have been operating informally for a long time. Application control then has to do two jobs at once: enforce posture, and absorb all the exceptions generated by the absence of the upstream process.
That is a hard position to be in. The technology will survive it. The program may not.
a useful pre-project checklist
Before the first policy is deployed, it is worth running through these five questions honestly:
- does new software arrive through a formal, documented intake process?
- is patching automated and consistent enough that allowlist maintenance can follow the same cadence?
- is the endpoint build standardised enough to produce a meaningful baseline policy?
- are end users running without local administrator rights?
- is there a separation between who can write policy changes and who can approve and deploy them?
If the answer to all five is yes, the application control project has a reasonable foundation. If several of the answers are no or uncertain, the project plan should reflect that — because closing those gaps is part of the work, not a precondition that can be deferred.
WDACManager is designed for environments that have those foundations and need the operational tooling to run an application control program at scale. If the foundations are still being built, the most useful thing the platform can do is help you understand the gap — and the most useful thing you can do is be honest about where you are starting from.