The Pain of Manual Endpoint Privilege Management (EMP): A Story of Software Updates
Every single week, a flood of support tickets arrives: users are unable to launch the updated app because it requires administrative privileges. As part of your Endpoint Privilege Management (EPM) process in Intune, you spend precious hours creating a new elevation rule for a file like DesignApp_v2.12.3.exe
, only to repeat the process next week for DesignApp_v2.13.0.exe
.
This tedious cycle isn’t just inefficient—it’s a drain on both security and productivity. Traditional privilege management solutions often force administrators to choose between a secure but rigid approach, or a flexible but risky one.
Fortunately, Microsoft has recognised this challenge and introduced a powerful solution: Wildcard EPM Rules in Intune. This feature changes the game, allowing you to create flexible elevation policies that adapt to software updates without compromising your security posture. It’s a major step forward in making the principle of least privilege practical for modern IT environments.
What is Endpoint Privilege Management (EPM) in Intune?
Before diving into wildcards, let’s review the basics. Endpoint Privilege Management (EPM) in Microsoft Intune is a key part of a Zero Trust security strategy.
Its purpose is to empower users to run as standard users, the most secure baseline, while still allowing them to perform certain admin-level tasks like installing approved software or running specific utilities.
Instead of granting blanket admin rights, EPM provides controlled, just-in-time elevation for specific applications. It’s built on two main policy types:
- Elevation Settings Policy – Device-level policy that enables EPM, sets default behaviors for unmanaged files, and configures reporting.
- Elevation Rules Policy – The rules engine that defines which executables can be elevated, under what conditions, and by whom.
When a user right-clicks an app and selects Run with elevated access, Intune checks these rules to determine if the elevation should be allowed.
The Problem with Traditional Version-Based Elevation Rules
Historically, EPM elevation rules relied on exact file matches—based on file name, hash, path, or certificate. While secure, this method breaks down for apps that update frequently.
For example:
- Rule matches
C:\Program Files\Vendor\MyApp_v1.0.0.exe
- Vendor releases
MyApp_v1.0.1.exe
- Rule no longer applies, and users are blocked
The result?
- Constant manual updates to elevation rules
- Cluttered policy libraries full of outdated entries
- Tension between security enforcement and productivity demands
What Are Wildcard EPM Rules & How Do They Work?
Wildcard EPM Rules directly solve the versioning problem. They allow you to create a single, flexible rule that matches multiple file variations.
Wildcard characters supported:
*
(Asterisk) – Matches zero or more characters?
(Question mark) – Matches exactly one character
You can use them in file name and file path fields (but not in file extensions).
Examples:
DesignApp_v*.exe
→ Matches any version of DesignAppVSCodeUserSetup-arm64-*.exe
→ Matches all ARM64 VS Code installersC:\Users\*\Downloads\
→ Matches downloads for any user profile
By using wildcards, one rule can replace dozens of version-specific entries, reducing admin work significantly.
Step-by-Step: Creating a EPM Wildcard Rule in Intune
- Access EPM in Intune
Go to Endpoint security → Endpoint Privilege Management in the Microsoft Intune admin centre. - Create a New Policy
Select + Create Policy, choose Windows 10 and later → Windows elevation rules policy. - Configure Details
Give the policy a name (e.g.,Wildcard Rule for DesignApp
) and optional description. - Add Elevation Rule
- Rule Name:
DesignApp Wildcard
- File Name:
DesignApp_v*.exe
- File Path:
C:\Program Files\DesignApp\*.exe
- Elevation Type:
User confirmed with business justification
for accountability
- Rule Name:
- Add Security Attributes
- Attach the trusted publisher certificate for the application to ensure only legitimate signed files are elevated.
- Assign Policy
- Target the relevant device or user group.
Best Practices for Secure EPM Wildcard Rules
- Pair with a certificate – Never rely on filename matching alone.
- Restrict to secure paths – Avoid wildcards in writable locations like
C:\Users\*
. - Test before production – Deploy to a pilot group first.
- Audit regularly – Use Intune EPM reporting to monitor usage and detect anomalies.
Comparison: Wildcard vs. Exact Path Matching
Feature | Wildcard EPM Rules | Exact Path Matching |
---|---|---|
Pros | Flexible, low maintenance, adapts to version changes | Highly secure, precise |
Cons | Can be risky if too broad | High maintenance, breaks on updates |
Best Use Case | Frequently updated apps | Static, critical system files |
Real-World Scenarios
- Software with frequent updates –
VSCodeUserSetup-arm64-*.exe
matches all VS Code versions without new rules each time. - Cross-user scripts –
C:\Users\*\Downloads\DiagTool.exe
with certificate validation for an IT diagnostic tool. - Device drivers –
HP-Printer-Driver-v*.msi
in a secure temp folder with publisher certificate validation.
Common Mistakes to Avoid
- Too broad –
*.exe
without restrictions is dangerous. - Using wildcards in user-writable paths without certificate/hash validation.
- Skipping testing – Can lead to blocked workflows or privilege misuse.
Infographic – The Wildcard Elevation Workflow

Conclusion
Wildcard EPM Rules in Intune deliver the flexibility IT teams need to support rapidly evolving software without drowning in administrative updates. When paired with strict security attributes like trusted publisher certificates and secure paths, they strike the perfect balance between productivity and protection.