One Admin Account Should Never Be Able to Wipe a Fleet: Lessons from the Stryker Breach

No malware. No zero-day. No sophisticated tradecraft. The most destructive Microsoft 365 incident of early 2026 needed exactly one compromised admin account and a management platform doing precisely what it was built to do.

On March 11th, 2026, employees at Stryker started their day to blank screens. Within three hours, roughly 80,000 devices had been wiped across the company's 61-country footprint. Not encrypted. Not ransomed. Erased. An Iran-linked hacktivist group had compromised an admin account and used Microsoft's own Intune remote wipe capability against the entire managed fleet. Manufacturing halted. Shipping stopped. Surgeries were rescheduled.

One admin action caused all of it, and no second checkpoint existed to slow it down. (Full incident reporting: Stryker attack wiped tens of thousands of devices, no malware needed (opens in new tab).)

The controls that would have blunted this already exist in your Microsoft environment. Most organizations have not turned them on. Here is what they are, how to configure them, and where they still fall short for MSPs as of May 2026.

What puts a second key on the wipe button?#

Multi Admin Approval (MAA) is the built-in Intune feature Microsoft pointed to directly in response to the Stryker breach. It requires a second admin from a designated approver group to sign off before any sensitive action executes.

In a default Intune setup, one admin can wipe any device instantly, so one compromised account is all an attacker needs. MAA breaks that single point of failure by holding the action in a queue until a separate approver reviews and approves it. Think of it as a two-key protocol: one person initiates the request, and a second person must turn their key before anything happens.

What MAA covers today: device wipes, device retires, device deletes, script deployments, app assignments, RBAC role changes, compliance policies, and configuration policies. It also applies to Graph API calls, not just actions taken in the Intune portal.

Reference: Use Multi Admin Approval in Intune (opens in new tab)

Setting up MAA, start to finish#

You need at least two admin accounts and an Intune Plan 1 license.

1. Create an approver security group#

1. In Entra ID, go to Groups, then New Group
2. Group type: Security
3. Name it clearly. Recommended: "Intune-MAA-Approvers"
4. Add the accounts that will serve as approvers. Use dedicated security admin accounts, not day-to-day tech accounts
5. Click Create

2. Open Multi Admin Approval in Intune#

Intune Admin Center > Tenant Administration > Multi Admin Approval > Access Policies > Create

3. Create a policy for device wipe#

1. Name the policy, e.g. "Protect - Device Wipe"
2. Profile Type: Device actions
3. Click Next
4. On the Approvers page, click Add Groups and select your "Intune-MAA-Approvers" group
5. Click Next, then Submit for Approval

Note on activation: the access policy itself requires a second admin to approve it before it goes live. Sign in with your approver account, go to Received Requests, approve the policy, then return to the original account and click Complete to finalize.

4. Test the workflow before you need it#

Log in as a standard admin and attempt to wipe a test device:

Devices > [Select device] > Wipe

You now see a Business Justification field instead of an immediate wipe prompt. Fill it in and submit. Allow a few minutes for the policy to propagate in your environment before testing.

Switch to your approver account and go to:

Tenant Administration > Multi Admin Approval > Received Requests

Review and approve the request. Once approved, the original requester returns to their request and clicks Complete to finalize the action. The approver and the executor are two distinct steps by design.

Requests that sit unacted on for approximately three days are automatically marked stale and expire, which keeps a backlog from accumulating.

The two gaps MSPs cannot ignore#

MAA is a meaningful control. It also has two holes that change how you should deploy it.

GDAP traffic sails right past MAA#

If you are an MSP using GDAP to access customer Intune environments, actions performed through those delegated permissions currently bypass Multi Admin Approval entirely. A technician using a GDAP-delegated Intune Admin role to wipe a device in a customer tenant will not trigger the approval flow. The action executes immediately.

That means the security of your customers' Intune environments depends directly on how well you protect your own MSP tenant and the accounts holding those GDAP relationships.

Even outside this gap, MAA presents a structural challenge for MSPs: the approval workflow requires an account within the customer tenant to act as approver, and most MSPs do not operate that way. This is what makes the layered mitigations below more practical for MSP environments.

A Global Admin can approve their own requests#

If an attacker already holds Global Administrator access, they can create a new admin account, add it to the approver group, and use it to approve their own requests. MAA assumes the approver group has not been compromised, and once an attacker reaches GA level, that assumption breaks.

Routing around MAA requires the attacker to understand the feature and take extra configuration steps, which does slow them down. But it is not a reliable barrier once the identity perimeter has already been breached.

Layered defenses: what we recommend MSPs do this week#

Turn MAA on anyway#

If you are a direct customer tenant, configure MAA this week. Cover device wipes, scripts, apps, and configuration policies at minimum. This is Microsoft's direct recommendation following the Stryker breach.

For MSPs: enable MAA in your internal tenant and encourage customers to enable it in theirs. Understand the GDAP gap, but do not let it stop you from deploying a control that still adds meaningful protection for direct tenant actions.

One operational warning, confirmed in Microsoft's documentation: Intune sends no alerts when a new approval request is submitted. No email, no Teams message, no push notification. You need to build a notification process. At minimum, establish a Teams message convention with your approvers. For a better solution, build a Logic App that monitors Intune audit logs and posts a Teams alert when a new MAA request comes in.

Put PIM in front of your MSP tenant privileges#

Privileged Identity Management addresses the root cause of the Stryker attack: standing privileged access. Your technicians should not have permanent Intune Administrator or Global Admin access in your MSP tenant. That tenant connects to every customer environment you manage via GDAP, so one compromised tech account with standing GA access is a single point of failure for your entire customer base.

With PIM for Groups configured, technicians request elevation only when needed, for a defined time window, with MFA or approval required to activate. When the window closes, access is removed. A compromised account at 2 AM on a Saturday inherits low privileges, not access to every customer you manage.

PIM extends to GDAP itself: just-in-time access to customer environments only when a ticket requires it, removed automatically outside active work windows. That eliminates the persistent GDAP relationships that represent ongoing supply chain risk. Full walkthrough: Secure Your GDAP Access with Just-in-Time Permissions.

Govern break glass accounts like the weapons they are#

Every tenant needs break glass accounts: emergency-only admin credentials for when normal access paths fail. Most organizations manage them poorly. They should meet three requirements:

• Cloud-only. Not synced from on-prem AD and not a federated identity. These accounts must work even if your hybrid infrastructure fails.
• Excluded from Conditional Access. At least one break glass account must bypass your CA policies so it remains accessible when everything else is locked down.
• Monitored with sign-in alerts. Configure audit log alerts to fire immediately any time a break glass account authenticates. Any use outside a declared emergency is worth investigating.

And keep them out of your MAA approver group. Break glass is for emergency access recovery; MAA approvers are for day-to-day governance. Mixing them weakens both controls. Full walkthrough: Best Practices for Break Glass Accounts.

None of this requires new budget#

The Stryker attack succeeded because one account could do everything instantly. Multi Admin Approval, PIM, and proper break glass governance are all available today, and none require a new line item. They require configuration and the discipline to implement them before an incident forces your hand.