PRACTITIONER GUIDE | ENDPOINT SECURITY
Practitioner GuideUpdated 10 min read

Removing Local Admin Rights from Users: How to Enforce Standard User Accounts Without Breaking Everything

86% of critical vulnerabilities
in Microsoft products reported in 2023 would have been mitigated by removing admin rights from users, according to BeyondTrust's annual Microsoft Vulnerability Report. Running as a standard user does not prevent exploitation but prevents exploitation from resulting in full system compromise
Restricted Groups GPO
is the Group Policy mechanism for controlling local group membership. Setting the local Administrators group membership via Restricted Groups ensures that even if an attacker or application adds itself to local Admins, the next Group Policy refresh removes it. It is the authoritative enforcement mechanism for local admin membership
LAPS + standard users
is the recommended pairing. LAPS manages the unique local Administrator password per machine (so it cannot be reused for lateral movement); standard user enforcement ensures regular users cannot elevate to use local admin rights. Together they address both the lateral movement and local privilege abuse attack surfaces
UAC Prompt for credentials
is the more secure UAC behavior (requires entering admin credentials for elevation) compared to the default 'prompt for consent' (just click Yes). On workstations where users are standard users, UAC prompts for credentials already because standard users have no admin token -- the harder setting primarily affects users who ARE admins but shouldn't be

SponsoredRetool

Retool's new app builder is where AI-generated code ships safely

Building apps with AI is easy. Getting them to production safely is another story.

Start building for free today

Most endpoint malware infections rely on the user running as a local administrator. If the user is a standard account, malware cannot persist in HKLM registry keys, cannot modify system directories, cannot install drivers or services, and cannot disable security software without triggering an elevation prompt. The application compatibility objection to standard user enforcement -- 'some applications need admin rights' -- is valid but manageable. The question is not whether any applications need elevation, but whether those elevation requirements justify giving every user permanent local admin rights on every machine.

Audit Who Has Local Admin Rights Across the Fleet

Before removing anything, inventory the current state.

# Check local Administrators group members on a single machine
Get-LocalGroupMember -Group 'Administrators'

# Audit local Administrators group across all workstations
$workstations = Get-ADComputer -SearchBase 'OU=Workstations,DC=domain,DC=com' -Filter *
$results = @()
foreach ($ws in $workstations) {
    try {
        $members = Invoke-Command -ComputerName $ws.Name -ScriptBlock {
            Get-LocalGroupMember -Group 'Administrators' | ForEach-Object {
                [PSCustomObject]@{
                    Computer = $env:COMPUTERNAME
                    Member = $_.Name
                    PrincipalSource = $_.PrincipalSource
                    ObjectClass = $_.ObjectClass
                }
            }
        } -ErrorAction Stop
        $results += $members
    } catch {
        Write-Warning "Unreachable: $($ws.Name)"
    }
}

# Filter for domain users (not service accounts or domain groups)
$results | Where-Object {
    $_.PrincipalSource -eq 'ActiveDirectory' -and
    $_.ObjectClass -eq 'User' -and
    $_.Member -notlike '*service*' -and
    $_.Member -notlike '*admin*'
} | Export-Csv C:\LocalAdminAudit.csv -NoTypeInformation

This gives you a list of regular user accounts with local admin rights. Sort by frequency (how many machines a user has admin rights on) -- users with local admin on many machines are higher priority for removal.

Remove Local Admin Rights via Group Policy Restricted Groups

Restricted Groups GPO overwrites the local Administrators group membership on every policy refresh.

Group Policy path: Computer Configuration > Windows Settings > Security Settings > Restricted Groups

Right-click > Add Group:

  • Group: Administrators
  • Members: Specify who should be in the local Administrators group:
    • BUILTIN\Administrator (the built-in local admin account)
    • DOMAIN\Domain Admins (for domain admin access)
    • DOMAIN\IT-Local-Admin-Group (if you want specific IT staff to have local admin)
    • Do NOT include: individual user accounts

If a user is currently in local Admins on a machine and your GPO does not list them in the Restricted Groups configuration, they will be removed on the next policy refresh.

