Implementing Intune Endpoint Privilege Management: Elevation Rules, Approval Flows, and Audit

Standing local administrator rights are the single largest unmanaged attack surface on a Windows fleet. Every “the app only works as admin” exception becomes a permanent, always-on elevation that ransomware, token theft, and lateral movement all happily reuse. Endpoint Privilege Management (EPM) lets you take the local Administrators group away from your users and hand back just-in-time, per-file elevation governed by policy, justification, and approval. This guide builds the full stack: licensing the add-on, authoring elevation settings and rules, choosing between automatic, user-confirmed, and support-approved flows, controlling child processes so an elevation doesn’t become a privilege-escalation chain, and tuning the whole thing from collected telemetry.

1. The least-privilege model: why standing local admin is the problem

The usual justification for leaving users in the local Administrators group is a handful of applications that genuinely need elevation — a legacy line-of-business installer, a developer tool that writes under Program Files, a hardware utility. The cost is wildly disproportionate to the benefit:

• An admin token is present for the entire session, not just the 30 seconds the installer needs it. Malware running in that session inherits it.
• UAC consent prompts on an admin account are a single click, so phishing and drive-by payloads elevate silently as far as the user is concerned.
• You can’t audit what was elevated, by whom, or why — the right is ambient.

EPM inverts the model. The user is a standard user, and elevation is granted to a specific executable that matches a rule you authored, for the moment it runs, with optional justification and approval, and every elevation is logged. The mental shift is from “this person is an admin” to “this binary, identified by hash or signing certificate, is allowed to run elevated under these conditions.”

EPM is not a UAC replacement and it is not AppLocker. UAC asks “do you consent to this admin action” after you already hold admin rights; EPM grants elevation to a standard user who has none. AppLocker decides whether a binary may run at all; EPM decides whether a binary that is allowed to run may run elevated. They compose well, but they answer different questions.

2. Licensing, add-on activation, and the EPM client

EPM is a paid add-on. It is included in the Microsoft Intune Suite, and it is also available as a standalone EPM add-on licensed per user for tenants that don’t want the full Suite. There is no EPM in the base Intune Plan 1/Plan 2 SKUs.

Activation is a tenant-level step, separate from assigning the license to users:

1. In the Intune admin center, go to Tenant administration -> Intune add-ons (some tenants surface it under Tenant administration -> Endpoint Privilege Management). Confirm the add-on shows as Active.
2. Assign the EPM (or Intune Suite) license to the users whose devices will be managed. Licensing is per user, evaluated against the primary user of the enrolled device.
3. Devices must be Microsoft Entra joined or Entra hybrid joined and Intune-enrolled, running a supported Windows 10/11 Enterprise or Pro build.

You do not package or deploy an agent. Once the add-on is active, the user is licensed, and an EPM policy is assigned, Intune provisions the EPM client-side component to the device automatically on the next policy sync. The client is what intercepts elevation, evaluates rules locally, and reports elevation events back to Intune. If you ever need to confirm provisioning on a device, the client and its diagnostic logs live under the Intune management extension; the simplest signal is that the Run with elevated access right-click verb appears and elevation reporting starts flowing.

Licensing is checked at the device’s primary user. A shared or kiosk device with no licensed primary user will not get EPM behavior even if a policy is assigned to it. For shared devices, scope EPM to the device group and ensure a licensed user is set, or plan a different control.

3. Authoring the elevation settings policy: default behavior and prompts

EPM uses two distinct policy types, and conflating them is the most common authoring mistake:

Policy type	Purpose	How many apply
Elevation settings policy	Turns EPM on for the device, sets the default elevation behavior, and controls reporting scope	One effective per device
Elevation rules policy	Per-file rules that grant elevation to specific executables	Many can apply and merge

Create the settings policy under Endpoint security -> Endpoint Privilege Management -> Elevation settings policy -> Create policy (platform: Windows). The settings that matter:

• Endpoint Privilege Management: must be Enabled. This is the on switch — without it, the client does nothing.
• Default elevation response: what happens when a user invokes elevation on a file that no rule matches. Options are Deny all (block; the user can only elevate what an explicit rule allows), Require user confirmation, or Require support approval. Deny all is the correct default posture for a hardened fleet — explicit-allow only.
• Send elevation data for reporting: turn this on, and choose the scope. To build rules from telemetry (Step 8) you want Diagnostic data and all endpoint elevations, which reports all elevations including ones not managed by a rule. Tighten the scope later once your rules are mature.

The “default elevation response” is the lever that makes EPM a least-privilege control rather than a convenience feature. Set it to Deny all so that elevation is impossible except where you have explicitly authored a rule. If you set it to Require user confirmation, you have effectively re-created click-through admin for any binary the user can launch — useful as a discovery posture for a short pilot, dangerous as a steady state.

