Stop asking what is dangerous. Decide what belongs.

Your endpoints are protected by tooling that recognises bad things, and they should be. Antivirus and XDR are not optional, and nothing here is an argument against them.

Both have to recognise something first, though. Underneath them sits a different kind of decision, about what is allowed to run at all, and that one does not require recognising anything. It is one of four moves, and they only work together.

This is the difference between a blocklist and an allowlist. If you learned it as application whitelisting, that is the same decision under an older name.

What detection does, and what sits underneath it #

Antivirus and XDR do work application control cannot. They catch known malware at volume, they tell you what happened afterwards, and they correlate an endpoint alert with an identity and an inbox. Every organisation needs both.

A decision about what may run does something they cannot: it means the tooling above has a smaller, known estate to watch rather than whatever accumulated over a decade.

Microsoft states the relationship plainly, and it is worth quoting because it is their engine:

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 same documentation says application control is not a replacement for antivirus. So this is an argument about order, not about substitution. App Control vs antivirus vs XDR sets out which question each layer answers.

Living off the land works because the land is generous #

Attackers reach for tooling that is already present, already signed by Microsoft, and already trusted. powershell.exe, wmic.exe, certutil.exe, bitsadmin.exe, mshta.exe, regsvr32.exe, rundll32.exe, msiexec.exe, cscript.exe, wscript.exe, forfiles.exe, installutil.exe. All catalogued publicly, none of it a disclosure.

The obvious response is to block the list, and it fails immediately, because real things depend on those binaries.

Published research tells you which of these get abused, and it is worth reading. What it cannot tell you is why each one is installed in your estate, and that second half is what decides what you can safely do about them.

None of it is optional software, which is why a blanket block breaks a build pipeline on the first ring. The answer is to upgrade where you can and scope where you cannot, rather than to aim for absence. The execution techniques have not changed covers why this list stays stable year after year.

The four moves, made three times #

Here is the model. Read down a column and it looks like three separate programmes owned by three different teams. Read across a row and it is one decision made three times.

Know your estate #

You cannot decide what belongs until you know what is there.

For software, that means discovery and audit across the fleet rather than one gold image, producing an inventory with owners against it. For hardware, what models, what firmware and which driver versions are actually deployed, rather than what procurement bought. For remote access tooling, which tools are installed, on what, and who has used them.

An inventory assembled from purchase orders is not an estate.

Only what the business needs #

A circle of trust drawn from a known state, not a guess.

Nothing installed that nobody asked for, because an application without an owner is not a requirement, it is a habit. One standard build per role, rather than whatever was cheapest in the quarter it was bought. One remote access tool, where most estates have three or four because each acquisition arrived with its own.

Kept current, managed centrally #

The exploited version is almost always the old one.

One deployment path, patched when the update ships rather than on a quarterly cycle an attacker is not observing. Latest drivers from one source, because the vulnerable driver on a blocklist is usually the one somebody left behind. Current agent only, one console, one audit trail.

Controlled, with a way back #

The first three narrow the estate. This one holds the line.

Application control refuses anything the policy does not name, before the process starts. Vulnerable drivers blocked where nothing depends on them and staged where something does. Remote tooling restricted to the endpoints and the people who need it.

The order matters. Application control over an estate nobody standardised, nobody manages centrally and nobody patches is a policy with an unbounded exception list, which is how programmes end up parked in audit mode.

Every move shortens the list #

Each of those decisions takes something off the surface an attacker can use, and off the list a threat feed has to cover.

Start with every signed tool on the machine, which is what a feed has to account for. Know your estate and you find out what is actually there. Keep only what the business needs and most of it turns out never to have been needed. Keep it current and the abusable old builds are gone. Control what is left and it is scoped to who uses it.

That is a direction rather than a measurement. Every estate is different and the proportions differ with it, which is why there are no percentages here.

How a request gets decided #

None of the above says who decides whether a given application is allowed, and that is the step programmes skip. The useful model is one every organisation already runs competently somewhere else.

A finance function does not ask whether a purchase is technically possible. It asks whether the business stops without it, whether somebody would simply prefer it, or whether the line item has been renewing for years because nobody looked.

The middle answer is the one that makes the outer two survivable. A model with only allow and block forces every genuine but non essential request into one of two wrong answers, and in practice it becomes allow, because refusing a team outright is a fight nobody wants twice.

Five fields on every exception #

Whatever the answer, the record needs the same five things a purchase order already carries. Who owns it. What exactly. Where it applies. When it expires. Why it was granted.

The fourth is the one nobody asks for and the only one that decides whether the policy is still yours in a year. Without an expiry, an exception is permanent from the moment it is granted. That is how a narrow policy becomes a wide one, one urgent request at a time, and no tooling prevents it if the field is not there.

How PoliEze does this #

The model above is the argument. This is what the platform actually does with it.

Know your estate. PoliEze collects execution evidence from the fleet and resolves it to applications and owners, so the inventory is what the estate is running rather than what anyone believes it is running. That is the first move, and it is the one most estates cannot perform today.

Decide what belongs. Base and supplemental policy authored in one place, every rule carrying an owner and a recorded reason, at the trust level that suits it. Publisher where the signer is durable, file hash only where nothing better exists.

See it before it lands. Simulate enforcement against your own evidence and get the list of what a policy would stop, before a single user meets it. This is the step that turns the fourth move from a risk into a decision.

Hold the line. Ring by ring enforcement with a way back that does not need a change board, time boxed overrides that expire by themselves, and alerts when a device stops matching the policy you approved.

Keep the request honest. Need, want and has, with the five fields on every exception, in a workflow rather than an inbox.

Where to start #

Not with a policy. With the first move, because it is the input every later decision depends on.

The platform sets out the sequence. Running this at scale covers what changes when the fleet is large enough that these decisions sit in different reporting lines.