Why EPM Matters More Than Ever in 2026

If you have spent any time in enterprise IT, you know the permanent local admin problem. A user needs to install an application. A developer needs to run a build tool. A field technician needs to update a driver. For years, the answer was the same: add them to the local Administrators group and hope for the best. That era is over.

Modern ransomware and credential-theft attacks almost universally rely on one precondition: the victim is running as a local administrator. Remove that privilege and 50–80% of successful endpoint compromises simply do not work. Microsoft Intune Endpoint Privilege Management (EPM) is the engine that makes least-privilege a practical reality — not a security aspiration written in a policy document that nobody follows.

2026 has been a transformational year for EPM. A licensing overhaul included EPM in M365 E5 for the first time. The product shipped support for Azure Virtual Desktop. Admin Tasks went GA. Scope tag RBAC reporting was fixed. A new elevation type was added to preserve user profiles during elevation. This post covers every significant change — and exactly how to configure them in your lab and production environment.

What Changed in EPM — 2026 Complete Timeline

How EPM Works — Architecture & Core Concepts

Before diving into configuration, you need to understand exactly what EPM does at a technical level. Many deployments fail because administrators configure it without understanding the isolation model.

The EPM Architecture

When an Elevation Settings Policy is assigned to a device or user, Intune automatically installs the Microsoft EPM Agent at C:\Program Files\Microsoft EPM Agent. This agent runs as a Windows service called Microsoft EPM Agent Service and is the enforcement point for all elevation decisions.

The Three Elevation Types (2026)

Virtual Account Isolation (Why It Matters)

For all elevation types except “Elevate as current user,” EPM uses a virtual account to perform the elevation. This is the most important security concept in EPM. The elevated process runs as an isolated admin account that:

• Is NOT added to the local Administrators group (so it disappears after the process ends)
• Cannot access the logged-in user’s profile, AppData, or user registry hive
• Has no network identity — preventing elevated process from accessing network resources as admin
• Creates a hard boundary between the elevated process and the user session

The practical effect: even if a malicious binary tricks EPM into elevating it, it runs in an isolated context that cannot access the user’s credentials, browser cookies, or domain token. This is fundamentally different from traditional “Run as Administrator” which runs in the full user context.

Licensing — 2026 Changes Explained

The licensing model for EPM has been the single biggest blocker for adoption. Before July 2026, EPM required either a standalone Intune Suite add-on or an EMS E5 license. Most mid-market organizations on M365 E3 or E5 were paying for EPM separately — or simply not deploying it.

Best Practices — Senior Engineer Recommendations

1. Always Start with Audit Mode

Never deploy EPM in enforcement mode on day one. The EPM documentation itself recommends this, and every experienced engineer I know who skipped this step regretted it within two weeks. Audit mode deploys the EPM agent and logs every elevation event without blocking anything. This gives you a 2–4 week data baseline to understand what your users are actually elevating before you write a single rule.

2. Use File Hash Verification for Critical Elevation Rules

EPM supports multiple file detection methods: file path, file hash, certificate, and product name. File path alone is trivially exploitable — an attacker who knows your elevation rules can copy a malicious binary to the same path. Always use file hash + certificate signing in combination for any automatic elevation rule.

3. Implement Child Process Controls

One of the most overlooked EPM capabilities is child process controls. When a process is elevated by EPM, you can control whether child processes it spawns inherit elevated privileges. Without this, a user could elevate a legitimate application and then launch a shell from within it — inheriting full admin rights.

4. Use Support Approved Elevation as the Default for Unknowns

Configure your Elevation Settings Policy default to Deny with Support Approved rather than flat Deny. This means when a user tries to elevate something that has no matching rule, instead of getting a silent block with no recourse, they get a support request workflow — the request lands in your Admin Tasks queue for review.

5. Build Detection Rules with EpmTools — Not Manually

Do not manually look up file hashes and certificate details. The EpmTools PowerShell module can extract all detection attributes directly from any file, formatted ready to paste into your elevation rule.

