What is App Control for Business, and what happened to WDAC

App Control for Business is the Windows feature that decides which executables, libraries, scripts and drivers are allowed to run on a device. Everything else is refused, in the kernel, before it starts. Microsoft renamed it from Windows Defender Application Control, or WDAC, with the Windows 11 24H2 release. Same feature, same policy format, new name.

If you have arrived here because you searched for WDAC and are wondering whether you are reading about the right thing, you are.

Why the name keeps changing #

The naming history is genuinely confusing and it matters, because it determines which documentation you find.

The practical effect is that most of the good technical writing, most Stack Overflow answers and most of the community tooling still say WDAC. Microsoft Learn has largely moved to the new name. You need both terms in your vocabulary.

Whitelisting, allowlisting, application control #

Those are labels for the technique itself rather than for Microsoft's product, and which one you hear depends mostly on when the person learned it.

Application whitelisting, often shortened to app whitelisting, is the original term and still the one most people search for. It fell out of use on language grounds rather than technical ones, so if that is the phrase you know, nothing about the technique has changed underneath it.

Application allowlisting, also written as app allow listing, is the direct replacement. Same idea, better word, and the one now used in most current writing.

Application control is what the security frameworks call it. The Australian Signals Directorate uses that name in the Essential Eight, and so do most audit and assurance documents you will be asked to satisfy.

App Control for Business is Microsoft's implementation of the technique in Windows, and it is what this post is about.

The first three describe an idea. The last one is the engine that enforces it, and it is already on the machines you own.

What it actually does #

A policy is an XML document that describes what is trusted. When something tries to execute, Windows checks it against the policy in force. If nothing in the policy allows it, it does not run.

That sounds simple and the consequences are not. A few things follow from it.

It is deny by default. This is the opposite of how antivirus works. You are not describing what is bad, you are describing what is acceptable. Anything you forget to describe is blocked, which is both the entire value of the control and the reason rollouts are difficult.

It covers more than .exe files. Depending on how you configure it, a policy can govern executables, DLLs, MSIs, scripts, packaged apps, compiled HTML, control panel applets and drivers. Each one you include is more protection and more things that can break.

It works on identity, not content. Rules describe code by who signed it, what product it belongs to, its exact hash, or where it lives on disk. There is no scanning and no verdict. Either the code matches a rule or it does not.

Rule levels, and why the choice matters more than anything else #

This is the decision that determines whether your policy is maintainable. Rules can be created at different levels of specificity.

Signer and publisher rules are what you want. They keep working when the vendor ships an update, because the signature is still the same.

Hash rules break on every single patch. A policy full of hash rules will look correct on the day you create it and will start blocking things the following Tuesday. If you find yourself creating many hash rules, the real problem is usually that the software is unsigned, and the real fix is to sign it yourself or ask the vendor to.

Path rules are the weakest option. They trust a location rather than a thing, so they are only meaningful if users cannot write to that location. A path rule over a directory a standard user can write to is not a control, it is a comment.

Managed installer #

Writing a rule for every application in an enterprise is not realistic. Managed installer is the mechanism that makes application control practical at scale.

The idea is that you nominate your deployment tool, Intune or Configuration Manager, as trusted. Anything it installs is then treated as trusted, because you already control what it deploys. Your existing software approval process becomes the trust decision.

This is enormously useful and it is also the fastest way to trust far more than you intended. Everything your deployment tool has ever installed becomes trusted, including things deployed years ago by someone who has since left. Knowing what is on that list is a real piece of work.

Audit mode #

A policy can run in audit mode, where it logs what it would have blocked without blocking anything. Events land in the Windows event log under Applications and Services Logs / Microsoft / Windows / CodeIntegrity / Operational.

Two event IDs matter most.

• 3076 is the audit event. This is what would have been blocked.
• 3077 is the enforcement event. This is what actually was blocked.

Audit mode is not a formality you pass through on the way to enforcement. It is where the actual work happens. Every 3076 event is a question you have to answer: is this something we should allow, something we should sign properly, or something that should genuinely never have been running here?

Teams that rush this step are the ones that break a department.

Base and supplemental policies #

You can have more than one policy in force. A base policy sets the ground rules and supplemental policies extend it, which is how a large organisation lets business units manage their own additions.

The behaviour that surprises people is what happens when policies disagree. Windows applies the most restrictive result. Two policies allowing something does not outvote one that does not. A business unit cannot loosen the base policy with a supplemental, only add to what the base already permits.

This is correct and deliberate. It is also the single most common cause of confusing escalations, because two teams can each be certain they granted access and the user is still blocked.

Where it sits alongside your other controls #

App Control is a preventive control. It stops execution. It knows nothing about intent, behaviour or reputation.

Your endpoint detection platform is doing a different job. It watches what runs, spots abnormal use of legitimate tools, and gives you something to investigate. It has to recognise something first, which is exactly the gap that unknown malware and living off the land techniques exploit.

Neither replaces the other, and anyone telling you otherwise is selling something. The honest framing is that App Control shrinks the set of things that can execute at all, and detection covers the misuse of what remains. Signed Microsoft binaries that attackers abuse still need explicit block rules, and those rules need maintaining.

What it means for Zero Trust #

Zero Trust asks for three things. Verify explicitly, grant least privilege, assume breach.

Most organisations have applied all three rigorously to identity. Conditional access, multifactor authentication, risk based sign in. Very few have applied any of them to code execution, which is where an attacker ends up once the identity controls are behind them.

Application control is those same three principles pointed at executables rather than users. Every binary checked against a policy before it runs. Endpoints able to execute only what the organisation approved. When credentials are stolen and someone lands on the device, the payload they brought still does not run.

Where to go next #

If you are deciding whether to invest in this, the useful next question is not technical. It is whether your organisation is ready to change how software gets in, because that is what enforcement actually requires.

The platform page covers how PoliEze manages the lifecycle, and running this at scale covers what changes on a large fleet.

Sources #

• Application Control for Windows, for the rename and what the feature covers
• Understand App Control for Business policy rules and file rules
• App Control for Business design guide
• Applications that can bypass App Control and how to block them, which is where the recommended blocklist lives
• Microsoft recommended driver block rules