Intune Endpoint Privilege Management: Saying Goodbye to Local Admin

Removing local administrator rights from end users is one of those security controls that everyone agrees is important and nobody actually wants to do. I get it. The potential for user disruption, the inevitable pushback, the flood of support tickets — it’s enough to make you quietly shove it to the bottom of the backlog and hope nobody notices.

Thing is, local admin rights remain one of the most exploited weaknesses in endpoint security. Malware loves admin rights. Ransomware loves admin rights. That one user who keeps installing browser extensions from questionable sources? They really love admin rights. The risk is well understood and it’s not going anywhere.

Endpoint Privilege Management (EPM) in Intune is Microsoft’s answer to the classic “remove admin but don’t break everything” problem. I’ve been involved in several rollouts now, and I want to share what’s actually worked — and what hasn’t.

How EPM Works

The concept is straightforward enough. You remove users from the local Administrators group, then use EPM to selectively elevate specific applications or processes when there’s a legitimate need. Users run as standard users by default, and EPM gives them a controlled way to run things with elevated privileges.

EPM sits within Intune as part of the Endpoint Security workload. Once it’s enabled, you deploy elevation policies that define:

• Which applications can be elevated — identified by file name, file path, file hash, or certificate
• How the elevation happens — automatically (transparent to the user), with user confirmation, or requiring support approval
• What business justification is needed, if any
• Audit and reporting of every elevation event

The client component runs on the endpoint and intercepts elevation requests. When a user tries to do something requiring admin rights, EPM checks the request against your policies and either elevates it, prompts the user, or blocks it.

The EPM overview documentation covers the architecture in detail.

Elevation Types

Getting the elevation type right for each scenario is where the real work is. You’ve got three options:

Automatic elevation: The application runs elevated without the user doing anything different. They might not even realise EPM is involved. This works well for applications that always need admin rights and are trusted — your IT management agents, specific line-of-business apps, approved development tools, that sort of thing.

User confirmed elevation: The user gets a prompt asking them to confirm they want to elevate and optionally provide a business justification. This is the sweet spot for most scenarios in my experience. It lets the user self-serve while creating an audit trail and adding just enough friction to discourage casual elevation.

Support approved elevation: The user requests elevation and it goes into a queue for IT to approve. This is for edge cases — applications you’re not sure about, temporary needs, high-risk scenarios. It adds latency, obviously, but sometimes that’s the right call.

My recommendation: start with user confirmed as your default, use automatic for your known-good applications, and reserve support approved for the genuinely sensitive stuff. If you make everything support approved, your service desk will drown and your users will revolt. I’ve seen it happen.

Building Your Elevation Rules

This is the most time-consuming part of an EPM deployment, but it’s also the part that matters most. Get this right and the rollout goes smoothly. Get it wrong and you’ll spend months firefighting.

File hash rules are the most secure option. You identify the exact file hash of the executable that needs elevation. Even if someone renames a malicious file to match a trusted application name, it won’t be elevated. The downside? Hashes change with every update, so you need a process to keep them current.

Certificate-based rules are more practical for most organisations. You trust the publisher certificate rather than a specific file hash, which means any application signed by that publisher gets elevated (within your other rule constraints). Less maintenance, slightly broader trust surface.

File name and path rules are the least secure but sometimes you’ve got no choice. Use these sparingly and always in combination with other attributes where you can.

Here’s an approach I’ve used that’s worked well:

1. Audit first — deploy EPM in audit-only mode for 2-4 weeks. This captures every elevation request without blocking anything.
2. Analyse the data — look at what’s actually being elevated. You’ll find patterns. The same 15-20 applications come up repeatedly in most environments.
3. Create rules for the common ones — certificate-based rules for vendor-signed software, hash rules for internal applications.
4. Test with a pilot group — remove admin rights from a willing group of users with the elevation policies in place. Find the gaps and fix them.
5. Roll out in waves — don’t do everyone at once. Department by department, building confidence as you go.

The User Pushback Problem

I’ll be honest about this. Some users will not be happy. Developers in particular tend to feel strongly about having admin rights. Same goes for power users who’ve been installing whatever they want for years.

Here’s what I’ve picked up from managing this:

Communicate early and clearly. Don’t surprise people. Explain why it’s happening, what they’ll notice changing, and how they can request elevation for legitimate needs. Frame it as “we’re giving you a safer way to run these applications” rather than “we’re taking away your rights.”

Have a fast-track process for genuine needs. If a developer needs to install a new tool and the elevation policy doesn’t cover it yet, there needs to be a quick way to get it added. If the turnaround is a week, you’ve lost them. Same day is the target.

Use the data. After the audit period, you can show exactly which applications need elevation. This turns what feels like an emotional argument into a factual one. “We’re not blocking anything you actually use — we’re just adding a safety net.”

Accept some exceptions — temporarily. For certain roles, you might need a phased approach. Grant a time-limited elevation capability while you build out the rules for their specific toolset. The key word there is temporary. Set a review date and actually stick to it.

Get leadership buy-in. This is not optional. When the first senior person complains about not being able to install something, you need leadership to back the policy. Without that support, the whole programme falls apart. I’ve seen this happen too.

Reporting and Ongoing Management

EPM provides reporting through Intune that shows:

• Elevation requests — approved, denied, and pending
• Which applications are being elevated most often
• The business justifications users provide
• Trends over time

This data matters for two things: showing stakeholders that EPM is delivering security value, and spotting new applications that need elevation rules. I’d recommend reviewing the reports weekly for the first couple of months, then dropping to monthly once things settle.

You’ll also want a process for adding new elevation rules when new software gets deployed. This needs to be part of your application deployment workflow, not something you bolt on after the fact. When IT deploys a new application, the EPM elevation rule should ship as part of the package.

Licensing and Prerequisites

EPM requires Microsoft Intune Suite or the standalone Endpoint Privilege Management add-on licence. Devices need to be Intune enrolled and running Windows 10/11. The licensing documentation has the specifics.

Final Thoughts

Removing local admin rights is one of those controls that pays for itself many times over. Every ransomware incident report I read seems to mention local admin as a contributing factor. EPM makes it practical to actually do this without destroying user productivity.

The deployment isn’t trivial — it takes planning, communication, and ongoing attention. But I’ve yet to see an organisation regret doing it once they’re through the initial transition period.

Start with audit mode. Build your rules from real data. Communicate relentlessly. And be prepared for the first few weeks to be noisy — that’s normal, and it does settle down.

The EPM deployment guide is worth a read before you start. And if you want to swap notes on EPM rollout experiences, you know where to find me.