The documentation problem
WDAC has good documentation. The Microsoft Learn pages cover the rule schema, the signing scenarios, the policy options, the deployment paths. The community blogs fill in the gaps with worked examples and edge cases. If you want to learn how a WDAC policy is structured, the material is there.
But that is roughly 10% of what makes an application control program succeed.
The other 90% is operational, and almost none of it is written down.
What the 90% actually looks like
When teams stall with WDAC, they rarely stall on syntax. They stall on questions like these:
- who approves a new allow rule at 4pm on a Friday
- how do you know the rule you added six months ago is still needed
- what happens to the policy when the person who wrote it changes roles
- how do you explain to an auditor why a specific publisher is trusted
- how do you safely remove something without breaking a workflow you did not know existed
None of these are technology problems. They are operating problems. They require ownership, process, and a shared understanding of how change moves through the environment.
The reason this part is rarely documented is that it depends on the organisation. Microsoft cannot write the policy review cadence for your environment. A blog post cannot define who has approval authority for a supplemental policy in your business. That work is local, and it is what most teams skip when they start.
Why the 10% feels like the whole problem
The 10% is concrete. XML can be reviewed in a pull request. A signing scenario either works or it does not. A rule either matches or it does not. There is satisfaction in solving these problems because the feedback loop is fast.
The 90% has none of that. It is slower, less visible, and harder to demonstrate progress on. It usually involves conversations rather than code. So teams gravitate toward the 10%, which is why so many WDAC programs have technically correct policies that nobody can confidently change.
What better looks like
The teams that succeed with WDAC did not get there by mastering the schema. They got there by deciding, before they wrote rules, how the program would operate.
That usually means clear answers to a small number of questions:
- who owns each policy and who can change it
- how new application requests are captured, reviewed, and approved
- how exceptions are handled without becoming permanent policy weakening
- how policy changes are tested and rolled back if something breaks
- how the program reports on its own state to the people who need to see it
The answers do not need to be complex. They need to exist, and they need to be the same answer this Friday as they were last Friday.
The Friday afternoon problem
One of those questions deserves special attention because it is where most application control programs quietly fail.
At some point, in every environment, somebody legitimately needs to run something that the policy does not allow. A new installer. A support tool. A piece of software that was approved but has not yet made it into a deployed policy. The request is real, the timing is bad, and the person asking is not interested in the lifecycle.
If the only options are "wait for the next policy cycle" or "have an admin disable enforcement temporarily," the program has a problem. The first option is too slow. The second option, repeated enough times, is how enforcement quietly becomes audit mode in practice.
This is the moment that decides whether your control is real.
OneCode as one answer
OneCode is one example of designing the operating model rather than working around it. It treats temporary execution as a first-class workflow rather than a shadow process: a time-bounded, telemetry-captured, automatically reverting window during which a specific endpoint runs in audit mode while the user installs or executes what they need.
The mechanics matter less than the principle. The principle is that the program acknowledges legitimate temporary need exists, designs a path for it that does not weaken the overall policy, and captures the data needed to update the policy properly afterward.
The result is that the Friday afternoon question has an answer that does not require an exception, a workaround, or a quiet conversation with someone who has local admin rights.
OneCode is one mechanism. The point is broader: every common operational situation in an application control program needs a designed answer. When those answers exist, the technology does what it was designed to do. When they do not, the technology spends most of its time in audit mode while everyone politely agrees not to look too closely.
The takeaway
WDAC is not hard because of XML. It is hard because the program around it has to be designed, and almost nobody writes about that part.
If you are starting an application control initiative, spend less time on the schema than the documentation suggests, and more time on the operating model than feels comfortable. The ratio that matters is not lines of policy. It is whether someone can answer the five questions above without hesitation.
When those answers are clear, enforcement is sustainable. When they are not, no amount of well-formed XML will save the program.