Intune Endpoint Privilege Management Tools Compared: Native EPM, Admin By Request, BeyondTrust and ThreatLocker (2026)

This comparison is for Intune admins who want standard users on every laptop and still need a safe way to install an approved printer driver or run a signed vendor tool. It covers four ways of doing that on Windows devices managed by Microsoft Intune: Microsoft's native Endpoint Privilege Management (EPM), Admin By Request, BeyondTrust Endpoint Privilege Management and ThreatLocker (Elevation Control with application allowlisting).

It assumes devices are Entra joined or hybrid joined and enrolled in Intune (or co-managed), run a supported 64-bit Windows build, and can deploy Win32 apps; Learn's EPM planning prerequisites list the exact builds and network requirements. It is a decision framework built from Microsoft Learn and vendor documentation plus operating experience, not a lab benchmark. Where a vendor's public documentation does not answer a question, the article says so and puts it on your proof-of-concept list instead of guessing.

Licensing first: what you may already own

The cheapest EPM is the one already in your tenant, so check entitlement before any vendor call. Three facts from Microsoft Learn and Microsoft's pricing FAQ settle most of the confusion:

• Intune Plan 2 does not include EPM. Plan 2 covers Microsoft Tunnel for Mobile Application Management, specialty and shared device management, and firmware-over-the-air updates. EPM needs a separate entitlement.
• Microsoft 365 E5 includes EPM from July 2026. From July 2026, with the rollout completing by 1 August 2026, Microsoft 365 E5 and E7 include Endpoint Privilege Management, Enterprise App Management and Microsoft Cloud PKI, per Microsoft Learn. Microsoft 365 E3 instead receives Remote Help, Advanced Analytics and Plan 2. On other plans, EPM is a standalone add-on or part of the Intune Suite. Every route sits on top of Intune Plan 1 or Plan 2.
• Outside E5, you pay per user. Per Microsoft's published pricing FAQ, standalone Intune add-ons are priced individually between $2.00 and $5.00 per user per month, and the full Intune Suite is $10.00 per user per month. A 90-day trial covers up to 250 users.

Illustrative arithmetic, not a quote: for 1,000 users, Microsoft's standalone range works out to between $24,000 and $60,000 a year ($2 to $5, times 12 months, times 1,000), and the full Suite to $120,000 a year. If your tenant already holds E5, the marginal cost of native EPM is the rule-writing time. Native EPM is licensed per user, while the other three tools price per endpoint, so a shared-device estate and a one-user-many-devices estate can flip the comparison.

Which tool fits which estate

The four tools side by side

Taking admin rights away is a separate Intune project

Teams that "remove local admin" usually treat it as one change. It is two, and they fail differently. Taking the rights away is an Intune Account protection policy that edits the local Administrators group: quick, and the step that generates helpdesk tickets the same afternoon. Giving back exactly what people need is the job of a privilege management tool, which decides which binary may run elevated, for whom, with what approval, and what that binary may launch next. None of the four tools removes the rights for you; that stays an Intune policy whichever vendor you choose.

All four sit behind the same policy: Endpoint security > Account protection > Local user group membership, with the Administrators group and the Add (Replace) action. Replace works like a Restricted Group, so any member you do not list is removed.

Microsoft's own migration walkthrough lists two Entra SIDs to keep: the Global Administrator role and the Microsoft Entra joined device local administrator role, both with SIDs starting S-1-12-1-. Before you replace, also list anything else that legitimately belongs there: a Windows LAPS managed account, a break-glass account or a local account the vendor agent creates. A Replace policy that omits them locks you out the next time the policy syncs.

Known conflicts to check first:

• Native EPM does not support elevations when Administrator Protection is enabled.
• Native EPM does not support UAC being disabled by methods other than the documented policy controls.
• Native EPM can be blocked by App Control for Business policies that do not account for the EPM client. A default-deny tool such as ThreatLocker needs the same care for every other agent on the device.

Child processes and the file-dialog escape

This is where tools differ most, and it is the axis that decides whether "elevated" means "this one installer" or "this user can now do anything".

The child process problem

A legacy setup.exe is the classic case. You approve the bootstrapper, it unpacks and launches msiexec.exe, which also needs administrator rights. If the tool elevates only the file you approved, the install fails halfway and the ticket comes back. If it elevates everything the parent launches, you have created an escape route.

The escape is simple and old. An elevated application with a file dialog (Open, Save As, Browse) lets the user right-click in the dialog and open a command prompt or another executable. That process inherits the elevated context. Anyone who can reach an elevated Open File dialog can reach an elevated cmd.exe.

