Endpoint Privilege Management lets you remove local admin rights safely

Local administrator rights on Windows endpoints come up in almost every customer environment I review. Nobody disputes that cutting back local admin matters a great deal for security. Actually pulling those rights everywhere is another story. It has always meant pushback from users and from IT, because nobody wants to break workflows and support teams dread a wave of permission requests. Endpoint Privilege Management (EPM), available through the Intune Suite or as a standalone add-on (licensing details), finally gives us a way to take admin rights away safely without hurting productivity.

Endpoint Privilege Management controls elevation through two Intune policies

EPM gives you fine-grained control over privilege elevation, and it's built directly into Microsoft Intune. Older privilege management tools usually felt bolted onto Windows, so this is a real change. EPM is based on two policy types. The elevation settings policy covers global EPM behavior, such as the elevation timeout and whether users have to confirm or give a justification. The elevation rules policy defines which files or processes can be elevated, on what criteria and with what interaction. You deploy and manage both centrally in Intune, and reporting comes built in.

I like how flexible the elevation rules are. You can target an exact file path, but also a file hash or a publisher certificate. For tools that update often, certificate-based rules save a lot of work because you don't have to chase every new file version. A rule can ask the user for a justification or elevate silently and automatically, so you can weigh convenience against auditability.

A good rollout starts with reporting rather than enforcement

If at all possible, I roll out EPM in report-only mode first. The Intune reports show exactly which programs and tasks need elevation and who is asking for it. That takes a lot of guesswork out of the project and shows you where you'll need custom elevation rules. More than once, the report logs have pointed me to outdated software or workflows that IT automation should have been handling anyway.

Practical tip: Base your first real elevation rules on the most-requested processes in the reports. Keep the rule set small at the start, since a sprawling one only adds confusion and support overhead.

When the picture is clear, build rules for the most important applications. Only after that do I remove users from the local Administrators group. I do that with an Intune policy, and for the built-in Administrator account I combine EPM with Windows LAPS so a safe emergency access path still exists.

Elevation rules can be automatic, user-justified or support-approved

How you design the rules depends heavily on company culture and risk appetite. Intune lets you choose whether elevation happens automatically (for safe, widely used tools) or requires a user justification (with a prompt and an audit trail). A newer option, introduced in early 2024, is support approval: IT support reviews and approves the elevation request through a ticket. This model is still quite new and needs tight process controls, but it's an interesting addition to EPM.

Keep rules as specific as you can. Certificate or hash-based rules are ideal, and at the very least a rule should be tightly scoped to a known file path. Installers, scripts and other more complex cases may need a combination. Here is a simple certificate-based rule:

{
  "RuleType": "Certificate",
  "Publisher": "Contoso Ltd.",
  "ProductName": "ContosoApp",
  "AllowElevation": true
}

If you pair the technical controls with organizational measures, such as documentation requirements or support approval, you limit abuse and users can still get their work done.

EPM policies decide what happens to each elevation request

The diagram below shows how a typical elevation request is handled once EPM is in place, including the paths for automatic, user-justified and support-approved elevation:

flowchart TD
  User["User launches app"] --> EPMClient["EPM client checks local policy"]
  EPMClient -->|"Match: auto elevate"| Elevate["Elevation granted"]
  EPMClient -->|"Match: user justification"| Justify["User enters reason"]
  Justify --> Elevate
  EPMClient -->|"Match: support approval"| SupportReq["Support request created"]
  SupportReq --> SupportApprove["Support approves"]
  SupportApprove --> Elevate
  EPMClient -->|"No match"| Deny["Request denied"]

Figure: How Endpoint Privilege Management decides on an elevation request.

Intune reports and consistent licensing make the rollout easier

The elevation reports live right in Intune and show which applications get elevated, how often and by whom. In the early weeks this data is extremely useful for adjusting rules and tightening policies. On licensing, Endpoint Privilege Management is part of the Intune Suite or available as an individual add-on. You can technically mix license types across user groups, but in my experience administration and reporting are much easier if you keep it consistent. Microsoft's EPM overview has the latest details.

I put transparency first and control second

In my experience, the hard part of removing local admin rights isn't the technology. It's the fear of breaking workflows and the uncertainty about exceptions. EPM makes this much less painful. I start with transparency (report-only), then roll out targeted rules, and that way I avoid both over-restriction and chaos. This phased approach of reporting, piloting rules and then removing rights broadly has worked in several projects. Together with Windows LAPS and a well-run support process, Endpoint Privilege Management gives admins the tools they have needed for a long time.