If you manage Windows endpoints, you have probably heard at least one of these lines:
- “If we remove local admin, our helpdesk will melt down.”
- “Developers must be admins, that is just how Windows works.”
- “We cannot remove admin rights because of that one legacy app.”
They sound reasonable in the moment, but they are mostly myths that keep organizations stuck with unnecessary risk. In earlier posts like The Double-Edged Sword of Local Admin Rights, Common Pitfalls of Over-Privileging Users, and Best Practices for Implementing Least Privilege on Windows, we looked at the risks and the right patterns for least privilege.
This post focuses on the myths themselves: the stories that keep local admin alive long after it should have disappeared.
Myth 1: “If we remove local admin, ticket volume will explode forever”
This is the classic fear. If users lose admin rights, they will open tickets for every printer driver, browser plugin, and minor configuration change. The helpdesk will drown in “please install this” requests and leadership will demand that you “just make them admin again”.
Reality: ticket volume does spike if you flip the switch without a plan. Then it settles down once you put a few guardrails in place. In Removing Local Admin Rights Without Disrupting Business (Part 1) we walk through that planning step: identify who has admin now, which apps and workflows actually break, and piloting on a friendly group instead of the entire estate at once.
Teams that succeed with least privilege do three things:
- Give users a clear path for getting software (software portal, standard catalog).
- Use controlled elevation for a short list of legitimate admin tasks.
- Automate common installs so support is not dragged into every small request.
Done this way, the long term effect is usually fewer tickets, not more. You get rid of the “mystery breakage” caused by unmanaged admin tweaks on endpoints.
Myth 2: “Developers and power users must be local admins”
Developers, engineers, and other power users do need more flexibility than a typical office user. They install tools, debug software, and work with drivers and SDKs. It is easy to jump from that reality to “they have to be full local admins all day”.
Reality: they need controlled elevation, not permanent admin. Your options include:
- Giving them a separate, named admin account that is used only when needed.
- Allowing a curated set of tools to install or run elevated via policy.
- Using a privilege management tool to approve elevation for specific workflows.
Even for technical staff, running everything as admin greatly increases the blast radius if a browser tab or email attachment goes wrong. Moving them to standard user with good elevation workflows reduces risk while still letting them get work done. Our post The Pros and Cons of Making Users Local Admins digs into where full admin really makes sense and where it does not.
Myth 3: “We cannot remove admin rights because of legacy Windows apps”
This one has a kernel of truth. Many environments still rely on older Windows applications that assume the user can write to Program Files, touch HKLM, or register COM components at runtime. We explored this in Why Legacy Windows Apps Still Need Admin Rights (And What To Do About It).
Reality: legacy apps are not a reason to give users full local admin. They are a reason to be more precise about what actually needs elevation. In practice, you usually have three options:
- Fix the app by moving writes to proper locations or working with the vendor.
- Contain the app on dedicated hosts or VMs with tighter controls.
- Broker elevation just for that executable, while keeping the user standard.
That last option is where tools like Elevator for Windows come in. Elevator lets non-admin users run specific legacy applications with the admin rights they still need, without putting those users into the local Administrators group. You define a short, explicit list of executables to elevate; everything else runs as a standard user.
Myth 4: “We already have EDR, LAPS, or Intune EPM, so standing local admin is fine”
Modern security tooling is great: EDR, LAPS, Intune Endpoint Privilege Management, and Windows 11 Administrator Protection all help reduce risk. It is tempting to think that with those in place, leaving people as local admins is an acceptable trade off.
Reality: these tools help manage and monitor privilege, but they do not change the basic math: a compromised local admin account is still a big problem. LAPS protects shared local admin passwords, EDR helps detect malicious activity, and Intune EPM gives you a rules engine for elevation. They are best used to move you toward fewer standing admins, not to justify keeping them.
In our post Windows 11 Administrator Protection, Intune EPM, and the Legacy Apps They Still Cannot Fix, we look at how these features and a focused tool like Elevator can work together: EPM for broad elevation policy, Elevator as a simple “last mile” answer for a small set of stubborn apps.
Myth 5: “Removing local admin is a huge project, we will do it later”
Least privilege sometimes gets treated as a giant, multi-year initiative that needs perfect inventory, perfect tools, and perfect politics before anything happens. So it never starts.
Reality: you can make real progress in weeks by tackling a narrow slice first:
- Identify a small group of machines where users are local admin today.
- List the 2 or 3 applications that actually break if you remove admin rights.
- Use per-app elevation (via Intune EPM rules or Elevator) just for those apps.
- Run a pilot, remove local admin for that group, and measure tickets and user feedback.
This gives you evidence you can show to security, IT leadership, and the business: users stay productive, attack surface shrinks, and the world does not end. From there, you can widen the scope.
Where Elevator fits in
At UNYK, we built Elevator specifically for teams that are stuck on these myths:
- You have a handful of legacy Windows apps that “only work as admin”.
- You want users to run as standard accounts by default.
- You do not want to roll out a heavyweight privilege suite just to fix three applications.
Elevator allows non-admin users to run selected applications with admin rights, based on a list that you control. Users keep their standard accounts, you keep an audit trail of elevation events, and those stubborn apps keep working.
If you are ready to start busting these myths in your own environment, you can learn more on the Elevator product page or start a free trial with a few of your own legacy applications and see how it feels to remove local admin without disrupting the business.
