Endpoint Privilege Management not working: agent, rule or device

Endpoint Privilege Management not working almost always means one of three things: the agent never installed, the elevation rule never matched, or something on the device refused the elevation after the rule matched. The Intune admin center reports all three the same way, as a policy that applied. This post sorts them by symptom, names the documented cause behind each, and marks the points where Microsoft’s documentation stops.

Licensing is the gate in front of all of it. Outside Microsoft 365 E5, EPM is a paid capability, and which plans include an Endpoint Privilege Management licence is covered separately. If you are not yet sure the fault is EPM rather than the device’s wider relationship with Intune, start from Intune troubleshooting for elevation faults and everything around them. Every Microsoft fact below was checked against Microsoft Learn on 28 October 2026.

Endpoint Privilege Management not working: the three layers

Work out which layer you are in before you touch a policy. The symptoms separate cleanly once you know what to look for.

The agent never installed

The EPM client is not deployed as an app. Microsoft’s deployment planning guidance for Endpoint Privilege Management states that Intune provisions the components only when an elevation settings policy is received and that policy expresses the intent to enable EPM. An elevation rules policy on its own installs nothing. Once present, the client runs as the Microsoft EPM Agent Service and keeps its binaries in C:\Program Files\Microsoft EPM Agent. If that folder is missing, nothing further down this page applies yet.

The same page sets the device requirements. The device must be Microsoft Entra joined or Microsoft Entra hybrid joined, and enrolled in Intune or co-managed with Configuration Manager, with no workload requirement. Only 64-bit Windows is supported, Arm64 included. Windows 11 24H2 is supported as shipped; earlier Windows 11 releases and Windows 10 21H2 and 22H2 are supported only from a specific build with a named cumulative update. Windows 10 is listed as allowed after its October 2025 end of support, with functionality not guaranteed.

Two enrolment paths fail without saying so. Microsoft’s known issues list states that workplace-joined devices fail to enable EPM and do not process either policy type. The second is not on Learn: in an accepted answer on Microsoft Q&A in May 2024, an MVP attributed a missing agent on hybrid joined laptops to devices enrolled with a device enrolment manager account or the MDM-only option, which skips the second enrolment EPM depends on. The symptom the reporter quoted was a line in the management extension log reading Skipping EPM Scenario logging as PrivilegeManagement flag is not set. If you need to find that line, where the management extension writes its logs covers the file and its rotation.

The right-click option is missing but the agent is there

This one is documented. On devices running a Windows version earlier than 24H2 with the April 2025 update, the Run with elevated access option is not always added to the context menu after a successful agent installation. Microsoft’s workaround is to run EpmShellExtension.msix from C:\Program Files\Microsoft EPM Agent\EPMShellExtension to install the shell extension by hand. Later Windows versions do not have the problem, so the durable fix is the update, not the package.

The rule exists but never matches

This is the layer that wastes the most time, because it looks like a settings problem. When a user chooses Run with elevated access, EPM checks the device’s elevation rules for a match. If none applies, the device falls back to the default elevation behaviour in the elevation settings policy. A user who is asked for support approval on a file you wrote a rule for is not seeing the settings policy override the rule. They are seeing a rule that did not match.

A May 2025 Microsoft Q&A thread shows the pattern exactly. Two rules, one with a certificate condition and one without; the one without matched, the one with did not. The accepted community answer put it down to the certificate condition failing and noted that rules take precedence over settings rather than the stricter of the two winning. Microsoft’s guidance on creating elevation rules supports the mechanism: certificates must be trusted and valid, and validation checks trust, expiry and revocation. The known issues list adds that rules built on an expired certificate fail to elevate.

Capture attributes from the binary that will actually run, not from a copy or a vendor page. The EPM agent ships a cmdlet for it.

1# Read the attributes and certificate chain EPM will see for a file.
2# Run on a device where the EPM agent is installed.
3Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'
4Get-FileAttributes -FilePath 'C:\Tools\example.exe' -CertOutputPath 'C:\Temp\EpmCerts\'

Three further causes sit in Microsoft’s known issues list. Rules for a file on a network share or mapped drive may fail, because EPM supports only files stored locally. A file downloaded from the internet and still marked as blocked may fail to elevate until it is unblocked from its properties. And if two rules target the same file, EPM resolves them with its own logic, not the general behaviour in how Intune decides which conflicting policy wins: a deny rule always wins, user-targeted rules beat device-targeted rules, a hash rule is the most specific, then the rule with the most attributes, and any remaining tie resolves in the order user confirmed, elevate as current user, support approved, automatic.

The settings policy has its own conflict behaviour. Two elevation settings policies with conflicting values send the client back to its default behaviour until the conflict is resolved. Changing the default elevation behaviour several times in quick succession can also produce a reported conflict or a fallback to deny, which Microsoft describes as transient and self-resolving in under 60 minutes.

The rule matches and the elevation still fails

Every item here is on Microsoft’s known issues for Endpoint Privilege Management, and none of them shows up as a policy error.

1. UAC explicitly disabled. EPM does not support it. Microsoft points to the UAC prompt behaviour controls rather than disabling services. If more than one profile is setting UAC values, tracing which security baseline profile set a UAC value is the first job.
2. Administrator Protection enabled. It does not currently support elevations initiated from EPM, and on devices where standard users rely on EPM the elevation fails.
3. App Control for Business. EPM is not included in default policies, so a policy that does not allow the EPM client components stops them working.
4. Interactive sign-in restricted. EPM elevates through an isolated account that must be able to create an interactive sign-in session.
5. SSL inspection. EPM does not support break and inspect; the EPM endpoints have to be exempt or the client never receives policy.
6. Unsupported targets. EPM elevates .exe, .msi and .ps1 files. Settings app pages, Control Panel items and UWP apps cannot be elevated.

The failure modes

The isolated context row is the one users report as Endpoint Privilege Management not working at all, when it is behaving exactly as documented. An installer that needs to read from a share, elevated through EPM, cannot see the share. The fix is to stage the file locally, which also satisfies the local-file requirement above. When you need the device-side evidence in one bundle, collecting diagnostics remotely saves a remote session.

What I would do differently

I would build every rule from Get-FileAttributes output on the exact file and never from memory. For tools that update themselves, a hash rule stops matching at the next version, which is a property of what a hash is rather than anything Microsoft documents as a fault, so certificate plus product and internal name is the more durable pairing there. For scripts and one-off utilities I would use the hash every time.

I would leave child process behaviour at Require rule to elevate. Microsoft’s rule guidance states that allowing child processes to run elevated skips rule evaluation for the child, deny rules included. That is the setting that quietly turns one approved installer into a general-purpose elevation.

And I would decide the default elevation behaviour once, pilot it, and stop editing it. The 60-minute transient conflict is documented, and a helpdesk that sees every request denied for an hour after a policy change will not trust the tool again.

I have not run this in production. My tenant is a lab with no enrolled devices, so everything above comes from the Microsoft sources named and the dated community threads, and where I would expect it to bite hardest is hybrid estates enrolled years ago through a path nobody remembers.

Last verified: 28 October 2026.