Join our Newsletter — 33% off our NHI Course
Home› Guides› Endpoint Privilege Management Guide: Removing Local Admin Rights
Guide Endpoint Security

Endpoint Privilege Management Guide: Removing Local Admin Rights

← All guides
By Lalit Choda, NHI Mgmt Group Updated 16 October 2026 15 min read
On this page

A user who is a local administrator on their workstation hands every piece of malware they run the ability to dump credentials, disable defences and persist on the device. Endpoint privilege management (EPM) removes standing local admin rights and replaces them with controlled, logged elevation for the specific tasks people still need. This guide covers how to remove local admin rights without stopping work: elevation rules, how they relate to application control and which to deploy first, managing the built-in Administrator and other local admin accounts, UAC settings, detection and metrics. It is written for endpoint, identity and security engineers, with Windows detail because that is where most local admin sprawl lives, and notes for macOS and Linux.

Key takeaways

  • Standing local admin is an attacker's toolkit. Removing users from the local Administrators group is a listed MITRE ATT&CK mitigation for UAC bypass (T1548.002) and closes off much of credential dumping and local account persistence.
  • Elevate the task, not the person. EPM tools elevate one approved process under a separate context, so the user never becomes a member of Administrators.
  • Rule quality decides the outcome. Hash and publisher rules are strong; file name or user-writable path rules can be abused, and "allow all child processes" turns one approved app into a general admin shell.
  • Audit first, then remove admin, then enforce application control. Run elevation reporting and application control in audit mode together; enforcement of an allowlist on a device whose user is still admin is easy to undermine.
  • Local admin accounts still exist after the project. Randomise and rotate them with LAPS, block their network logon, and alert when anyone joins the local Administrators group.

What local admin rights give an attacker

The Cisco 2022 intrusion investigated by Cisco Talos shows the sequence on a compromised Windows host: the attacker created an account with net user z ... /add, added it with net localgroup administrators z /add, saved the SAM, SYSTEM and SECURITY hives with reg save, dumped LSASS with comsvcs.dll MiniDump, opened RDP in the host firewall with netsh and cleared event logs with wevtutil cl. Every step needs administrative rights. See the Cisco breach 2022.

Attacker technique (ATT&CK)Why admin rights matterEPM-related control
T1548.002 Bypass User Account ControlSilent elevation only helps an attacker if the user's token can be elevatedStandard users; UAC prompt for standard users set to deny; highest UAC level for remaining admins
T1003 OS Credential Dumping (SAM, LSASS)Reading LSASS memory or the SAM hive requires administrative or SYSTEM contextRemove admin; deny rules for dumping tools; alert on SeDebugPrivilege use
T1136.001 Create Account: Local Accountnet user /add and group changes need adminRemove admin; monitor events 4720 and 4732
T1078.003 Valid Accounts: Local AccountsShared local admin passwords allow lateral movement across machinesLAPS unique passwords; deny network and RDP logon for local admin accounts
Defence impairment (disable tools, clear logs)Stopping security services and clearing the Security log need adminRemove admin; forward logs off the host

Approaches to removing local admin

There is no single control. Most organisations combine several of these, by persona.

ApproachHow it worksStrengthsLimitsFits
Standard user, IT does all installsNo elevation path for users; software comes from a managed catalogueSimplest and strongestTicket volume; slow for edge casesInformation workers, kiosks, frontline
Separate admin accountUser has a second, admin-only account entered at the UAC credential prompt or with runasNo extra tooling; satisfies CIS Safeguard 5.4Admin account is a reusable credential; tends to be used for everythingIT staff on dedicated admin workstations
EPM elevation rulesAgent elevates approved files on demand (automatic, user confirmed or support approved)Granular, logged, no admin group membershipAgent cost and rule maintenance; weak rules can be abusedMost of the workforce, developers, engineers
Just-in-time adminUser is added to local Administrators for a time window after approvalHandles tasks no rule anticipatesWhole session is admin during the windowSupport technicians, break-fix
LAPS-managed local accountA single rotated local admin account, password retrieved from the directoryRecovery and offline support without shared passwordsNot a day-to-day elevation methodEvery managed device

