Removing local admin rights is the single most effective hardening step on Windows endpoints, and the reason it stalls is always the same: a handful of installers, drivers and tools that genuinely need elevation. Endpoint Privilege Management (EPM) lets users stay standard users while Intune elevates specific files under rules you define, with every elevation logged. In this post I'll walk through the two policy types, how to write rules that can't be spoofed, what users actually see, the reports, and how to debug a rule that isn't matching.
How it works#
EPM is one of the Intune advanced capabilities and requires a subscription in addition to Intune Plan 1 or Plan 2, through the Microsoft Intune Suite, a standalone add-on, or select Microsoft 365 bundles; Tenant administration › Intune add-ons shows whether it's active in your tenant. Once a device receives a Windows elevation settings policy that enables EPM, Intune provisions the client: the Microsoft EPM Agent Service and binaries under C:\Program Files\Microsoft EPM Agent. From then on, a standard user can right-click an .exe, .msi or .ps1 and choose Run with elevated access. The agent checks the Windows elevation rules policies for a match; if none applies, the default elevation response from the settings policy decides. Elevations run under an isolated virtual account rather than the user's own account (except the Elevate as current user type), and neither is added to the local Administrators group.
Prerequisites#
- Windows 11 24H2, 23H2, 22H2 or 21H2, or Windows 10 22H2 or 21H2, each at the minimum builds Microsoft lists; 64-bit only, including Arm64. Devices on unsupported builds report the settings policy as not applicable.
- Microsoft Entra joined or Microsoft Entra hybrid joined, and enrolled in Intune or co-managed. Microsoft Entra registered ("workplace joined") devices don't process EPM policy.
- Clear line of sight to the EPM endpoints without TLS inspection. Azure Virtual Desktop single-session VMs and Windows 365 Cloud PCs are supported.
- An Intune role with the Endpoint Privilege Management Policy Authoring permission: the built-in Endpoint Privilege Manager (full), Endpoint Privilege Reader (read and reports), or Endpoint Security Manager.
Step-by-step#
Step 1: Create the elevation settings policy (audit first)#
Go to Endpoint security › Endpoint Privilege Management › Policies › Create Policy, platform Windows, profile Windows elevation settings policy. The settings:
| Setting | Options and recommendation |
|---|---|
| Endpoint Privilege Management | Enabled installs the client. Disabling deactivates it at the next sync, and the components are removed after a seven-day delay. |
| Default elevation response | Deny all requests or Require support approval (both recommended by Microsoft), or Require user confirmation. Not configured behaves as deny. This only applies to files without a rule, and only when the user explicitly uses Run with elevated access. |
| Validation | For user confirmation: Business justification, Windows authentication, or both |
| Send elevation data for reporting | Yes during rollout |
| Reporting scope | Diagnostic data and all endpoint elevations (default) captures unmanaged "Run as administrator" elevations too, which is exactly the data you need to build rules |
Assign it to a representative pilot group and let it collect data. Microsoft's deployment phases are: audit, identify personas, build rules from the reports, monitor, then move users from administrator to standard user with a Local Users and Groups policy.
Watch out: Require user confirmation as the default response means any file can be elevated after a prompt. Never leave it as the steady state for standard users.
Step 2: Build elevation rules#
Create a second policy with profile Windows elevation rules policy (up to 100 rules per policy). The fastest way to get accurate file details is the report: open Reports › Elevation report, select the file, review the Elevation detail pane and choose Create a rule with these file details, adding it to an existing or new policy. Tick Require the same file path as this elevation when the path is somewhere standard users can't write to. Each rule has:
- Elevation type: User confirmed (default, optional business justification or Windows authentication), Automatic (silent; hash required; no wildcards), Support approved (an admin approves each request in the Elevation requests tab), Elevate as current user (runs in the user's own context; requires Windows authentication) and Deny.
- Child process behavior: Require rule to elevate (default), Allow all child processes to run elevated (skips rule evaluation, including deny rules) or Deny all.
- File information: file name (wildcards
?and*allowed except in automatic rules), optional file path, Signature source (a certificate from a reusable settings group, an uploaded.cer, or not configured), certificate type Publisher or Certificate authority, plus optional minimum version, file description, product name and internal name. A file hash is required when there's no certificate. - Arguments: set Restrict arguments to an allow list to permit, for example,
dsregcmd /statusbut not/leave. Arguments are case-sensitive and anything not listed is denied.
Get the attributes from a reference copy of the file with the EpmTools module that ships with the agent:
Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'
Get-FileAttributes -FilePath 'C:\Windows\System32\msinfo32.exe' -CertOutputPath 'C:\EpmCerts\'
Get-FileHash 'C:\Windows\System32\msinfo32.exe' -Algorithm SHA256Write strong detections: a hash is the strongest; a publisher certificate paired with product name, internal name or description is the maintainable choice for apps that update often; a file name alone is weak because anyone can rename a trusted-signed binary. Store certificates in Reusable settings so a vendor certificate rollover is a single edit.
Step 3: Assign and understand conflicts#
Rules can target users or devices and merge on the client. When several rules match: deny always wins, user-targeted rules beat device-targeted rules, a rule with a hash is the most specific, then the rule with the most attributes, and finally the order User confirmed, Elevate as current user, Support approved, Automatic. Two settings policies with conflicting values make the client fall back to default behaviour until you resolve the conflict.
Verify#
What the user sees#
Right-click the file and choose Run with elevated access. A user-confirmed rule shows a simple confirmation, optionally asking for a justification or credentials; an automatic rule elevates with no prompt at all; a support-approved rule lets the user submit a request and notifies them when it's approved; a deny rule, or the default deny, shows a message that the app can't be run as administrator.
On the device#
Get-Service 'Microsoft EPM Agent Service'
Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'
Get-Command -Module EpmCmdlets
Get-ClientSettings
Get-Policies -PolicyType ElevationRules
Get-DeclaredConfigurationAnalysisGet-ClientSettings shows the effective default response and reporting scope, Get-Policies lists the rule policies the agent received, Get-DeclaredConfigurationAnalysis shows whether each policy targeted at the device has actually been processed, and Get-ElevationRules queries the agent's lookup for a file name or certificate so you can see which rule it would pick. The readme.md in the EpmTools folder documents each cmdlet's parameters.
In the admin center#
Under Endpoint security › Endpoint Privilege Management, the Overview tab is a readiness dashboard built from the last 48 hours: users with only unmanaged elevations, users with both, users with only managed elevations, and the most frequent unmanaged, support-approved and denied files. The Reports tab offers the Elevation report, Managed elevations report, and elevation reports by application, publisher and user. Data is processed every 24 hours and retained for 30 days, and viewing it needs the View Reports right.
Tips & gotchas#
- Device never gets EPM: check the join type (Entra registered is unsupported), the OS build, that an elevation settings policy with Enabled actually targets the device, and that a proxy isn't inspecting the EPM endpoints.
- Run with elevated access is missing: on builds older than Windows 11 24H2 with the April 2025 update, the shell extension sometimes isn't registered; Microsoft's workaround is to run
EpmShellExtension.msixfromC:\Program Files\Microsoft EPM Agent\EPMShellExtension. - Rule doesn't match: the file was updated so the hash changed, the certificate expired (EPM checks expiry), the path differs from the rule, an argument wasn't in the allow list, or the file sits on a network share, which isn't supported. Downloaded files blocked by Mark of the Web won't elevate until unblocked.
- Elevated app can't reach OneDrive or a file share: expected; the virtual account has no user credentials. Use Elevate as current user only when compatibility truly requires it.
- Not supported: UWP apps, Control Panel items and Settings pages can't be elevated; package the task as a
.ps1instead. Explicitly disabling UAC, enabling Administrator Protection, or App Control for Business policies without rules for the EPM components will break elevations. Settings policy values changed several times in quick succession can show a transient conflict for up to 60 minutes. - Finish the job: once the dashboard shows a persona with only managed elevations, remove their local admin rights with an account protection policy for local user group membership, and keep LAPS for the break-glass account.