Alternative approach: Local Users and Groups preference (more granular): Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups

  • New > Local Group
  • Group name: Administrators
  • Action: Update
  • Remove the current user checkbox: unchecked (but specify the exact membership) This approach does not overwrite the entire group -- it adds or removes specific members without touching others.
Free daily briefing

Briefings like this, every morning before 9am.

Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.

Handle Applications That Require Elevation

Standard user enforcement will break some applications. Common scenarios and solutions:

Legacy application requires admin rights to run:

  • Check if the application can be installed in a per-user location (AppData) rather than Program Files -- many older apps work correctly as standard user if installed to a per-user path
  • Use Microsoft Application Compatibility Toolkit to create a compatibility shim that elevates silently for the specific executable
  • Use Windows Installer repair with elevated privileges (the SYSTEM account can apply it) rather than running the app elevated
  • If the application genuinely cannot run without admin rights: create an Application Virtualization (App-V) package or use a terminal server/virtual desktop for that application

Approved software that needs installation: For planned software installations, use your software deployment tool (SCCM, Intune, Chocolatey) to deploy as SYSTEM -- standard users do not need local admin to receive SCCM/Intune-delivered software.

Ad-hoc elevation for specific tasks: For individual users who occasionally need elevation for specific legitimate tasks (IT staff on managed machines, power users), use a PAM tool that provides time-limited, approved elevation:

  • CyberArk Endpoint Privilege Manager
  • BeyondTrust Privilege Management for Windows
  • Thycotic Privilege Manager These allow standard users to request elevation for specific executables, with approval workflow and full audit trail.

Document exceptions: For each application exception, document: the application name, why it needs elevation, who approved the exception, and when it should be reviewed for remediation.

Harden UAC to Prevent Elevation Abuse

UAC hardening matters even after removing local admin rights -- it protects against elevation prompt manipulation for the remaining admin accounts.

Key UAC Group Policy settings: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

  • User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode

    • Recommended: Prompt for credentials on the secure desktop
    • This requires admins to enter their password for elevation, not just click 'Yes'
    • The secure desktop prevents screen capture or click-jacking of the UAC prompt
  • User Account Control: Behavior of the elevation prompt for standard users

    • Recommended: Prompt for credentials on the secure desktop
    • Standard users see a credential prompt when elevation is needed -- they can call IT or use a separate admin credential
  • User Account Control: Run all administrators in Admin Approval Mode

    • Enabled (this is the setting that makes UAC work -- do not disable it)
  • User Account Control: Switch to the secure desktop when prompting for elevation

    • Enabled (prevents click-jacking of UAC prompts by malicious foreground windows)
  • User Account Control: Detect application installations and prompt for elevation

    • Enabled (catches installer packages that would otherwise run silently)
# Verify UAC settings on an endpoint
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' |
    Select-Object EnableLUA, ConsentPromptBehaviorAdmin, ConsentPromptBehaviorUser, PromptOnSecureDesktop
# EnableLUA = 1 (UAC enabled)
# ConsentPromptBehaviorAdmin = 1 (prompt for credentials, not just consent)
# ConsentPromptBehaviorUser = 1 (prompt for credentials on standard user elevation)
# PromptOnSecureDesktop = 1 (use secure desktop)

The bottom line

Local admin removal is a three-phase project. Phase 1: audit who has local admin rights via PowerShell. Phase 2: deploy Restricted Groups via GPO to enforce the desired local Administrators group membership, starting with a pilot OU, then fleet-wide. Phase 3: handle application exceptions with either per-user installation paths, SCCM/Intune software deployment, or a PAM tool for approved elevation. Pair with LAPS to ensure the local Administrator account has a unique password per machine that cannot be used for lateral movement after the user's domain credential is removed from local Admins.

Frequently asked questions

Will removing local admin rights break application installations for end users?

Yes, for applications installed by the user (downloaded installers, ad-hoc installations). The answer is to route software delivery through your software deployment tool (SCCM, Intune) where the installation runs as SYSTEM, not as the user. End users request software through a portal, IT approves and deploys it centrally. This is a workflow change, not just a technical change -- it requires communicating to users that they should request software through the helpdesk rather than downloading and installing it themselves. The security benefit (preventing unauthorized software installation) is also the user experience change.

Can I give users local admin rights on their own machine but not on other machines?

