March 13, 2026

Your Management Console Is a Weapon. Here's How to Unload It.

Microsoft Security
·
JP Bourget
·
March 15, 2026
·
14
min read
Blog Topic Image

The Stryker cyberattack in March 2026 showed exactly how a compromised admin account can wipe an entire device fleet in minutes using Microsoft Intune. This post covers how to prevent an Intune bulk wipe attack using Microsoft’s existing security stack — Entra ID Privileged Identity Management, Intune Multi Admin Approval, phishing-resistant MFA, Conditional Access, Intune RBAC, and Microsoft Sentinel detection rules. Every control described here is available in licenses most Microsoft enterprise customers already own. If you’re on M365 E3, E5, or the newly announced M365 E7, you have the tools. The gap is implementation.

⚠ What happened at Stryker: On March 11, 2026, a pro-Iranian group called Handala executed a Microsoft Intune wiper attack against Stryker Corporation — a $25B medical device company with 56,000 employees across 61 countries. They issued remote wipe commands that hit hundreds of thousands of devices. They didn’t deploy malware. They didn’t exploit a vulnerability. They got admin credentials and used the Intune admin console the same way you would. Stryker confirmed a global disruption to its Microsoft environment in an SEC 8-K filing. We’re going to spend exactly one more paragraph on the Stryker cyberattack, and the rest of this post on what you should actually do about it.

The Stryker Intune attack succeeded because admin credentials were compromised and there were no controls to prevent a single authenticated session from triggering an Intune bulk wipe across every managed device in the fleet. The geopolitics aren’t your problem to solve. The configuration is.

The Actual Problem: Standing Permissions + No Guardrails

The Stryker attack wasn’t technically sophisticated. Microsoft Intune is designed to let administrators wipe devices remotely — that’s a feature, not a bug. The problem is that in most environments, the Intune Administrator role is permanently assigned. Always on. Always ready. And the only thing standing between your entire device fleet and a factory reset is a username and password.

When an attacker steals those credentials — through phishing, through a stealer like Rhadamanthys, through a session hijack — they don’t need to do anything clever. This is a textbook living-off-the-land (LotL) attack: no malware, no exploit, just legitimate tooling in unauthorized hands. They open a browser, go to intune.microsoft.com, and they’re you. Your EDR won’t see it. Your antivirus won’t flag it. You’ll find out when your phone goes blank.

The fix isn’t a new tool. It’s using the tools you already have. Here’s the complete Intune security hardening playbook.

Prevention: Lock Down the Admin Plane

1. Enable PIM for Every Privileged Intune Role

Privileged Identity Management (PIM) in Microsoft Entra ID is the single highest-impact control for preventing an Intune wiper attack. It eliminates standing Intune privileged access — roles are activated on-demand, for a bounded window, with MFA plus approval. A stolen credential doesn’t get you in because the standing permission no longer exists.

Enable PIM for: Intune Administrator, Global Administrator, Intune Service Administrator, and Cloud Device Administrator. Require MFA + second-admin approval to activate any of these roles. Cap activation windows at 1–4 hours with written justification. Maintain a break-glass account separately — scoped, MFA-required, monitored, and not in daily use.

🔑 License: PIM requires Entra ID P2 or Entra ID Governance. Included in M365 E5 and M365 E5 Security. Available via the Defender Suite for Business Premium add-on (~$10/user/month) for M365 Business Premium organizations up to 300 users.

2. Force Phishing-Resistant MFA for Admin Accounts

Standard TOTP codes and SMS pins can be stolen in real time by credential-relay proxies — the exact technique used in the Stryker cyberattack pattern. FIDO2 security keys and Windows Hello for Business bind the credential to the physical device and origin — they cannot be relayed.

Require FIDO2 or Windows Hello for Intune admins, Global Admins, and Cloud Device Admins — no exceptions. Create a Conditional Access policy with Authentication Strength set to Phishing-resistant MFA targeting these roles. Block legacy authentication protocols (Basic Auth, NTLM) entirely for admin accounts.

