The Stryker Cyberattack: What Happened, and the Same Hole in Your Software

No malware, no ransom note: attackers used Stryker's own admin tools to wipe tens of thousands of devices in three hours. The entry points they used exist in plenty of small-business software too.

Nov 11, 2026

A server cabinet with its door ajar, an open padlock in front of it and a shield beside, on a cream background

TL;DR: On 11 March 2026, attackers wiped nearly 80,000 devices at Stryker, the US medical-device giant, in about three hours, using Microsoft Intune, the company's own device-management tool, after compromising an administrator account. No malware was deployed. The pro-Iran group Handala claimed the attack, and the US Justice Department later tied the group to Iran's intelligence ministry. Stryker's products were not affected, but order processing, manufacturing and shipping were disrupted in 79 countries. The same entry points, admin access plus missing monitoring, exist in many small-business systems. Here is what happened and what to check in yours.


What happened on 11 March 2026

  • 05:00 to 08:00 UTC, 11 March. Wipe commands issued through Microsoft Intune erased data from nearly 80,000 devices, according to a source familiar with the incident (BleepingComputer). Employees in the US, Ireland, Australia and India reportedly watched corporate laptops and personal phones, enrolled in Intune, wipe in real time.
  • Same day, 12:18 ET. The pro-Iran hacktivist group Handala claimed the attack on its site, before Stryker's own disclosure (TechCrunch).
  • 12 March. Stryker filed an 8-K with the SEC: a cybersecurity incident affecting certain IT systems caused a "global disruption" to its Microsoft environment, with order processing, manufacturing and shipping affected, and an unknown restoration timeline (8-K via StockTitan, Stryker's customer update). The company said it had no indication of ransomware or malware.
  • 19-20 March. The US Justice Department announced the seizure of four domains controlled by Iran's Ministry of Intelligence and Security, including the one used on 11 March to claim a destructive attack on a US-based multinational medical technology company; the US publicly accused Iran's government of operating Handala (TechCrunch, NBC News).

The group claimed data theft, reported as 50 GB in some accounts (HIPAA Journal); larger device and data figures circulating online are not verified. The incident disrupted operations in 79 countries (HIPAA Journal), and NHS England tracked disruption to the supply of medical equipment and consumables for UK hospitals.

How the attackers got in

The technical details come from sources familiar with the incident, not from Stryker, which has not confirmed them: a compromised administrator account, a newly created global administrator account, then Intune wipe commands. That is "living off the land": no malware to detect, just the company's own management tools used against it. Palo Alto Networks' Unit 42, which Stryker engaged for threat hunting and forensics, said it found no unauthorized activity after 11 March and that the immediate risk to the operational environment was mitigated (HIPAA Journal).

Two details matter for any business reading this. First, device management is admin access: whoever can reach the MDM console can wipe every enrolled device, including employees' personal phones if BYOD is enrolled. Second, the attack needed no exploit at all: valid admin credentials were enough. That is the same pattern as the October-November 2026 fridge attacks in European supermarkets, where attackers changed defrost settings through internet-exposed admin interfaces with valid logins.

What it cost, and what Stryker said after

Stryker said the incident materially affected first-quarter 2026 earnings and cut its full-year sales outlook from as much as 9.3% growth; the exact financial figure was not disclosed (HIPAA Journal). Stryker emphasized that its connected, digital and life-saving products remained safe to use and that patient-related services were not disrupted (SEC 8-K). By early April the company reported its global manufacturing network fully operational (Vascular News). At the AdvaMed MedTech Conference in October 2026, incoming CEO Spencer Stiles shared what the attack taught the company about communication and resilience during a crisis.

The same hole, in your software

Swap "MDM console" for any admin surface and the scenario holds. What we regularly find when we take over an application:

  • An admin page or management console reachable from the internet, or reachable by a vendor or contractor account, protected only by a password.
  • Device-management or remote-access tooling (Intune, RMM, TeamViewer unattended, fridge and BMS controllers) with admin rights that nobody reviews.
  • Shared or default credentials on those consoles, including accounts created for a supplier years ago.
  • BYOD enrolled in management tooling, so a wipe hits personal phones too.
  • No monitoring of bulk changes: a mass wipe or a changed setting at 5 a.m. can go unnoticed until the damage is done.

None of this needs a nation-state budget. It needs admin access plus an absence of monitoring, which is exactly what a code audit looks for.

What we do about it, and what we don't claim

Because we host and run most of the software we build, these questions are ours. As set out on our security page:

Admin access stays off the public internet. Cluster nodes have no public IP addresses; admin tools and database access are reachable only from inside our private Tailscale network, never from the internet; public services sit behind Google's load balancer and Cloud Armor rules. That is the same "access only through a protected network" model CERT-FR recommended after the fridge attacks.

Credentials can't leak from code. They live in HashiCorp Vault and Google Secret Manager, unsealed with Google KMS, and services authenticate with Workload Identity, so there are no long-lived key files to steal and reuse.

Changes are reviewed and scanned. All infrastructure is code (Terraform) changed through reviewed pull requests; every pull request runs gosec, govulncheck and an automated security review that blocks the merge on a finding; Dependabot and a scheduled scan keep dependencies current; every release is the exact image that already ran on staging.

What we don't claim, also written on the security page: we are not SOC 2 or ISO 27001 certified (we answer security questionnaires item by item, with evidence from the systems); backups are daily snapshots kept seven days, not point-in-time recovery; and our private network keeps admin access off the internet but does not yet restrict each person to individual services.

Questions to ask this week

  1. Which admin consoles and management tools do we have, and which of them are reachable from the internet?
  2. Which vendors and contractors have admin accounts on them, and when did we last review those accounts?
  3. Are any personal devices enrolled in device management, and who can issue a wipe?
  4. If someone wiped or changed a setting in bulk tonight, who would notice, and when?
  5. Which of our systems run versions that no longer get security fixes?

If you can't answer the first two, the fixed-price audit is the right starting point: it lists each exposure with a costed fix, in two to five days.

Related: our security page, the European supermarket fridge attacks, remote access security, what the CISA KEV list means for your software, and the Railway breach.