Remove Local Admin Rights Across Every Client

What local admin rights give an attacker

Local admin on a workstation is what turns one compromised user into the credentials and tools of everyone else who uses that machine. Taking it away closes off unapproved software installs, in-memory credential theft and a range of persistence techniques at once.

Three primary sources make the case without any vendor statistics:

MITRE ATT&CK on credential dumping from memory: the credentials Windows keeps in the memory of the Local Security Authority Subsystem Service (LSASS) after a sign-in "can be harvested by an administrative user or SYSTEM". A standard user can't dump them. On a machine where a technician has signed in, that is the difference between one compromised user and a compromised technician.
FBI and CISA on Scattered Spider (November 2023): the group deploys remote monitoring and management tools "to then maintain persistence", the advisory lists Mimikatz among the tools it uses to extract credentials, and the agencies' mitigations include "Require administrator credentials to install software." An MSP reads that twice: the persistence tool is the same category of software you run.
NSA and CISA, Top Ten Cybersecurity Misconfigurations (October 2023): number two is "improper separation of user/administrator privilege". The mitigations include "reduce, restrict, audit, and monitor administrative accounts and privileges", time-based and just-in-time privileged access, and not reusing local administrator passwords across systems.

The standard most clients will be measured against says the same thing. The CIS Controls safeguard on administrator accounts (5.4) is "Restrict Administrator Privileges to Dedicated Administrator Accounts", and it sits in Implementation Group 1, which CIS defines as "essential cyber hygiene", a minimum standard for all enterprises.

Step 1: find every local admin

Start with an inventory, per client and per device, of who is in the local Administrators group. The list usually holds more than the users you'd expect: leftover vendor accounts, the person who joined the machine to Entra, old technician accounts and security identifiers (SIDs) for accounts that no longer exist.

The quickest way across a fleet is a script pushed through your RMM. The built-in cmdlet is:

Get-LocalGroupMember -Group "Administrators"

Two things trip it up on real client machines:

32-bit script hosts. Microsoft's documentation says the LocalAccounts module isn't available in 32-bit PowerShell on a 64-bit system. If your RMM runs scripts in a 32-bit process, call the 64-bit host explicitly: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe.
Orphaned SIDs. If the group holds a SID that no longer resolves (a deleted domain account, a removed Entra user), the cmdlet can fail with "Failed to compare two elements in the array". The problem was reported in the PowerShell repository in 2017 and closed without a fix, and administrators were still reporting it on Windows 11 in 2023. The workaround commenters on that issue use is the older net localgroup Administrators command.

Record the result per client with a date. It is your baseline, and the first thing an insurer or auditor will ask for is the before and after.

Don't forget the machines Active Directory can't see. Workgroup machines at small clients, and Entra-joined laptops at clients who never had a domain, only show up through the RMM or an endpoint client.

Step 2: stop new admins being created

On Entra-joined devices, the person who joins the device becomes a local admin by default. If you skip this step, every new laptop undoes the work.

Microsoft's documentation lists three principals added to the local Administrators group at Entra join: the Microsoft Entra Joined Device Local Administrator role, the Global Administrator role, and "the user performing the Microsoft Entra join". Two ways to stop the third:

In each client tenant, set the device registration policy so registering users are not added as local administrators.
If the client uses Windows Autopilot, set the deployment profile so the primary user isn't a local admin.

Also look at who holds the Microsoft Entra Joined Device Local Administrator role in each tenant. Microsoft's description is that "users assigned to this role are added to the local administrators group on Microsoft Entra joined devices." A technician with that role assigned permanently has standing admin on the client's Entra-joined fleet.

Changes here are not instant. Microsoft notes it can take up to 4 hours for a new Primary Refresh Token with the changed privileges, and the user has to sign out and sign back in; locking the screen and signing back in doesn't refresh it.

Step 3: remove the rest by policy, not by hand

Removing users from the Administrators group by hand lasts until the next helpful technician adds one back. Set the membership by policy so it is reapplied every time the device checks in. The tool depends on how the device is joined.

Active Directory-joined devices: Group Policy

Use Group Policy Preferences: Computer Configuration, Preferences, Control Panel Settings, Local Users and Groups, New, Local Group, Group name "Administrators (built-in)". Choose the action Update, tick "Delete all member users" and "Delete all member groups", then add back only the groups that should be there (your break-glass group and the account LAPS manages).

Link the Group Policy Object (GPO) to the OU that holds the computer objects, not the users. In a Microsoft Q&A thread on exactly this problem, the accepted answer was to move the link to the OU that holds the computers.

