On March 11, 2026, Stryker woke up to roughly 200,000 devices that had stopped working.
An Iran-linked threat group had stolen credentials for Stryker's Microsoft Intune console, the mobile device management (MDM) platform used to control endpoints across their organization. The attack itself was trivial to execute. Single command. The Intune wipe function, a feature every MDM administrator has access to, was used to remotely brick servers, desktops, laptops, and smartphones across nearly 80 countries. Twelve petabytes of data destroyed, fifty terabytes exfiltrated. No malware required.
Paramedics temporarily lost the ability to transmit ECG data from ambulances, reverting to verbal radio reports while transporting patients. The financial impact is still being calculated. Six class action lawsuits are pending because employee-owned phones enrolled in Stryker's MDM program were wiped along with company assets. Stryker's stock fell more than 3% on the news.
The thing is, Stryker did most of it right. Their incident response was textbook. Hour-by-hour updates for their clients and the industry, immediate triage, transparent communication. That is exactly what good incident response looks like. The failure was narrower and more instructive: standard username-and-password credentials protecting a console capable of wiping every device in their global infrastructure.
Before I get into what manufacturers should take from this, let me set some context on where FDA cybersecurity requirements for medical devices stand right now.
The FDA's first premarket cybersecurity guidance circulated in 2013. Seven pages. Nobody treated it as a hard requirement. A postmarket guidance followed in 2016, also largely advisory in practice.
In 2023, Congress gave the FDA formal authority to define and enforce cybersecurity requirements for medical devices under Section 524B of the Food, Drug, and Cosmetic Act. The premarket guidance that followed is now over 70 pages. That progression from seven pages to seventy is not just a word count difference. It reflects the degree of specificity the FDA now expects from manufacturers of connected and software-enabled devices.
The division of medical device cybersecurity (DMDC) now handles all cybersecurity reviews on premarket submissions. These are specialists, not general reviewers with peripheral security knowledge. They do this every day, and the quality of their technical questions reflects real depth. I work with them regularly. If you were counting on vague responses getting by a reviewer who did not know what to look for, that window has closed.
One thing I want to address directly: the cybersecurity requirements do not scale down. I hear arguments to the contrary every week without fail. A software-enabled device that poses low patient safety risk still has to satisfy every cybersecurity requirement in the premarket guidance. Company size does not factor in, and neither does device risk class. The only qualifier is software. If your device has software, the full set of requirements applies. I onboarded a new client last week who told me they did not have to do cybersecurity on their previous device. If they are referring to a submission before 2023, that may be accurate. The situation today is entirely different.
Ignoring cybersecurity until late in development does not make the requirement go away. It makes it painful and expensive to address. For SaMD teams in particular, where development cycles are fast and architecture decisions lock early, this is a compounding risk. And as the Illumina case showed recently, the consequences extend beyond submission delays. A nearly $10 million settlement with the Department of Justice over misrepresentation of cybersecurity in their systems is now on the record. The DOJ was involved, not just the FDA. Think about what every subsequent Illumina submission will look like under that kind of scrutiny.
When you submit through eStar, the FDA's electronic submission portal, the moment you indicate your device has software, 14 cybersecurity documentation requirements turn on. All of them, without exception, without scaling.
The list includes a cybersecurity risk assessment, a software bill of materials (SBOM) in machine-readable format (CycloneDX or SPDX JSON), a security architecture description, a cybersecurity controls report with sections the FDA specifies in detail, and a cybersecurity testing report. The SBOM in particular has taken on new significance. The FDA is now actively loading submitted SBOMs into monitoring tools to track ongoing vulnerability disclosures. If a component in your device gets a new CVE after clearance, expect to hear from them about it.
The cybersecurity testing report that goes into eStar is a summary. Behind it sit multiple rounds of actual test reports covering static application security testing (SAST), penetration testing, fuzz testing, and others. The FDA asks for the page numbers of specific sections in your controls report when you submit. That level of specificity is the new normal. For teams working through premarket submission documentation, cybersecurity artifacts need to be planned from day one, not assembled at the end.
Start this early. The comment I make to every client is the same: if you come to me early, we will get along great. If you tell me you want to ship next Tuesday, you are going to dislike every conversation we have. The teams that handle this best are usually the ones that have their quality system built for pre-market development from the start, where cybersecurity artifacts, risk records, and design controls live in the same place rather than getting assembled from separate spreadsheets at the end.
The reason timing matters so much is hardware. Threat modeling can reveal that a microcontroller you have already committed to cannot support the cryptographic operations your architecture requires. An implantable device with battery constraints may have hardware that was designed before modern encryption standards were the expectation. There is no software fix for insufficient CPU bandwidth or memory. If you discover this during submission prep, you are looking at an architecture redesign. If you discover it during early threat modeling while the design is still open, you make a different chip selection and move on.
Threat modeling is an umbrella term that covers several different processes, but the most valuable form for most teams is what is called STRIDE per element. You build a system diagram showing all components and their interactions, then systematically analyze each element for spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege vulnerabilities. This is not a freeform brainstorm. It is a structured process, originating with Microsoft, that derives a comprehensive list of potential vulnerabilities from the design choices you have made.
A mobile app that uses SQLite in plaintext is a design vulnerability, not an implementation bug. Threat modeling surfaces it. You made a conscious architectural choice that created exposure, and catching that kind of issue at the design stage costs far less than catching it after first silicon.
The FDA also requires five additional forms of threat modeling covering supply chain, manufacturing, deployment, updates, and decommissioning. These are more process-oriented and catch issues in how you handle the lifecycle of the device rather than its architecture. They matter, but they are downstream of the design threat model in terms of priority and timing.
Cybersecurity risks are ultimately software risks, and they belong in your risk management process under ISO 14971 alongside other hazards. Treating threat modeling as a separate compliance exercise, disconnected from your design history file and risk management file, is how teams end up with duplicate documentation and gaps that reviewers find during submission.
Everyone is discussing Stryker as an organizational attack. And that is correct as far as it goes. But the lesson most manufacturers are missing is the one that applies directly to their own devices.
Roughly half the manufacturers I work with have MDM tools built into their medical device infrastructure. Not for their company's internal IT infrastructure, but for the kitted assets that are part of their medical device system. When you provide a tablet to a surgeon for use during an implant procedure, that tablet needs to be monitored, updated, and patched by you as the manufacturer. When you kit a laptop for a physician, you are responsible for that device's security posture for its entire operational life. Not until end of support. Not until end of life. For as long as you are in business and that device is in the field.
The tool you will likely use to manage those assets is an MDM, and that MDM is now part of your device's attack surface.
Are you hardening those kitted assets before they go out? Are you thinking about them as endpoints on your attack surface? Do you have controls on your MDM console that would prevent what happened to Stryker? Most manufacturers have not asked these questions because they have been treating kitted devices as off-the-shelf components they buy and ship. That is not how the FDA categorizes them, and it is not how attackers think about them.
Stryker's specific technical failure was credential-based. Their MDM console was protected by standard username and password authentication. Credentials were harvested, the console was accessed, and the wipe command was executed. No other technical sophistication was required.
The mitigations are not complicated, but they require deliberate implementation:
Of those controls, hardware security keys and multi-admin approval for destructive actions are the most effective by a significant margin. Monitoring is valuable but reactive. The combination of strong authentication and approval requirements for high-impact operations is what would have prevented what happened to Stryker.
A question I get regularly: does a device that was already cleared under older requirements need to be brought up to current cybersecurity standards?
The answer is that touching a legacy device is enough to trigger a full cybersecurity review. A manufacturer I worked with, a few years before submissions became as stringent as they are today, changed only the smartphone model that shipped with their implantable drug infusion system. The implant did not change. The bridge did not change. The app ran on the new phone without modification. They filed a supplemental.
The FDA came back with dozens of cybersecurity questions: authentication between the bridge and the implant, integrity controls, encryption. There were more than 4,000 of those pumps already implanted in patients. The FDA's position was that they could not allow continued use of a system that did not meet current cybersecurity standards, regardless of the fact that nothing about the pump itself had changed.
If you have a legacy device with software components, especially one built on older microcontrollers that predate modern cryptographic capabilities, talk to a cybersecurity expert now. The answer may be that a path exists through limited modifications, or that the architecture needs to be redesigned from scratch. Either way, learning that later is worse than learning it now.
Post-market guidance from 2016 gives manufacturers 30 days to notify affected parties after discovering a vulnerability and 60 days to begin rolling out a patch or workaround. Those time frames were already out of date when they were published. Today, the window from vulnerability disclosure to working exploit in the field is measured in minutes. Artificial intelligence has accelerated that timeline significantly, and it was already down to hours before AI got involved.
The FDA does not expect 100% remediation of every device in the field. They understand that is not achievable. They do expect that you are actively pushing updates and that the coverage curve is climbing. If remediation is taking more than six months, the FDA is likely to step in with a mandatory Class 1 recall and will scrutinize whether you were moving aggressively enough.
Reporting to the FDA does not happen immediately. You notify affected parties at the 30-day mark, which is when the FDA becomes aware of the situation. The formal documentation of what you did and how goes into your annual submission. But do not mistake the reporting timeline for the response timeline. Those are different clocks.
For SaMD companies operating under IEC 62304, post-market cybersecurity obligations connect directly to your software maintenance process. A vulnerability discovered in a third-party library you are using is a change event with a full lifecycle: assessment, design, implementation, verification, and release. Teams that treat cybersecurity patching as an informal hotfix process will not survive a regulatory audit of their post-market activities.
Cybersecurity has always been an engineering problem. What has changed is the regulatory expectation, the enforcement infrastructure, and the threat landscape. The teams that clear premarket submissions without cybersecurity deficiency letters are almost uniformly the ones that engaged cybersecurity expertise before their design was locked. The teams that discover problems at submission have a harder and more expensive road ahead.
Stryker's incident happened to one of the largest medtech companies in the world. Their MDM console had standard credentials. An attacker used that console's own wipe function to destroy operations across 80 countries. The attack vector was not sophisticated. The impact was enormous.
For a manufacturer shipping kitted devices or managing endpoints in the field, that attack surface is part of your device system. The question is whether you are treating it that way.
If you are building out your cybersecurity and software compliance process, these related guides go deeper on the specific components: