The recent cyber incident involving Stryker, whereby there entire device fleet was remotely wiped, has become one of the clearest modern examples of why identity protection and administrative governance matter just as much as traditional endpoint security. Reports surrounding the attack suggest that threat actors leveraged compromised privileged access within Microsoft’s cloud management ecosystem to issue destructive actions at scale, reportedly using legitimate tooling rather than malware in the traditional sense. That distinction is important. The attack was not necessarily about exploiting a vulnerability in Microsoft Microsoft Intune itself, but rather exploiting trust, permissions, and the absence of additional control gates around highly destructive administrative actions.

In light of the Stryker incident, Microsoft quickly unveiled Multi Admin Approval (MAA) controls within Microsoft Intune. MAA requiring a second authorised administrator to approve sensitive actions such as device wipes, script deployment, or high-risk configuration changes. By enabling MAA organisations introduce a deliberate operational pause into the attack chain. Even if an attacker successfully compromises a privileged account, they are no longer able to immediately execute large-scale destructive actions unchecked. In practical terms, Multi Admin Approval transforms a single point of failure into a controlled, observable workflow, significantly reducing the likelihood of a catastrophic “one-click” compromise of an entire managed estate. In an era where attackers increasingly abuse legitimate management tooling rather than deploying obvious malware, dual-approval models are rapidly becoming a necessary part of modern endpoint governance rather than simply a “nice to have” security feature.

How to enable Multi Admin Approval

Login to Intune, browse to Tenant Administration and within Tenant Admin, click on Multi Admin Approval.

Click on Access Policies, and Create Policy.

Select the Policy Type, i.e. choose what you’re trying to “lock” behind a Multi Admin Approval workflow. In this example, we’ll restrict the ability to perform a Device Wipe without first seeking additional approval. Enter a description and when ready, click Next.

Select the Approvers group.

On the Review screen, you will be required to enter business justification before Creating the Access Policy.

Another administrator within the environment must then approve the Access Policy request. This is done by logging into Intune, browsing to Tenant Administration and within Tenant Admin, clicking on Multi Admin Approval. Within, pending requests will be visible on the dashboard.

Clicking the pending request will reveal further details. Within, you will be required to enter an approval reason.

After the policy creation has been seconded/approved, the creator needs to complete the policy to make it good.

And now, with the policy in place. If anyone tries to Wipe a device, the Multi Admin Approval flow will kick in and the command must not only be justified, but it must be approved before the Wipe command is actually sent.

Unfortunately, out of the box, there is no “notification” system that would alert you to the fact Multi Admin Approval requests are sat waiting, so for now, checking this for requests should become part of your daily checks.

Alternatively, developing a system to monitor this on your behalf and triggering a notification should be explored 😉

In other footnote comments. ONLY enabling MAA for Wipe, is probably not the full solution to the issues you’re trying to solve.

Wipe Options with MAA enabled

So with Multi Admin Approval enabled, what options do we have around performing device wipes, either in person on a 1:1 basis, and/or in bulk.

In terms of bulk, well… that ability pretty much goes away, due to the nature of MAA.

Wipe Method	Success/Fail	Result
Local Reset via Settings > System > Recovery > “Reset this PC“	Success	Providing this is not locked down/restricted elsewhere a local 1:1 user driven reset can be performed using “Reset this PC”.
Local Reset via Company Portal	Success	Providing this is not locked down/restricted elsewhere a local 1:1 user driven reset can be performed using “Company Portal”
Local Reset using script/application	Failure	Previously I have used WMI queries, and/or systemreset.exe to drive partially silenced device resets. Handy when needing to provide the user with control over when a device reset occurs – think about a tenant migration or similar.
Remote Reset using Graph API	Failure	Calling ./deviceManagement/managedDevices/$ManagedDeviceId/wipe with useProtectedWipe = $true, results in a 400 error when MAA is enabled. Disable MAA and this command works fine. Leave useProtectedWipe as disabled, and keepEnrollmentData enabled and an Autopilot Reset can be performed remotely using Graph API just fine.
Remote Reset using Intune Console	Success	Obviously with MAA enabled, you must do the initiator, approver, initiator workflow for the Wipe to work.
Remote Reset using script/application	Success	Using WMI queries and when initiated using the SYSTEM account, a Remote Wipe can occur – “bypassing” the need for MAA. I say “bypassing” it’s not a bypass per-se, as this requires the controlled creation and assignment of said script/application to allow this action. You could enable MAA to prevent Script/App creation without following a MAA workflow to prevent something like this.

Picture the scene…

I work a lot with Tenant to Tenant migrations and/or Device repurposing, a lot of the work I do in these engagements has a strong focus on “User Experience”.

Given that a good User Experience is key in those kind of projects, empowering the user to choose when their device reset happens is important. We don’t want to dictate that their device reset occurs 5 minutes after they sign in on Monday morning – no one wins there. Instead, we want the user to pick the right moment. No meetings Wednesday afternoon? Got a few hours free? Perfect.

And then, with guided instructions, the user is empowered to make their own choice as to when the process occurs.

For example;

And then. You can wrap a script into an App, and deploy it in a targeted manner. This App could be assigned as required, and the script could be written to “just do” and not prompt – that would handle Bulk wipe, but completely removes control over WHEN the reset occurs and that takes away from the User Experience I’ve banged on about above.

The benefit of the “App” approach, is that additional workflows could be triggered before the wipe. As shown in the demo below, prompts informing the user of the Reset. You could have this drive a 3 strikes and force Wipe, or have the user schedule a time etc…

But hey, all good fun. And food for thought.