CyberMed
← All articles

What the Stryker Attack Actually Means for Medical Device Companies

Published Updated Andres EcheverryEditorial policy

The Stryker wiper attack exposed the gap between FDA compliance and operational resilience. Here is what medical device companies should actually do about it.

FDA compliance layer versus operational resilience layer diagram

As of March 25, 2026, the Stryker attack is still unfolding. On March 11, Stryker confirmed that an attack on its Microsoft environment had wiped employee laptops and phones. The group claiming responsibility, Handala, put the number at 200,000 devices. Stryker has not confirmed a count. Public reporting attributes the group to Iran.

Stryker says the incident is contained and that it's rebuilding wiped systems from backups predating the compromise window. Good news operationally. For the rest of the industry, the mechanism of the attack is the most important data point right now.

RAPS Regulatory Focus is asking whether this changes how FDA will think about cybersecurity requirements. The short answer is: possibly, but that's not the most important thing for device companies to focus on right now.

Most of the coverage has focused on the headline: pro-Iranian hackers, massive disruption, a major medical device manufacturer knocked offline. Here's what most coverage is missing.

This wasn't ransomware, and it wasn't a traditional wiper either

Public reporting on the incident, and CISA's March 18, 2026 alert on hardening endpoint management platforms, describe how it was done. The attackers did not need custom malware. They gained access to Stryker's Microsoft Intune environment, the same endpoint management platform most large enterprises use to manage employee devices, and used its built-in remote-wipe function against enrolled phones and computers. Stryker said it had no indication that malware was deployed.

The attack vector wasn't a vulnerability in Stryker's medical devices. It was the IT management infrastructure the company uses to keep its fleet compliant and patched. The tools designed to improve security became the weapon.

Ransomware has a logic to it. The attacker wants payment, so they need you to be able to operate well enough to negotiate and pay. There's perverse restraint built into the model.

A destructive attack has no such restraint. The goal is maximum disruption. There's no ransom demand and no negotiation window. You lose the data and the systems, and the attacker walks away with nothing except the damage itself. For nation-state actors responding to geopolitical events, that's exactly the point.

Most device companies are building their cybersecurity posture around FDA's 524B requirements: SBOMs, premarket submission documentation, postmarket vulnerability monitoring, a plan for coordinated disclosure. That's the right foundation. But 524B was written to protect patient safety from device vulnerabilities. It wasn't written to defend against an adversary who wants to wipe your manufacturing infrastructure.

FDA compliance and operational resilience are two different problems

If your regulatory affairs team has your cybersecurity documentation in order but your IT team doesn't have an incident response plan that covers destructive attacks, you have a gap. A significant one.

Stryker said the damage is contained. That means it had the incident response capability to contain it, which is exactly what most smaller device companies and SaMD startups do not have.

The companies most exposed right now are mid-sized: too large to be invisible, too small to have dedicated security operations, and increasingly connected enough to be attractive targets. Many of them have spent the last two years building out their FDA cybersecurity documentation for 510(k) submissions. That work matters. It's not the same as having an incident response plan that accounts for a wiper.

One nuance: FDA's February 2026 guidance does treat manufacturer-controlled "related systems," such as software update servers, as in scope for cyber device cybersecurity under Section 524B(b)(2). The line between device compliance and corporate IT isn't perfectly clean. But corporate laptops and phones are on the IT side of it.

What you should actually do this week

A few concrete things worth doing right now:

  1. Audit your device management platforms. If your company uses Microsoft Intune, Jamf, or any similar platform, ask whether a compromised admin credential could wipe your fleet. Most device companies have never war-gamed this scenario. Stryker just made it real.
  2. Check whether your incident response plan covers destructive attacks. Skip the boilerplate ransomware scenarios. You need a real playbook for what happens when someone uses your own IT tools against you. Our book chapter on incident response covers what that playbook should contain.
  3. Know your critical business systems and your recovery time from backup. If the answer is "we're not sure" or "weeks," that's the gap to fix.
  4. Don't treat your FDA submission as your security strategy. The two overlap, but your submission package won't protect you from a compromised endpoint management environment. Your security architecture will.

Having your FDA documentation in order does not protect you from litigation if your internal IT practices fall short. An administrative access control problem in a corporate Microsoft environment is not a device vulnerability FDA reviews, but it is exactly what plaintiffs and regulators examine after an incident. Every risk review, every deferred patch, and every skipped control becomes discoverable.

That's the scenario smaller device companies should be thinking about.

The readiness question

We built CyberMed's readiness assessment to help device companies understand where they stand against FDA's 524B requirements. That's still the right starting point for most clients.

But the Stryker attack is a reminder that the compliance floor is just that: a floor. What happens after your submission clears is a different conversation, and more companies should be having it now, before an incident forces it.

If you haven't looked at your cybersecurity posture recently, our readiness assessment is a fast way to see where the gaps are. Fourteen questions, about three minutes, with a score and specific recommendations.

Need help with incident response planning or medical device penetration testing? Email us at info@cybermed.ai.

Sources

Frequently asked questions

›What happened in the Stryker cyberattack?

On March 11, 2026, Stryker confirmed an attack on its Microsoft environment that wiped employee laptops and phones. Public reporting attributed it to an Iran-linked group that used the remote-wipe function in Microsoft Intune. Stryker said it had no indication malware was deployed and believed the attack was contained.

›Was the Stryker attack a medical device vulnerability?

No. The attack vector was the company's IT endpoint management infrastructure, not its medical devices. That is why FDA's Section 524B documentation, which addresses device cybersecurity, would not have prevented it.

›Does FDA compliance protect a device company from this kind of attack?

Not on its own. Section 524B and FDA's February 2026 guidance address device and related-system cybersecurity. Protecting manufacturing and corporate IT from a destructive attack is an operational resilience problem that needs its own incident response plan.

›What should device companies do after the Stryker attack?

Audit your endpoint management platform for what a compromised admin credential could do, write an incident response plan that covers destructive attacks, know your recovery time from backup, and keep your FDA submission package separate from your security strategy.