Microsoft Intune Endpoint Privilege Management: How to Remove Local Admin Rights and Enable On-Demand Elevation
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.
The single most impactful endpoint hardening control is removing permanent local admin rights from standard users. An attacker who compromises a standard user account via phishing has limited persistent damage capability -- they cannot install drivers, modify system files, disable security software, or dump LSASS without first escalating privileges. The reason most organizations still give users local admin rights is legitimate application compatibility: installers, drivers, and poorly written software that require admin rights. EPM solves this by providing per-process elevation for approved applications without granting the user a permanent admin session.
Prerequisites and License Requirements
EPM requires: Windows 10 version 2004 or later (or Windows 11), Intune enrollment and management, and either Microsoft Intune Suite license or the Endpoint Privilege Management standalone add-on. The EPM agent is automatically installed on Windows devices that receive an EPM policy from Intune -- no manual agent deployment is needed. Verify your Intune subscription includes EPM: in the Intune admin center, navigate to Endpoint Security > Endpoint Privilege Management. If the feature is visible and policy creation is allowed, EPM is licensed. If not, work with your Microsoft licensing contact. Important: EPM is not the same as BeyondTrust or CyberArk Endpoint Privilege Management -- it is Microsoft's native equivalent. For organizations already running third-party EPM tools, evaluate whether EPM replaces or complements the existing tool. EPM covers Windows only; macOS admin right management requires separate tooling (Microsoft does not offer EPM for macOS as of mid-2026).
Elevation Policy Types
EPM provides three elevation rule types: Automatic elevation -- specified applications are always elevated when launched, without any user prompt. Use for line-of-business applications that always require elevation (specific internal tools, managed software installers). User-confirmed elevation -- the application can be elevated but the user must confirm the elevation request. Use for applications that occasionally need elevation (some diagnostic tools, installer updates for approved software). Support-approved elevation -- the user must submit a request that an IT helpdesk approves before elevation is granted. Use for unrecognized applications or infrequent elevation needs. Configure rules based on: file path (specific executable path), file hash (SHA256 hash of the application), certificate signature (publisher certificate that signed the executable), or file version metadata (product name and version). For best security, use file hash or certificate signature over file path -- file path rules can be bypassed by placing a malicious executable at the approved path.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Configure the Windows Elevation Settings Policy
The Windows Elevation Settings Policy controls the overall EPM behavior. Create in Intune admin center > Endpoint Security > Endpoint Privilege Management > Policies > Create policy > Windows Elevation Settings. Key settings: Show elevation prompts (Enabled -- users see the EPM prompt when attempting to run an elevated application). Default elevation response for unsigned files: choose between 'Prompt user for credentials', 'Deny elevation', or 'Require support approval' for applications not covered by a specific rule. Recommended: Deny elevation for unsigned files. Default elevation response for publisher signed files: 'Prompt user for confirmation' (user confirms without a credential challenge). Validation period for elevation: set how long an elevated process can run before re-elevation is required. Require a business justification text when requesting unmanaged elevation (Enabled -- adds accountability to each elevation event). Assign the Settings Policy to the device groups where EPM will be enforced. Deploy alongside the Elevation Rules Policies (which define specific applications).
Phased Rollout: Audit Mode Before Enforcement
A direct rollout that removes local admin rights and enforces EPM simultaneously causes immediate application breakage and helpdesk calls. Use a phased approach: Phase 1 (Audit mode, 2-4 weeks): deploy an EPM policy in 'Report only' mode to a pilot group. Collect the elevation events -- every application that a pilot user attempts to elevate is recorded in Intune under Reports > Endpoint Privilege Management > Elevation Report. Review the report to identify the applications that need elevation rules. Phase 2 (Rule creation): create elevation rules for all applications identified in Phase 1. Test each rule by confirming it allows the application to elevate correctly. Phase 3 (Remove local admin from pilot group): remove the pilot group from the Local Administrators group (via Intune Account Protection policy or GPO), confirm EPM is handling all required elevations. Phase 4 (Broad rollout): repeat for all standard user groups. Keep a separate process for power users and IT staff who legitimately need persistent local admin -- exclude them from EPM and track them separately with a documented risk acceptance.
Monitor EPM Elevation Events
All EPM elevation events are logged in Intune and can be exported for SIEM integration. Intune admin center > Reports > Endpoint Privilege Management > Elevation Report. Filter by: device, user, file elevated, elevation type, and date range. Alert on: User-confirmed or support-approved elevations for file hashes not previously seen (new executables being elevated -- potential attacker tool). High frequency of elevation requests from a single user in a short time period (attacker testing what they can elevate). Elevation requests for executables stored in temp directories (%TEMP%, %APPDATA%, Downloads) -- legitimate applications typically install to Program Files, not temp paths. Denied elevation attempts -- an attacker attempting to run a tool that is blocked generates a denied event. Integrate EPM logs with Sentinel: the EPM elevation data is available via the Microsoft Graph API for Intune and can be ingested with a Logic App or Data Collection Rule. Each event includes the device, user, file path, file hash, elevation type, and timestamp.
The bottom line
Removing permanent local admin rights via EPM is the endpoint hardening control with the highest return on security investment. Use the phased audit-then-enforce rollout to prevent application breakage. Build elevation rules based on file hash or publisher certificate, not file path alone. Monitor elevation events for new executables and temp-directory elevation requests -- these are high-signal indicators of attacker activity post-compromise.
Frequently asked questions
Does EPM work with applications that need admin rights to install, not to run?
Yes. For application installers that require admin rights during installation: create a user-confirmed elevation rule for the installer executable (matched by file hash or publisher certificate). The user runs the installer, EPM elevates the installer process, the installation completes, and then the running application executes normally as a standard user. This is the most common EPM use case -- the application itself runs fine without admin rights, but the installer requires elevation. Once installed, remove the elevation rule for the installer if it is a one-time install.
What happens when an application elevated by EPM tries to launch a child process?
The elevated parent process can launch child processes that also run with elevated privileges if they inherit the token. This is the expected behavior for installers (which spawn sub-processes as part of installation). However, it is a potential risk if the elevated process is exploitable -- a compromised elevated process can spawn an elevated shell. Configure EPM elevation rules at the narrowest scope possible and prefer user-confirmed elevation (which requires interaction) over automatic elevation for applications that launch child processes. MDE behavioral monitoring detects suspicious child process creation from elevated processes.
How does EPM interact with UAC (User Account Control)?
EPM works alongside UAC but handles the elevation differently. Without EPM, a standard user attempting to run an application that requires admin rights sees a UAC prompt asking for admin credentials -- which the standard user does not have. With EPM, the UAC prompt is replaced (or preceded) by the EPM elevation prompt for approved applications. UAC is still active and still presents for applications not covered by EPM rules -- a standard user without an EPM rule for an application will still see the UAC credential prompt and be unable to proceed. EPM does not disable UAC; it provides a managed alternative for approved applications.
Can EPM elevation rules be bypassed by renaming an executable?
If the rule uses file hash (SHA256) or publisher certificate signature, renaming the file does not bypass the rule -- the hash and signature remain tied to the file's content, not its name. If the rule uses file path only, a malicious executable renamed to match the expected path would be elevated. Always prefer hash or certificate-based rules over path-based rules for this reason. For applications that update frequently and change their hash, use publisher certificate-based rules scoped to the specific certificate subject and optionally the product name and minimum version.
Which EPM elevation events should I alert on in my SIEM?
Alert on these EPM-reported patterns: elevations from temporary directories (%TEMP%, %APPDATA%, C:\Users\[user]\Downloads) are high-risk -- legitimate managed applications do not self-elevate from user-writable temp paths. Elevations from executables with unsigned or self-signed certificates warrant immediate investigation. Elevations for executables not in any EPM elevation rule (auto-approved but not policy-controlled). Any user-confirmed elevation denied by the user after review (the user clicked 'Deny' in the EPM prompt) suggests the elevation was unexpected. Query these from the MDE DeviceEvents table: DeviceEvents | where ActionType == 'EpmElevation' | where InitiatingProcessFolderPath matches regex '(?i)(temp|appdata|downloads)'. Correlate with process execution events to understand what the elevated process did after elevation.
How does Endpoint Privilege Management compare to removing users from the local Administrators group, and when is EPM necessary versus simply removing local admin rights?
Removing users from the local Administrators group is the foundational control -- EPM is a supplement for environments where full admin removal creates productivity blockers, not a replacement for performing admin removal first. Removing local admin addresses the root issue: a compromised standard user cannot install kernel drivers, modify system files, or access other users' credential caches without a privilege escalation step. EPM adds the ability to elevate specific pre-approved applications to run as administrator while the user's primary session remains standard. When EPM is necessary: software that requires a one-time installer run as admin (VPN clients, specialized industry software), applications that need periodic admin access for configuration (updating print drivers, accessing Device Manager), and legacy applications whose vendor has not provided a non-admin mode. EPM is not a substitute for removing local admin from accounts that currently have it as a habit. The correct sequence: remove local admin from all users, monitor what breaks using EPM in 'audit only' mode, create EPM elevation rules for legitimate needs that surface, then enforce. Organizations that deploy EPM without removing local admin first have accomplished nothing -- the user still has admin rights, EPM is just an additional layer with no security value in that configuration.
Sources & references
Free resources
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.
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.
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.
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.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.