6. Separate Elevation Rules Policies by User Group

Do not create one monolithic elevation rules policy and assign it to all devices. Create separate policies per business unit or persona (Developers, Finance, HR, IT). This gives you:

• Granular audit visibility — you see which GROUP is elevating which applications
• Scope isolation — a Finance elevation rule breach does not expose Developer elevated tools
• Easier rollback — if a rule causes issues in IT, you disable the IT policy without touching Finance
• Compliance reporting — demonstrate least-privilege by business unit for auditors

7. Review Admin Tasks Daily — Not Weekly

The new Admin Tasks queue in Intune (GA January 2026) centralizes support-approved elevation requests. If you are running Support Approved as your default for unknowns, the queue will fill quickly in the first two weeks. An unanswered elevation request blocks a user from completing their work. Set a service level target: review and respond within 4 business hours. Stale requests destroy user confidence in EPM and lead to workarounds (users finding ways to get local admin back).

Real-World Session — Enterprise Deployment Lessons

Lab Configuration Guide — Step by Step

Phase 1: Create the Elevation Settings Policy (Enable EPM)

1. Sign in to intune.microsoft.com → Navigate to Endpoint Security → Endpoint Privilege Management
2. Select Policies tab → Click Create Policy → Platform: Windows 10 and later → Profile: Elevation settings policy
3. Name: EPM-Settings-Audit-Phase → Click Next
4. Configure settings:
   • Endpoint Privilege Management: Enabled
   • Default Elevation Response: Deny Elevation — for audit phase, set to Audit (Allow with review)
   • Send Elevation Requests to IT Support: Enabled
   • Reporting Scope: Diagnostic data — All elevation events
   • Elevation Control: Enabled (allows right-click “Run with elevated access”)
5. Assignments: Assign to a test device group (not all devices yet) → Review + Create
6. Verify deployment: On test device, right-click any .exe → confirm “Run with elevated access” appears in context menu (may take 30 minutes to sync)

Phase 2: Use EpmTools to Extract File Attributes for Rule Building

1. On the enrolled test device, open PowerShell as standard user
2. Import the EpmTools module: Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'
3. Point to your test application: Get-ElevationRuleAttributes -FilePath "C:\path\to\yourapp.exe"
4. Copy the output: FileName, FileHash (SHA-256), Publisher (certificate), ProductName, ProductVersion
5. Keep this output open — you will paste these values into the elevation rule in the next phase
6. Also run: Get-EPMStatus — verify Agent State: Running, Policy State: Applied

Phase 3: Create an Elevation Rules Policy

1. In Intune → Endpoint Security → Endpoint Privilege Management → Policies → Create Policy
2. Profile: Elevation rules policy → Name: EPM-Rules-[TeamName]-v1
3. Click Add to create a new rule → Fill in:
   • Rule Name: Notepad++ Installer Elevation (or your app name)
   • Elevation Type: User confirmed (for testing) — change to Automatic for production if trusted
   • Child Process Behavior: Deny all child processes (safer default)
   • Elevation Condition: Add file condition → File hash (paste SHA-256 from EpmTools output)
   • Add second condition → Certificate (paste Publisher CN from EpmTools output)
4. Save rule → Review + Create → Assign to same test device group as Settings policy
5. Allow 30 minutes for policy sync → On test device, run: Get-Policies -PolicyType "ElevationRules" to verify rule appears

Phase 4: Test Elevation and Verify Audit Log

1. On test device as standard user: navigate to your test application .exe
2. Right-click → Run with elevated access → You should see: elevation confirmation prompt (for User Confirmed type)
3. Enter business justification text → Click Confirm → Application should install/run with elevated rights
4. Back in Intune: Navigate to Reports → Endpoint Privilege Management → Elevation Report
5. Confirm your elevation event appears — verify: User, Device, File, Elevation Type, Result (Managed), Timestamp
6. Test denial: Try running a .exe that has NO rule → should prompt for Support Approved request if you enabled that, or show denial message