🔑 License: Conditional Access requires Entra ID P1 (M365 E3+). Authentication Strength policies for requiring FIDO2 require Entra ID P1. Identity Protection risk-based CA requires Entra ID P2.

3. Protect the Intune Admin Console with Conditional Access

intune.microsoft.com should not be reachable from arbitrary devices at arbitrary hours. Require a compliant, Entra-joined device for access to Intune and M365 admin portals. Use named locations to restrict access to corporate IP ranges or VPN egress only. If your Intune admin console is reachable from a coffee shop in Tehran, that’s a configuration choice you made.

Set a sign-in frequency control requiring re-auth after 1 hour of admin portal inactivity. Use Defender for Cloud Apps session policies to block download and clipboard operations in admin sessions.

🔑 License: Conditional Access requires Entra ID P1+. Defender for Cloud Apps is included in M365 E5, M365 E5 Security, and the Defender Suite for Business Premium add-on.

4. Separate the Wipe Permission — and Require Two Admins to Use It

Intune RBAC lets you separate “read device info” from “wipe or retire a device.” The ability to trigger an Intune bulk wipe should require a different credential than the one your helpdesk uses daily.

Create a scoped custom Intune role with retire/wipe permissions limited to a dedicated break-glass account. That account should be MFA-required, have no email, be monitored by a separate alert rule, and require PIM activation before it can do anything.

Multi Admin Approval — the easiest Intune wipe protection you’re not using. Intune’s built-in Multi Admin Approval (MAA) feature requires a second administrator to explicitly approve protected actions before they execute. Enable it for Wipe and Retire operations by navigating to Tenant administration → Multi Admin Approval → Access policies → Create. Name the policy, select Device actions for wipe, delete or retire as the policy type, assign an approver group, and submit for approval.

Once active, any wipe request — including scripted API calls — enters a pending queue and cannot execute until an approver in that group confirms it. An attacker with a single compromised Intune admin account cannot complete the Stryker-style wipe alone.

The nuance that matters: MAA has a built-in self-protection mechanism that most writeups skip. The access policy itself — the rule that says “wipes require approval” — also requires approval from a second admin to create or modify. This means an attacker who compromises a single admin account cannot simply log in, delete the MAA policy, and then wipe. Disabling the protection requires the same two-admin process it protects. That’s the design intent, and it’s exactly what you want: the control that prevents unauthorized wipes is itself protected from unauthorized removal.

🔑 License: Intune RBAC and Multi Admin Approval are both included with any Microsoft Intune Plan 1 license. No additional premium licensing required. PIM-gating the break-glass account requires Entra ID P2.

5. Back Up Your Intune Config and Entra ID Objects

A wiper attack means your recovery speed depends entirely on whether you have a current, tested backup of your MDM config. Most organizations don’t. Export Intune configuration via Microsoft Graph API on a schedule — the open-source IntuneManagement tool by Micke-K is purpose-built for this.

Store backups in a separate tenant or offline — not in the same Entra ID the attacker just compromised. Test your restoration process. A backup you’ve never restored is a hypothesis, not a recovery plan. Back up Entra ID group memberships, role assignments, and Conditional Access policies separately, as these are often not included in standard Intune exports.

Detection: Alert Before the Intune Wipe Finishes

Detection after the fact is useless for a wiper attack. But there’s a window — between when the wipe command is issued and when every device finishes executing — where a fast alert and automated response can limit the damage. The four Sentinel rules below wire that up.

Before these rules do anything, confirm these connectors are enabled: Microsoft Entra ID connector (enables AuditLogs and SigninLogs), Microsoft 365 connector (enables IntuneAuditLogs — also requires enabling Intune Diagnostic Settings separately in the Intune portal under Tenant administration → Diagnostic settings), and MicrosoftGraphActivityLogs via Entra Diagnostic Settings (not part of the standard connector — requires a separate setting in Entra admin center → Monitoring → Diagnostic settings). Queries against empty tables alert on nothing.

🔑 License: Sentinel is pay-per-GB. AuditLogs and SigninLogs from Entra ID ingest free. IntuneAuditLogs and MicrosoftGraphActivityLogs are billed at standard rates (~$5/GB). Risk signal columns (RiskState, RiskLevelDuringSignIn) require Entra ID P2.

