After the Stryker / Handala incident, CISA’s recommendation to organisations running Microsoft Intune was unusually direct: turn on Multi Admin Approval. The attack chain was a textbook example of why — a compromised admin account, a freshly created Global Admin, and Intune’s built-in wipe capability used as a weapon against the fleet it was supposed to protect.
Most IT teams nodded, opened the Microsoft Learn page, and then never finished the rollout. The setup is not difficult, but it does require some real decisions about who approves what, and a couple of pitfalls catch people out. This is a practical guide to getting it in place before you need it.
What Multi Admin Approval actually does
Multi Admin Approval (MAA) requires a second administrator to approve a sensitive change before Intune applies it. You define an Access Policy that specifies:
- What is protected. A single resource type per policy: Apps, Scripts, Device actions (wipe, retire, delete), Compliance policies, Configuration policies, RBAC, Access Policies themselves, or Tenant Configuration.
- Who can approve. A security group of approvers.
When any admin in the tenant tries to make a change to a protected resource, the change goes into a pending state. A different admin from the approver group has to approve it before it takes effect. The original admin then comes back and clicks Complete to apply the change.
Two things that matter:
- An admin cannot approve their own request, even if they are in the approver group. That is the entire point.
- The approver group must be a security group. Distribution lists, Microsoft 365 groups, and mail-enabled security groups silently fail to resolve and your policy will not work as expected.
What to gate first
You do not need to turn MAA on for everything at once. In fact, you should not. Pick the highest-blast-radius actions first and add the rest in waves.
Wave 1: Device actions (wipe, retire, delete)
Start here. This is the action used in the Stryker attack and it is the action with the largest immediate operational impact. A wrongly issued wipe — whether by accident, by a fat-finger, or by an attacker holding a compromised admin account — destroys data on real devices belonging to real people. There is no “undo.”
Gating wipes behind a second pair of eyes adds maybe two minutes to a legitimate request. It adds an entire human checkpoint to a malicious one.
Wave 2: Apps
App deployment is one of Intune’s most powerful living-off-the-land paths. Anyone who can push an app to the fleet can push code to the fleet. If your tenant ever gets a compromised admin, this is one of the first things they will reach for.
Gate Apps behind MAA. Yes, your packaging team will grumble for a week. Then they will adjust to the workflow.
Wave 3: Scripts
Scripts deployed to Windows devices run as SYSTEM. If you would not let a single admin push arbitrary SYSTEM-level code to your fleet without review, you should be gating this.
Wave 4: Configuration and compliance policies
These are slower-moving threats but still high impact. A compliance policy edit can change which devices are considered “healthy” by Conditional Access. A configuration policy edit can disable controls across the fleet. Worth gating once your team is used to the workflow.
The setup steps
The path is straightforward, but follow it carefully:
- Sign in to the Microsoft Intune admin center.
- Navigate to Tenant administration > Multi Admin Approval > Access policies.
- Click Create.
- Name the policy clearly. “MAA – Device wipe / retire / delete” beats “Policy 1.” You will thank yourself later.
- Pick the Profile type. One per policy.
- On the Approvers page, add a security group containing the admins who can approve this category of change.
- Review and create.
Repeat for each wave. You will end up with one Access Policy per protected resource type.
The rollout pitfalls that catch teams out
Pitfall 1: Approver groups too small
If your approver group is two people and they both go on PTO at the same time, the entire workflow stops. Your team cannot deploy apps, push scripts, or wipe lost devices. Plan for at least four approvers in the group, with explicit rotation expectations.
Pitfall 2: Forgetting to gate Access Policies themselves
MAA can be applied to MAA. If you do not gate the Access Policy resource itself, a compromised admin can simply remove your other access policies first, then do whatever they want. Add an Access Policy that protects Access Policies. Yes, it is a tongue-twister. Yes, it matters.
Pitfall 3: Approver fatigue
If your approvers are getting 40 requests a day, they will start rubber-stamping. That defeats the purpose. Make sure each approval request has enough context (who, what, target group) and keep the volume manageable by being deliberate about which actions you gate.
Pitfall 4: Break-glass accounts
Your break-glass / emergency access accounts should be carefully considered against MAA. The point of break-glass is single-account access in an emergency. The point of MAA is no single-account high-impact action. Resolve this tension in advance by documenting which break-glass scenarios are exempt and how that exemption is monitored. Do not let “emergency” become a permanent bypass.
Pitfall 5: Treating MAA as a substitute for least privilege
MAA does not replace good RBAC. It is a second control layer for actions that are already restricted to a small group of admins. If half your IT staff are tenant Global Admins, MAA helps but it does not save you. Tighten your role assignments at the same time.
What to do this week
- Create the Access Policy that protects device wipe / retire / delete. Even if you do nothing else, do this one.
- Identify your approver security group. Confirm it is a real security group, not a mail-enabled or M365 group.
- Add a calendar reminder for two weeks from now to review the approval queue volume and add the Apps policy.
MAA is one of those controls that costs almost nothing once the workflow settles, and pays off the first time you avoid an accidental wipe — long before you ever face a Stryker-style targeted attack.
