If you’ve ever woken up in a cold sweat wondering, “What if one of my admin accounts got compromised and someone wiped 5,000 devices overnight?” Firstly, you need more restful sleep, but second, Microsoft has finally heard you.

Enter Multiple Administrative Approval (MAA) in Intune. Think of it like that classic buddy system from school trips, you can’t make a move without a partner watching you. Except instead of making sure you don’t wander off at the museum gift shop, MAA makes sure no single admin can make big changes to your tenant without someone else giving the thumbs up. Good Right?

Here’s the gist:

• You create access policies that protect certain things called a “protection action” (apps, device wipe actions, scripts, RBAC changes, and even the MAA policies themselves).
• When an admin makes a change, with a policy configured to protect an action, Intune says, “Not so fast, cowboy”, and holds that request hostage until another admin, someone in your designated approver group reviews it and hits Approve.

It’s a neat safeguard, but before you run off to secure the kingdom, let’s talk about what you can and can’t do with it.

The Big Gotcha: It’s All or Nothing

When you set an access policy, it applies tenant-wide. That means all admins are covered by it, regardless of whether they’re junior Service Desk tech or your top-level cloud architect. You can’t yet assign policies to specific groups, devices, or scenarios.

For example, wouldn’t it be brilliant if:

• A small group of trusted admins could wipe devices immediately, while everyone else required approval?
• Or if corporate-owned devices could be wiped without fuss, but BYOD devices required approval because, let’s face it, accidentally nuking someone’s personal phone is a fast track to HR complaints or even worse?

Sadly, that flexibility isn’t here—at least not yet. Right now, it’s a blanket rule for everyone.

Why It’s Still Worth It

Limitations aside, MAA is a strong step toward protecting against compromised accounts and fat-finger mistakes. Even the best admins occasionally click the wrong thing, and having that extra checkpoint could save your bacon.

The process also builds transparency: business justifications are logged, approvals and rejections are documented, and everything shows up in the audit logs. That’s not just good for governance, it’s fantastic for compliance conversations when someone inevitably asks, “So, who approved this?”

Living with MAA

If you’re going to use it, here are a few practical tips:

• Have at least two active admin accounts (sounds obvious, but you’d be surprised how often tenants rely on a single person).
• Both admin accounts require either Intune Admin or the appropriate Multi Admin Approval permissions with Role Based Access Controls (RBAC).
• Communicate with your approvers. There’s no built-in notification system for new requests yet, so if it’s urgent, you’ll need to poke them directly.
• Keep an eye on requests, pending changes expire after 30 days if nobody acts on them.

How to Configure

Alright, so you’re sold on the idea and want to set this up. The good news? The process isn’t rocket science. The bad news? You’ll need two admin accounts handy, because you can’t approve your own request (no cheating the system).

I’ll take you through the process of creating a protected device action of wiping a device. The same process can be followed for other actions.

Create the Access Policy

1. Sign in to the Microsoft Intune admin center with your first admin account.
2. Create a group in Entra or if your old fashioned (and stuck in your ways), Active Directory and wait for the group to sync up. (I won’t start on why using AD groups in Entra with sync’d admins is a bad idea, that’s for another day.). This group will act as the Approvers List. Once a protected action is triggered, it’ll be this group of users that can approve the action. Even if they’re already a GA or Intune admin. Not in this group, they can’t approve it!
3. Head over to Tenant administration > Multi Admin Approval > Access policies.
4. Select Create.
5. On the Basics page, give your policy a name, add an optional description (bonus points if it’s funny enough to make future-you smile), and choose the profile type you want to protect (Apps, Scripts, Device actions, etc.).
6. On the Approvers page, select Add groups and pick which group of admins will approve changes for this policy. Important: You can’t exclude groups or get fancy with scoping here—it’s one group, one policy, all users.
7. Review your settings, and add a ‘business justification’ for the approver. Something like this;
8. Then hit Submit for Approval.

At this point, your shiny new policy is created, but it’s not live until it’s approved. You’ll see this under My Requests

Approve the Policy

1. Sign out of your first admin account and sign back in with a different admin account that’s either an GA, Intune Admin or has the permission Approve MAA within RBAC.
2. Navigate to Tenant administration > Multi Admin Approval > All requests.
3. Find the pending request for your new access policy.
4. Open it up, review the details (including the justification) and add in your approver notes. This is required
5. Then hit Approve request (or reject request if your future self is having second thoughts).
6. You’ll then see the policy as approved, if you refresh the page.

Complete the Policy

You would think, that’s it, right? No, it’s not! The first admin, now needs to complete the policy before it becomes live.

1. Sign out of your second admin account and sign back in with the fist admin account.
2. Navigate to Tenant administration > Multi Admin Approval > My requests.
3. You’ll see your new policy as approved
4. Select the policy and select Complete request.
5. Now wait! It takes around 10 minutes in my testing for the policy be adopted and the action to be protected. You’ll know when it is as you’ll see a business justification field, when you try to carry out the protected action. If you don’t see it, it’s not live yet!

What does it look like in action?

So you’ve got this far and set up your shiny new access policy. What actually happens when an admin tries to make a change that’s now protected? Let’s walk through it, no popcorn required.

1. The Admin Makes a Change Imagine an admin tries to wipe a device (or maybe deploy a script). Normally, that action would go straight through. But now, when they hit save, Intune steps in and says: “Hold on, explain yourself.” A Business justification box appears at the bottom of the screen. The admin types in why the change is needed—something like “User lost laptop on the train again” (we all know that person).
2. The Request Gets Parked Instead of being processed immediately, the request now sits in limbo under My requests in the Intune admin center. The status will show as Needs approval.
3. The Approver Steps In Another admin, one who’s in the designated approver group, logs into Intune and heads to Tenant administration > Multi Admin Approval > Received requests. They’ll see the pending request, complete with details of what action was attempted, who submitted it, and that all-important ‘business justification’.
4. Decision Time The approver can either hit Approve or Reject, and they’ve got a notes field to leave comments—helpful for feedback, or the occasional passive-aggressive remark like “Stop wiping devices on Friday afternoons.”
5. The Requestor Finishes the Job Here’s the twist: even after approval, the original requestor has to go back in and hit Complete before the action actually happens. This ensures the person who started the process is still in the loop. Once completed, the status updates to Completed, and Intune carries out the change.
6. Everyone Stays in the Loop If the request is rejected, the notes from the approver are visible to the requestor, so they know why. Every step is logged in audit logs, so you’ve got the receipts if you need them later.

The whole process feels a bit like tagging in a teammate during a wrestling match, one person starts the move, but someone else has to back them up before it lands. It adds a couple of extra clicks, but in exchange, you’re massively reducing the risk of one compromised account (or one tired admin mis-click) causing chaos.

Looking Ahead

Will Microsoft eventually let us scope approvals to specific groups or device types? One can hope. The ideal future is granular control: different approval paths for different admin roles, device ownership types, or even for high-risk vs. low-risk actions.

Until then, MAA is a solid foundation. It might not be the dream scenario where your junior admin can reset a password but needs approval to delete a fleet of laptops—but it’s still a powerful safety net for every organization running Intune.

And hey, if nothing else, it makes sure your admins are talking to each other. Who knew security could double up as team bonding?