Most organisations I work with have been chasing least privilege for years. Strip out local admin rights, shrink the attack surface, limit what a compromised account can do. All good instincts.

The trouble is what happens on Monday morning when someone genuinely needs to install a printer driver or run an update that insists on admin rights. That’s the gap EPM was built to close.

Microsoft Intune Endpoint Privilege Management (EPM), part of the Intune Suite and now part of Microsoft 365 E5, lets standard users run specific approved things with elevated rights—on demand, for that one task, without ever making them a local admin. No more, no less.

This is the deployment playbook I use with clients: how EPM actually works under the hood, how to roll it out without a support desk meltdown, and the configuration choices that separate a good deployment from one that just moves the risk around.

What EPM actually does

EPM elevates specific applications, scripts, installers and processes. The user stays a standard user throughout. That distinction matters more than it sounds — you’re not granting a person more power; you’re granting a process more power, for as long as it needs it.

Under the hood, EPM policies decide:

• Which applications are allowed to elevate
• Who is allowed to trigger that elevation
• Whether the user has to explain why
• Whether someone else has to approve it first
• Whether it happens automatically or on request
• What gets logged when it does

Get this right, and you’ve got Zero Trust in practice rather than Zero Trust as a slide in a deck.

The architecture, briefly

Three pieces do the work:

The EPM service sits in the cloud, bolted onto Intune. It manages policy and reporting.

The Intune Management Extension (IME) is the bit already running on your endpoints that pulls those policies down.

The EPM client components sit on the device itself, evaluating each elevation request as it happens.

When someone launches something that needs admin rights, EPM checks it against your rules, decides whether to allow it, runs that one process elevated if approved, and ships the audit trail straight back to Intune. The user’s session itself never changes. Only the process does.

Licensing — check this before you get excited

EPM needs one of the following sitting on every user you want covered:

• Microsoft 365 E5
• Microsoft Intune Suite
• The Intune EPM add-on

It works on Windows 10 and 11, on Entra-joined or Entra hybrid-joined devices. Devices need to be enrolled in Intune with the Management Extension installed — if that’s not already ticking along on your estate, sort that first.

I’ve seen more than one EPM pilot stall for a fortnight because nobody checked licensing coverage until after the policies were built. Do this bit first.

Plan before you configure anything

Here’s the mistake I see most often: someone gets excited about EPM, builds a few elevation rules based on gut feel, and rolls it out. Three weeks later, the helpdesk is drowning in tickets because nobody actually knew what needed admin rights in the first place.

Before touching a policy, find out what’s actually elevating today. Look at:

• Line-of-business applications with dodgy installers
• Legacy software that’s never been rewritten to behave
• Update mechanisms that insist on admin rights for no good reason
• Device management and monitoring tools
• Developer toolchains
• Anything bespoke and internal

Microsoft Defender for Endpoint and advanced hunting queries are genuinely useful here — they’ll show you real elevation attempts rather than what you assume is happening. Your existing software deployment reports are worth a look too.

This discovery phase is unglamorous, and it’s the single biggest predictor of whether the rollout goes smoothly.

Roll it out in phases — don’t be a hero

A big-bang EPM deployment across the whole estate is asking for trouble. I always recommend three phases.

Phase 1 — Discovery. A small pilot group: IT admins, security team, application owners, a few power users. Use them to work out what your elevation scenarios actually look like before anyone else sees a prompt.

Phase 2 — Controlled pilot. Push EPM to a limited slice of real production users. Watch the user experience closely, check application compatibility, make sure reporting and audit events are landing where you expect.

Phase 3 — Enterprise rollout. Expand in waves — by department, device type, region, risk profile, whatever makes sense for your organisation. Waves, not one big switch.

Configuring EPM

Step 1 — Turn it on. In the Intune admin centre, go to Endpoint Security → Endpoint Privilege Management, enable it, and assign the policy to the device groups you actually mean to target.

Step 2 — Build your elevation settings policy. This is where you decide how elevation feels for the user. There are four flavours:

Automatic elevation — the app elevates automatically, with no prompt. Fine for trusted business apps and standardised, well-understood tools. I wouldn’t reach for this outside of software you genuinely trust without question.

User confirmed elevation — a prompt the user has to accept. Good for the odd admin task and medium-risk tools.

User justification — the user has to type a reason before it elevates. This is where I’d put anything remotely sensitive — administrative utilities, security tooling, that sort of thing. The justification text is more useful than people expect when you’re investigating something later.

Approval required — someone else has to say yes first. Reserve this for your genuinely high-risk admin tools and privileged maintenance work. It’s friction, and friction is the point.

Elevation rules — how you identify what’s allowed to run

Three ways to match an application, each with a real trade-off.