Restricted Groups (Computer Configuration, Policies, Windows Settings, Security Settings) does the same job with a blunter instrument: it replaces the membership outright. Either works; pick one per client and don't run both on the same OU.

Entra-joined and hybrid-joined devices: Intune

Use the Intune endpoint security Account protection policy, profile "Local user group membership". It has three actions, from Microsoft's documentation:

Add (Update): adds members and leaves everyone else alone.
Remove (Update): removes the members you name and leaves everyone else alone.
Add (Replace): replaces the membership. It "works in the same way as a Restricted Group": anyone you didn't list is removed.

Add (Replace) is the one that actually removes local admin rights. If the same group gets both a Replace and an Update action, Microsoft says Replace wins. The profile supports Windows 10 20H2 and later and Windows 11. It works on Entra-joined devices, and on hybrid-joined devices when you enter the members manually. One caveat from the same page: Entra groups deployed with this policy don't apply to remote desktop connections, so RDP permissions on Entra-joined devices need individual user SIDs.

Workgroup machines

No directory, no policy engine. Run the removal as an RMM script on a schedule (Remove-LocalGroupMember -Group "Administrators" -Member <name>), and report on drift every time it runs. If a client has more than a handful of workgroup machines, that is a conversation about joining them to Entra.

Roll it out by client, not all at once

Pilot at one client with a cooperative contact and a small fleet. Run it for two weeks, fix what breaks, then move client by client. Keep a named break-glass group in every Replace policy so you can get back in if the policy goes wrong.

Step 4: put the built-in Administrator under rotation

Every Windows machine keeps a local Administrator account, and in a lot of MSP fleets it still has the same password on every machine at a client, sometimes at every client. Removing users from the Administrators group doesn't fix that. Rotation does.

Windows LAPS manages the password of a local administrator account on Entra-joined or AD-joined devices, and can rotate it after it has been used. It does not remove anyone from the Administrators group; it is a password control for one account, not a membership control. Our guide to rotating service account passwords covers the domain side of the same problem.

If you vault the account instead, the requirements are the same: a unique password per device, rotated on a schedule or on demand, and a record of who accessed it.

Step 5: replace the reasons people had admin

Users had admin rights because something needed them: an installer, a line-of-business app that writes to its own program folder, a printer driver. If you take the right away without replacing the reason, you get a ticket every time, and somebody quietly puts the user back in the group.

The replacement is endpoint privilege management (EPM): the user stays a standard user, and specific applications or tasks get elevated under rules. Microsoft's own version is Intune Endpoint Privilege Management. It is Windows only, it needs Intune advanced capabilities licensing on top of Intune, and it supports five elevation types: automatic, user confirmed, elevate as current user, support approved and deny.

Whatever tool you use, decide three things per client before you switch admin off:

The known list. Applications that elevate automatically, by publisher certificate or file hash, because you've already approved them.
The request path. Everything else gets a request that lands in your PSA as a ticket, with a time limit on the approval.
The deny list. Remote access tools you don't run, and anything else the client has said no to. After the Scattered Spider advisory, an unknown RMM or remote support tool asking for elevation is the request to refuse.

Step 6: move your technicians onto just-in-time accounts

Removing end users' admin rights and leaving your technicians' admin accounts standing moves the risk rather than reducing it. Technician accounts are the ones worth stealing.

Give each technician dedicated admin accounts that are disabled by default, enabled for a task against a ticket, and disabled again when the task ends. The just-in-time admin access guide covers how to do that with Entra PIM, granular delegated admin privileges (GDAP) and Active Directory, and where each one stops.

Step 7: keep the evidence

Once admin rights are gone, the job is proving they stay gone. An insurer, an auditor or the client's own board will ask the same question: who has admin rights on these machines today, and who had them last quarter?

Keep, per client:

the Administrators group membership on every device, with the date it was read, and the baseline from step 1
every elevation request, who approved it and what ran
every exception (the user who still has admin), with an owner, a reason and an expiry date
an alert whenever a user is added to the Administrators group outside policy

The traps that are specific to MSPs

The line-of-business app that "needs admin". Often it needs write access to one folder or one registry key. Find out which, grant that, and the app runs as a standard user. Where it really does need elevation, put it on the known list.
Co-managed clients. The client's internal IT person wants to keep admin. Give them the same just-in-time model as your technicians, or document the exception with an expiry. Don't leave a standing account because the conversation is awkward.
The executive who refuses. Make the exception visible: named, approved by the client contact, reviewed every quarter.
Rollback. A Replace policy with a typo can lock everyone out. The break-glass group in every policy is your way back in. Test it at the pilot client before you need it.