EPM is sold as standalone agents, as modules of PAM suites, and as OS or MDM-native features such as Microsoft Intune Endpoint Privilege Management. The concepts below use Intune's documented settings as a worked example; other tools use similar constructs under different names. See the PAM Buyer's Guide.

Designing elevation rules

  • Elevation types: Intune offers Automatic (no prompt), User confirmed (the user picks "Run with elevated access" and can be asked for a business justification and Windows authentication), Support approved (an administrator approves a request), Elevate as current user, and Deny. Microsoft recommends automatic elevation "be used sparingly, and only for trusted files that are business critical".
  • Elevation context: most Intune elevation types run the process under a virtual account isolated from the user, and neither account is added to Administrators. Elevate as current user runs under the user's own account, so prefer the virtual account unless an application breaks.
  • Default response: decide what happens to files with no rule. Intune's options are Deny all requests, Require user confirmation and Require support approval; Not Configured behaves as Deny all requests.
  • Child processes: the default, Require rule to elevate, makes each child process match its own rule. Allow all child processes to run elevated skips rule evaluation for children, including deny rules, so an elevated installer or IDE can launch an elevated shell.
  • Arguments: restrict arguments to an allow list for tools such as msiexec.exe or powershell.exe where the binary is trusted but some switches are dangerous. Never put secrets in rule arguments.
  • Scope: assign rules by persona (finance, engineering, developers) so one group's needs do not become everyone's privileges.
Rule attributeStrengthRisk and guidance
File hashStrongestMicrosoft calls hash rules "the strongest rules" and requires a hash for automatic rules; must be updated on every new version
Publisher certificate plus product and minimum versionStrongSurvives updates; trusts everything the publisher signs that matches, so pin product name and version
Certificate authority onlyWeakTrusts any file signed under that CA; avoid for elevation
File pathDepends on the folderUse only locations standard users cannot write to, such as C:\Program Files
File nameWeak aloneMicrosoft warns file names are "highly susceptible to change"; any user who can write to the folder can rename a file

Application control and deployment order

Practitioners often ask whether to deploy application allowlisting before or after removing local admin rights. The two controls answer different questions: EPM decides what may run with admin rights; application control (CIS Safeguards 2.5, 2.6 and 2.7 cover software, libraries and scripts) decides what may run at all. The order that works in practice:

  1. Audit both together. Turn on EPM reporting and an application control policy in audit mode. Elevation data shows which installers and tools people actually elevate; App Control for Business audit events (3076) show what an allowlist would block.
  2. Remove local admin next. A local administrator can change local policy, stop services and install drivers, so an allowlist on an admin's device is easier to undermine. ATT&CK lists removing users from the local administrator group as a mitigation for UAC bypass.
  3. Enforce application control last, starting with devices that have the most stable software sets, using the rules learned from both audits.

On Windows, Microsoft states that App Control for Business is designed as a security feature under MSRC servicing criteria, while AppLocker "doesn't meet the servicing criteria for being a security feature". Use App Control where you can, with managed installer rules so software deployed by your management tool is trusted automatically; AppLocker remains useful for per-user rules on shared machines.

The built-in Administrator and other local admin accounts

Removing users from Administrators does not remove local admin accounts. The built-in Administrator (RID 500) cannot be deleted or locked out; Windows setup disables it, and renaming it does not hide it because the SID stays the same.

  • Randomise and rotate with Windows LAPS: built into Windows 11 and Windows 10 (from the April 11, 2023 update) and Windows Server 2019 onwards, backing up to Microsoft Entra ID or Active Directory, not both. Legacy Microsoft LAPS is deprecated and its MSI is blocked on Windows 11 23H2 and later.
  • Block lateral use: set "Deny access to this computer from the network" and "Deny log on through Remote Desktop Services" to "Local account and member of Administrators group", and keep LocalAccountTokenFilterPolicy at 0 so local accounts cannot use C$, ADMIN$ or remote administration over network logon.
  • Control retrieval: LAPS passwords in Entra ID are readable by default by Global Administrator, Cloud Device Administrator and Intune Administrator. Grant retrieval to a narrower help-desk role and audit every read.