The validation rules and prompts a rule enforces (justification text, Windows authentication, multifactor) are defined per rule, not globally — covered next.

4. Elevation rules by file: hash, certificate, and attributes

An elevation rules policy contains one or more rules. Each rule has two halves: how the file is detected, and what elevation behavior applies when it matches. Create one under Endpoint Privilege Management -> Elevation rules policy -> Create policy, then add rules.

File detection

EPM identifies the target executable by a combination of attributes. The two anchors are:

• File hash (SHA256): the strongest, most specific match. The rule applies only to this exact build of the binary. Precise, but brittle — every vendor update changes the hash and breaks the rule.
• Certificate: match on the file’s code-signing certificate. You upload the signing certificate (or its public portion), and EPM can require the file to be signed by it. This is the durable choice: a vendor that re-signs every release with the same certificate keeps matching across versions.

You then narrow a certificate match with file attributes so it doesn’t over-grant to everything that vendor signs:

Attribute	Example	Why
File name	vendortool.exe	Restrict to one binary
Internal name	VendorTool	Survives a renamed file on disk
Product name	Vendor Hardware Suite	Scope to a product family
Description	Vendor Configuration Utility	Extra disambiguation
Minimum version	4.2.0.0	Don’t grant to old, vulnerable builds

The right pattern for a maintained, signed app is certificate + internal name + minimum version. You get durability across updates (certificate), resistance to a swapped-in lookalike on disk (internal name, which lives in the file’s version resource, not the filename), and a floor that refuses to elevate a downgraded, known-vulnerable build. Reserve pure hash rules for unsigned binaries you control and re-hash on every change.

You can capture these attributes by hand, but the realistic source is the elevation report: EPM records the full file metadata of observed elevations, and the portal lets you create a rule directly from a reported elevation, pre-filling hash, certificate, and attributes. Build rules from what your fleet actually runs, not from guesses.

Elevation behavior and validations

Each rule sets one elevation type (Section 5) plus optional validations the user must satisfy before the elevation is granted:

• Business justification: force the user to type a reason. It is recorded in the elevation report — your audit trail of why.
• Windows authentication: require the user to re-enter their credentials (proves presence; defeats a background process silently elevating).
• Multifactor authentication / business justification combinations: stronger gates for sensitive rules.

5. Automatic vs user-confirmed vs support-approved flows

The elevation type is the heart of the design. Three exist, and choosing correctly per rule is what separates a usable rollout from a help-desk flood or a security theatre.

Type	User experience	When to use
Automatic	Elevation happens silently, no prompt	Trusted, frequently-run, low-risk signed apps where prompting adds nothing
User confirmed	User right-clicks Run with elevated access, then satisfies the rule’s validations (justification, Windows auth)	The default for most rules — the user is in control and accountable
Support approved	User submits a request; an approver in Intune must approve before elevation is granted	High-risk binaries, or anything that should never self-serve

Automatic is convenient and the most dangerous to over-use. It elevates with no user interaction and no per-event justification, so it should be reserved for binaries you fully trust and whose risk of being abused as an elevation vector is low. A signed, internal deployment tool that runs unattended is a fair candidate; a general-purpose utility is not.

User confirmed should be your default. Pair it with Windows authentication so a human is demonstrably present, and with business justification so you capture why — this is the posture that satisfies most auditors while keeping users productive. The user invokes it deliberately through the Run with elevated access context-menu verb that EPM adds.

Support approved moves the decision off the endpoint entirely. The user’s elevation produces a request that lands in the EPM approval queue; a delegated approver reviews the file, the device, the user, and the justification, then approves or denies. Nothing elevates until approval. This is the right control for rare, sensitive, or one-off elevations where self-service is unacceptable. It requires the approver to hold the appropriate Intune RBAC permission for EPM elevation requests, and the default elevation response or the rule itself to be set to support-approved.

A clean three-tier model: automatic for a tiny allowlist of fully-trusted signed tools, user-confirmed + Windows auth + justification for the bulk of legitimate business apps, and support-approved as the catch-net (including as the default response) for everything else. That gives you self-service where it’s safe and a human gate where it isn’t.

6. Child process behavior: preventing escalation chains

This is the control people miss, and it is where a well-intentioned elevation rule turns into a privilege-escalation primitive. When an elevated process spawns children, what privilege do those children inherit? If the answer is “the parent’s elevated token,” then any app you elevate that can launch another process (a setup wizard that shells out to cmd.exe, an installer with a “browse” dialog that can open Explorer, a tool with a built-in scripting host) becomes a way for a standard user to get an elevated shell.

Each rule sets a child process behavior:

