App Control vs antivirus vs XDR, and why you need all three

Endpoint security has collected a lot of terms. Antivirus, EDR, XDR, application control, allowlisting, attack surface reduction, zero trust. Vendors are not helping, because each of them wants to be the layer you buy, and a comparison table is an easier sell than an architecture.

So the question arrives as "which of these do we need", and that is the wrong question. These controls are not substitutes for each other. They answer different questions at different points on the attack path, and the useful way to tell them apart is to look at the question each one is actually asking.

Each layer is asking a different question #

Read down the second column and the overlap mostly disappears. Antivirus is making a judgement about a file. Application control is applying a decision you already made. EDR and XDR are reasoning about behaviour after the fact.

Antivirus decides what looks bad, which is a prediction #

Antivirus is the layer everyone already has, and it still earns its place. It stops known malware cheaply and at volume, and modern engines catch a great deal more than signatures.

What it cannot do is be certain. Every antivirus decision is a prediction about a file it may never have seen, and Microsoft is unusually blunt about the consequence:

And with thousands of new malicious files created every day, relying solely on traditional methods like antivirus (AV) solutions gives you an inadequate defense against new attacks.

That is not an argument against antivirus. It is an argument against antivirus being the only thing standing between a user and code execution.

Application control decides what is allowed, which is a policy #

Application control inverts the model. Instead of asking whether something looks malicious, it asks whether the code is on the list of things you decided may run. Microsoft describes the shift plainly:

Application control changes Windows from a place where all code runs unless your AV solution confidently predicts it's bad, to one where code runs only if your policy says so.

The difference matters most for the things antivirus is worst at. Novel malware has no reputation to check. Living off the land techniques use binaries that are genuinely legitimate. A signed tool doing something it was never meant to do is not a malware detection problem at all. In each case a prediction engine has very little to work with, and a policy that simply does not authorise the code does not need to predict anything.

It also reaches further than most people expect. This is not only about blocking .exe files:

Although we call it application control, the code running on your system isn't always an app. Application control extends beyond apps to also cover scripts and Microsoft installers (MSI), command-line batch files, and even interactive sessions of Windows PowerShell, which run in Constrained Language Mode.

And it applies in the kernel as well as in user mode, which is the part that makes it structurally different from a tool sitting in user space watching what happens. If you want the detail on how those two scopes differ, and why one of them is opt in, what App Control for Business actually is covers the mechanics. Windows App Control for Business is the current name for the feature many teams still call WDAC.

XDR decides what a set of signals adds up to #

XDR is not a bigger EDR. The distinction is scope: EDR reasons about an endpoint, and XDR reasons across domains. Microsoft defines its own product as:

a unified pre- and post-breach enterprise defense suite that natively coordinates detection, prevention, investigation, and response across endpoints, identities, email, and applications to provide integrated protection against sophisticated attacks.

The capability that makes it worth having is correlation. Its documentation describes security teams being able to

stitch together the threat signals that each of these products receive and determine the full scope and impact of the threat; how it entered the environment, what it's affected, and how it's currently impacting the organization.

Those are questions no endpoint control can answer, because they are not about one endpoint. Did this alert involve a credential that was also used somewhere unusual? Did it start in email? Is the same person being targeted across three channels? What is the blast radius, and what should be isolated?

Notice what every one of those questions has in common. They are all asked about something that has already happened. That is not a criticism, it is the job. But it does mean the volume of work arriving at that layer is set by how much got through the layers before it.

One attack, four separate chances to stop it #

The layers are easiest to see in sequence. A fairly ordinary intrusion:

1. Someone receives a convincing phishing email and opens the attachment.
2. Antivirus checks the payload. If it is known, this ends here.
3. If the payload is novel, antivirus has nothing to match. Application control asks a different question, and unapproved code does not run regardless of whether anything recognised it.
4. If the attacker gives up on their own tooling and uses signed binaries already present on the system, application control has less to say, because those are legitimate. EDR sees the behaviour.
5. If they move to stolen credentials and legitimate access, the endpoint looks well behaved. XDR correlates the endpoint, the identity and the email, and the shape of the attack becomes visible.
6. The security team contains it with the full scope in front of them.

No single row of that list is sufficient. Remove antivirus and you handle known malware by hand. Remove application control and step three has no answer. Remove XDR and step five is four separate alerts that nobody joins up.

Where teams get this wrong #

"We have XDR, so application control is redundant." XDR makes you better at understanding incidents. It does not reduce how many you have. Prevention and detection are not interchangeable, and a detection layer fed by fewer events is a detection layer that works better.

"We have antivirus, so application control is overkill." This is the one Microsoft answers directly:

Although application control can significantly harden your computers against malicious code, it's not a replacement for antivirus. You should continue to maintain an active antivirus solution alongside App Control for a well-rounded enterprise security portfolio.

Worth reading in both directions. It says keep your antivirus. It also says application control significantly hardens the machine, which is not language Microsoft uses about optional extras.

"Application control is a compliance control." Compliance is usually what pays for it, because it is mitigation one of the Essential Eight. That is a funding argument, not a security one. The security argument is the ASD position quoted above, and it stands on its own.

"Application control means blocking executables." Scripts, installers, batch files, PowerShell language modes and kernel code are all in scope. A policy that only considers .exe files is a policy with most of the operational cost and a fraction of the benefit.

The layer that is hardest to operate, not hardest to understand #

Very little of the above is controversial. Most teams accept the argument quickly, and then the programme stalls anyway.

It stalls because application control is the only one of these four layers where the difficulty is operational rather than analytical. Antivirus and XDR are largely bought and configured. Application control has to be authored against your actual software estate, then run in audit mode long enough to be trusted, then moved to enforcement ring by ring, with exceptions that expire, approvals that are recorded, and a way back that is faster than a change board. Most programmes that fail do not fail on the policy. They fail on that.

That is the part PoliEze exists for, and the platform is the honest version of what it takes.

Sources #

• Application Control for Windows, Microsoft Learn. The antivirus relationship, the change in execution model, the code types in scope and the Australian Signals Directorate reference.
• What is Microsoft Defender XDR?, Microsoft Learn. The definition of XDR, the domains it coordinates across and the signal correlation capability.