Make This the Year You Remove Local Admin Rights on Windows (For Real)

Every January, IT and security teams write the same resolutions:

“We’ll finally get rid of unnecessary local admin.”
“We’ll move closer to least privilege on our Windows estate.”
“We’ll sort out those legacy apps that only work as admin.”

Then real life happens. Projects land, audits appear, someone needs “just a bit of admin” to keep a line-of-business app working, and the resolution quietly slips to next year’s list.

This post is about turning “remove local admin rights” from a vague aspiration into a practical New Year’s plan you can actually execute – without breaking users or rewriting every legacy Windows application you own.

We’ll link to some of our existing posts along the way, including:

Why “remove local admin” is a perfect New Year’s resolution

If you had to pick one endpoint security change that gives you a big jump in risk reduction without replacing half your tooling, removing standing local admin rights is hard to beat.

Dropping users out of the local Administrators group:

Reduces the blast radius of a compromised account or phishing email.
Makes it harder to disable defenses, tamper with logs, or install persistent malware.
Plays nicely with modern Windows features like Administrator Protection and Intune Endpoint Privilege Management.
Helps satisfy regulatory expectations around least privilege.

We cover the wider risk picture in The Double-Edged Sword of Local Admin Rights, but the short version is simple: fewer admins means fewer ways for an attacker (or a mistake) to cause damage.

Step 1: Be honest about where you are today

New Year’s resolutions fail when they start from fantasy. So first: get a clear view of your current local admin reality.

At a minimum, answer these questions:

Which users are in the local Administrators group? Across laptops, desktops, VDI, RDSH, and servers.
Why? What’s the stated reason they “need” admin rights?
Which applications truly break without admin? Not just “we’ve always done it this way”, but actual failures.

In Removing Local Admin Rights Without Disrupting Business (Part 1) we walk through a simple discovery process. Often you’ll find the same patterns:

Legacy Windows apps that assume full file system or registry access.
Power users and developers running everything as admin “just in case”.
Old troubleshooting exceptions that quietly became permanent.

This list is your starting point. Don’t overcomplicate it. You just need enough detail to avoid surprising people when you start making changes.

Step 2: Turn myths into a plan

Once you’ve got the list, the next barrier is psychological. We covered five common objections in Five Myths About Removing Local Admin Rights on Windows:

“Ticket volume will explode forever.”
“Developers must be local admins.”
“We can’t touch that legacy app.”
“We have EDR and LAPS, so we’re fine.”
“It’s too big a project; we’ll do it later.”

Your job is to turn each myth into a concrete response:

Tickets: yes, there will be a spike – so start with a small pilot group and have a clear escalation path.
Developers: give them controlled elevation and a good toolset, not full-time admin.
Legacy apps: decide case by case: fix them, contain them, or broker elevation just for that executable.
Tooling: use EDR, LAPS, and Intune EPM to support least privilege, not to justify standing admin.

This turns “we can’t” into “here is how we’re going to do it safely.”

Step 3: A realistic 90-day roadmap

Instead of a huge, multi-year project, treat “remove local admin” as a 90-day New Year’s experiment with clear milestones.

Days 1–30: Discover and pick your first wins

Run your local admin inventory and group membership reports.
Talk to a handful of key users: “Which apps actually break if we remove admin?”
Pick 10–20 machines and 2–3 applications for a pilot.

Days 31–60: Put elevation in place and remove admin for the pilot

For each pilot app, decide:
- Can we fix it quickly?
- Do we need to contain it (e.g. dedicated host)?
- Or should we broker elevation just for this app?
Implement your elevation approach:
- Use Intune EPM where you already have it.
- Use a focused tool like Elevator to elevate exactly those legacy apps for standard users.
Remove local admin group membership for the pilot users.

Days 61–90: Measure, adjust, scale

Track tickets from the pilot group and compare to their baseline.
Gather feedback:
- Which workflows felt painful?
- Did any new apps surface that need elevation rules?
Use the evidence to:
- Refine your elevation policies.
- Plan the next wave of users or departments.

The goal is not perfection. The goal is to move from “we should remove local admin one day” to “we have already removed it for 20 people and it’s fine; now we’re scaling up.”

Step 4: Use the platform features you already have

If you’re on modern Windows builds, you already have features that support least privilege:

Windows 11 Administrator Protection makes elevation safer by using a system-managed admin context instead of leaving admin tokens lying around.
Intune Endpoint Privilege Management gives you a policy engine for elevation on Intune-managed devices.
LAPS helps manage local admin passwords where they still exist.

We talk about how these fit together in Windows 11 Administrator Protection, Intune EPM, and the Legacy Apps They Still Can’t Fix.

The key point: these features work best when you are actively reducing the number of users with permanent admin rights, not keeping the status quo.

Step 5: Handle the last-mile problem with Elevator

For many organizations, the hardest part of this resolution is not the tooling or the policies. It’s the last mile:

Three legacy Windows applications that “only work as admin”.
Two specialist teams who swear they cannot live without full local admin.
A handful of old install and repair routines that trigger UAC elevation unexpectedly.

This is exactly the gap we designed Elevator for Windows to fill.

Elevator lets you:

Keep users as standard users day-to-day.
Define a short, explicit list of applications that should run with admin rights.
Elevate only those applications – not the entire user session.
Log elevation events so you know who is running what, and when.

In other words, the app gets the admin rights it still needs; the user doesn’t. That gives you a practical way to make progress on your New Year’s resolution without waiting for every vendor to modernise their software.

If you want to start small, you can download an Elevator trial, choose two or three of your worst-behaved legacy apps, and test what it feels like to run them under controlled elevation while users are standard.

Make “remove local admin” the resolution you actually keep

You don’t need a perfect CMDB, a huge project team, or a brand new tool stack to start. You need:

Honest visibility into who has local admin and why.
A small pilot group and a 90-day plan.
A way to handle stubborn legacy apps without giving users full admin rights.

If this becomes the year you finally move away from “everyone is an admin”, your future incident response, audit findings, and upgrade projects will all thank you.

And if you want a Windows-focused helper along the way, we’d love you to try Elevator and see how it fits into your own least-privilege journey.

Share the Post: