Rolling Out Intune Endpoint Privilege Management Safely

#Operational requirement

You are going to find a spreadsheet somewhere in this tenant listing every account that has been granted local administrator rights on a laptop “because they need it for the software”. That spreadsheet is a liability, not a policy. Standing local admin is the single easiest privilege for an attacker to abuse once a phishing payload lands, and removing it without breaking legitimate workflows is one of the highest-value changes you can make as an endpoint engineer. That is exactly why this task lands on a junior administrator early: it touches licensing, Entra ID group membership, Intune policy authoring and change control in one exercise, and it teaches you to prove a change works before you scale it.

Your job is to pilot Microsoft Intune Endpoint Privilege Management (EPM) on a small set of Windows devices. You will strip standing admin rights, build an elevation policy that lets named approved applications run elevated on demand, and produce evidence before anyone signs off a tenant-wide rollout. Get the elevation rules wrong in either direction and you cause damage: too tight and the helpdesk queue fills with lockout tickets; too loose and you have built a self-elevation path dressed up as a security control.

#Prerequisites and required permissions

Confirm the following before you touch a single policy. Do not skip this list to save time — every item on it has caused a failed pilot for someone before you.

• Microsoft Intune Suite licence, or the standalone Endpoint Privilege Management add-on, assigned to the pilot users or devices in the Microsoft 365 admin center.
• Windows 10 21H2 or later, or Windows 11, already Intune-enrolled and reporting compliant. If enrolment or compliance status is broken, fix that first. EPM policy will sit silently at a non-applied state on a non-compliant device and give you no useful error to chase.
• An Entra ID role of Intune Administrator, or a custom RBAC role scoped with Create, Read, Update and Delete permissions on Endpoint Security policies.
• A dedicated, assigned Entra ID group for the pilot — call it SG-EPM-Pilot-Devices — kept deliberately small. Ten to fifteen devices, never a whole department.
• An approved change ticket with a defined pilot window and rollback trigger criteria agreed with the service desk lead before you go anywhere near production identities.

#Step 1: Confirm licensing and pilot group membership

Verify the Intune Suite or EPM add-on licence is attached to every account or device you intend to include. Licence gaps are the most common reason EPM policy reports as not applicable, with nothing further to go on.

1Connect-MgGraph -Scopes "User.Read.All","Group.Read.All"
2
3$group = Get-MgGroup -Filter "displayName eq 'SG-EPM-Pilot-Devices'"
4$members = Get-MgGroupMember -GroupId $group.Id
5
6foreach ($m in $members) {
7    Get-MgUserLicenseDetail -UserId $m.Id | Select-Object SkuPartNumber
8}

You are looking for a SKU that includes the EPM entitlement, either bundled in the Intune Suite SKU or the standalone add-on. Export this output to a CSV and attach it to the change ticket as your baseline evidence. Do not move to Step 2 until every pilot account or device shows as licensed. An unlicensed device will happily accept the local-admin removal in Step 2 but never receive the elevation policy in Step 3, and that combination leaves a real user with no admin rights and no way to elevate anything.

#Step 2: Remove standing local administrator rights

In the Intune admin center, go to Endpoint security, then Account protection, then Create policy, choosing Windows 10 and later and the Local user group membership profile type. Set the Administrators group action to Restrict membership and list only the accounts that should remain — a break-glass local account, and an on-call support account if your organisation still uses one. Assign this policy to the pilot group only. Never assign it to All devices at this stage.

On the next policy sync, the signed-in standard user is removed from the local Administrators group. Capture a before-and-after screenshot of net localgroup administrators run on a test device, and pull the policy assignment report from Intune showing a successful state for every pilot device. Confirm this with a remote session yourself — do not take the Intune assignment status blade on faith. If you build the elevation policy in Step 3 before removing admin rights here, you create a gap where users have neither standing admin nor a working elevation path, and the helpdesk phone starts ringing within the hour.

#Step 3: Build the Endpoint Privilege Management elevation policy

Go to Endpoint security, then Endpoint Privilege Management, then Create policy, Windows 10 and later. You need two linked policy objects: an elevation settings policy and an elevation rules policy.

In the elevation settings policy, set the default elevation response to deny all requests. This forces every elevation through an explicit rule rather than defaulting open. Set the elevation request reporting scope to all elevations, not just denials — during a pilot you want the full audit trail, not a filtered one. Menu wording in this console changes as Microsoft revises EPM out of preview, so confirm the exact labels in your own tenant rather than trusting a screenshot from elsewhere.