Native EPM

Native EPM gives you the clearest documented controls. Each elevation rule sets Child process behavior:

• Require rule to elevate (the default): the child must match a rule of its own before it runs elevated. Deny rules apply.
• Deny all: every child launches without elevation.
• Allow all child processes to run elevated: rule evaluation for the child is skipped, including deny rules, so a child can run elevated even when an explicit deny rule exists for it.

For the setup.exe case, create one rule for the bootstrapper with the default child behaviour and a second rule for msiexec.exe limited by file hash, certificate or arguments. Microsoft's own advice is to avoid broad rules for applications that can start other processes, such as command shells and script engines. EPM can also restrict command-line arguments to an allow list, which is how Microsoft's dsregcmd example permits /status and blocks /leave.

Native EPM also has documented gaps:

• It elevates .exe, .msi and .ps1 files. UWP apps, and Control Panel items and Settings app functions, cannot be elevated directly. Microsoft suggests packaging some of these as scripts and approving the script.
• The separate Elevation system settings policy lets standard users change selected Windows settings, including IPv4, IPv6 and DNS server configuration. That covers the common "I need to change my adapter settings" ticket without elevating anything.
• Files must be local. Network shares and mapped drives are not supported.
• A rule that identifies a file only by name and certificate can be hijacked by renaming a different file signed by the same certificate. Use the file hash, or pair the certificate with product name and internal name, and set a file path in a location standard users cannot write to.

Third-party tools

ThreatLocker pairs elevation with Ringfencing. Its documentation describes blocking an elevated application from launching PowerShell, Command Prompt or CScript while allowing named companions the application needs. The vendor's own FAQ positions Elevation Control as a convenience layer, with Ringfencing doing the containment, so budget for configuring both. Reviewers note that Ringfencing takes tuning for some global applications.

BeyondTrust documents application rules, service control and command or PowerShell control, which is deeper than file-by-file elevation. COM and ActiveX rule types are part of the Windows rule model, but confirm the exact types in the admin guide for the version you would buy.

Admin By Request is built around the user choosing an application to run as administrator, with approval and scanning in front of it. We did not find public documentation of child-process containment, so treat it as untested until you run the check below.

Run this regardless of vendor, in your pilot, on a standard-user device:

1. Elevate a rule-approved application that has a file dialog (an installer wizard with a Browse button is enough).
2. In the dialog, right-click an executable such as cmd.exe and open it.
3. Run whoami /groups in whatever launches. If it shows a high mandatory level, the escape works. If it does not launch, or launches as the standard user, containment works.
4. Repeat with ncpa.cpl, devmgmt.msc and services.msc to see which Control Panel and MMC items each tool can actually handle.

Approvals: who clicks, and what happens offline

The goal is a legitimate request approved in minutes, without giving the user a standing admin account.

Native EPM keeps approval inside Intune. A user submits a request with a business reason, and an admin with the Endpoint Privilege Management Elevation Requests permission approves or denies it on the Elevation requests tab. Three details matter for on-call design:

• Intune does not notify admins of new requests. Someone has to watch the tab or the Admin tasks pane.
• An approval enables the elevation for 24 hours from the moment of approval, with no custom period and no way to cancel early.
• A denial is not sent to the user, so the helpdesk has to reply by hand.

If your tenant is licensed for Security Copilot, the request pane has an Analyze with Copilot option that checks the file hash against Microsoft threat intelligence before you approve.

There is no documented offline challenge-response for native EPM. A laptop that cannot reach Intune cannot receive a new approval.

Admin By Request is built around that situation. Approvals can come from the portal or the vendor's iOS and Android apps. For an offline laptop, the user chooses the PIN option, the device shows PIN 1, the admin enters it against that device in the portal or app and reads back PIN 2, and the user types that in. One university guide notes the PIN is specific to the device. The same guide says a normal approval request stays invisible until the device reconnects, so a phone hotspot is the usual workaround.

ThreatLocker processes requests in its portal or mobile app, and elevation can be time-limited or scheduled.

BeyondTrust approval channels and offline behaviour were not verified from public documentation. Put them on your POC list.

Evidence for auditors: ISO 27001 Annex A 8.2