Setting	Effect	Use
Deny all	Child processes get the standard user token, not the elevated one	Safest default — elevation does not propagate
Require rule	Child processes are elevated only if they themselves match an elevation rule	Multi-binary apps where the helper is also known and ruled
Allow all	Child processes inherit the parent’s elevated context	Avoid unless you fully trust the entire process tree

The default for any rule that elevates an interactive application should be Deny all child processes. An installer that needs a known helper to also elevate is the case for Require rule — you author a rule for the helper too, and only that helper elevates, not an arbitrary cmd.exe the installer can be coerced into launching. Allow all is almost never correct; it re-opens exactly the escalation path EPM exists to close.

The classic abuse: a signed vendor installer with a file-picker. Elevate it with Allow all, click the “browse for a file” button, right-click a folder, choose “open in terminal” — and you now have an elevated shell as a standard user. Deny all child behavior neutralizes this entirely; the picker’s spawned processes drop back to the standard token. Treat Allow all as a finding in a security review.

7. Verify

Confirm both the security outcome (no standing admin, elevation gated) and the telemetry (events reaching Intune). Run these against a real enrolled, licensed device after policy sync.

First, confirm the user is genuinely not a local admin — EPM is pointless if the old membership lingers:

# The interactive user must NOT be in the local Administrators group
Get-LocalGroupMember -Group "Administrators" |
    Select-Object Name, ObjectClass, PrincipalSource

Confirm the EPM client provisioned and policy landed. The Intune management extension logs record EPM policy processing; check that the extension is healthy and that the device shows the assigned EPM policies:

# Intune Management Extension service should be running (EPM rides on it)
Get-Service IntuneManagementExtension | Select-Object Status, StartType

# Confirm an elevation rule actually fires: as the standard user, right-click a
# ruled executable -> "Run with elevated access", complete any justification/auth,
# then check the process is elevated (token elevation = TRUE)
Get-CimInstance Win32_Process -Filter "Name='vendortool.exe'" |
    ForEach-Object { $_.GetOwner().User }

Then walk each behavior explicitly:

1. Deny-all default holds: as the standard user, try Run with elevated access on an executable that no rule matches. With the default response set to Deny all, it must be blocked (or routed to a support request if that’s your default).
2. User-confirmed rule: invoke a user-confirmed rule. You must be prompted for justification and/or Windows authentication, and only then does it elevate. The event appears in Managed elevations.
3. Support-approved rule: invoke a support-approved rule. It must produce a request in the queue and not elevate until an approver approves it.
4. Child process containment: elevate an app with Deny all child behavior, have it spawn a child (e.g. a shell or file dialog), and confirm the child is not elevated.
5. Reporting flows: within a short window, Endpoint security -> Endpoint Privilege Management -> Reports shows your test elevations under Managed (rule-matched) and any others under Unmanaged.

8. Operational tuning: building rules from collected telemetry

You cannot author a complete rule set up front — you don’t know everything your fleet elevates. The supported rollout is discover, then enforce:

1. Phase 1 — Discover. Deploy an elevation settings policy with reporting set to Diagnostic data and all endpoint elevations to a pilot ring. Critically, do not yet remove local admin and consider a user-confirmed default response so you observe real elevation behavior without breaking anyone. Let it run for a full business cycle so weekly and monthly tasks (month-end tools, quarterly updates) all surface.

2. Phase 2 — Analyze. EPM’s reports tell you exactly what to author:

   Report	What it shows	How you use it
   Elevation report / All elevations	Every elevation observed across reporting devices	Your raw demand signal
   Managed elevations	Elevations that matched an existing rule	Confirms coverage
   Unmanaged elevations	Elevations with no matching rule	Your backlog of rules to write
   Elevation requests	Pending/approved/denied support-approved requests	The approval queue

   Work the Unmanaged elevations list. For each legitimate, recurring entry, use Create rule from elevation so the file’s hash, certificate, and attributes are captured accurately, then refine the detection to certificate + internal name + minimum version and pick the appropriate type and child behavior.

3. Phase 3 — Enforce. Once the unmanaged list is dominated by known, ruled apps, flip the default elevation response to Deny all, now remove users from local Administrators (via your standard configuration — an Intune Local user group membership policy / Accounts CSP, or your existing GPO/baseline), and expand the ring. Re-check Unmanaged elevations at each ring; new entries are either new rules to write or genuine attempts to block.

If you manage policy as code, the EPM policy objects are reachable through the Microsoft Graph beta endpoint as device-management configuration policies, which lets you snapshot and diff your rule set:

