On March 11, 2026, a single compromised Intune admin credential led to the erasure of roughly 80,000 devices at Stryker Corporation, one of the world’s largest medical device companies. No malware was involved. No CVE was exploited. The attacker used legitimate Intune commands to push wipe actions across the entire managed device fleet. Every control needed to prevent this attack was available before the breach. This post breaks down how the attack worked, why the standard “we have MFA” answer is no longer sufficient, and what it actually takes to validate and close these gaps before an attacker finds them.
How Did the Stryker Intune Attack Work?
March 11, 2026. Employees at Stryker Corporation, a $25 billion medical device company with 56,000 people across dozens of countries, watched their phones reset while holding them.
Some surgeries were delayed. Order processing went dark. Manufacturing and shipping ground to a halt. The company filed with the SEC confirming significant disruption to its Microsoft environment.
No ransomware was detected. No malware signature triggered an alert. The attacker did not need any of that.
The Iran-linked group Handala compromised an existing Intune administrator account, used it to create a new Global Administrator account, then pushed wipe commands through Intune across Stryker’s entire managed device fleet. The commands targeted all phones and workstations with an Intune base64 string. Handala claims the number was closer to 200,000 devices and 12 petabytes of data. Stryker has not independently confirmed device counts.
This is a living-off-the-land attack: the attacker uses legitimate tools and legitimate commands, operating entirely within normal system behavior, rather than deploying custom malware. There was no payload for an EDR to catch. The commands came from inside the console.
Forrester analyst Paddy Harrington confirmed this framing. The attack does not point to any inherent weakness in Intune. It uses the platform’s own capabilities against itself.
Denis Mandich, a former CIA official, framed the structural failure: “We are essentially giving attackers a single point of failure that allows one compromised credential to execute a global factory reset.”
According to the 2025 Verizon Data Breach Investigations Report, stolen credentials were the initial access vector in over 40% of breaches analyzed that year. The Stryker attack is a textbook example of that pattern taken to its logical extreme.
Eight days after the attack, CISA issued a public advisory urging all U.S. organizations to harden their endpoint management configurations. Microsoft had published its own hardening guidance three days earlier. Both pointed to the same set of controls. All of them were already available before March 11.
Why Did the Attack Succeed Despite MFA?
This is the pattern we see consistently at Nagomi: the tools were there. The attack succeeded because the configurations governing those tools were never validated.
Here is exactly what was missing, based on CISA’s advisory and Microsoft’s hardening guidance published in the wake of Stryker.
One: Phishing-resistant MFA was not enforced for admin accounts.
Microsoft’s guidance is unambiguous. Every privileged Intune action, including device wipe, script deployment, and role management, should require phishing-resistant authentication. Not push notifications. Not TOTP codes. FIDO2 keys or passkeys specifically, because standard MFA methods are bypassed routinely through adversary-in-the-middle proxies and push bombing. Microsoft’s 2024 Digital Defense Report found that over 99% of compromised accounts lacked phishing-resistant MFA. Most organizations can confirm that MFA is “enabled.” Almost none can confirm it is enforced for every admin account, on every portal, with no exceptions.
Two: Admin roles were not scoped with least privilege.
A properly scoped admin should only be able to affect the devices and users within their assigned scope: a region, a platform team, a business unit. Instead, the industry default is broad Global Administrator assignments, which is exactly the architecture Handala exploited. CISA’s advisory is direct: remove broad role assignments that do not map to a specific job function.
Three: Destructive actions had no Multi Admin Approval requirement.
Multi Admin Approval in Intune requires a second administrator to approve sensitive actions (device wipe, script deployment, role changes) before they execute. This feature existed before March 11. It was not configured at Stryker. With it enabled, Handala would have needed to compromise two independent admin accounts and coordinate approvals to execute the wipe. A substantially harder problem.
The toxic combination: An over-permissioned Global Admin account + no phishing-resistant MFA on admin portals + no Multi Admin Approval on destructive actions = one compromised credential, global factory reset.
None of these are exotic misconfigurations. They are the defaults in most Intune environments. The controls to prevent this attack were available, documented, and undeployed.
How Do You Continuously Validate Intune Security Controls?
At Nagomi, we run continuous validation across the exact configuration layers CISA and Microsoft identified as the failure points in Stryker. When something drifts or a new toxic combination surfaces, our agents do not fire an alert and wait. The autonomous investigation triggers immediately.
What we validate
Phishing-resistant MFA for privileged users, through Entra ID, the same policy layer Microsoft’s guidance targets. Not “is MFA on?” but “is phishing-resistant authentication enforced specifically for privileged roles, with legacy protocols explicitly blocked, and no Conditional Access exceptions that silently create a gap?”
MFA enforcement for admin portals: Intune, Entra ID, and related admin endpoints verified separately from end-user MFA policy. Admin portal access is frequently treated as implicitly covered by a general MFA requirement that does not actually enforce phishing-resistant methods. That assumption is the gap.
PIM enforcement across 14 identity checks, covering the full range of privileged identity hygiene across roles, activation policies, and assignment configurations. Three of these checks map directly to the Stryker attack chain:
No Permanent Privileged Role Assignments. Detects users with standing, always-on assignments to privileged roles with no expiration date. Permanent assignments bypass PIM’s entire Just-In-Time model: no activation step, no time limit, no opportunity to require MFA or approval at the moment of use. A compromised account with a permanent Global Admin assignment has indefinite, unrestricted access.
Require MFA for Privileged Role Activation. Validates that eligible users must authenticate with MFA at the moment they activate a privileged role, not just at initial sign-in. Even if an attacker has stolen valid credentials and the user is PIM-eligible, requiring MFA at activation means a single credential compromise does not automatically lead to privilege escalation.
Require Approval for Privileged Role Activation. Verifies that activating a privileged role requires sign-off from a designated approver. Without it, any eligible user, or any attacker with their credentials, can self-activate to Global Administrator at any time with no human gate.
What happens when a check fails or drifts
The agent runs the investigation automatically. It identifies which assets are exposed and what the operational blast radius is. It cross-references current threat intelligence. When an Intune admin MFA gap surfaces today, the agent factors in that this exact attack vector was weaponized by an active threat actor this week. It evaluates compensating controls. And it routes a fully contextualized remediation case, including root cause, asset exposure, business impact, and specific fix, directly to the team that owns it.
After remediation, the agent revalidates continuously. If a Conditional Access exception is added that inadvertently excludes a privileged role from phishing-resistant MFA, the agent catches it. If an admin drifts back to a standing Global Admin assignment after an access review, the case reopens. Automatically.
What used to take an analyst hours completes in minutes, triggered by any environmental change.
What To Do Right Now
CISA’s advisory and Microsoft’s hardening guidance are both public. The prioritized actions based on the Stryker attack chain:
- Audit every Global Administrator and Intune Administrator assignment today. Who has these roles? Does each map to a named person with a specific job function? If you cannot answer within the hour, start here.
- Enforce phishing-resistant MFA for admin portals. FIDO2 and passkeys for Intune and Entra ID administrative access. Verify no Conditional Access exception excludes a privileged account. Explicitly block legacy authentication protocols.
- Enable Multi Admin Approval for destructive actions. Device wipe, script deployment, RBAC role changes. None of these should be executable by a single administrator.
- Implement PIM with zero standing admin access. Time-bound elevation with reauthentication. No permanent Global Admin assignments for daily operational work.
The Stryker attack is not an edge case. MDM weaponization is not new. What is new is the scale, the speed, and an explicit CISA advisory that applies to every organization running Intune.
The question is not “do we have MFA?” It is “can I prove right now that it is enforced for every privileged identity, with no exceptions?”
If the answer requires a manual audit, it arrives too late.
That is what Nagomi is built to do. Request a demo today.