That is the current default state in most organizations, and it is still a significant security problem. A user with local admin on their own machine can: disable security software (Defender, EDR agents), install persistence mechanisms, modify firewall rules, read credential stores, and provide a local admin account for Pass-the-Hash to reach that specific machine. The goal is to remove local admin from users entirely and manage privileged access through LAPS (for IT break-glass access), domain admin accounts via PAWs (for IT administration), and a PAM tool for application-specific elevation. User should not have persistent local admin on any machine.

How do I handle the transition period when removing local admin from power users?

Communicate early and give a transition window. Common approach: announce three months ahead that local admin rights will be removed on a specific date. Send a survey to users asking them to identify applications or tasks they currently use admin rights for. Review each response and classify: can be resolved via software deployment tool (most cases), needs a PAM elevation exception (specific business cases), or needs IT to redesign the workflow. Give users two to four weeks notice before the actual removal date. Prepare your help desk for an increase in elevation-related tickets in the first two weeks. The call volume drops off quickly as the common cases are resolved.

Does removing local admin rights prevent all malware from running?

No. Malware can still execute in the user's context (AppData, Downloads, user profile directories), exfiltrate data the user has access to, send email as the user, and use the user's credentials for lateral movement to network resources. What standard user enforcement prevents is: kernel-level rootkit installation, system directory modification, security software disabling, registry HKLM persistence, driver installation, and many lateral movement techniques that require local admin rights on the target. It raises the cost and complexity of an attack significantly without being a complete defense -- it should be paired with EDR, application allowlisting, and LAPS.

How do I handle software installation requests after removing local admin rights?

Establish a software catalog and a request-and-approval workflow. Provide users a self-service portal (Microsoft Endpoint Manager Company Portal, Ivanti Neurons, or a similar tool) where they can install pre-approved applications without admin rights. For applications not in the catalog, implement a request workflow: user submits a request with business justification, IT evaluates and either adds the app to the catalog (packaged as a silent install) or provides a time-limited elevation via a PAM tool (CyberArk, BeyondTrust, Endpoint Privilege Management). The elevation approach grants temporary admin rights for a specific approved application install and revokes it automatically. Never give users persistent local admin back -- time-limited elevation addresses the legitimate use cases without restoring the security gap.

How does UAC work and why doesn't it substitute for removing local admin rights?

User Account Control (UAC) is a Windows mechanism that prompts for elevation when a process requires administrative privileges, even if the logged-in user is a local administrator. It creates two tokens for admin accounts: a filtered standard user token (used for most operations) and a full administrator token (used only when the user consents to an elevation prompt). The limitation: UAC is a consent mechanism, not a security boundary. A local admin user can always approve their own UAC prompt, so UAC does not prevent a local admin from elevating any process. Malware running in the user's context can trigger UAC prompts that the user approves thinking they are legitimate. UAC auto-elevation (for Microsoft-signed binaries) and UAC bypass techniques (dozens of documented bypasses exist) further reduce its security value as a standalone control. The correct mental model: UAC reduces accidental privilege escalation by non-malicious users; it does not stop a motivated attacker or malware on a machine with a local admin account.

Sources & references

  1. Microsoft -- User Account Control overview
  2. CIS -- Standard Local Administrator Account Management

Free resources

25
Free download

Critical CVE Reference Card 2025–2026

25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.

No spam. Unsubscribe anytime.

Free download

Ransomware Incident Response Playbook

Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.

No spam. Unsubscribe anytime.

Free newsletter

Get threat intel before your inbox does.

50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.

Unsubscribe anytime. We never sell your data.

Eric Bang
Author

Founder & Cybersecurity Evangelist, Decryption Digest

Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.

Black Hat Giveaway

Win a $2,495 Black Hat pass.

Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.

Joins Decryption Digest daily briefing. Unsubscribe anytime.

Giveaway: Black Hat USA 2026 Full-Access Pass ($2,495 value)

Details →
Daily Briefing

Subscribe to enter the giveaway

Every subscriber is automatically entered. You also get daily threat intel every morning: zero-days, ransomware, and nation-state campaigns. Free. No spam.

Already subscribed? You're already entered.

Giveaway

Win a $2,495 Black Hat USA 2026 pass.