In the elevation rules policy, add one rule per approved application. Choose your identification method carefully: file name plus publisher or certificate subject is the safest balance, file hash is the tightest but breaks on every patch cycle, and file name alone is too loose to survive an audit. Here is a working example for a legacy line-of-business installer:

1{
2  "ruleName": "LOB-Installer-Elevate",
3  "fileName": "LegacyAppSetup.exe",
4  "filePathExact": "C:\Apps\LegacyApp\LegacyAppSetup.exe",
5  "publisherName": "CN=Contoso Software Ltd",
6  "elevationType": "AutomaticallyApprove",
7  "childProcessBehavior": "AllowElevatedChildProcesses"
8}

Export the finished rule set as JSON, or a screenshot if export is not available in your build, and attach it to the change record. This is exactly what an auditor asks for six months later when someone questions why an application was authorised to self-elevate. One rule, treated as non-negotiable: never set childProcessBehavior to allow elevated child processes for anything except an installer you control end to end. A browser or scripting host with that flag set is a privilege-escalation path wearing a business justification.

#Step 4: Deploy to the pilot group and validate elevation

Assign both the elevation settings policy and the elevation rules policy to SG-EPM-Pilot-Devices. Force a sync on a test device rather than waiting out the standard cycle:

Get-ScheduledTask -TaskName "PushLaunch" | Start-ScheduledTask

Alternatively, on the device itself, open Settings, Accounts, Access work or school, select the connected account, then Info, then Sync. As a standard, non-admin user, right-click the approved application and select Run with elevated access. The application should launch with an elevation token and no UAC prompt, and the user never holds standing admin rights at any point. Capture a screen recording or timestamped screenshot of the elevation succeeding, plus the corresponding entry in the Endpoint Privilege Management elevation report. Test one deliberate failure too: attempt to elevate an application that has no rule defined, and confirm it is denied cleanly rather than silently allowed through.

#Verification

Before you widen the rollout beyond the pilot group, assemble this evidence pack and hold it against the change ticket:

• The Endpoint Privilege Management elevation report in Intune, filtered to the pilot group, showing successful and denied elevation events with timestamps.
• Local device logs at C:ProgramDataMicrosoftIntuneManagementExtensionLogs confirming both the elevation policy and the account-protection policy applied cleanly on at least three pilot devices.
• The exported elevation rule set from Step 3, signed off by whoever owns application security exceptions in your organisation.
• Written confirmation from the service desk that no unplanned elevated-privilege tickets were raised in the 48 hours following deployment.

#Failure Modes

#Rollback

If the pilot causes disruption beyond the threshold agreed in the change ticket, reverse it in this specific order. Reversing it the other way round re-creates the exact admin-rights gap you were warned about in Step 2.

1. Edit the Local user group membership policy from Step 2. Either change the action back to add for the pilot accounts, or remove the policy assignment from SG-EPM-Pilot-Devices entirely.
2. Force a sync on affected devices using the same PushLaunch scheduled task command from Step 4, then confirm restoration with net localgroup administrators on each device.
3. Unassign — do not delete — the elevation settings and elevation rules policies from the pilot group. You want the rule definitions and audit trail preserved for the retry.
4. Update the change ticket with the rollback timestamp, the exact failure evidence that triggered it, and notify the service desk lead that standing admin rights have been restored for the named pilot users.

#Operational Summary

What you hand back at the end of this exercise is a working, evidenced pilot: a small group of devices with standing local admin removed, a validated elevation rule set covering the applications those users genuinely need, and an audit trail proving both the removal and the elevation behaviour actually worked. Keep the evidence pack — the licence export, the policy JSON, the elevation report, the sync logs — because the next stage of this project is expanding to the full estate, and whoever signs off that expansion will ask for exactly this proof rather than your assurance that it worked in testing. Treat the pilot group size as fixed. The temptation to add “just a few more users” before the rule set is proven is precisely how EPM rollouts turn into helpdesk incidents instead of a security win you can point to in a review.

For the underlying policy mechanics and licensing detail, read the Microsoft Intune Endpoint Privilege Management overview and the elevation rules documentation before writing rules for anything beyond this pilot. The matching precedence between file name, publisher and hash is documented there, and it changes how conservatively you should scope each rule as you move past a ten-device test into a live estate.