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 matter | EPM-related control |
|---|---|---|
| T1548.002 Bypass User Account Control | Silent elevation only helps an attacker if the user's token can be elevated | Standard 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 context | Remove admin; deny rules for dumping tools; alert on SeDebugPrivilege use |
| T1136.001 Create Account: Local Account | net user /add and group changes need admin | Remove admin; monitor events 4720 and 4732 |
| T1078.003 Valid Accounts: Local Accounts | Shared local admin passwords allow lateral movement across machines | LAPS 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 admin | Remove admin; forward logs off the host |
Approaches to removing local admin
There is no single control. Most organisations combine several of these, by persona.
| Approach | How it works | Strengths | Limits | Fits |
|---|---|---|---|---|
| Standard user, IT does all installs | No elevation path for users; software comes from a managed catalogue | Simplest and strongest | Ticket volume; slow for edge cases | Information workers, kiosks, frontline |
| Separate admin account | User has a second, admin-only account entered at the UAC credential prompt or with runas | No extra tooling; satisfies CIS Safeguard 5.4 | Admin account is a reusable credential; tends to be used for everything | IT staff on dedicated admin workstations |
| EPM elevation rules | Agent elevates approved files on demand (automatic, user confirmed or support approved) | Granular, logged, no admin group membership | Agent cost and rule maintenance; weak rules can be abused | Most of the workforce, developers, engineers |
| Just-in-time admin | User is added to local Administrators for a time window after approval | Handles tasks no rule anticipates | Whole session is admin during the window | Support technicians, break-fix |
| LAPS-managed local account | A single rotated local admin account, password retrieved from the directory | Recovery and offline support without shared passwords | Not a day-to-day elevation method | Every 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.exeorpowershell.exewhere 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 attribute | Strength | Risk and guidance |
|---|---|---|
| File hash | Strongest | Microsoft 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 version | Strong | Survives updates; trusts everything the publisher signs that matches, so pin product name and version |
| Certificate authority only | Weak | Trusts any file signed under that CA; avoid for elevation |
| File path | Depends on the folder | Use only locations standard users cannot write to, such as C:\Program Files |
| File name | Weak alone | Microsoft 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:
- 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.
- 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.
- 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
LocalAccountTokenFilterPolicyat 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 setting | Default | Suggested position |
|---|---|---|
| BackupDirectory | 0 (disabled) | 1 (Entra ID) or 2 (Active Directory) |
| PasswordAgeDays | 30 | 30 or less (minimum 7 with Entra ID backup) |
| PasswordLength / PasswordComplexity | 14 / 4 | At least 14 with complexity 4, or a passphrase option (6 to 8) on Windows 11 24H2 and later |
| PostAuthenticationActions | 3 (reset password and sign out) | 3, or 11 to also end processes running as the account (24H2 and later) |
| PostAuthenticationResetDelay | 24 hours | Shorter, such as 2 to 8 hours; 0 disables post-use rotation |
| ADPasswordEncryptionEnabled | True | True (needs 2016 domain functional level); keeps password history |
| AutomaticAccountManagementEnabled | False | Consider 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. AvoidALLandNOPASSWDfor people, useCmnd_Aliasto grant specific commands, usesudoeditinstead of granting editors (editors and shells allow escapes), and enablelog_outputfor 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
- Measure the starting point: count members of the local Administrators group on every device, separating IT, users, service accounts and unknown SIDs.
- 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.
- Identify personas and build rules from the reports, starting with the top elevated files by volume.
- 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.
- Expand in rings of a few hundred devices, watching elevation request volume and help-desk tickets per ring.
- Tighten: convert frequently confirmed elevations to hash or publisher rules, and move the default response towards support approval or deny.
- 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
| Signal | Source | Why |
|---|---|---|
| 4732: A member was added to a security-enabled local group | Security log, Audit Security Group Management | Anyone added to local Administrators outside the managed process |
| 4720: A user account was created | Security log, Audit User Account Management | New local accounts on workstations (T1136.001) |
| 4688 with Token Elevation Type %%1937 | Security log, Audit Process Creation | Processes started with an elevated token outside EPM |
| 4672: Special privileges assigned to new logon | Security log, Audit Special Logon | Logons with SeDebugPrivilege and similar by accounts not expected to hold them |
| 3076 / 3077 and 8028 / 8029 | CodeIntegrity Operational; AppLocker MSI and Script | Application control audit and block events for files and scripts |
| Managed and unmanaged elevations | EPM reporting | Unmanaged 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
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-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. 5 | CM-7(5), CM-11 | Allow-by-exception software; user-installed software |
| NIST CSF 2.0 | PR.AA-05, PR.PS-05, DE.CM-09 | Least privilege; unauthorised software prevented; endpoint monitoring |
| CIS Controls v8.1 | 5.4; 2.5, 2.6, 2.7 | Dedicated administrator accounts; allowlisting software, libraries and scripts |
| ISO/IEC 27001:2022 Annex A | 8.2, 8.19 | Privileged access rights; installation of software on operational systems |
| MITRE ATT&CK | T1548.002, T1078.003, T1136.001, T1003 | Techniques removed or made harder by standard user plus LAPS |
Common failure patterns
- Broad automatic rules: automatically elevating
cmd.exe,powershell.exeor 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
- CIS: Controls v8.1 Assessment Specification, Control 5 Account Management
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- MITRE ATT&CK: T1548.002 Bypass User Account Control
- Microsoft Learn: Windows LAPS overview
- Microsoft Learn: Local accounts
- Microsoft Learn: App Control for Business and AppLocker overview
- Microsoft Learn: Create elevation rules for Endpoint Privilege Management
- Cisco Talos: Cisco Talos shares insights related to recent cyber attack on Cisco
Related NHI Mgmt Group resources: Privileged Access Management Guide · JIT Access Guide · Service Account Security Guide · Active Directory and Entra ID Hardening Guide