Endpoint Privilege Management (EPM) in Intune: Complete Setup Guide 2026

If you’re still handing out local admin rights to users who need to install an application or update a driver — this guide is for you. Endpoint Privilege Management (EPM) is one of the most practical additions to the Microsoft Intune Suite, and as of early 2026 it’s included in Microsoft 365 E5 licences, meaning a huge number of organisations now have access to it without any additional cost.

In this guide I’ll walk you through what EPM is, how it works under the hood, and a complete step-by-step setup — including the new EPM Overview Dashboard and the Elevate as current user elevation type that landed in October 2025.

What is Endpoint Privilege Management?

EPM lets your users run as standard users (no local admin rights) while still being able to perform specific tasks that require elevation — like installing an approved application, updating a driver, or running a diagnostic tool. Instead of granting blanket admin access, EPM gives you granular, auditable, just-in-time elevation.

Think of it as the answer to this classic IT dilemma:

• User needs to install an app → you either give them local admin (security risk) or they log a ticket and wait (productivity killer)
• With EPM → user right-clicks the installer, selects Run with elevated access, provides a business justification, and either gets auto-approved or waits for admin approval — all audited and logged

This aligns directly with Zero Trust principles: least privilege by default, with controlled exceptions.

Licensing

EPM is available through:

• Microsoft Intune Suite — includes EPM + Remote Help + Advanced Analytics + Cloud PKI + more
• Intune Plan 2 — standalone add-on to Intune Plan 1
• Microsoft 365 E5 — as of the December 2025 licensing update, EPM is included here
• Standalone EPM add-on — purchasable on top of any Intune Plan 1 subscription

If your organisation is on M365 E5, you likely already have access — check Tenant administration > Intune add-ons in the Intune admin center.

How EPM Works Under the Hood

When an elevation settings policy is deployed to a device, Intune provisions the EPM Agent on that device. This agent handles all elevation requests locally and enforces the policies you’ve configured.

For most elevation types, EPM uses a virtual account to run the elevated process — completely isolated from the user’s own profile. This means the elevated process cannot access user-specific data, environment variables, or profile paths. There are four elevation types:

• Automatic — EPM elevates the application silently, no user interaction required. Use with caution; broad rules here can impact your security posture.
• User Confirmed — User right-clicks and selects Run with elevated access. You can optionally require a business justification or authentication prompt.
• Support Approved — User submits a request with a justification; an admin approves or denies it in the Intune portal. Great for sensitive or infrequent elevations.
• Elevate as Current User (new in October 2025) — Runs the elevated process under the signed-in user’s account instead of the virtual account. Necessary for applications that need access to the user’s profile paths, environment variables, or personalised settings.

Step 1: Create an Elevation Settings Policy

The Elevation Settings Policy is the foundation. It tells Intune to provision the EPM agent on the device and sets the default behaviour for anything not covered by a specific rule.

1. Go to Intune admin center → Endpoint security → Endpoint Privilege Management → Policies → Create policy
2. Platform: Windows, Profile: Elevation settings policy
3. Give it a descriptive name — e.g. EPM – Elevation Settings – Pilot
4. Configure key settings as per the table below
5. Assign the policy to a pilot device group

Once this policy reaches a device, the EPM agent is installed and the Run with elevated access right-click option becomes available to users.

Step 2: Create an Elevation Rules Policy

Elevation rules define exactly which applications are allowed to elevate, and how. Each rule targets a specific binary identified by file hash, certificate, or metadata.

1. Endpoint Privilege Management → Policies → Create policy
2. Platform: Windows, Profile: Elevation rules policy
3. Click + Edit instance to add a rule
4. Set rule name, elevation type, file name, and file hash
5. Assign to the same group as the settings policy

To get the SHA256 hash of the exact binary you want to allow:

Get-FileHash -Path "C:\Installers\7z2301-x64.exe" -Algorithm SHA256

Copy the hash value into the rule. This ensures only that exact binary — not a tampered or different version — can use this elevation rule.

Step 3: Certificate-Based Rules (Advanced)

File hash rules are precise but require updating whenever the app version changes. For frequently-updated internal applications signed by your own certificate, use a certificate-based rule instead:

1. Export the signing certificate of the application (.cer file)
2. In EPM → Reusable settings → + Add → upload the certificate
3. In your elevation rule, reference the certificate from Reusable settings instead of specifying a file hash

Any application signed by that certificate will match — no policy updates needed when the app is updated.

The New EPM Overview Dashboard

Released in October 2025, the EPM Overview Dashboard gives you a bird’s-eye view of elevation activity. Navigate to:

Endpoint security → Endpoint Privilege Management → Overview

The dashboard aggregates data from the last 48 hours and shows: managed vs unmanaged elevations, devices with local admin accounts (readiness for migration), top elevated applications, and pending approval requests. This is invaluable when planning your rollout — you can identify which apps need rules before you remove local admin rights.

Monitoring with KQL in Microsoft Defender

If you have Microsoft Defender for Endpoint integrated, EPM events are available in Advanced Hunting:

DeviceEvents | where ActionType == "AppElevationRequest" or ActionType == "AppElevationApproved" or ActionType == "AppElevationDenied" | project Timestamp, DeviceName, AccountName, FileName, FolderPath, ActionType, InitiatingProcessCommandLine | order by Timestamp desc

Audit Local Admins Before Rollout

Before removing local admin rights across your fleet, audit who currently has them. Deploy this via Intune Remediations or SCCM:

$adminGroup = [ADSI]"WinNT://./Administrators,group"
$members = @($adminGroup.psbase.Invoke("Members"))
$result = foreach ($member in $members) { 
$name = $member.GetType().InvokeMember("Name", 'GetProperty', $null, $member, $null) 
$adspath = $member.GetType().InvokeMember("AdsPath", 'GetProperty', $null, $member, $null) 
[PSCustomObject]@{ ComputerName = $env:COMPUTERNAME AccountName = $name AdsPath = $adspath } } 
$result | ConvertTo-Json

Recommended Rollout Approach

Don’t remove local admin rights on day one. A phased approach works best:

1. Deploy EPM in audit mode — set default elevation to Require User Confirmation and monitor what users elevate
2. Review the EPM Overview Dashboard after 2–4 weeks — identify top 10–20 applications being elevated
3. Create rules for those apps — Automatic or User Confirmed depending on sensitivity
4. Remove local admin rights from a pilot group and monitor for issues
5. Gradually expand the rollout while refining rules based on incoming Support Approved requests

Summary

Endpoint Privilege Management solves a real, painful problem that every enterprise IT team has been dealing with for years. If you’re on M365 E5, the licence cost is already covered — there’s no reason not to start a pilot today.

• Deploy the Elevation Settings Policy first to provision the EPM agent
• Create Elevation Rules for known applications using file hash or certificate
• Use the EPM Overview Dashboard to identify apps that need rules before removing admin rights
• Use Elevate as current user for apps that need user profile access
• Audit with KQL in Defender for a full elevation trail