This was not the silence of a network outage or a server crash that startled the security team. Instead it was the silence of nearly 200,000 wiped devices. Everything from laptops, phones and servers across 79 countries going dark simultaneously even before most of the workforce had their morning sip of coffee. What happened to Stryker on March 11 is different from your usual attacks, not only because of its scale (even though the scale is worrisome), but because of it reveals a blind spot that is hiding in plain sight inside virtually every enterprise on the planet. Its time we work up to this threat. 

Let me walk you through this incident.

Before we move forward, don’t forget to check out our previous blog post on  How Iranian threat actors are operating without connectivity here. 

What actually happened. The version nobody is leading with

Stryker Corporation is medical device manufacturer. It makes surgical robots, orthopaedic implants, hospital beds, and the Lifenet electrocardiogram transmission system used by emergency responders. It was hit by a destructive cyberattack claimed by Handala, an Iran-linked group linked to Iran's Ministry of Intelligence and Security (MOIS) that reports to the President of Iran (unlike IGRC that reports to the Supreme Leader). Handala has been showing extraordinary levels of activity in a connectivity starved environment over the last two weeks.

The surface-level story is essentially this. Handala wiped clearn more than 200,000 devices, claimed to exfiltrate 50 terabytes of data, defaced login screens with its logo and idled 56,000 employees globally. It also sent Stryker's stock down nearly 4 percent over a single trading session. The attack was framed as retaliation for a missile strike on a school in Minab, Iran.

You have heard and read all this. Here is the story they are not telling you.

The real attack vector: Your security tool was the weapon

A majority of post-incident coverage has described this as a simple "wiper attack" and moved on. That framing, while technically accurate, buries the most important detail in this entire incident: Handala likely did not deploy any novel malware to wipe those 200,000 devices. They just used Microsoft Intune.

Intune is the cloud-based Mobile Device Management platform that enterprises use to enforce security policies, push software updates, and remotely wipe devices that are lost or stolen to prevent data theft. It is designed specifically to give IT administrators a single console from which they can factory reset any enrolled device on the planet with a few clicks. It can be equated to an administrative nuclear button.

Handala gained administrative access to Stryker's Intune environment and used Intune's own built-in remote wipe capability to issue a mass wipe command to all enrolled devices in one go. That is not a zero-day exploit. That is not cutting-edge malware. That is logging into a legitimate enterprise platform with stolen admin credentials and pushing a button that was already there.

This is the detail that should be keeping every CISO awake right now: the attackers no longer need any custom tool or deploy a wiper. They just need to reach the administrative layer of a platform the potential victim is already paying for and trusting implicitly. Once they had that access, traditional endpoint detection was blind to it. A remote wipe command issued through Intune looks identical to a legitimate IT administration move. No malware signature, no anomalous process and no alert.

The risk from within

BYOD became a liability multiplier in ways employees never consented to understand. Stryker, like most enterprises, operated a Bring Your Own Device policy and employees enrolled their personal iPhones and Androids into Intune for work access. When the wipe command was executed, it did not discriminate between corporate data and personal data. Personal photos, banking apps and authenticator apps used for two-factor authentication were all wiped clean. In another twist of fortune, employees who lost their personal authentication apps then found themselves locked out of their own bank accounts because the second factor was gone. This is a catastrophic BYOD failure that compliance teams have to take note of. 

Lifenet going down was a patient safety event hiding inside a corporate IT story. Stryker's Lifenet system is used by emergency medical services to transmit electrocardiogram data to hospitals ahead of patient arrival, critical seconds in a cardiac event. Maryland's Institute for Emergency Medical Services confirmed that Lifenet was non-functional across most of the state following the attack, instructing EMS clinicians to revert to radio consultation. This is the healthcare sector's worst nightmare (and it keeps on happening): a cyberattack on a vendor silently degrading the quality of emergency care without a single hospital being breached. This dimension has received almost no analytical attention.

Third: the targeting rationale reveals a new and dangerous logic. Handala's manifesto described Stryker as a "*******-rooted corporation," referencing the company's 2019 acquisition of OrthoSpace. Stryker has no connection to military operations or defense contracting. It was targeted because of a historic business acquisition that tied it, in the attackers' ideological framework, to Israel. The implication is significant and I won’t reiterate it here.   

The attack began just after midnight Eastern Time, precisely calibrated to maximize global reach during the off-hours window when security operations are typically at minimum staffing and devices are idle but connected. The timing was not incidental. It reflects operational planning designed to maximize the number of enrolled devices online when the wipe command fired, while minimizing the time defenders had to respond before the damage was done globally. 

What went wrong?

