Blocking unapproved applications without breaking Windows

Most organisations have a list of software that should not be on their devices: a second browser nobody supports, a games client, a file-sharing tool, an AI desktop app that has not been through a data protection review. Writing the list is easy. Making it stick is the hard part, because uninstalling something once does nothing to stop it coming back next week.

Why a banned-software list is not enough

A policy document tells people what not to install. An uninstall script removes what is there today. Neither stops a user downloading the same installer tomorrow, or running a portable copy from their Downloads folder that never appears in Add or Remove Programs. To stop software running you need something that sits in the path of every program start, and on Windows that is code integrity in the kernel.

Blocking also matters for Cyber Essentials. The malware protection control can be met with anti-malware software or with application allow listing, and secure configuration expects you to remove and prevent unnecessary software. Either way, an assessor will want to see that what you say is blocked actually is.

App Control for Business, in brief

App Control for Business is the Windows feature previously known as Windows Defender Application Control. Policies are enforced by the operating system itself rather than by an agent that can be stopped or bypassed, and rules can identify an application by its publisher, its original file name or its file hash rather than by the name the file happens to have on disk. That is what makes a renamed copy of a blocked program fail in the same way as the original.

The feature is powerful, and it is also easy to get wrong. A policy that is too broad can stop line-of-business software or parts of Windows from starting. That is why every serious deployment begins in audit mode, where Windows records what it would have blocked without blocking anything.

How AppBlocker makes it routine

• Audit before enforce. Every rule starts in audit. The console shows which devices would have been affected and what would have been stopped, so the decision to enforce is made on evidence.
• A deliberate switch to enforce. Enforcement only happens when an admin confirms it by typing the rule's name, which removes the one-click mistake.
• Tested rule packs, and your own rules. Packs such as Google Chrome and Steam are ready to use, and you can add rules by product name, original file name or website.
• Prohibited, not hidden. Copies that are already installed appear as Prohibited in the Risk Register, so they sit alongside the vulnerabilities and can be removed in the same workflow.
• Evidence. A blocked-attempts log and an audit report per rule show what was stopped, where and when.
• Safe by design. Windows, Microsoft and Assure components are protected from being blocked, exceptions can be granted per device, and a pause-all switch stands everything down without a reboot.

A sensible rollout

1. Pick one application that genuinely should not run, and turn its rule on in audit for every device.
2. Review a week of audit results. Look for devices where the application is in real use and decide whether they need an exception or a conversation.
3. Remove existing installs using the Prohibited entries in the Risk Register.
4. Enforce, then watch the blocked-attempts log for the first few days.
5. Repeat for the next application. Small, evidenced steps beat a large allow list written in a meeting room.