Most IT teams don’t keep users as local admins because they love risk. They do it because one or two applications refuse to behave unless someone has elevated rights.
The good news: “this app needs admin” is usually one of a small set of classic legacy patterns. If you can identify which pattern you’re dealing with, you can often fix it, or at least contain it.
1) Writes to Program Files (or “next to the EXE”)
Many older apps assume they can write logs, config files, databases, or temporary files in the same folder where the app is installed. On modern Windows, that’s typically under Program Files, which is not writable by standard users.
Least-painful fixes:
- Move writable data to %ProgramData% (machine-wide) or %AppData% (per user).
- Update the app to use a proper config location, if the vendor supports it.
- Redirect the app’s data path to a user-writable location (temporary stopgap).
2) Writes to HKLM (machine-wide registry) instead of HKCU
Another classic: the app stores settings under HKLM\Software instead of HKCU. Standard users can’t write to HKLM, so the app “needs admin” just to save preferences.
Least-painful fixes:
- Switch settings to HKCU where possible.
- Use vendor options or compatibility settings to relocate config storage.
- Fix the specific key/permission issue rather than granting broad admin rights.
3) Needs to install a service, driver, or scheduled task
Installing or modifying services/drivers/tasks requires elevation. Some legacy apps do this during first run, on every update, or even every launch.
Least-painful fixes:
- Install services/drivers at deployment time (IT-managed), not at runtime (user-managed).
- Ask the vendor if a user-mode option exists.
- Separate “installer/admin actions” from “daily use.”
4) Hard-coded paths and “C:\” assumptions
Older apps often assume they can write to the root of C:\, create folders anywhere, or store data in custom locations like C:\MyApp. Standard users can’t do that reliably on locked-down systems.
Least-painful fixes:
- Redirect data paths to %AppData% / %ProgramData%.
- Standardize install locations and writable directories via packaging and policy.
- Fix the assumption in configuration if the app supports it.
5) “Updater” logic that runs as the user
Some apps embed self-updaters that try to replace binaries under Program Files, patch registry keys, or install components during normal user sessions. That’s a guaranteed admin prompt (or a broken update).
Least-painful fixes:
- Disable self-updaters and update via your deployment tool (Intune, SCCM, RMM, etc.).
- Use vendor MSI packages designed for managed deployment.
- Keep update workflows separate from day-to-day app use.
6) Assumes “admin session” as a design shortcut
Some apps do a little bit of everything above, not because they truly require admin rights, but because they were built in an era where “everyone is an admin” was the easiest development path.
Least-painful fixes:
- Document what fails under standard user and isolate the minimum elevated action needed.
- Pressure vendors to modernize (it works more often than you’d expect).
- Contain the risk: keep users standard and elevate only the app that needs it.
A practical way forward: keep users standard, elevate only the exceptions
This is the gap most teams fall into:
- They want least privilege and standard users.
- They have 2–10 legacy/specialist apps that still behave like it’s 2005.
- So they keep users as local admins “for now”… and “for now” becomes years.
Where Elevator for Windows fits
At UNYK, we built Elevator for Windows for exactly this situation. Elevator lets you keep users as standard users while still allowing a short, explicit list of approved applications to run elevated.
- Keep users out of the local Administrators group.
- Elevate only the applications you approve.
- Reduce always-admin endpoints.
- Log elevation events so you can see what still depends on admin rights.
A simple 2-week pilot you can actually run
- List your “admin-required” apps and map each one to the patterns above.
- Pick 2–3 apps and a small pilot group.
- Make those users standard and allow only those apps to elevate.
- Track what breaks and whether it’s truly admin or just packaging/config.
If you want to test this approach with your own problem apps:
Start Free 30-Day Trial Request Elevator Pricing
