Multi Admin Approval in Intune: Because One Admin Shouldn't Rule Them All

Multi Admin Approval (MAA) in Intune requires a second administrator to approve changes before they take effect. In this post you will learn what it protects, how to configure access policies, and why every Intune tenant should have this enabled yesterday.

Here's a fun thought experiment: imagine a disgruntled admin — or worse, an attacker who compromised an admin's account — decides to wipe every managed device in your organization. Or quietly removes your compliance policies. Or reassigns RBAC roles to give themselves full control while locking everyone else out.

Without Multi Admin Approval? That change goes live instantly. No second pair of eyes. No "are you sure?" from a colleague. Just raw, unfiltered administrative power and whatever chaos it brings.

I know what you're thinking: "that would never happen to us." And sure, maybe it won't. But the whole point of security is planning for the scenarios you hope never happen. That's where Multi Admin Approval comes in — and honestly, it's one of those features that should have existed from day one.

What Multi Admin Approval actually does

The concept is straightforward: you create access policies that protect specific Intune resource types. When any admin makes a change to a protected resource, Intune doesn't apply it immediately. Instead, it creates a request that a different admin must explicitly approve before the change takes effect.

Think of it as a pull request for your Intune configurations. You wouldn't merge your own PR in a production codebase (I hope), so why would you let a single account push changes to thousands of managed devices unchecked?

The key word there is different. Even if the requesting admin is also a member of the approver group, they cannot approve their own requests. Intune enforces this — no rubber-stamping your own changes.

What can you protect?

As of March 2026, MAA access policies support the following resource types:

That last one — protecting Access Policies — is particularly clever. It means an attacker can't just disable MAA as their first move. They'd need a second admin to approve disabling the thing that requires a second admin. It's turtles all the way down.

Q: What about app protection policies? Conditional Access? Endpoint Security profiles?

A: Not yet. MAA currently covers the resource types listed above. Notably, Endpoint Security policies (like your firewall rules, antivirus configurations, and attack surface reduction rules) are not in scope. Neither are Conditional Access policies — those live in Entra ID, not Intune. Hopefully Microsoft expands the scope over time, but for now, protect what you can.

Prerequisites: What you need before you start

Before you dive into creating access policies, let's get the boring-but-important bits out of the way.

You need at least two admin accounts. This seems obvious, but I've seen organizations where one Global Admin account does everything. If that's you, MAA is the universe telling you to fix your RBAC.

To create and manage access policies, you need one of:

• A custom Intune role with the Multi Admin Approval permissions: Create access policy, Read access policy, Update access policy, and Delete access policy. This is the recommended approach — least privilege and all that.
• The Intune Administrator Entra role. This works, but it's a privileged role that gives full read/write to Intune, so it's overkill for just managing access policies.

To approve or reject requests, the account must:

1. Be a member of the approver group assigned to the access policy
2. Have the Approval for Multi Admin Approval permission in their Intune role
3. The approver group must also be a member group of at least one Intune role assignment — if it isn't, Intune will periodically remove approver group members. This is the kind of gotcha that bites you three weeks after setup when approvers suddenly can't approve anything. Ask me how I know.

Important: The approver group requirement for role assignment membership is easy to miss. If your approvers are losing their ability to approve requests, check that their security group is added as a member group to an Intune role assignment. It doesn't matter which role — the group just needs to be associated with something.

Setting it up: Step by step

Step 1: Create your approver group

Before creating any access policy, set up a security group in Entra ID containing the admins who should have approval authority. A few recommendations:

• Use a dedicated security group — don't reuse an existing "all admins" group. You want to be deliberate about who can approve what.
• Include at least two or three members. If your only approver is on vacation when someone needs an urgent change approved, you're going to have a bad time.
• Consider having separate approver groups for different resource types. Your app deployment team might not be the right people to approve RBAC changes.

Step 2: Create an access policy

1. Sign in to the Microsoft Intune admin center
2. Navigate to Tenant administration > Multi Admin Approval > Access policies
3. Click Create
4. On the Basics page:
   • Give it a descriptive Name (e.g., "Require approval for device actions")
   • Add an optional Description
   • Select the Profile type — each policy protects a single resource type
5. On the Approvers page:
   • Click Add groups and select your approver security group
   • Note: you can't do complex group configurations here — no exclusions, just a straightforward group selection
6. On the Review + Create page, review and save

Step 3: Approve the access policy itself

Here's the part that trips people up: the access policy you just created is itself subject to approval. You need a second admin account to approve it.