Where this sits in the PAM journey

Removing local admin rights isn't one phase; it runs through most of them. Discovery (phase 1) finds the admins. Remediation (phase 2) removes them by policy. Vaulting (phase 3) and zero-knowledge credential rotation (phase 4) take care of the built-in account. Just-in-time access (phase 6) replaces technician standing admin, audit (phase 7) proves it, and endpoint privilege management (phase 8) handles the elevation requests. The PAM journey hub walks all eight in order.

How CyberQP handles it

Panthera's discovery continuously finds every privileged identity at each client, from admin accounts to end users with hidden admin rights, so the step 1 inventory comes from one place instead of a script per tenant. The removal doesn't need a script either: the CyberQP endpoint client lists the local admins on each Windows or macOS device and lets a technician remove the ones that shouldn't be there. Local admin passwords rotate on a schedule or on demand and are stored in a zero-knowledge vault. Technicians get dedicated just-in-time accounts that are disabled by default and can require a second approval; an account can be linked to a ConnectWise Manage ticket today, with Autotask and HaloPSA coming to Panthera. Endpoint privilege management lets end users on Windows request elevation, which a technician approves or denies or a rule approves automatically, and each request is scored for risk using threat intelligence. Elevation on macOS is coming to Panthera. There's a self-guided tour on removing local admin rights in the product tours.

What done looks like

No end user at any client is a member of the local Administrators group without a named, dated exception.
Group membership is set by GPO or Intune policy, not by hand, and drift raises an alert.
Entra join no longer makes the joining user a local admin in any client tenant.
The built-in Administrator password is unique per device and rotates after use.
Elevation requests land in your PSA, are approved by rule or by a person, and expire.
No technician holds standing local admin rights; they use just-in-time accounts.
For any client, you can produce the before and after membership in one export.

Frequently asked questions

Will removing local admin rights break software?

Some of it, and that's what the pilot is for. Most applications run fine as a standard user. The ones that don't usually need write access to one location, which you can grant directly, or need elevation for an installer or update, which goes on the known list in your endpoint privilege management policy.

Is privilege elevation and delegation management the same as EPM?

Privilege elevation and delegation management (PEDM) and endpoint privilege management (EPM) describe the same job: users work without admin rights, and specific applications or tasks are elevated under policy. Vendors and analysts use both names. Microsoft calls its version Intune Endpoint Privilege Management.

Does Windows LAPS remove local admin rights?

No. Windows LAPS manages and rotates the password of a local administrator account. It doesn't change who is in the Administrators group. You need a membership policy (Group Policy or Intune) to remove users.

How do I remove local admin rights with Intune?

Create an endpoint security Account protection policy with the "Local user group membership" profile, select the Administrators group, and use the Add (Replace) action with only the members you want to keep. Anyone not listed is removed. Separately, set the device registration policy so users who join devices to Entra aren't made local admins.

What about Macs?

Everything on this page is Windows. macOS has its own admin model and its own tools, usually through mobile device management (MDM). Panthera's endpoint client also runs on macOS: discovery finds local admin accounts on Macs, the endpoint client can remove them, local admin credentials can be rotated, and technicians can use just-in-time accounts on Macs. Elevation requests on macOS are coming to Panthera; until then, plan Mac elevation through your MDM.

Sources: MITRE ATT&CK, OS Credential Dumping: LSASS Memory (T1003.001), last modified 12 May 2026; FBI and CISA AA23-320A, Scattered Spider (16 Nov 2023, updated 21 Nov 2023); NSA and CISA AA23-278A, Top Ten Cybersecurity Misconfigurations (October 2023); CIS Controls v8.1; CIS Controls Assessment Specification, Control 5; CIS Implementation Group 1; Microsoft Learn, Get-LocalGroupMember; Microsoft Learn, File System Redirector; PowerShell issue 2996; Microsoft Learn, manage the local administrators group on Entra joined devices (updated 17 Jun 2026); Microsoft Learn, Entra built-in roles; Microsoft Learn, configure a Local Group preference item; Microsoft Q&A, local Administrators via Group Policy Preferences (Nov 2023); Microsoft Learn, Intune account protection policy (updated 15 Apr 2026); Microsoft Learn, Remove-LocalGroupMember; Microsoft Learn, Windows LAPS overview (updated 16 Sep 2026); Microsoft Learn, Windows LAPS concepts; Microsoft Learn, Intune Endpoint Privilege Management (updated 23 Jun 2026). Checked 19 October 2026.