Why adding a second approval for remote device action like "wipe" is no longer optional in a world of compromised privileged access.
There are some security lessons that arrive as a whitepaper, and then there are the ones that arrive like a brick through the server room window.
The recent Iran-linked cyberattack on Stryker appears to belong firmly in the second category.
Public reporting suggests the incident caused major disruption to Stryker’s Microsoft environment, with multiple reports pointing to attackers likely gaining access to Microsoft Intune and using legitimate remote wipe capabilities to reset or wipe enrolled devices at scale. [nbcnews.com], [krebsonsecurity.com], [pcmag.com]
And that is the uncomfortable part many organizations need to sit with for a moment.
Because thisability to remotely wipe a managed device IS NOT an exotic feature buried inside a secret admin vault. It exists for real IT day to day operational tasks for reasons like lost, stolen, retired, or repurposed devices, and the usual endpoint lifecycle mess that keeps enterprise admins hydrated on caffeine — a legitimate functionality that may have been abused in this incident to wipe or factory-reset enrolled devices at scale.
This is not just a story about malware. It is not just a story about ransomware. And based on public reporting, it does not primarily appear to be a story about some exotic technical exploit either.
Instead, it is a story about what happens when attackers get hold of powerful administrative control planes and start pressing the buttons that were designed for legitimate IT operations.
Table of Contents
One Admin Account Should Not Be Able to Start a Fleet-Wide Apocalypse
Security teams often imagine dramatic breach scenarios involving payloads, persistence, lateral movement, and all the usual cybersecurity bingo cards. But sometimes, the most dangerous thing an attacker can get is not code execution privilege, but control of a management plane.
Because when a bad actor gets privileged access, the danger is no longer theoretical. The danger becomes operational, immediate, and very expensive.
In the Stryker case, public reporting strongly indicates that legitimate device-management actions were weaponized through the Microsoft environment rather than a classic ransomware deployment.
And that is where the real problem lies.
In this whole Stryker incident, Microsoft’s Intune did not suddenly become evil — Intune did exactly what it was told to do.
When a privileged console is abused, your tooling does not become the victim — it becomes the weapon.
This is where Intune Multi-Admin Approval comes in.
Microsoft’s documentation is refreshingly clear on the purpose of Multi-Admin Approval (MAA):
MAA exists to reduce the risk of a compromised administrative account by requiring a second administrative account to approve a protected change before Intune applies it.
For device actions, Microsoft confirms that protection can cover wipe, retire, and delete. [learn.microsoft.com]
In simple words, with Multi-Admin Approval (MAA) in place, Intune adds a deliberate checkpoint between “someone clicked wipe” and “congratulations, now 50,000 devices are having the worst day of their lives.”
That means if someone gets hold of an Intune admin account and tries to go full chaos goblin with mass remote actions, the request should stop at the approval gate instead of turning your estate into a digital crater. It also means accidental damage gets blocked too, because let us be honest, not every disaster starts with a nation-state. Sometimes it starts with a tired admin, ten open tabs, and one catastrophically confident click.
Because “one admin account can wipe half the fleet before breakfast” is not a governance model. It is a career-limiting event waiting for a calendar invite.
That checkpoint is not bureaucracy, it is blast-radius reduction. And in enterprise security, blast-radius reduction is often the only thing separating “contained incident” from “everyone cancel your weekend plans.”
What Intune Multi-Admin Approval (MAA) Actually Does
Multi-Admin Approval (MAA) in Intune works through access policies.
When an admin tries to make a protected change, Intune does not immediately execute it. The requester submits the action with a business justification, a different authorized approver reviews it, and only after approval does the requester is able to complete the change so Intune can process it.
Microsoft further notes that the requester can see their requests, approvers can approve or reject them, and the requester cannot approve their own request. [learn.microsoft.com]
In plain English:
Intune says, “Cool story. Get another adult to sign off on it.”
Microsoft also documents that actions and approval steps for protected resources are logged in Intune audit logs, and that request states such as Needs approval, Approved, Completed, Rejected, and Canceled are tracked in the workflow. [learn.microsoft.com]
So this is not just about stopping bad changes. It is also about accountability, auditability, and not having to reconstruct catastrophe from vibes and screenshots later.
What Organizations Should Take Away from This
Let’s be honest here.
“Require a second admin to approve destructive actions” does not exactly sound like the kind of feature people print on conference T-shirts. It sounds procedural. It sounds slow. It sounds like the sort of thing people skip because surely our privileged accounts are locked down enough.
And then, reality happens.
If you are using Intune, Multi-Admin Approval (MAA) for device actions should be treated as a security control, and not an optional administrative inconvenience.
Microsoft explicitly supports MAA for device actions including wipe, retire, and delete, precisely to add an approval gate before those changes are applied.
Is it a little extra friction?Yes. Is that friction infinitely preferable to explaining why thousands of devices got reset because one privileged account was abused? Alsoyes.
Yes, it adds a little operational delay. Yes, approvers need to exist, be assigned correctly, and actually pay attention. And yes, Microsoft notes that Intune DOES NOT send automatic notifications when new approval requests are created, which means you need process discipline around urgent requests.
But…
That friction is still infinitely cheaper than explaining to leadership about a mass device reset event across the estate that got initiated through a compromised account and succeeded, all because of a 2nd checkpoint gatekeeper that, though is available, but not put in place.
In a world where geopolitical tensions increasingly spill into cyber operations, no organization should assume it is too ordinary to become collateral damage. The gap between “that happened in the news” and “that happened in our tenant” is smaller than many organizations are still comfortable admitting
Final Thought
The lesson from the Stryker incident is simple — legitimate admin tools can become weapons of destruction and wreak havoc with compromised privileged access. And when legitimate remote actions can be abused at scale, “four-eyes approval” stops being bureaucracy and starts looking a lot like common sense.
So if there’s a way to add a second gatekeeper, if it exists, you should, in all probability and sense, add it, instead of thinking it as an additional friction to the operations.
In Intune, that means enabling Multi-Admin Approval for device actions.[learn.microsoft.com]
Because “we require a second admin to approve wipe” sounds far better in a post-incident review than “someone got into the console and pressed the big red button.”
Looking for an "how to?" — long back I did a blog post on this [joymalya.com] but back then it was still in public preview. Though the underlying working principle as explained in that post still holds true, I'd still recommend to take a look at the official Microsoft document to start with updated data.
This blog post is all about sharing my experience of trying out the new Multi Admin Approval (MAA) feature introduced in Intune with the November service release. [Read More]
Be the first to comment