1. Sign in with a different admin account (one that's in the approver group with the Approval for Multi Admin Approval permission)
2. Go to Tenant administration > Multi Admin Approval > Received requests
3. Find the request for your new access policy
4. Click the Business justification link to review the details
5. Add any Approver notes and click Approve request
6. Sign back in with the original account, find the request under My requests, and click Complete

Yes, the creating admin needs to come back and finalize it. The workflow is: Create > Approve (different admin) > Complete (original admin). It's a three-step dance, but it ensures both parties are in the loop.

Step 4: Repeat for each resource type

Each access policy covers one resource type. If you want to protect apps, compliance policies, device actions, and RBAC, you need four separate access policies. Tedious? A little. But it gives you granular control over who approves what.

My recommended starting point — protect these resource types first:

1. Device actions (Wipe, Retire, Delete) — the most destructive operations
2. Role-based access control — prevents privilege escalation
3. Access Policies — protects MAA itself from being disabled
4. Scripts — PowerShell scripts can do anything on a device
5. Compliance policies — removing compliance can silently break Conditional Access enforcement

The day-to-day workflow

Once MAA is active, here's what life looks like for your admins:

Submitting a change

Nothing changes about how you create or edit resources. You use the same Intune admin center workflows as always. The difference is at the end: instead of the change going live immediately, you'll see a Business justification field on the final review page. Fill it in (be descriptive — your approver will read this), and submit.

The change sits in a pending state until approved.

Pro tip: Intune does not send notifications when a new request is created. If your change is urgent, reach out to your approvers directly. Slack them. Teams them. Walk to their desk. Carrier pigeon. Whatever works. Don't just submit and wait, hoping someone checks the approval queue today.

Approving a change

Approvers check the Received requests page under Tenant administration > Multi Admin Approval. For each request, they can see who submitted it, what type of change it is, and the business justification. They review the details, add approver notes, and either Approve or Reject.

If rejected, the approver notes are visible to the requestor — so provide a reason. "No" is not helpful feedback. "No, because this compliance policy removes the encryption requirement and that violates our baseline" is.

Completing a change

After approval, the original requestor needs to come back and click Complete to actually apply the change. This final step is intentional — it ensures the requestor reviews the approval and consciously triggers the deployment.

Request lifecycle

Requests expire after 30 days of inactivity. If a request expires, it must be resubmitted from scratch. Also, only one pending request per object is allowed — if someone already has a pending change for that compliance policy, you can't submit another one until the first is resolved.

Things to consider (the practical part)

No notifications — seriously

I mentioned this above, but it bears repeating because it's the single biggest operational pain point. Intune does not send email notifications, Teams messages, or push alerts when approval requests are created or when their status changes. Your approvers need to proactively check the admin center.

For organizations that take this seriously, consider building a lightweight automation — a Logic App or Power Automate flow that polls the Intune Graph API for pending approval requests and posts to a Teams channel. It's not built-in, but it's not hard either.

Audit logging

Every MAA action — request creation, approval, rejection, completion — is logged in the Intune audit logs. This is your paper trail. If you ever need to answer "who approved the deletion of our compliance baseline on March 15th?", the audit log has it. Navigate to Tenant administration > Audit logs and filter on Multi Admin Approval activities.

Emergency break-glass

Think about your break-glass scenario. If your tenant is under active attack and you need to make an emergency change to a protected resource, can you get approval fast enough? Make sure your approver group has members across time zones, and that your break-glass admin accounts have the necessary permissions. Document the emergency procedure before you need it.

Start with monitoring, then enforce

If you're nervous about disrupting your admin team's workflow, start by protecting the most critical resource types (device actions and RBAC) and leave the rest unprotected. Get your team used to the approval workflow on high-impact changes before expanding to apps, scripts, and configuration policies. Gradual rollout beats big-bang deployment every time.

Why this matters for Zero Trust

Multi Admin Approval is fundamentally a Zero Trust control. It assumes that any single admin account might be compromised and builds in a verification step before destructive or sensitive changes take effect. It's the same principle as requiring MFA for sign-ins — except applied to administrative actions rather than authentication.

If you're building a Zero Trust posture for your endpoint management (and you should be), MAA is one of those table-stakes features that's easy to enable and hard to regret. The only regret is not having it when something goes wrong.

Final words

Multi Admin Approval in Intune is one of those rare security features that's genuinely simple to set up and immediately valuable. No agents to deploy, no complex architecture, no licensing gotchas (it's included in your existing Intune license). Just access policies, approver groups, and a workflow that ensures no single admin can make tenant-wide changes unchecked.

Is it perfect? No. The lack of notifications is a real gap. The per-resource-type policy creation is a bit tedious. And the list of protectable resources doesn't yet cover everything you'd want (Endpoint Security policies, I'm looking at you). But what it does cover — device wipes, compliance policies, RBAC, scripts — hits the highest-impact categories.

Set it up. Protect your device actions first. Protect your RBAC second. Then expand from there. Your future self — the one who's not dealing with an unauthorized mass device wipe at 2 AM — will thank you.

As always, I hope you find inspiration in this article. And I welcome any feedback in the LinkedIn comments or preferably a follow on LinkedIn: @michael-mardahl.