Fix: “This App Has Been Blocked by Your System Administrator” on Intune + MDE Managed Devices
This behaviour is expected when baseline security settings enforce Attack Surface Reduction (ASR) rules and SmartScreen controls in blocking mode. This guide explains exactly why it happens and how to resolve it safely.
🔍 The Symptoms / Error Message
⚠️ Error Messages You May See
- “This app has been blocked by your system administrator”
- “Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.”
🧠 Root Cause
💡 The Intune Security Baseline Enables Multiple Protections Automatically
| Feature | Effect |
|---|---|
| ASR Rules | Blocks executables downloaded from web/email |
| SmartScreen (Block mode) | Blocks unknown/untrusted apps |
| Network Protection + MOTW | Downloads treated as untrusted zone |
| Controlled Folder Access (sometimes) | Restricts app execution in user paths |
⚠️ Most Commonly, the Culprit Is This ASR Rule
“Block executable files from running unless they meet a prevalence, age, or trusted list criteria”
This blocks:
- EXE files from Downloads
- Internally sourced tools that aren’t widely trusted by Microsoft’s cloud reputation service
🛠️ Step-by-Step Resolution
Identify the Active Security Baseline
Locate which baseline is applied to the impacted devices before making any changes.
✅ GUI Method — Microsoft Intune Admin Center
- Go to Microsoft Intune Admin Center → Endpoint Security → Security Baselines
- Open either: Microsoft Defender for Endpoint Baseline or Windows Security Baseline
- Check the Assignments tab to confirm the device group assigned to impacted users
Modify ASR Rules in the Baseline
Switch the relevant rules to Audit mode for testing before deciding on a permanent configuration.
✅ GUI Method
Open the baseline profile → go to Attack Surface Reduction and locate these settings:
| Setting | Recommended Action |
|---|---|
| Block executable files unless they meet prevalence/age/trusted list | ✅ Set to Audit (for testing) |
| Block executable content from email and webmail | ✅ Set to Audit |
Move to a Dedicated ASR Policy (Best Practice)
Instead of relying on the baseline, manage ASR rules through a standalone policy for finer control.
💡 GUI Method
- Go to Endpoint Security → Attack Surface Reduction
- Create a Custom ASR Policy
- Start with Audit mode, then move to Block after validating against real usage
Add ASR Exclusions (If the App Is Trusted)
For applications confirmed safe, add a targeted exclusion rather than disabling protection broadly.
✅ GUI Method
- Go to Endpoint Security → Attack Surface Reduction
- Add an exclusion path, for example:
C:\Users\*\Downloads\YourAppName*.exe
⚠️ Better Approach
Where possible, use a publisher-based exclusion instead of a file path exclusion — this is more secure since it validates the digital signature rather than trusting any file at a given location.
Adjust SmartScreen Settings in the Baseline
Soften SmartScreen from a hard block to a warning, giving users the choice to proceed for trusted files.
✅ GUI Method
- In the Security Baseline, find Microsoft Defender SmartScreen
- Change the setting from Block → ✅ Warn
Test Locally (Quick Validation)
On the affected device, unblock the specific file and review ASR block events to confirm what triggered the block.
Unblock-File -Path "C:\Users\YourUsername\Downloads\YourAppName.exe"
Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | Where-Object {$_.Message -like "*Attack surface reduction*"} | Select-Object TimeCreated, Id, Message -First 20
Validate Policy via Microsoft Graph PowerShell
Confirm which baseline-derived configuration policies are currently active in the tenant.
Connect-MgGraph -Scopes "DeviceManagementConfiguration.Read.All" Get-MgDeviceManagementConfigurationPolicy | Where-Object {$_.Name -like "*baseline*"}
💡 Best Practices & Recommendations
- Do not use Security Baseline alone in production — it is intentionally aggressive by design
- Always deploy ASR rules through the Audit → Monitor → Block rollout phases rather than enabling Block immediately
- Maintain a trusted application allow-list for line-of-business tools
- Avoid excluding the full Downloads folder — use targeted exclusions for specific known-safe applications instead
- Prefer custom Endpoint Security policies over baselines where you need granular control
✅ Key Takeaway
The fastest fix is to set the relevant ASR rules to Audit mode within the baseline, or remove ASR enforcement from the baseline entirely and manage it through a custom Endpoint Security policy with a proper Audit → Block rollout.
📚 References & Further Reading
- 🔗 Security baselines in Microsoft Intune — Microsoft Learn
- 🔗 Attack surface reduction rules overview — Microsoft Learn
- 🔗 Attack surface reduction policy in Intune — Microsoft Learn
- 🔗 Microsoft Defender SmartScreen overview — Microsoft Learn