Antivirus asks whether a file is known to be bad. Application control asks whether it is known to be good. That reversal is unglamorous, decades old, and still the strongest single thing most small businesses are not doing.
Most endpoint security is built around a question that gets harder every year: have we seen this before?
Signature-based antivirus keeps a catalogue of things known to be malicious and compares what arrives against it. It works, it is cheap, and it fails in one specific and important way: it can only recognise what has already been observed, analysed and catalogued by somebody, somewhere. A payload assembled this morning has no entry to match.
That gap has always existed. What has changed is how cheap it has become to produce novel payloads faster than any catalogue can be updated, which means the gap widens rather than closes.
Application control — also called application allowlisting, and older than most of the products that sell it — asks the opposite question. Not “is this known to be bad?” but “is this known to be approved?”
The US National Institute of Standards and Technology put it plainly in its Guide to Application Whitelisting: “An application whitelist is a list of applications and application components that are authorized for use in an organization. Application whitelisting technologies use whitelists to control which applications are permitted to execute on a host. This helps to stop the execution of malware, unlicensed software, and other unauthorized software.”
The consequence is worth stating slowly, because it is the whole argument. An allowlist does not need to have seen the threat before. A brand-new ransomware strain is not on the approved list. Neither is a renamed copy of a legitimate tool, a script dropped by an attacker who already has a foothold, or something a staff member downloaded believing it was a PDF reader. None of them are approved, so none of them run.
| Signature-based antivirus | Application control | |
|---|---|---|
| The question asked | Is this known to be bad? | Is this known to be approved? |
| Default answer | Allow | Block |
| Brand-new payload | Nothing to match against | Not on the list, so it does not run |
| Legitimate tool misused | Usually permitted | Permitted only if approved for this environment |
| Depends on updates | Yes, continuously | Much less so |
| Main operational cost | False positives | Approving legitimate software quickly enough |
If you do business with Australian government, or with anyone who has been assessed themselves, you have met the Essential Eight — the Australian Signals Directorate’s baseline set of eight mitigation strategies, published through the Australian Cyber Security Centre. Application control is one of the eight.
That matters commercially as well as technically. Essential Eight maturity increasingly turns up in tender questionnaires, supplier assessments and insurance applications, which means application control is drifting from “good practice” towards “a box someone will ask you to tick”. If you are going to be asked, it is cheaper to implement it deliberately than to retrofit it the week before an assessment.
Anybody who tells you default-deny is free is skipping the part that decides whether it survives contact with your staff.
Something legitimate will be blocked. A bookkeeper installs a tool the accountant asked for. An engineer needs a vendor utility to talk to a machine. A developer pulls down something new. On day one of a default-deny rollout, those all stop.
What happens in the next twenty minutes decides everything. If the answer is “log a ticket and wait two days”, people will find a way around the control, and a control people route around protects nobody. So decide these three things before deployment, not after:
Start in a monitoring mode that records what would have been blocked, and leave it there long enough to cover a full business cycle — a month end, a payroll run, an audit. The list of surprises in that log is the real implementation plan.
Application control is one layer, and it does not replace the others:
Any vendor — including us — telling you one product removes the need for the rest is selling, not advising.
Adaptive Defence is a default-deny endpoint product built on exactly the principle above: unknown executables do not run, regardless of how they arrived or what they are pretending to be. It runs on Windows and macOS, is designed to keep enforcing when the machine is offline, and is sold both to individuals and small teams and as an enterprise deployment for organisations running ten or more endpoints. Its pricing, its technical detail and its performance claims are published on its own site, and there is a free trial — which is the right way to evaluate something like this, because the only question that matters is how much friction it creates in your week.
If you are running this across an organisation, the deployment questions are the ones above: who approves, how fast, out of hours, and how long you sit in monitoring first. That is a rollout conversation rather than a download, and our Corporate Solutions team handles those alongside the other systems work.
That order is deliberate. Steps one to three cost nothing and protect you tomorrow. Step four costs a month of patience and tells you what enforcing would actually break.
Antivirus asks whether a file matches something known to be bad, and allows everything else. Application control reverses the question: it asks whether a program is known to be approved, and blocks everything else. NIST describes an application whitelist as a list of applications and components authorised for use, with the technology controlling which applications are permitted to execute on a host.
Because ransomware is usually new. A blocklist can only recognise what has been seen and catalogued before, so a payload built this morning has no entry to match. An allowlist does not need to have seen it: anything not on the approved list simply does not execute, whether it is a known strain, a brand-new one, or a legitimate tool being misused.
Yes. Application control is one of the eight mitigation strategies in the Australian Signals Directorate’s Essential Eight, published by the Australian Cyber Security Centre. Organisations working towards Essential Eight maturity, or being assessed against it by a customer or insurer, will meet it as a specific requirement.
Friction, not licence fees. Something legitimate will eventually be blocked, and somebody has to approve it quickly enough that people do not start looking for ways around the control. Before deploying, decide who approves an exception, how fast, and what happens out of hours. A control people route around protects nobody.
No. It is one layer. Tested offline backups, prompt patching, multi-factor authentication and restricting administrative privileges all still matter, and none of them is replaceable by another. Application control is unusually high-leverage for the effort, but any vendor telling you a single product removes the need for the rest is selling rather than advising.
Adaptive Defence is a product of Oppermind Pty Ltd, the publisher of this article; this article is promotional in that respect and should be read accordingly. Product capabilities, pricing and any performance figures for Adaptive Defence are published on its own website and are not restated or independently verified here — check them there before purchasing. This article is general information about information-security practice. It is not security, legal, insurance or compliance advice, it does not take account of your circumstances, and it must not be relied on as an assessment of your risk or of your compliance with the Essential Eight or any other framework; obtain your own professional advice. No security control prevents all attacks.
Default-deny endpoint protection for Windows and macOS, with a free trial and enterprise deployment for larger fleets.