Every application control tool, including ManageEngine's, lets you identify an app in several ways — by its file name, its folder path, its file hash, or its vendor. Pick the wrong identifier and your block is either useless or unmaintainable. Here is each rule tested against the two things users and updates actually do: rename files and change versions.
Blocking looks simple until the first clever user renames game.exe to report.exe and is playing again by lunch. That trick works because a name rule only reads the label on the file, and labels are free to change. The fix is not a bigger blocklist — it is choosing an identifier that matches what you actually mean. Here are the four identifiers, graded honestly.
A name (or product name) rule matches the text in the file name. It is the easiest rule to create and the easiest to defeat: rename the file and the rule no longer sees it. Moving the file does not even matter — the name is all it checks.
Name rules still have one honest use: a first, fast block while you build the real rule, and polite blocking of well-behaved software in an office where nobody is trying to fight you. Never mistake a name rule for security.
A path rule blocks everything running from a folder, for example everything under a games folder or a known install directory. It survives renames, and it is the right shape when a whole location is the problem.
Its weakness is location itself: install or copy the app somewhere else and it runs. Path rules also backfire when the folder is user-writable and shared — block a broad path like the Downloads folder and you will stop legitimate tools that happen to run from there. Keep paths narrow and specific.
A hash is a fingerprint computed from the file's actual contents, so a renamed or moved copy still matches — the strongest identifier of the four. You can compute one in seconds: certutil -hashfile "C:\Program Files\App\app.exe" SHA256.
Now the honest cost: every update changes the file, so every update changes the hash. A hash blocklist quietly stops matching the day the app auto-updates, and a hash allowlist breaks the morning a needed app patches itself. Hash rules are excellent for one frozen, known-bad file — and a maintenance trap as a general strategy.
Vendor rules match the digital signature on the file: whoever signed it, not what it is called or where it sits. Renaming does nothing, moving does nothing, and ordinary updates stay covered because the vendor signs the new version with the same identity. This is why ManageEngine puts Vendor and Verified Executable at the top of its filter list.
The trade-off is breadth: a vendor rule affects everything from that publisher. Blocking a game studio's signature is precise; blocking a giant vendor whose driver utility you also need is not. Check what else carries the same signature before you deploy.
Every click shown live in the ManageEngine console — application groups, policy deployment and the audit-to-strict switch.
▶️ Watch Full VideoBecause the rule was probably a hash rule. An update replaces the executable with a new build, the new build has a new hash, and the old rule no longer matches anything. Switch the block to the vendor or verified-executable filter, which follows the publisher's signature across versions, and the next update stays blocked.
Any rule except the name rule. A folder path rule still catches it in the same location, a hash rule catches it anywhere because the content is unchanged, and a vendor rule catches it because the signature is unchanged. Renaming only defeats rules that read the file's name — which is why name rules are a first aid measure, not a policy.
Yes — for one exact file you never want to run again, like a specific known-bad installer or a frozen old version of a tool. It is precise and nothing else matches by accident. It becomes the wrong choice when used for software that updates itself, because you will be re-creating the rule after every update while believing you are protected.