This post highlights a new option in Endpoint Privilege Management (EPM) called Elevate as current user. This option is introduced in Intune’s October 2025 service release (2510). The available elevation types now include User confirmed, Automatic, Deny, Support approved, and the newly added Elevate as current user option in the Elevation type drop-down menu.
The option you select in the Elevation type drop-down determines how an elevation request is handled for a file. The default selection is User confirmed. For all elevation types except Elevate as current user, Endpoint Privilege Management uses a virtual account to elevate the process to administrator privileges. Below screenshot shows an Elevation rules policy with the Elevation type drop-down displaying the Elevate as current user option.
Virtual account isolates elevated actions from the user’s profile, this reduces the exposure to user-specific data and minimizes the risk of privilege escalation. Therefore, it is recommended to use a virtual account whenever possible. If a specific application or file must run with administrator privileges in the user context, then use the Elevate as current user option in the policy. Below is a screenshot showing virtual account MEM\AzureAD_jatin_$ which has been created by EPM.
About Elevate As Current User Option
Elevate as current user option allows a process to run with administrator privileges under the signed-in user’s context instead of using a virtual account. This option is useful for applications that require access to user-specific data or settings during elevation, such as profile-based configurations or environment-dependent scripts. However, since it runs in the user context, it also carries higher security risks if not used carefully.
Key points:
- Supports Multi-factor authentication (MFA).
- Runs the elevated process under the current user’s profile, not a virtual account.
- Maintains access to user-specific paths and registry hives (e.g.,
HKCU,%AppData%). - Useful for legacy applications or scripts that depend on user-level environment variables.
- Increases security exposure, as elevated actions occur within the user’s context.
Recommendations:
- Use Elevate as current user only when required, such as for applications that fail with virtual accounts or for compatibility issues.
- For most elevation scenarios, prefer the virtual account option to minimize privilege escalation risks.
- Test the behavior of applications in both modes to confirm which elevation type works best (prefer virtual account).
- Regularly review and audit elevation rules using this setting to see if they are still necessary.
Elevation Rules Policy with Elevate As Current User Option
Now, let’s test this option to understand how it works and what we can expect on the client computer after the elevation request. For demonstration purpose, I have created a test rule to elevate powershell.exe.
After the rule is deployed on the target Windows device, right-click PowerShell.exe file and select Run with elevated access. You may get an additional authentication pop-up, enter your credentials to proceed. Once PowerShell is launched, it will be opened in current user context, to check and confirm run whoami command, or you can also [System.Security.Principal.WindowsIdentity]::GetCurrent().Name.
Conclusion
In this post, we explored the Elevate as current user option in Endpoint Privilege Management (EPM). This option is useful in scenarios where an application has compatibility issues and can only function properly in the user context due to dependencies on the user profile, HKCU registry keys, or user environment variables. Use this option only in such specific cases, and not as a default or general method for elevation.
