Block Any App in Office

Discover What Is Actually Installed

Open the Endpoint Central console and start with discovery, not blocking: the agent on each managed PC scans and lists the applications that are really installed across the office, including software nobody in IT ever approved. Read that list before you block anything. Expect surprises - a personal VPN here, an old screen recorder there, three PDF tools doing the same job. This discovery report is also your evidence later: when someone asks why an app was blocked, it shows the app was running on office machines before any policy existed.

Write the Policy Before the First Block

Decide the rules on paper first. Write categories, not app names: games, torrent and peer-to-peer clients, personal VPNs, remote-access tools nobody approved, crypto miners, and anything with no business purpose. Categories survive next month's new game; a list of names does not. Name the person or role who approves exceptions, the route staff use to ask, and a promised reply time - one working day is a good promise. Temporary needs get temporary, time-bound access, never a permanent hole opened in a hurry.

Build the Blocklist as an Application Group

In the console, go to Application Control, then Application Groups, and choose Create Blocklist. Add applications with the filters the console offers: Vendor, Product Name, Verified Executable, File Hash, Folder Path and Store Apps. The blocked app stays installed on the PC - it simply cannot run. For one single file on a few PCs, Endpoint Central also has a simpler Block Executable option under Inventory, matched by path or hash; Application Groups are the proper route when the rule must live as a policy across the whole office.

Choose Rules That Survive a Rename

How you identify an app decides whether the block holds. A file-name rule is the weakest: it reads only the label, and renaming game.exe to report.exe defeats it completely. A folder-path rule survives a rename but not a move to another folder. A file hash is a fingerprint of the file's exact contents, so a renamed or moved copy still matches - but every update changes the hash, so hash lists need maintenance. Vendor and verified-executable rules follow the publisher's digital signature: they survive renames, moves and ordinary updates, which makes them the practical default. To get a hash for one known-bad file, compute it on any Windows PC:

certutil -hashfile "C:\Program Files\App\app.exe" SHA256

Replace the example path with the real file's path. The command prints the SHA256 hash you paste into a File Hash rule.

Deploy to a Pilot Group in Audit Mode

Under Deployment, open Deploy Policy and attach the blocklist to a custom group of computers - start with a small pilot group such as your own department, even if the final target is every office PC. While deploying, do two things. First, set the custom notification message users will see when an app is blocked: name the policy and say who to contact. Second, switch on the option that lets users request applications - turn it on now, not after the first crisis, so a blocked user gets a request route instead of a dead end. Deploy the policy in Audit Mode: nothing is blocked yet, but every application start is recorded.

Resolve Every Unmanaged App Before Enforcing

Run Audit Mode for at least one full work cycle - a month that includes month-end, when the rarely used closing and reporting tools come out. Then work through the Unmanaged Apps view and give every entry a verdict: add it to the allowlist, add it to the blocklist, or move it into an application group. For a genuinely unknown file on one PC, ask its user before judging - half the scary names are boring tools with bad branding. The goal before enforcement is a short, understood unmanaged list, so Strict Mode holds no surprises.

Switch to Strict Mode - and Run the Exception Door Properly

Switch the pilot group to Strict Mode first, run it for a week, and only then roll out group by group. In Strict Mode the block is real: a filter checks every program at the moment it tries to start, so the rule holds even for apps installed long before the policy and for portable copies that never installed at all. When a blocked app turns out to be needed for real work, approve just-in-time access for a few hours or a day - it expires on its own. If the same department keeps requesting the same app, move it to that group's allowlist properly and keep the decision in the audit log.