Rule 1 — Intune Bulk Wipe or Retire Detected

The IntuneAuditLogs table records wipe and retire actions as OperationName values “wipe ManagedDevice” and “retire ManagedDevice”. Both the actor UPN and target device names are nested inside the Properties JSON column — not top-level fields. Use todynamic() to parse them correctly.

IntuneAuditLogs | where OperationName in ('wipe ManagedDevice', 'retire ManagedDevice') | extend ActorUPN = tostring(todynamic(Properties).Actor.UPN) | extend DeviceName = tostring(todynamic(Properties).TargetDisplayNames[0]) | summarize ActionCount = count(), DeviceList = make_set(DeviceName) by ActorUPN, bin(TimeGenerated, 5m) | where ActionCount >= 2 | extend AlertSeverity = iif(ActionCount >= 10, 'High', 'Medium') | project TimeGenerated, ActorUPN, ActionCount, AlertSeverity, DeviceList

Rule 2 — PIM Activation Outside Business Hours

PIM activations are recorded in AuditLogs with OperationName “Add member to role completed (PIM activation)”. Role name is in TargetResources[0].displayName. Time is UTC — adjust the hour filter to match your org’s timezone.

AuditLogs | where OperationName == 'Add member to role completed (PIM activation)' | where Result == 'success' | extend ActorUPN = tostring(InitiatedBy.user.userPrincipalName) | extend RoleName = tostring(TargetResources[0].displayName) | where RoleName in ('Intune Administrator', 'Global Administrator', 'Cloud Device Administrator', 'Intune Service Administrator') | extend LocalHour = datetime_part('Hour', TimeGenerated) | where LocalHour !between (7 .. 19) | project TimeGenerated, ActorUPN, RoleName, ResultDescription

Rule 3a — Risky Admin Sign-In (Entra ID P2)

RiskState and RiskLevelDuringSignIn are populated only when Entra ID Identity Protection (P2) is licensed. Stolen credentials from the type of attack that hit Stryker almost always appear with elevated risk signals.

SigninLogs | where AppDisplayName in ('Microsoft Intune', 'Microsoft Intune Enrollment', 'Microsoft Azure Active Directory', 'Microsoft 365 Admin Portal') | where ResultType == 0 | where RiskState == 'atRisk' or RiskLevelDuringSignIn in ('high', 'medium') | project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, RiskState, RiskLevelDuringSignIn

Rule 3b — Admin Sign-In from Unexpected Country (P1)

SigninLogs | where AppDisplayName in ('Microsoft Intune', 'Microsoft Intune Enrollment', 'Microsoft Azure Active Directory', 'Microsoft 365 Admin Portal') | where ResultType == 0 | extend Country = tostring(LocationDetails.countryOrRegion) | where Country !in ('US', 'CA', 'GB') or tostring(NetworkLocationDetails) has 'anonymousProxy' | project TimeGenerated, UserPrincipalName, IPAddress, Country, NetworkLocationDetails

Rule 4 — Graph API Device Management Spike

An attacker scripting a mass Intune wipe via the Graph API generates unusual call volume from a single principal — the same pattern that would appear in a Stryker-style automated wipe. MicrosoftGraphActivityLogs requires separate Entra Diagnostic Settings configuration and is not enabled by default.

MicrosoftGraphActivityLogs | where RequestUri has '/deviceManagement/managedDevices' | where RequestMethod in ('POST', 'DELETE') | summarize CallCount = count() by UserId, bin(TimeGenerated, 10m) | where CallCount > 20 | project TimeGenerated, UserId, CallCount | order by CallCount desc

Automated Response

Wire Rules 1 and 3 to a Sentinel Playbook (Logic App) that fires immediately: disable the actor’s Entra ID account via Graph API (accountEnabled: false), revoke all active refresh tokens via revokeSignInSessions, remove any active PIM role assignment via the PIM API, and post to your SOC Teams channel with actor UPN and affected device count. The goal is alert-fires-to-account-disabled in under 60 seconds.

