One compromised Intune administrator account is enough to wipe devices, push a script to every PC or rewrite who holds which role. Multi Admin Approval (MAA) puts a second administrator between that account and your tenant. In this post I'll show what you can protect, how to set up approvers so they actually work, and how the request, approve and complete flow looks from both sides.
How Multi Admin Approval works#
You create access policies. Each one protects a single resource type and names one approver group. When anyone creates, edits, assigns or deletes something of that type, Intune holds the change as a request with a business justification. A different administrator from the approver group approves or rejects it, and the original requester then selects Complete to apply it. Nobody can approve their own request, Global Administrators and Intune Administrators included.
Microsoft Graph calls to protected resources are intercepted too, whether delegated or made by an app with its own credentials, so automation goes through the same workflow.
| Profile type | What it protects |
|---|---|
| Apps | App deployments (not app protection policies) |
| Compliance policies | Creating and managing compliance policies |
| Configuration policies | Policies created in the settings catalog |
| Device actions | Wipe, retire and delete |
| Role-based access control | Roles, role permissions, admin groups and member group assignments |
| Scripts | Scripts deployed to Windows devices |
| Tenant Configuration | Creating, editing and deleting device categories |
Changes to the access policies themselves always need a second administrator, so that type is protected automatically and isn't in the list.
Prerequisites#
- At least two administrators. In practice, plan several approvers so a request never waits on one person.
- Licences. By default, every admin in the workflow needs an Intune licence. The Allow access to unlicensed admins setting lifts that, but it can't be turned off again.
- Policy managers need a custom Intune role with the Multi Admin Approval permissions to create, read, update and delete access policies, or the Intune Administrator role.
- Requesters need their normal permission for the action, such as
MobileApps/CreateorRemoteTasks/Wipe. - Approvers must meet three conditions, covered in step 1.
Step-by-step#
Step 1: Build the approver group and its role assignment#
This is where most setups go wrong. The approver group must be:
- A security group with direct members. Distribution lists, Microsoft 365 groups and mail-enabled security groups fail silently, and nested membership is unreliable.
- Backed by the Read permission for every resource type its members approve, for example
ManagedDevices/Readto approve a device delete. - Added directly as a member group of at least one Intune role assignment. Roles that members hold individually or through other groups don't count, and if the group isn't in a role assignment, its members are periodically removed from it.
A simple design: in Tenant administration › Roles › All roles › Create, build a custom role with the Read permissions your approvers need, plus Approval for Multi Admin Approval so they can approve access policy changes. Assign it with the approver group as the Admin Groups member.
Step 2: Create the access policies#
- Go to Tenant administration › Multi Admin Approval › Access policies and select Create.
- On Basics, enter a name and choose the Profile type. One policy covers one type.
- On Approvers, select Add groups and pick the approver group. Excluding groups isn't supported.
- On Exclusions, add enterprise applications only if an automation app must bypass approval (see the gotchas).
- On Review + submit for approval, enter a business justification and select Submit for approval.
- A second admin approves the policy. Then sign back in with the first account, open the policy and select Complete.
Tip: Start with Device actions and Scripts, where one bad change does the most damage fastest, then add Apps, Compliance policies and Configuration policies. Protect Role-based access control last.
Step 3: Submit a protected change#
Work as usual. When you save a change to a protected resource or trigger a protected device action, Intune asks for a Business justification and creates a request instead of applying the change. Track it in Tenant administration › Multi Admin Approval › My requests, where you can also cancel it before approval. Only one request per object can be pending at a time.
Step 4: Approve or reject#
Approvers open Tenant administration › Multi Admin Approval › Received requests; requests also show up under Tenant administration › Admin tasks. Select the Business justification link, review the change, add Approver notes and choose Approve request or Reject request. The requester sees the notes, so use them to explain a rejection.
Step 5: Complete the change#
Approval doesn't apply anything by itself. The requester opens the approved request in My requests and selects Complete; once Intune has processed it, the status changes to Completed.
| Status | Meaning |
|---|---|
| Needs approval | Waiting for an approver |
| Approved | Approved and waiting for Complete, or being processed |
| Completed | Applied successfully |
| Rejected | Turned down by an approver |
| Canceled | Withdrawn by the requester |
| Expired | No further action within 3 days; submit it again |
Each status stays visible for up to 30 days after it changes.
Verify#
- With a requester account, retire a test device or assign a test app. You should get a justification prompt and a request in My requests, not an immediate action.
- Try to approve it with the same account; that must not be possible.
- Approve it as a member of the approver group, complete it as the requester and confirm the action ran.
- Open Tenant administration › Audit logs and check that the request and approval steps are recorded.
- Run your automation and confirm it raises requests or is covered by an exclusion you intended.
Tips & gotchas#
- No notifications. Intune doesn't alert approvers about new requests or status changes. Agree on a channel, such as a Teams chat, and a response time, especially for urgent wipes.
- Role-based access control can lock you out. Once it's protected, every role change, including the role assignment MAA itself relies on, needs approval. Set up everything else and confirm the approver group's assignment first. If you get stuck, delete the Role access policy, wait 3–5 minutes, fix the assignments in Tenant administration › Roles, then re-create the policy.
- Exclusions are gaps. They apply only to app-only calls, never to delegated sign-ins, are capped at 50 apps per policy, need a second admin's approval and are audited. Review them regularly.
- Coverage is literal. Apps doesn't cover app protection policies, and Configuration policies means settings catalog policies. Compare the table above with what you need to protect.
- Layer it. MAA works best with least-privilege roles and just-in-time activation; see Intune RBAC and scope tags and Privileged Identity Management.

