Endpoint Privilege Management Just Moved Into Your E5 License — Here's How to Actually Deploy It

From July 1, 2026, Microsoft has been rolling out a change that quietly makes one of Intune's most useful security features free for a huge number of tenants: Endpoint Privilege Management (EPM) is now included in full Microsoft 365 E5, instead of being sold only as a standalone add-on or as part of the Intune Suite. If your organization already pays for M365 E5, you may already be entitled to a feature that used to cost extra — and most admins have not touched it yet, because it never showed up as "included" until now.

This post is a deployment guide, not a licensing announcement — the licensing change itself is already covered here if you need the E3/E5 rollout details. What follows is everything you need to actually turn EPM on: what it does under the hood, the console clicks to enable it safely (audit first, enforce later), the two elevation types that matter most in production, how to check a device's real EPM state without guessing, and where this feature's licensing claims needed correcting once checked against Microsoft's own documentation.

The problem: local admin rights, and why "just take them away" never works

Here is the trade-off every IT team eventually runs into. Leave users as local administrators, and any malware they click on runs with full admin rights too — no extra step required. Take local admin away, and your helpdesk queue fills up with tickets for things a standard user legitimately needs to do: installing a printer driver, updating a personal dev tool, running a diagnostic utility that happens to need elevation, or reinstalling an app that lost its license activation. Most organizations pick one side of that trade-off and live with its downside.

Third-party privilege management tools have existed for years to solve exactly this, but they mean another agent, another console, and another vendor relationship layered on top of Intune. Microsoft's answer, built directly into Intune, is Endpoint Privilege Management (EPM): a standard user stays a standard user, but specific, IT-approved files and scripts can still run with administrator rights when they need to — without ever handing that user (or a shared "helper" account) standing admin.

Until mid-2026, EPM sat behind a real cost barrier: it needed a separate Intune Suite subscription or a standalone per-user add-on, on top of a base Intune Plan 1 or Plan 2 license. That made it easy for teams to file EPM under "nice to have, budget permitting" and move on. The licensing change below removes that excuse for a large share of Microsoft's customer base — which is exactly why this is worth a proper deployment guide now, not just a news item.

Why it happens: how EPM elevates one task without granting standing admin

To deploy EPM sensibly, you need to understand what actually happens on the device when it elevates something — not just "it lets standard users run things as admin." There are three moving parts.

The EPM Agent — a small service, not a policy setting

EPM is not just a registry flag Windows checks. When you assign an EPM policy to a device for the first time, Intune provisions a real client component: the Microsoft EPM Agent Service, with its binaries in C:\Program Files\Microsoft EPM Agent. This service is what intercepts the Run with elevated access right-click action, checks it against the device's elevation rules, and — if it matches — performs the elevation. If you ever remove EPM from a device (disable it in policy, or unassign the policy), Microsoft's own documentation is explicit that the client components are not torn down immediately: there's a seven-day grace delay before they're deprovisioned, specifically so an accidental unassignment doesn't instantly strip protection.

Two policy types, and they both matter

EPM is configured with exactly two policy types, and you need both for elevation to actually happen for anyone:

• Windows elevation settings policy — the on/off switch. It enables (or disables) EPM on the device, sets the default elevation response for anything that doesn't match a rule, and controls how much elevation data the device reports back to Intune.
• Windows elevation rules policy — the allow-list. Each rule identifies one file (by name, hash, and/or publisher certificate) and says how it's allowed to elevate: automatically, with a user prompt, with support approval, or not at all (deny).

A device with only a rules policy and no settings policy enabling EPM does nothing — the client never even installs. A device with EPM enabled but no rules policy falls back entirely to the settings policy's default elevation response, which — importantly — defaults to deny all requests if you leave it unconfigured. That default-deny behavior is deliberate and matches least-privilege thinking, but it surprises teams who expected "enabled" to mean "permissive."

The virtual account — where the actual privilege lives

This is the part most admins skip past, and it's the part that actually makes EPM safe. For every elevation type except one (Elevate as current user, covered below), EPM performs the elevated action using a virtual account — an account that is isolated from the signed-in user's own profile and is never added to the local Administrators group. The elevated process runs with admin rights for that one action, in that isolated context, and then it's done. No admin token is ever handed to the user's own logon session.

Elevate as current user is the deliberate exception to the virtual-account model, and it's worth understanding precisely because it's the riskier of the five types. Instead of a virtual account, the elevated process runs under the signed-in user's own identity — so it can see the user's profile paths, environment variables, and personal settings. Some installers and tools genuinely need that to work correctly. The cost is that the elevated process now has the user's full context available to it, which is a materially larger attack surface than the isolated virtual account. Microsoft's own guidance is blunt about when to reach for it: only when a virtual-account elevation actually fails for that specific application, and scoped as tightly as possible when you do.

How to verify: licensing, prerequisites, and a device's real EPM state

Before you touch a single policy, confirm three things: that your tenant is actually licensed, that your target devices meet the platform requirements, and — for a device you're troubleshooting — what its EPM client is really doing right now.