The entry point was almost certainly credential compromise (phishing is Handala's documented primary access method). Someone with administrative privileges to Stryker's Microsoft Entra ID (formerly Azure Active Directory) environment was compromised, and that compromise granted Handala access to the Intune administrative console. From that position, the attacker had god-mode over every enrolled device in the organization.

What failed was not a lack of security tools. Stryker had Intune deployed globally. They had MDM policies. What failed was the absence of adequate controls around privileged access to the MDM administrative layer itself. Specifically: multi-factor authentication using phishing-resistant credentials for admin accounts was either not enforced or was bypassed; there were no alerting rules for bulk wipe commands. Wipe actions on more than a handful of devices in a short window never triggered an automatic investigation; privileged Identity Management controls that would have required just-in-time elevation to perform destructive actions like mass wipes were either absent or insufficiently configured; and no one appears to have treated the Intune admin console with the same security rigor applied to a domain controller, even though in terms of blast radius, it is now arguably more dangerous than one.

Enterprises deploy MDM to secure their devices, then fail to secure the MDM itself. The tool designed to protect turns into the very a mechanism of destruction. In security, we call this a single point of catastrophic failure — and enterprises have been building them into their Microsoft environments for years without recognizing it.

Advisory

The following are not aspirational controls. They are actions that, had they been in place at Stryker, would have either prevented this attack or contained it before it reached 200,000 devices.

Treat your MDM admin console like a domain controller because it is one. Audit every account with Intune Administrator, Global Administrator, or Intune Role Administrator privileges right now. There should be very few of them, they should all be named individuals, and every single one should require phishing-resistant multi-factor authentication, hardware security keys or certificate-based authentication, not SMS or authenticator apps that can be socially engineered.

Implement Privileged Identity Management for MDM administrative roles. Using Microsoft Entra PIM or an equivalent, require just-in-time elevation for any account that needs to perform sensitive Intune actions. The ability to issue a bulk remote wipe should never be persistently assigned to any account. It should require approval, time-boxing, and audit logging every time it is used.

Build a bulk wipe alert immediately. Configure your SIEM or Intune itself to trigger an immediate high-severity alert and automated block any time a wipe command is issued to more than five devices in any rolling ten-minute window. There is no legitimate IT scenario that requires wiping fifty devices simultaneously without human review. This single control would have stopped the Stryker attack cold.

Revisit your BYOD policy with honest risk disclosure. If you enroll personal devices in corporate MDM, employees need to understand in plain language that the company retains the legal and technical ability to factory reset their personal device — and that in a security incident, that wipe may happen without warning. Beyond disclosure, evaluate whether personal device enrollment in full MDM is necessary, or whether a containerized model — where only a sandboxed work partition is managed — would reduce the blast radius without sacrificing productivity.

Segment your OT and clinical systems from your corporate Microsoft environment. The Lifenet disruption was a foreseeable consequence of operational technology being tethered to the same Microsoft environment that was compromised. Clinical systems, medical devices in active use, and patient data systems should be network-segmented with their own authentication infrastructure, insulated from corporate IT outages regardless of cause.

Treat geopolitical threat intelligence as operational intelligence. Security teams have historically treated geopolitical risk analysis as someone else's problem. The Stryker attack demolishes that posture. If your organization has acquired a company in a country that is currently a target in an active military conflict, or maintains strategic partnerships in that country, that is a threat intelligence input that belongs in your risk assessment today. Review your M&A history. Map your vendor relationships to active geopolitical conflict zones. Assess your threat exposure accordingly.

Practice a mass-wipe recovery scenario. When did your organization last test restoring 10,000 devices from zero? Not a theoretical exercise — an actual test of your device rebuild pipeline, your BitLocker key recovery process, your application re-provisioning workflows? Most organizations have never run this drill. After Stryker, it is no longer optional. Recovery speed from a catastrophic wipe event is a business continuity metric that needs an owner and a tested SLA.

Last world

Stryker will recover. The devices will be rebuilt, the systems restored, the investigation concluded. But the lesson buried inside this attack is one the industry has been slow to internalize: the greatest threat in your environment may not be the malware the attacker brings in. It may be the administrative power you have already granted, sitting unguarded in a cloud console, waiting for someone with the right credentials to press the wrong button.

Twenty-five years ago, attackers had to be physically inside your building to do this kind of damage. Today, they need a stolen password and access to a login page. This attack was not a failure of security technology, it was a failure of security thinking, specifically, the persistent assumption that the tools we deploy for protection are themselves protected.

They are not. And in an era of active geopolitical cyberwarfare, that assumption is no longer one any organization can afford to hold.

Additional reading

IEC 62443-based OT/ICS risk assessment checklist for the food and beverage manufacturing sector
Removable media scan solution vendor evaluation and selection checklist

A note on the incident posted on Stryker's website