Choose the right elevation path for each installer, script, and support request. Start with a controlled rule, keep the user standard, and retain an audit trail.
The “best” option depends on frequency, trust, urgency, and whether the app needs the signed-in user’s profile.
A matched file elevates after the user confirms. You may require Windows authentication, a business justification, or both.
The user submits a request; an authorized administrator approves or denies it before elevation.
A tightly identified file elevates without a prompt. Microsoft recommends using this sparingly.
Runs elevated under the signed-in identity, preserving profile paths, settings, and environment variables.
Blocks a matched file from running elevated. A deny rule wins when conflicting allow rules also apply.
Answer three questions. This is a rollout recommendation—not a substitute for testing the binary and its child processes.
Two policy layers are required: elevation settings enable EPM on the endpoint; elevation rules define what happens to a specific file.
Confirm your Intune Suite or EPM add-on entitlement, supported Windows devices, and pilot groups.
Create and assign a Windows elevation settings policy. Choose the default elevation response and reporting scope.
Identify files with hash or certificate plus signed properties; add a protected path where practical.
Test installer children and updates, review elevation reports, then expand assignment in stages.
Supported rule file types include .exe, .msi, and .ps1. Rules can be assigned to users or devices; a user-targeted rule takes precedence over a device-targeted rule during elevation.