Windows LAPS settingDefaultSuggested position
BackupDirectory0 (disabled)1 (Entra ID) or 2 (Active Directory)
PasswordAgeDays3030 or less (minimum 7 with Entra ID backup)
PasswordLength / PasswordComplexity14 / 4At least 14 with complexity 4, or a passphrase option (6 to 8) on Windows 11 24H2 and later
PostAuthenticationActions3 (reset password and sign out)3, or 11 to also end processes running as the account (24H2 and later)
PostAuthenticationResetDelay24 hoursShorter, such as 2 to 8 hours; 0 disables post-use rotation
ADPasswordEncryptionEnabledTrueTrue (needs 2016 domain functional level); keeps password history
AutomaticAccountManagementEnabledFalseConsider on 24H2 and later to have LAPS create and manage a custom admin account

Operating system settings for standard users

Windows User Account Control

User Account Control gives administrators a split token, so processes run as standard user until approved. Microsoft states "the recommended and more secure method of running Windows, is to ensure your primary user account is a standard user." The key Group Policy settings under Security Options:

  • User Account Control: Behavior of the elevation prompt for standard users: Microsoft's best practice is "Automatically deny elevation requests". Where IT staff use a separate admin account, "Prompt for credentials on the secure desktop" is acceptable. EPM agents present their own prompt, so the deny setting does not block managed elevation.
  • User Account Control: Run all administrators in Admin Approval Mode: keep enabled; disabling it turns UAC off.
  • User Account Control: Switch to the secure desktop when prompting for elevation: keep enabled, as Microsoft recommends.
  • Behavior of the elevation prompt for administrators in Admin Approval Mode: for remaining admins, prompting for credentials rather than consent stops click-through approval.

macOS and Linux

  • macOS: the same principle applies: users as standard accounts, with elevation through an EPM agent or MDM workflow. Remove admin at enrolment rather than retrofitting it later.
  • Linux sudo: sudo caches authentication for 5 minutes by default (timestamp_timeout) and logs to syslog. Avoid ALL and NOPASSWD for people, use Cmnd_Alias to grant specific commands, use sudoedit instead of granting editors (editors and shells allow escapes), and enable log_output for privileged sessions, since I/O logging is off by default.

Where identity fits

Local admin accounts, help-desk accounts that are local admin everywhere, and services running as local administrators are identities with standing privilege, usually outside identity governance. Inventory them with the same rigour as domain accounts: owner, purpose and last use. Services installed as local admin should move to a managed service account or virtual account with only the rights they need. See the Service Account Security Guide. Time-bound admin for support staff is a just-in-time pattern; see the JIT Access Guide.

Phased rollout

  1. Measure the starting point: count members of the local Administrators group on every device, separating IT, users, service accounts and unknown SIDs.
  2. Deploy the agent in audit: in Intune this means an elevation settings policy with Reporting scope "Diagnostic data and all endpoint elevations", which captures unmanaged elevations by current admins.
  3. Identify personas and build rules from the reports, starting with the top elevated files by volume.
  4. Pilot ring: remove admin from IT staff's daily accounts first, then a willing business unit. Default response: Require user confirmation with business justification, or support approval for higher-risk groups.
  5. Expand in rings of a few hundred devices, watching elevation request volume and help-desk tickets per ring.
  6. Tighten: convert frequently confirmed elevations to hash or publisher rules, and move the default response towards support approval or deny.
  7. Rollback: manage group membership centrally (Intune Local users and groups, or Group Policy) so a ring can be restored by removing it from the policy assignment; keep LAPS retrieval working for device-level recovery.

Small organisations can often reach standard users with no EPM agent: a managed software catalogue, LAPS and a separate admin account for the one or two IT staff. Large organisations need an agent, persona-based rules, a support-approval workflow with service-level targets, and reporting to show progress by business unit. Developers usually need the most rules; give them scoped rules for toolchains or a separate managed development environment rather than admin.

Detection and measurement

