# Multi Admin Approval is enabled in Intune to require a second admin to approve sensitive tenant changes
When Intune Multi Admin Approval (MAA) is not configured, a single compromised administrator account is sufficient to push a malicious app to every…
Source: https://maester.dev/docs/tests/ZTA.51015
:::note[Maester checks this too]
[MT.1096](/docs/tests/MT.1096) (Ensure at least one Intune Multi Admin Approval policy is configured) checks the same setting. Running both reports it twice.
:::
## Overview
When Intune Multi Admin Approval (MAA) is not configured, a single compromised administrator account is sufficient to push a malicious app to every managed device, deploy a hostile PowerShell script, wipe a fleet of corporate devices, alter compliance or configuration policies to weaken security, or grant additional privileged roles to an attacker-controlled account — all in one step, with no second pair of eyes. Threat actors who land on a privileged admin's workstation, harvest a session token, phish an Intune Administrator, or exploit an unsupervised privileged session can execute these tenant-wide actions before any detective control has a chance to react. Multi Admin Approval inserts a mandatory second-administrator approval gate before high-impact changes take effect, ensuring that even a fully compromised single admin cannot deploy apps, run scripts, change compliance / configuration policies, perform mass device actions (wipe, retire, delete), modify role assignments, or alter device categories without an independent approver in a separate approver group consenting to the change. Without at least one MAA access policy in place with an approver group assigned, the entire Intune control surface is single-credential to compromise.
## Remediation
- [Use access policies to require admin approval for sensitive Intune actions](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/multi-admin-approval)
- [Create an access policy](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/multi-admin-approval#create-an-access-policy)
- [Approve or reject a request for changes](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/multi-admin-approval#approve-or-reject-a-request)
- [Role-based access control with Intune (least-privilege admin roles)](https://learn.microsoft.com/en-us/intune/intune-service/fundamentals/role-based-access-control)
- [Privileged Identity Management for just-in-time admin access](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | High |
| Effort to fix | Medium |
| Impact on users | Low |
| Pillar | Devices |
| Category | Devices |
| Product | [Intune](/docs/tests/products/intune) |
| Feature | Tenant administration |
| Area | Privileged access |
| ATT&CK | [T1072](/docs/tests?mitre=T1072) Software Deployment Tools, [T1078.004](/docs/tests?mitre=T1078.004) Cloud Accounts |
| Licence | INTUNE_A |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.