Microsoft 365, Intune, identity and endpoint engineeringAdelaide, Australia
Implementation guide

Implementing Endpoint Privilege Management without permanent local admin

A phased enterprise deployment pattern for audit, elevation rules, support approval, local administrator removal and operational governance.

Endpoint Privilege Management (EPM) supports a standard-user operating model by allowing approved files and tasks to run with elevated rights without placing the user in the local Administrators group. The key is to treat EPM as a privilege-control programme, not as a broad allow button.

Understand the operating model

EPM uses an elevation settings policy to enable the client, set default behaviour and configure reporting. Elevation rules policies then identify specific executables, MSI files or PowerShell scripts and define how they can elevate. Most elevation types use an isolated virtual account; the “elevate as current user” option has a wider attack surface and should be exceptional.

Prepare the prerequisites

  • Eligible licensing is active for users benefiting from EPM.
  • Supported Windows devices are Intune managed and correctly joined.
  • Intune endpoints required by EPM bypass incompatible SSL inspection.
  • A dedicated custom RBAC role is created for rule and approval operations.
  • Support approval ownership and response targets are defined.
  • WDAC or App Control design is reviewed so elevation does not bypass application trust decisions.

Phase 1: enable audit and reporting

  1. Go to Endpoint security > Endpoint Privilege Management > Policies.
  2. Create a Windows elevation settings policy.
  3. Set Endpoint Privilege Management to Enabled.
  4. Set the default elevation response to Deny all requests or Require support approval. Do not use a permissive default.
  5. Enable reporting. For discovery, collect diagnostic data and all endpoint elevations for a limited pilot cohort.
  6. Assign to a controlled device or user group and allow enough time to observe real elevation behaviour.
Recommended starting patternAudit first. Microsoft’s deployment guidance uses a phased model: auditing, persona identification, rule building, monitoring and then transition from local administrator to standard user.

Build elevation rules from evidence

Create rules only for a defined business need. Use publisher certificate plus product metadata where a trusted vendor signs consistently. Use a file hash where exact binary control is required. Automatic elevation should be rare; user-confirmed elevation with business justification or support approval is easier to govern.

Rule typeUse whenRisk
AutomaticA tightly controlled task must run silently and the binary identity is stableBroad or weak matching can create silent privilege escalation
User confirmedThe user can initiate an approved task and provide justification or authenticationUser behaviour must be monitored; rule scope still matters
Support approvedRequests are infrequent or need case-by-case reviewRequires service-desk capacity and clear approval criteria
Elevate as current userAn application genuinely requires the signed-in user profileLess isolation; use only after compatibility testing

Example evidence capture

Get-FileHash -Algorithm SHA256 "C:\Path\ApprovedInstaller.msi"
Get-AuthenticodeSignature "C:\Path\ApprovedInstaller.msi" |
  Select-Object Status, StatusMessage, SignerCertificate

Remove standing local administrator access

After rules cover the business personas, use Intune Account protection > Local user group membership to manage the local Administrators group. Pilot the removal separately from EPM enablement so issues can be isolated. Keep a controlled break-glass process using Windows LAPS and privileged support workflows.

Establish the operating process

  • Route support-approved requests through a named queue and document evidence required for approval.
  • Review frequently unmanaged elevations and denied requests each week during pilot.
  • Expire or review rules when the associated application version, publisher or business process changes.
  • Correlate EPM reporting with Defender, WDAC/App Control and service-desk records.
  • Separate rule authors from support approvers where practical.

Validate the pilot

  • The EPM agent service is installed and healthy.
  • Unmatched files are denied or routed for approval.
  • Approved rules match only the intended file and version conditions.
  • Child-process behaviour is understood.
  • Local admin removal does not break recovery or support processes.
  • Elevation events appear in Intune reports and operational reporting.
Known infrastructure considerationMicrosoft documents that EPM does not support SSL “break and inspect” for its required endpoints. In environments using secure web gateways, validate bypass requirements before deployment.

Microsoft references

  1. Endpoint Privilege Management overview
  2. Deploy Endpoint Privilege Management
  3. Manage elevation settings
  4. Create elevation rules
  5. EPM reports
  6. Known issues

Review note: Microsoft cloud licensing, rollout dates and portal labels can change. Validate your tenant, Message Centre notices and current documentation before production implementation.