File hash. The most secure option, full stop. Nothing gets through unless it’s the exact binary you approved. The catch is maintenance — every update means a new hash, so this works best for tools that don’t change often, like dedicated security utilities.

File certificate. Matches on the publisher’s signing certificate rather than the exact file. Much less maintenance, and it survives normal software updates without you lifting a finger. The trade-off is you’re trusting the publisher more broadly, so this is best kept for Microsoft software and vendors you genuinely trust.

File path. Matches on where the file lives. It’s the easiest to set up and, frankly, the one I’d avoid wherever possible — a folder path is trivial to abuse if an attacker can drop something into it. Use this only when hash or certificate matching genuinely isn’t an option.

Configuration choices that actually matter

1. Remove local admin rights first

EPM isn’t meant to sit alongside widespread local admin access — it’s meant to replace it. If you deploy EPM but leave half your estate with standing admin rights, you’ve added a control without removing the risk it was meant to address. Pull permanent local admin memberships where you can, bring in proper privileged access management, and use EPM to handle the genuine exceptions.

2. Lean on certificate rules

For most enterprise software, certificate-based rules give you the best balance of security and sanity. Avoid broad path-based rules altogether, and think twice before going hash-only on anything that updates frequently — you’ll be maintaining that rule forever.

3. Make people justify PowerShell, CMD, and friends

PowerShell, Command Prompt, Registry Editor, Device Manager, MMC snap-ins — require justification and full audit logging on all of them. When something goes wrong later, having a written reason attached to every elevation is genuinely useful, not just a box-ticking exercise.

4. No wildcard rules. Ever.

Don’t allow entire folders or generic paths to elevate. C:\Temp\*, Downloads folders, user profile directories — these are exactly where an attacker would drop a payload, and a wildcard rule hands them the keys. If you find yourself writing a wildcard to save time, that’s the moment to stop and find the specific rule instead.

5. Wire it into Microsoft Defender for Endpoint

Defender gives you visibility into elevated process execution, incidents and investigations that EPM alone won’t show you. Your security team should correlate EPM events with endpoint telemetry, not treat them as two separate data sets.

6. Use RBAC properly

Don’t let one team own policy creation, application approval and reporting all at once. Split those responsibilities through Intune’s role-based access control. It’s a small thing that meaningfully reduces the risk of someone quietly approving their own elevation request.

7. Time-limit your approvals

If you use approval workflows, require a business reason, cap how long the approval lasts, and review them regularly. Elevation that never expires isn’t really elevation — it’s just admin rights with extra steps.

8. Audit everything, properly

Capture elevation requests, approvals, justifications, elevated launches and policy matches. Keep that data for as long as your security policy requires. When an incident happens, this data tells you what actually ran and why.

Keep watching after go-live

EPM deployments don’t finish at go-live — that’s when the real work starts. Review regularly:

• Which applications are being elevated most
• Failed elevation attempts
• Approval requests coming through
• What people are writing in the justification field
• Any device generating unusually high elevation activity

A sudden spike in elevation activity is worth investigating properly. It might just be a new tool rolling out, or a training gap, but it might also be someone poking around where they shouldn’t be. Treat it as a signal, not noise.

EPM isn’t the whole story

EPM meaningfully reduces risk compared with handing out local admin rights, but don’t mistake it for a complete security control. It’s one layer.

Pair it with Microsoft Defender for Endpoint, Attack Surface Reduction rules, Application Control for Business (the WDAC rebrand), Conditional Access, Privileged Identity Management, security baselines and device compliance policies. Together, that’s a layered defence that actually earns the label Zero Trust rather than just borrowing the phrase.

Mistakes I see again and again

• Migrating everyone at once instead of phasing it
• Leaning too hard on path-based rules because they’re quick
• Skipping the discovery phase and finding out what needs elevation the hard way
• Not monitoring elevation events once the policy is live
• Handing out approval permissions too broadly
• Letting developers elevate whatever they like, whenever they like
• Treating EPM as a substitute for proper application control rather than a companion to it

Fix these early, and the rest of the deployment tends to look after itself.

My Final thoughts

Of everything in Intune, EPM is one of the controls I’d genuinely encourage every organisation still running local admin rights to look at seriously. It lets you get rid of standing admin access without users feeling like they’ve been locked out of doing their jobs — which, in my experience, is usually the thing that kills these projects before they start.

The deployments that go well share the same pattern: proper discovery up front, a phased rollout, sensible governance, and monitoring that doesn’t stop once the project’s marked complete. Pair EPM with Defender for Endpoint, Application Control and your wider Zero Trust controls, and it becomes a genuinely load-bearing part of your endpoint security strategy — not just another policy nobody looks at again.

If you’re still sitting on widespread local admin rights, EPM is a practical, well-trodden way to start taking that away — without your users noticing much difference to how they work.