Step 1 — Confirm licensing (and don't assume "E5" alone is enough)

This is the claim most worth double-checking rather than repeating from a headline. Microsoft's own licensing guidance for EPM states plainly: "This feature requires a subscription in addition to Microsoft Intune Plan 1 or Plan 2." As of July 1, 2026, that "subscription in addition to" can be satisfied for free by full Microsoft 365 E5 — but specifically the full M365 E5 bundle, not the standalone Enterprise Mobility + Security (EMS) E5 component. A tenant on EMS E5 without the complete M365 E5 subscription does not pick up EPM from this change; it still needs the standalone EPM add-on or the Intune Suite.

Check your own tenant's entitlement in the Microsoft 365 admin center rather than assuming from the SKU name alone — service plan names inside a bundle don't always match the marketing name of the bundle. The read-only script in "The fix" section below prints your tenant's subscribed SKUs as a starting point, but treat that list as something to cross-check against your own licensing records, not as a definitive yes/no on EPM entitlement — Graph doesn't expose a single "EPM entitled: true/false" flag.

Step 2 — Confirm device prerequisites

EPM only works on devices that meet specific version and join-state requirements. Microsoft's platform requirements page lists the exact supported builds; the practical summary for anything you'd realistically be deploying to in 2026 is:

Step 3 — Check a device's real EPM state with EpmTools, not guesswork

Here is the correction worth calling out plainly: EPM does not write to a documented Windows Event Viewer channel the way Microsoft Defender Antivirus or MDM enrollment do. There is no public "EPM/Operational" log with a catalog of Event IDs you can search the way you would for DeviceManagement-Enterprise-Diagnostics-Provider. What EPM does expose locally is the EpmTools PowerShell module, which ships inside the EPM Agent install itself and is the genuine, documented way to check a device's state.

Import it from an elevated PowerShell session on a device that has already received an EPM policy:

A healthy, EPM-enabled device reports back something like this. The values below are illustrative — reconstructed to show the shape of a real run, not copied from a production tenant:

If Get-ClientSettings returns nothing, or the module import itself fails, that's your first real signal: the device has not yet received an elevation settings policy, or the policy hasn't synced. Check the FAQ's own troubleshooting guidance next — Microsoft names two causes for a policy showing "error" or "not applicable": a missing prerequisite Windows update, or the device failing to reach the specific network endpoints EPM requires (listed on Microsoft's Intune network endpoints page, linked in References).

STATE: 4 RUNNING confirms the agent itself is alive. If the service doesn't exist at all, the device has never received an elevation settings policy with EPM enabled — the client is provisioned only on first policy receipt, never pre-installed.

The fix: deploying EPM policies the safe way, phase by phase

Microsoft's own guidance describes five deployment phases, and skipping straight to "remove admin rights" is the single most common way this rollout goes badly. Follow the order.

Phase 1 — Turn on auditing first, with no rules yet

Create the settings policy that enables EPM and starts collecting elevation data, before you write a single rule. This gives you real usage data to build rules from, instead of guessing.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security › Endpoint Privilege Management, select the Policies tab, then select Create Policy.
3. Set Platform to Windows and Profile to Windows elevation settings policy, then select Create.
4. On Basics, give the policy a descriptive name — for example, "EPM — Audit only — Pilot group".
5. On Configuration settings, leave Endpoint Privilege Management set to Enabled (the default). Set Default elevation response to Deny all requests or Require support approval — both are Microsoft's own recommended options; avoid Require user confirmation as your default, since that setting lets every unmatched file elevate as long as the user clicks through a prompt.
6. Set Send elevation data for reporting to Yes, and Reporting scope to Diagnostic data and all endpoint elevations — this is the setting that populates the reports you'll use in Phase 3, so don't scope it down during the audit phase.
7. Select Next through Scope tags, then on Assignments select a small pilot group of devices or users — not "All devices" on your first pass.
8. Select Next, review, and select Create.

Let this run for at least a couple of weeks (Microsoft's own MSEndpointMgr-published guidance, cited in References, recommends at least four weeks) before drawing conclusions. Rushing this phase produces rules based on an incomplete picture of what your pilot users actually need elevated.

Phase 2 and 3 — Identify personas, then build rules from the reports

Once you have audit data, use it. The Overview dashboard groups your pilot users into exactly the categories you need for Phase 2's persona work:

From either the Elevation report or a support approved request, you can build a rule automatically instead of typing every file detail by hand:

1. In Endpoint security › Endpoint Privilege Management, select the Reports tab, then the Elevation report tile.
2. Find the file you want to allow, and select its linked name to open the Elevation detail pane.
3. Select Create a rule with these file details.
4. Choose Create a new policy or Add to an existing policy.
5. Set the rule's Type (start with User confirmed for anything you haven't fully vetted) and Child process behavior, then select OK.
6. If prompted, provide a Policy name, then edit the resulting policy to assign it to your pilot group.