Priority Matrix

Do today: Enable PIM for Intune Administrator and Global Administrator (eliminates the standing access the Stryker attack exploited), enforce phishing-resistant MFA for admins (stops credential relay attacks).

This week: Enable Intune Multi Admin Approval for Wipe and Retire actions (ten minutes, free, requires two admins to complete a wipe — the single most direct mitigation against the Stryker attack pattern), deploy the bulk wipe Sentinel alert rule (Rule 1), configure Conditional Access requiring compliant device for admin portals, add admin sign-in anomaly alert (Rule 3), separate RBAC wipe permissions, deploy PIM after-hours alert (Rule 2).

This month: Deploy Graph API spike alert (Rule 4), build automated response playbook, configure Intune config backup via Graph API.

None of This Requires New Licensing

Everything needed to prevent a Stryker-style Intune wiper attack is in Microsoft’s existing security stack. Quick map:

PIM: Entra ID P2 or Entra ID Governance — M365 E5, M365 E5 Security (enterprise); Defender Suite for Business Premium add-on (SMB, up to 300 users).

Conditional Access: Entra ID P1 — M365 E3 and above.

FIDO2/WHfB: Entra ID P1 for Authentication Strength policies; FIDO2 keys are hardware (~$25–$60/key).

Intune RBAC + Multi Admin Approval: Any Microsoft Intune Plan 1 license — no additional cost. MAA for device wipe is one of the highest-value free controls available in any Intune deployment.

Sentinel: Pay-per-GB. AuditLogs and SigninLogs ingest free. IntuneAuditLogs and Graph activity logs ~$5/GB. Logic App playbooks billed per execution — typically pennies per run.

🔑 SMB path — Defender and Purview Suites for Business Premium: On M365 Business Premium (up to 300 users)? The Defender Suite for Business Premium add-on (~$10/user/month) includes Entra ID P2 (unlocking PIM and Identity Protection), Defender for Endpoint P2, Defender for Identity, and Defender for Cloud Apps. The Purview Suite (~$10/user/month) adds DLP, insider risk, and audit. Combined ~$15/user/month — roughly 68% savings versus buying components separately. Multi Admin Approval is included in the base Intune Plan 1 license that comes with Business Premium — no add-on required.
🔑 M365 E7 note: Microsoft 365 E7: The Frontier Suite (GA May 1, $99/user/month) bundles M365 E5 + M365 Copilot + Agent 365 + the full Microsoft Entra Suite — Entra ID Governance, Identity Protection, and Private Access. Every control in this post is included. Complete this Intune security hardening before enabling Copilot and agents at scale — the same admin plane that can wipe devices can also govern your AI agents.

The gap is almost never licensing. It’s that organizations deploy Intune and treat the management plane as an afterthought. Admins have standing access they rarely use. MFA is on, but it’s the kind that can be relayed. The console is reachable from anywhere. And there’s no alert on an Intune wipe command because “no one would ever do that.”

Someone did. The Stryker cyberattack took one authenticated session and a few minutes. Preventing it takes one afternoon and tools you already own.

The management plane is the attack surface. Lock it down like one.

About Blue Cycle

Blue Cycle is a Microsoft Intelligent Security Association (MISA) member and Microsoft Solution Partner with specializations in Security, Identity, and Modern Work. We implement the exact controls described in this post — Microsoft Sentinel deployments, Intune security hardening, Entra ID PIM configuration, and M365 Copilot readiness — for organizations across the healthcare, manufacturing, and financial services sectors.

As a MISA member, Blue Cycle works directly within Microsoft’s security partner ecosystem, with early access to threat intelligence, product roadmaps, and joint go-to-market programs. Our Intune and Entra ID security work is grounded in the same frameworks Microsoft’s own security team recommends — not generic best-practice lists.

If the Stryker cyberattack raised questions about your own Intune and admin plane exposure, book a security assessment. We’ll map your current state against the controls in this post and build a prioritized remediation plan — typically in a single half-day engagement.

Ready to get started?

Let’s talk about how Blue Cycle can help with your security operations.

Book an Assessment