Phase 5: Configure Admin Tasks for Support Approved Workflow

1. In Intune Admin Center → Tenant Administration → Admin Tasks
2. You should see any pending elevation requests submitted by users who encountered “Support Approved” prompts
3. Click on a request → Review: User, Device, File being requested, Business justification provided by user
4. Options: Approve (creates a one-time or reusable rule) or Deny
5. If you Approve and select “Create reusable rule” → a new elevation rule is automatically added to an assigned policy
6. Best practice: Review Admin Tasks at least twice per day during the first 30 days of enforcement-mode deployment

Phase 6: Switch from Audit to Enforcement Mode

1. After 2–4 weeks of audit data collection, review the EPM Elevation Report → identify top elevating applications
2. Create elevation rules for all high-frequency legitimate elevations before switching
3. Update EPM Settings Policy: Default Elevation Response → Deny with Support Approved
4. Stage the rollout: Start with IT team (most technically capable, can troubleshoot) → Expand to each business unit in 1-week waves
5. Monitor Admin Tasks queue after each wave — a spike in requests means missed applications in that group
6. Target: fewer than 5 new elevation requests per 100 users per week after stabilization (4–6 weeks post-enforcement)

Common Mistakes & How to Avoid Them

New: EPM on Azure Virtual Desktop (AVD)

The February 2026 EPM update adds support for Azure Virtual Desktop single-session VMs. This is a significant addition for organizations that host cloud desktops — previously the only option for elevating applications in AVD was to grant full local admin rights to the entire session.

Requirements for AVD EPM Deployment

• AVD single-session virtual machines only — pooled/multi-session not supported
• VMs must be enrolled in Intune (Entra joined or Hybrid Entra joined)
• Intune Suite add-on (or M365 E5 post-October 2026)
• Windows 11 22H2 or later on the session host VMs
• EPM policies assigned to the device or user groups that map to the AVD session hosts

AVD Lab Setup

1. In Azure portal: Ensure your AVD session host VMs are Entra-joined and show as enrolled in Intune (Intune Admin Center → Devices → All Devices)
2. Create a device group in Entra ID containing your AVD session host VMs (filter by device name pattern or tag)
3. Create EPM Settings Policy → Assign to the AVD device group (same steps as Phase 1 above)
4. Create EPM Rules Policy with elevation rules for AVD-specific applications → Assign to same AVD device group
5. Test: Log into an AVD session as a standard user → Right-click target application → “Run with elevated access” → Confirm elevation works
6. Verify audit log: EPM Elevation Report should show elevations tagged to the AVD session host device name

Monitoring & Reporting

Key Reports in Intune (2026)

KQL Query — Elevation Events in Defender Advanced Hunting

EPM elevation events also appear in Microsoft Defender XDR Advanced Hunting via the DeviceEvents table:

Final Thoughts — EPM in Your Zero Trust Strategy

EPM is not an optional add-on to a mature security program. It is a foundational control that should be deployed alongside, or shortly after, Microsoft Defender for Endpoint. The threat model is simple: remove permanent local admin rights and you eliminate the single most common precondition for successful endpoint compromise.

• Start with audit mode — always. 2–4 weeks of data before enforcement
• Child process controls are non-negotiable — every automatic elevation rule must define child process behavior
• Certificate + hash detection for automatic elevation rules — never file path alone
• The Admin Tasks queue is a service level commitment, not a to-do list — respond within 4 business hours
• Staged rollout: IT → Power Users → Finance → Standard users — each group one week apart
• 2026 licensing change: If you’re on E5, EPM arrives in your tenant October 2026 — start planning now

The organizations that have successfully removed permanent local admin from their user population share one common trait: they treated EPM as a user experience project, not just a security project. When users can accomplish their work without admin rights — because IT has built good elevation rules — they stop trying to get admin rights back.

Next in This Series