To build a rule manually instead — useful when you already know exactly which file, and want tighter control over hash and certificate matching from the start:

1. Go to Endpoint security › Endpoint Privilege Management › Policies › Create Policy. Set Profile to Windows elevation rules policy, then Create.
2. On Basics, name the policy.
3. On Configuration settings, select Edit instance on the blank starter rule.
4. Set Elevation type. For most production rules this is Support approved (admin reviews each request) or User confirmed (user acknowledges, optionally with a business-justification or Windows-authentication prompt).
5. Under File information, set the File name and, strongly recommended, a File path that a standard user can't write to.
6. Set Signature source to a certificate (directly uploaded, or from a reusable settings group) and/or supply a File hash. A hash is mandatory if you choose Automatic as the elevation type.
7. Select Save, then Add for any further rules in the same policy (up to 100 rules per policy).
8. Select Next through Scope tags, assign the policy on Assignments, then Next › Create.

Support-approved elevation, and the one genuinely new capability in 2026

For anything that shouldn't be automatic or purely user-confirmed, Support approved routes the request to an admin for a case-by-case decision. Here's the detail worth checking rather than assuming: is this limited to a device's primary, enrolled user? It is not, and Microsoft's own documentation says so directly: "Support approved elevation requests aren't limited to the device's primary user." Any signed-in user on a device — including a second person using a shared workstation across shifts — can submit and track their own elevation request; it isn't restricted to whoever Intune considers the device's primary enrollee.

1. Sign in to the Microsoft Intune admin center and go to Endpoint security › Endpoint Privilege Management › Elevation requests tab.
2. Review pending requests and requests from the last 30 days. Select a row to open its full detail — file, publisher, device, requesting user, and the user's typed justification.
3. Select Approve or Deny. Optionally add a Reason; it becomes part of the audit record either way.
4. On approval, Intune pushes the approval to the device and the user is notified by a toast that they can now run the file elevated — for the next 24 hours only. There's no current option for a custom time window or an early cancellation.

Phase 4 and 5 — Monitor, then move ready users to standard accounts

Keep iterating rules as new "frequently unmanaged" files show up in the Overview dashboard's own tiles. Only once a user's tile shows only managed elevations should you move them from local administrator to standard user — using Local Users and Groups policy (Account Protection, under Endpoint security) to manage local group membership, not a manual removal. Repeat phases 2 through 5 continuously; EPM deployment is not a one-time project.

Proof it worked: reading the readiness dashboard and the audit script's output

"Worked" here has two layers: the policy is actually live on the device, and the elevation behavior you configured is the elevation behavior actually happening in your tenant.

For the first layer, re-run the Get-ClientSettings check from "How to verify" against a freshly-targeted device and confirm EnableEndpointPrivilegeManagement reads True with the Default elevation response matching what you configured. If it still reads False or the module won't import, the policy hasn't synced yet — check the device's assignment and give it one more Intune sync cycle before assuming something is broken.

For the second layer, use the read-only companion script below. It queries the same data the Overview dashboard is built from, so you get the tenant-wide picture without opening the admin center for every check. Below is an illustrative run — reconstructed with fictional group and file names, not copied from any real tenant, since this script's real output would include actual employee UPNs and device names:

Read that output like this: the policy table confirms your pilot group actually has both an elevation settings policy and at least one elevation rules policy assigned — a common early mistake is deploying rules with no enabling settings policy, and this table catches that immediately. The pending requests section is your support-approved queue — Intune doesn't push a notification to admins for these, so this section exists specifically to stop requests going stale unnoticed. The activity summary is the same signal as the Overview dashboard's "unmanaged elevations" tile: any user still showing unmanaged elevations after your rules are live is either missing a rule they need, or is a candidate to keep as an administrator a little longer.

References

• Microsoft Learn — Endpoint Privilege Management overview (elevation types, EPM Agent, policy types)
• Microsoft Learn — Plan and prepare for EPM deployment (licensing, platform prerequisites, security recommendations, RBAC)
• Microsoft Learn — Deploy Endpoint Privilege Management (the five deployment phases)
• Microsoft Learn — Creating elevation rules (manual and automatic rule creation, file hash/certificate guidance)
• Microsoft Learn — Managing elevation settings (Windows elevation settings policy, console walkthrough)
• Microsoft Learn — Use EPM support approvals (confirms elevation requests aren't limited to the primary user)
• Microsoft Learn — Monitor EPM policies (Overview readiness dashboard, report tiles, RBAC permission for viewing reports)
• Microsoft Learn — EPM frequently asked questions
• Microsoft Learn — Microsoft Intune advanced capabilities (current licensing model for EPM and other Suite features)
• Microsoft Learn — privilegeManagementElevation resource type (Microsoft Graph beta)
• Microsoft Intune Blog (Tech Community) — Microsoft 365 adds advanced Intune solutions at scale (the E3/E5 licensing rollout)

Microsoft MVP community deep-dives