No installation, no entry in Programs and Features, no trace in your software inventory — a portable app simply runs. That is exactly why portable tools are the standard way staff route around office software rules. The good news: a blocking policy does not care how an app arrived. It cares what tries to start.
Most software control thinks in installs: what is on the machine, in the list, with an uninstaller. Portable applications ignore all of that. They run from a USB drive, the Desktop, the Downloads folder — anywhere a user can write. If your blocking rules were written against installed copies, portable versions of the same tools walk straight past them. Here is why start-time enforcement changes the picture, and which rule shapes actually catch a program that was never installed.
Endpoint Central's application control is enforced by a filter that examines every newly created process. An installed game, a downloaded tool and a portable utility off a pen drive all pass through the same gate at the same moment — the moment they try to run. That is the whole reason a blocklist can stop software that no inventory has ever recorded.
So when you test your policy, test it like a user would attack it: copy the blocked tool to a USB drive, run it from there. If your rules were built on identity, it stops. If they were built on install paths, you have just found your gap before your users do.
A portable copy is the same file wearing a different address. Hash rules still match it, because the content is unchanged; vendor rules still match it, because the signature travels with the file. A folder-path rule written against C:\Program Files does not match anything running from E:\ or from a user's profile.
The useful-path version of this lesson: users can only run portable apps from folders they can write to. A policy that treats user-writable locations with suspicion — and reserves trust for managed install folders — closes most of the portable route without chasing individual files.
A blocklist plays whack-a-mole with portable software: every new tool is unknown until someone lists it. An allowlist in Strict Mode reverses the question — only approved applications run, so a portable anything, known or unknown, is stopped by default. For high-risk machines (accounts, front desk, shared PCs) this is the honest end-state.
Price it honestly before promising it: strict allowlisting needs the audit-first rollout and a working request door, or the first blocked legitimate tool becomes the story of your whole project. Portable apps are the strongest argument for allowlisting, and allowlisting done in a hurry is the strongest argument against yourself.
Stopping the program is one half; the drive itself is the other. If a machine should never run anything from removable media — or never accept removable media at all — that is a device control decision: block or restrict USB storage on that PC, separately from application rules.
Keep the two tools in their lanes. Application control answers what may run; device control answers what may connect. Offices that mix them up end up blocking every pen drive in the building to stop one portable game — and then spend a month hearing about it.
Every click shown live in the ManageEngine console — application groups, policy deployment and the audit-to-strict switch.
▶️ Watch Full VideoBecause the policy does not check installations — it checks program starts. A filter examines every new process at the moment it launches, wherever the file lives. If the file's hash or vendor signature matches a block rule, or if a strict allowlist does not include it, the launch is stopped. The install record was never part of the decision.
Almost certainly a path rule. The installed copy ran from the folder your rule named; the USB copy runs from the drive letter of the pen drive, a different path entirely. Rebuild the rule on the file's identity — hash for one exact version, vendor for the publisher — and both copies stop, because identity travels with the file and location does not.
Only on machines where removable media itself is the risk — data leaving the building, unknown drives arriving. Blocking storage is a blunt, building-wide irritation when the actual problem is a handful of portable programs. Use application control for what runs, device control for what connects, and reserve the USB ban for the PCs whose data genuinely justifies it.