SignalSourceWhy
4732: A member was added to a security-enabled local groupSecurity log, Audit Security Group ManagementAnyone added to local Administrators outside the managed process
4720: A user account was createdSecurity log, Audit User Account ManagementNew local accounts on workstations (T1136.001)
4688 with Token Elevation Type %%1937Security log, Audit Process CreationProcesses started with an elevated token outside EPM
4672: Special privileges assigned to new logonSecurity log, Audit Special LogonLogons with SeDebugPrivilege and similar by accounts not expected to hold them
3076 / 3077 and 8028 / 8029CodeIntegrity Operational; AppLocker MSI and ScriptApplication control audit and block events for files and scripts
Managed and unmanaged elevationsEPM reportingUnmanaged elevations mean someone still has admin rights

Metrics that show the programme is working:

  • Admin coverage: percentage of devices where no standard user account is in local Administrators (target near 100%, exceptions listed).
  • Unmanaged elevations: count per month, trending to zero outside IT admin workstations.
  • Automatic rule share: proportion of elevations from automatic rules, and how many of those rules use hashes.
  • Support approval time: median minutes from request to decision.
  • LAPS compliance: percentage of devices with a password backed up within PasswordAgeDays.
  • Unexpected 4732 events: each investigated within one working day.

Framework mapping

FrameworkReferenceRelevance
NIST SP 800-53 Rev. 5AC-6(1), AC-6(2), AC-6(5), AC-6(7), AC-6(9), AC-6(10)Least privilege: security functions, non-privileged access for non-security functions, privileged accounts, privilege review, logging privileged functions, preventing standard users executing privileged functions
NIST SP 800-53 Rev. 5CM-7(5), CM-11Allow-by-exception software; user-installed software
NIST CSF 2.0PR.AA-05, PR.PS-05, DE.CM-09Least privilege; unauthorised software prevented; endpoint monitoring
CIS Controls v8.15.4; 2.5, 2.6, 2.7Dedicated administrator accounts; allowlisting software, libraries and scripts
ISO/IEC 27001:2022 Annex A8.2, 8.19Privileged access rights; installation of software on operational systems
MITRE ATT&CKT1548.002, T1078.003, T1136.001, T1003Techniques removed or made harder by standard user plus LAPS

Common failure patterns

  • Broad automatic rules: automatically elevating cmd.exe, powershell.exe or a whole vendor certificate recreates local admin with extra steps.
  • "Allow all child processes" on installers and IDEs: the approved parent launches an elevated shell, and deny rules are skipped.
  • File-name or user-writable path rules: a renamed binary dropped into Downloads matches the rule.
  • Same local admin password on every device: one dump gives lateral movement everywhere (T1078.003), the pattern LAPS exists to remove.
  • IT staff exempted on their daily account: the people with the broadest access browse and read email as admin, contrary to CIS Safeguard 5.4. In the Cisco breach the attacker added a new account to local Administrators and dumped credentials; an unexpected 4732 event is the alert that catches this.
  • Support approval as a rubber stamp: approvals with no check of the file or justification teach users that any request succeeds.

Practitioner checklist

  • Report local Administrators membership on every device and set a removal target by persona.
  • Run EPM reporting and application control in audit mode for at least one full business cycle before enforcing.
  • Build rules on file hash or publisher plus product and version; ban file-name-only and user-writable path rules.
  • Keep child process behaviour at "Require rule to elevate" unless a tested exception needs otherwise.
  • Set the UAC prompt for standard users to "Automatically deny elevation requests" once EPM is in place.
  • Deploy Windows LAPS with encryption, short post-authentication reset and narrow retrieval rights.
  • Deny network and RDP logon to local admin accounts and keep LocalAccountTokenFilterPolicy at 0.
  • Alert on 4732 and 4720 on workstations and on unmanaged elevations.
  • Enforce App Control for Business after admin removal, ring by ring.
  • Review elevation rules and approvals quarterly with the persona owners.

Standards and references

Related NHI Mgmt Group resources: Privileged Access Management Guide · JIT Access Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Written and reviewed by Lalit Choda, NHI Mgmt Group. Last updated 16 October 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org