Why Standard Windows Accounts Do Not Stop Steam Uninstalls

The most common advice on Reddit, Steam forums, and r/sysadmin for "my sibling keeps uninstalling my games" is: "make them a standard Windows account, not an administrator." The advice is well-meaning and wrong. A standard account can still uninstall every Steam game on the PC.

This post explains why. It also covers the other four things people suggest in the same threads: Steam Family Sharing, Windows parental controls, AppLocker, and Software Restriction Policies. None of them block uninstalls. At the end, a short section on what actually works.

Standard accounts can delete files they own

A standard Windows account is restricted from system-wide actions: installing drivers, modifying Program Files, changing global settings, writing to the registry's HKLM hive. That is what UAC and the admin/standard distinction is for.

Deleting files in a folder you can write to is not a restricted action. It never was. Steam's default install path on modern Windows is C:\Program Files (x86)\Steam\steamapps\common\, and Steam sets those folders to be writable by the installing user so it can patch, update, and — yes — uninstall games. Any account that can write to the folder can delete it.

Standard accounts also include full read/write/delete access to anything underC:\Users\{their name}, and Steam libraries on secondary drives (D:\SteamLibrary, etc.) are almost always owned by whichever account created them, which means delete access. None of this requires admin rights.

So "make them a standard user" blocks them from installing malware. It does not block them from right-clicking a game in Steam and hitting Uninstall.

Steam Family Sharing is not an uninstall lock

Steam Family Sharing (and its replacement, Steam Families) lets one account lend its library to others on the same PC. The second account can play your games without owning them. It is a licensing feature. It has nothing to do with file permissions. The underlying game files still live insteamapps/common/, and whoever has write access to that folder can delete them.

Family View (the PIN-locked parental mode inside Steam) restricts what the Steam client UI shows — not what Windows lets the user do. They can close Steam, open File Explorer, and delete the game folder directly. Or open a different Steam account on the same PC and uninstall from there. Family View is a shell lock, not a file lock.

Windows parental controls and Microsoft Family Safety

Microsoft Family Safety can block apps from launching, filter web content, set screen time limits, and restrict purchases on the Microsoft Store. It cannot prevent a user from deleting files they have write access to. That was not what it was designed for.

You can block Steam itself from launching under Family Safety, but the files are still deletable through File Explorer, PowerShell, or any other tool. And if you block Steam, the person you are protecting the library for cannot play the games either, which defeats the point on a shared PC.

AppLocker and Software Restriction Policies

AppLocker (Windows Pro/Enterprise) and the older Software Restriction Policies let an admin block specific executables from running for specific users. The usual suggestion is: "block Steam.exe from running for the kid's account."

Two problems. First, same as above: blocking Steam does not protect the files, it just prevents that user from opening Steam. They can still delete the folder from File Explorer. Second, if the intent is to let them play but not uninstall, blocking Steam.exe obviously fails — they cannot play either.

There is no AppLocker rule for "allow this user to run Steam, but deny the Uninstall action." Steam does not expose Uninstall as a separate executable. It is a function inside the same steam.exe binary that serves everything else.

NTFS deny-delete permissions — the right lock

The feature that actually works is already built into Windows: NTFS permissions. Every file and folder on NTFS (which means every Windows SSD/HDD on any PC made in the last 25 years) has an ACL — an access control list — that lists which accounts can read, write, modify, or delete.

You can add a deny-delete rule that says: "the Users group cannot delete files in this folder." Steam, running as that user, then gets an "access denied" error when it tries to remove the game. The game stays installed. The user can still launch it. Steam can still patch it because patching writes and modifies files — it does not delete them. SYSTEM and admin accounts are untouched by the rule, so Windows updates and driver installs continue to work.

You can set this manually with icacls (a command-line tool built into Windows). It is tedious and easy to get wrong. Most people who try it either set the rule too broadly (blocking SYSTEM, which breaks updates) or set it on the wrong level (the Steam install folder, which gets wiped when the user reinstalls Steam).

What about Deep Freeze and reboot-to-restore?

Deep Freeze and Reboot Restore Rx do protect games, but by reverting the entire drive on every reboot. This means if Steam, Windows, or the game gets a patch during a session, that patch is gone after the next reboot. To apply updates, you put the PC into "thaw" mode (unprotected), reboot, update, re-freeze, reboot again. On a 20-PC cafe, that is 80 reboots per update cycle.

Full comparison: Deep Freeze vs GamePinned.

What actually stops a Steam uninstall

• NTFS deny-delete ACL on the game folder for the users you want to block
• SYSTEM and admins not in the blocked set, so Steam and Windows updates work
• A watchdog that re-applies the ACL if anything removes it
• Steam launched as the logged-in user, not as admin (admin processes bypass per-user deny rules)

Every item on that list is automated in GamePinned. The free plan handles one game permanently. Paid plans cover the entire library plus anything installed later.