# Enumerate EPM elevation policies (settings + rules) for review / export.
# EPM policies surface as configurationPolicies; filter by template family.
az rest --method GET \
  --url "https://graph.microsoft.com/beta/deviceManagement/configurationPolicies?\$filter=templateReference/templateFamily eq 'endpointSecurityEndpointPrivilegeManagement'&\$expand=settings"

az rest reuses your az login token, so the signed-in identity needs the Intune admin role and DeviceManagementConfiguration.ReadWrite.All consent. For unattended exports, use a service principal with that application permission. Keep the exported JSON in source control — it is the auditable record of exactly what your fleet is allowed to elevate.

Enterprise scenario

A 15,000-seat engineering firm had to remove local admin to pass a cyber-insurance control, but their CAD and EDA toolchain was the blocker: several signed vendor utilities legitimately needed elevation to talk to license dongles and write driver-level config. An early attempt failed badly — they had authored a single automatic, Allow-all-child rule matched only on the vendor’s signing certificate, reasoning “it’s signed by the vendor, it’s safe.”

A red-team exercise broke it in minutes. One of the vendor’s signed tools was a license manager with a “browse for license file” dialog. Because the rule was certificate-only (so it matched every binary that vendor signed, including a bundled, signed scripting helper) and child behavior was Allow all, a standard user launched the elevated tool, used the file dialog to open the bundled helper, and got an elevated interactive context — full local admin, exactly what the project was meant to eliminate.

The fix was a redesign around least privilege per binary. They split the one permissive rule into several tightly-scoped rules built from the Unmanaged elevations report, each matched on certificate + internal name + minimum version so only the specific executables that genuinely needed elevation matched — not the entire vendor signature. The interactive tools moved to user-confirmed with Windows authentication and business justification, the one unattended deployment helper stayed automatic, and every rule was set to Deny all child processes. The bundled scripting helper got no rule at all, so it could no longer be elevated as a child.

{
  "ruleName": "CAD-LicenseManager-UserConfirmed",
  "elevationType": "userAuthorized",
  "fileDetection": {
    "matchOn": "certificate+internalName+minVersion",
    "certificateSubject": "CN=VendorCAD Signing CA",
    "internalName": "LicenseManager",
    "minimumVersion": "8.1.0.0"
  },
  "validation": ["windowsAuthentication", "businessJustification"],
  "childProcessBehavior": "denyAll"
}

The JSON above is an illustrative shape of the rule’s logical fields, not the exact Graph settings-catalog payload — author the real rule in the portal (or export it with the az rest call above to get the precise schema). The lesson is the design, not the literal keys: certificate-only matching plus Allow-all children is an escalation path, not an elevation control.

The control passed re-test, the toolchain kept working, and the Unmanaged elevations report became a standing operational queue — every new entry is triaged weekly into “write a scoped rule” or “this should be blocked.”

Checklist

• EPM (or Intune Suite) add-on shows Active in Tenant administration
• EPM license assigned to the primary user of every in-scope device
• Elevation settings policy with EPM Enabled and reporting set to all endpoint elevations for discovery
• Discovery phase run for a full business cycle before removing local admin
• Rules authored from the Unmanaged elevations report, not guesses
• File detection uses certificate + internal name + minimum version for maintained signed apps (hash only for unsigned binaries you control)
• Elevation types chosen per rule: automatic (tiny trusted set), user-confirmed + Windows auth + justification (default), support-approved (sensitive/catch-net)
• Deny all child process behavior on every interactive-app rule; Require rule only for known helpers
• Default elevation response set to Deny all before enforcement
• Users removed from local Administrators via Intune local-group policy / baseline
• Support-approval queue staffed with delegated approvers (correct EPM RBAC)
• EPM policy set exported via Graph and kept in source control for audit

Pitfalls and next steps

The failure modes are consistent. Certificate-only matching over-grants to every binary a vendor signs — always narrow with internal name and a minimum version. Allow-all child processes turns any elevatable app with a file dialog or scripting host into an admin-shell vector — default to Deny all and treat Allow all as a security finding. Over-using automatic elevation throws away the justification and human-presence signals you need for audit; reserve it for a tiny, fully-trusted set. Removing local admin before the discovery phase guarantees a help-desk flood from elevations you never knew about — discover first, enforce second. And leaving the default response at “user confirmation” as a steady state quietly re-creates click-through admin; the hardened end state is Deny all with explicit rules.

For next steps, wire the Elevation report into your SIEM (the events are valuable detection signal — an unexpected support-approved request for a never-before-seen binary is worth an alert), formalize the approval queue into your ITSM so requests are tracked and SLA’d, and review the unmanaged-elevations backlog on a recurring cadence so the rule set stays current as the application estate drifts. Done right, EPM converts “everyone is a local admin” into an auditable, per-binary, justified, just-in-time control — and the local Administrators group becomes empty by default.