EPM – CIAOPS

Endpoint Privilege Management (EPM) is the cleanest answer Microsoft has shipped for the local-admin problem. Done well, it lets your tenants run as standard users while still installing approved apps and updating drivers — auditable, just-in-time, no helpdesk ticket. Done badly, you ship a half-configured agent that produces noise, breaks line-of-business apps, and convinces the customer that “least privilege” is somebody else’s problem. Here is how to make EPM stick at an MSP.

The licensing trap nobody warns you about

EPM is not included in Microsoft 365 Business Premium. It needs Microsoft Intune Plan 1 plus either the Intune Suite add-on or the standalone EPM add-on. If your customer is on BP only, you have a quoting conversation before you have a deployment conversation. Confirm assignments under Tenant administration → Intune add-ons before you create a single policy.

While you are there, validate the other prerequisites people skip: devices must be Microsoft Entra joined or hybrid joined, Intune-enrolled (or ConfigMgr co-managed), 64-bit only, and on supported builds — Windows 11 24H2/23H2/22H2/21H2 or Windows 10 22H2/21H2 with the listed cumulative updates. EPM also needs clear line of sight to its endpoints without SSL inspection — this single item kills more pilots than anything else.

See EPM deployment planning for the full prerequisite matrix.

Where to configure

Everything lives in the Intune admin center at Endpoint security → Endpoint Privilege Management. There are two policy types you need to understand:

Elevation settings policy — provisions the EPM agent on the device, sets the default elevation response, and turns on reporting. One per device-targeted persona.
Elevation rules policy — defines which binaries can elevate, how (Automatic, User confirmed, Support approved, or Elevate as current user), and using which signal (file hash, certificate, or metadata). Up to 100 rules per policy.

Do not configure rules first. The agent does not exist on the endpoint until the settings policy lands. See the EPM overview.

The rollout pattern that actually works

Three rings, audit-first — same as every other Intune deployment that survives contact with users:

Audit ring (week 1–2). Deploy only an elevation settings policy to a pilot device group. Set Default elevation response = Require support approval, Send elevation data = Yes, Reporting scope = Diagnostic data and all endpoint elevations. No rules yet. Let it bake. EPM data is processed once every 24 hours, so resist the urge to declare it broken on day one.
Pilot ring (week 3–4). Use the Overview dashboard and the Frequently unmanaged elevations and Frequently approved by support tiles to identify the real top 5–10 elevation candidates. Build rules for those — prefer publisher certificate + file path over file hash, because hashes change with every app update. Roll into a 20–30 user pilot.
Production ring (week 5+). Widen progressively. Once managed-elevation coverage is high, deploy an account protection policy to remove standing local admin from the user group on those devices. That is the actual goal — the rules are just the bridge.

Build rules from Creating elevation rules. Watch coverage from EPM reports.

Top pitfalls

Certificate-rule sprawl. A certificate-only rule allows any binary signed by that publisher to elevate. Some vendors sign their entire catalogue — including tools you did not intend to elevate — with one cert. Always pair certificate with file name or path.
SSL inspection on the proxy. EPM telemetry travels over a pinned channel. Decrypt it and the device reports as “not applicable” with no useful error. Add an exclusion before you blame the agent.
Forgetting to remove local admin. Shipping rules without ever taking standing admin off the user group means EPM is theatre, not control. The whole point is the standard user.