Ask ten offices why they bought application control and nine will answer with one word: games. The installed game is the easy part. The real set includes Store games, launcher platforms like Steam, portable copies that never install, and browser games no application policy can touch. Here is the whole picture, honestly.
Games at work are rarely a technology problem first — they are a visibility problem. Staff play because nobody can see it. ManageEngine Application Control changes that twice: discovery shows which PCs have games on them, and a blocklist makes them stop running. But games arrive in four different shapes, and each shape needs a different rule. Block only the first shape and you have solved a quarter of the problem.
Do not guess which games to block. Run discovery and sort the installed list: the games name themselves. Build the blocklist from what is actually there — the racing game on the reception PC, the card game that has lived on the store machine for two years.
Use vendor or product filters rather than file names, because games update often and users rename shortcuts (which does nothing) and sometimes the executable itself (which defeats name rules only). One rule per title usually closes it for good.
Microsoft Store games arrive through the Store, so use the Store Apps rule to cover them — an install-path rule written for classic programs will miss them entirely. Platform launchers such as Steam or Epic are the bigger door: block the launcher and you block every game it delivers, present and future, with one rule.
Be honest about the reverse: a launcher rule is broad. If one design tool in your office legitimately arrives through a game platform (rare, but it happens), that group needs an exception, not a surprise.
A portable game copied from a pen drive leaves no install record, so it never appears in an installed-software list. It is still stopped — the policy checks every program at the moment it starts, installed or not — provided your rule matches its identity. A hash or vendor rule catches it; a rule written against an installed copy's folder path does not, because the portable copy runs from the Desktop or the USB drive itself.
For machines where this is a constant battle, the real answer is the stricter shape: an allowlist in Strict Mode, where anything not approved — installed, portable, downloaded — simply does not run.
Here is the line nobody selling you software will underline: a game that runs inside a browser tab is a website, and application control cannot block it. The browser is an allowed application doing an allowed thing. Blocking browser games is a web-filtering job — your firewall, DNS filter, or the browser security policy — not an application blocklist job.
The same honesty applies to the phone on the desk and the personal laptop on a hotspot: office application control governs office PCs. The policy, the discovery reports and the visible fairness of the rules do the rest of the work — most game-playing stops when it becomes visible, long before it needs to become impossible.
Every click shown live in the ManageEngine console — application groups, policy deployment and the audit-to-strict switch.
▶️ Watch Full VideoOnly software that is itself delivered or launched through Steam, which on an office PC is almost never work software. Check the discovery list first: if every Steam installation sits alongside games and nothing else, block the launcher with confidence. If one machine genuinely uses a Steam-delivered tool for work, give that machine's group an exception instead of weakening the rule for everyone.
No. A browser game is web content inside an allowed application, and an application blocklist only decides which programs may run. To stop browser games you need web filtering — a DNS filter, firewall category blocking, or browser policy. Application control and web filtering are partners, not substitutes, and an office that needs both should deploy both knowingly.
Yes, if the rule matches the program's identity rather than its install location. The policy checks every program when it starts, whether it was installed, copied, or run straight from USB. Hash and vendor rules catch portable copies; a folder-path rule pointing at the installed copy does not. On PCs where portable software is a recurring problem, a strict allowlist is the complete answer.