Cyber Essentials and ISO 27001 do not ask for a particular tool. They ask you to show that administrator rights are limited, approved and reviewable. For ISO 27001:2022 that is the privileged access rights control, Annex A 8.2 (the standard is published as ISO/IEC 27001:2022; Microsoft's cloud security benchmark privileged access controls map least-privilege and privileged-access practices to A.8.2, which is a useful starting point for your own control mapping). The evidence an assessor wants is: which binary ran elevated, who asked, who approved, what it launched, and whether anyone checked the file.

The native 30-day report window matters for audits. If your assessor wants a year of elevation history, pull the data through the Graph privilegeManagementElevations endpoint on a schedule, or export it, rather than relying on the console.

Deploying agents next to native EPM

Native EPM installs its own client, so "no extra agent" is not quite right. What you avoid is a second vendor's agent, console and release cycle. Intune provisions the Microsoft EPM Agent (service Microsoft EPM Agent Service, files under C:\Program Files\Microsoft EPM Agent) when an elevation settings policy that enables EPM is assigned. There is nothing to package.

The three third-party tools are Win32 apps. Deploy them like any other agent:

• Use a detection rule that checks for the vendor's service or a minimum file version, never an exact version, so an in-product update does not make Intune reinstall the old package. The Intune Win32 detection script generator builds a service, file version or MSI product code check that follows the Intune detection contract.
• Order matters on new devices: install the agent through the Enrollment Status Page or a required app before the Account protection policy removes admin rights, or the first user has nothing to elevate with.
• If packaging the agent is the slow part, the Win32 packaging tools comparison covers how to build and maintain the .intunewin. The same one-owner rule applies: one tool, one deployment, one detection rule.
• If the install fails, look up the code in the Intune error code lookup before reading the whole log.

Pre-flight diagnostics and pilot gates

Run this on a pilot device before the Account protection policy removes anyone, and again after.

1. Who is still a local administrator?

Get-LocalGroupMember -Group "Administrators" |
  Select-Object Name, ObjectClass, PrincipalSource |
  Sort-Object Name

Expected output shape: the built-in Administrator account (disabled by default), the Entra role SIDs, a LAPS or break-glass account if you use one, and the user you are about to demote. On some Entra joined devices Get-LocalGroupMember can fail on Entra SIDs it cannot resolve. If it errors, fall back to:

net localgroup Administrators

Any name you cannot explain goes on the keep-or-remove list before you write the Replace policy.

2. Is the Intune EPM client present and healthy?

Get-Service -Name 'Microsoft EPM Agent Service' | Select-Object Status, StartType

Import-Module 'C:\Program Files\Microsoft EPM Agent\EpmTools\EpmCmdlets.dll'
Get-ClientSettings
Get-Policies -PolicyType ElevationRules

The service should be running and set to automatic. Get-ClientSettings shows the effective client settings, and Get-Policies lists the elevation rules the device actually received. If a rule you assigned in the console is missing here, it has not reached the device and will not elevate. On Arm64, use Windows PowerShell x64 for the module.

3. What do the logs say?

Policy delivery runs through the Intune Management Extension, so start with its main log:

$ime = "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log"
Select-String -Path $ime -Pattern 'EPM|Privilege' |
  Select-Object -Last 30 LineNumber, Line

We could not find a log file name for the EPM client documented by Microsoft, so do not hard-code one. Look for what exists on your build:

$roots = @(
  "$env:ProgramData\Microsoft\IntuneManagementExtension\Logs",
  "$env:ProgramData\Microsoft",
  "$env:ProgramFiles\Microsoft EPM Agent"
)
Get-ChildItem -Path $roots -Recurse -Include '*Epm*.log' -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, LastWriteTime, Length -First 10

Get-WinEvent -ListLog '*EPM*', '*PrivilegeManagement*' -ErrorAction SilentlyContinue

If EpmTools.log or a similar file turns up under your pilot build, note its path in the runbook. If nothing does, rely on Get-Policies and the Intune reports, which are the documented sources.

4. Gate each pilot ring

1. Audit first. Assign an elevation settings policy with EPM enabled, Send elevation data for reporting set to Yes, the reporting scope set to Diagnostic data and all endpoint elevations, and no default elevation response. Wait for data: it can take 24 hours to appear.
2. Read the Overview dashboard. The users with only managed elevations tile lists your candidates for revocation. Frequently unmanaged elevations is your rule backlog.
3. Build rules from the Elevation report, with a file hash or certificate plus product name, a protected file path and the default child process behaviour.
4. Set a safe default. Move the default elevation response to Deny all requests or Require support approval, not Require user confirmation, which allows any file to elevate.
5. Test as a standard user on one device per hardware model, including the child-process escape check in section 1.
6. Only then assign the Local user group membership policy to Ring 0, check Get-LocalGroupMember again and leave it for a full work week before Ring 1.

If you use a third-party tool, steps 1 to 3 are the same idea in its own console: audit mode, rule build, safe default, then revoke.

When a rule or policy blocks real work

Plan for the day an elevation rule or the admin-removal policy stops someone doing their job.

1. Stop the ring. Remove the Local user group membership assignment from the ring. Devices pick up the change at the next policy sync.
2. Restore access narrowly. Re-add the affected user through a targeted Add (Update) policy, or approve the specific file, rather than re-granting admin to a whole group.
3. Fix the rule. Add the missing child process or hash from the Elevation report, and re-test before the ring resumes.
4. Keep break-glass. Make sure a LAPS-managed or break-glass local administrator survives every Replace policy, or recovery means re-imaging.

When not to use each tool

• Do not use native Intune EPM if macOS or Linux endpoints need the same workflow, or if you need push notification and offline approval for field laptops. It also should not be your answer if your estate runs Administrator Protection and cannot turn it off.
• Do not use Admin By Request as your only control if you need documented child-process containment until you have run the escape test in your tenant, and do not rely on the free tier's support.
• Do not use BeyondTrust for a small estate with no SIEM or PAM programme: you pay for depth you will not operate. For a regulated estate, do not shortlist it on datasheets alone: its approval flow and offline behaviour could not be verified publicly.
• Do not use ThreatLocker purely to avoid writing elevation rules. Default-deny application control is a bigger operational change than privilege management, and a tuning backlog of its own.

Pilot checklist

• Check which licences already include EPM (Microsoft 365 E5 or E7, the Intune Suite, or the add-on; Plan 2 does not) before any vendor call
• Record every current local administrator on pilot devices with Get-LocalGroupMember
• Decide the elevation owner per application: native EPM or a third-party tool, never both
• Start in audit mode and collect at least two weeks of elevation data
• Build rules from reports using file hash or certificate plus product name, with a protected file path
• Run the child-process escape test and the ncpa.cpl, devmgmt.msc and services.msc test on each candidate
• Test an offline laptop approval end to end if you have field staff
• List every account the Replace policy must keep: Entra role SIDs, LAPS, break-glass, vendor agent accounts
• Capture one request-to-approval evidence chain for your auditor
• Confirm per-user versus per-endpoint licence counts against your real numbers

Choosing a tool, and where to insist on a proof of concept

• Windows-only Intune estate that already owns the entitlement: start with native Intune EPM. It adds the least vendor surface, and its child process controls are the best documented here. Plan for console-based approvals and a 24-hour approval window.
• Mixed OS fleet, field laptops or a small team: trial Admin By Request. The offline PIN and the free 25-seat tier make it the easiest to prove. Run the escape test before you commit.
• Endpoint security team that also wants default-deny application control: price ThreatLocker as a platform, and pilot Ringfencing alongside Elevation Control.
• Regulated estate with SIEM and PAM requirements: shortlist BeyondTrust, but treat the recommendation as conditional on a proof-of-concept trial. Ask it to demonstrate approval flow, offline behaviour and log export, because none of those could be verified from public documentation.

The first deliverable of an EPM project is an audit-mode report, not a rule. Collect two weeks of elevation data before you write anything, and let that report, rather than a vendor demo, decide what the first rules look like.

Primary Sources

• Use Endpoint Privilege Management with Microsoft Intune
• Plan and prepare for Endpoint Privilege Management deployment (prerequisites)
• Creating elevation rules with Endpoint Privilege Management
• Support approved file elevations for Endpoint Privilege Management
• Reports for Endpoint Privilege Management
• Known issues for Endpoint Privilege Management
• Transition users from administrator to standard user with EPM
• Account protection policy for endpoint security in Intune
• Microsoft Intune planning guide: costs and licensing
• Use Microsoft Intune Suite add-on capabilities
• Microsoft Intune advanced capabilities
• Microsoft Intune plans and pricing
• Microsoft cloud security benchmark: privileged access
• ISO/IEC 27001:2022
• Admin By Request pricing and endpoint privilege management
• ThreatLocker Elevation Control
• BeyondTrust Privilege Management for Windows: application rules

Related Reading

• Intune Win32 detection script generator
• Intune error code lookup
• Intune Win32 app packaging tools compared
• Intune vs SCCM/MECM
• Endpoint Security hub