Stryker Was Wiped Through Its Own Infrastructure

Daniel Michan

Follow Smallstep

Stryker wasn't hit with ransomware, tens of thousands of devices across 79 countries were wiped using its own trusted tools.

One compromised credential and access to a legitimate admin console led to tens of thousands of devices being wiped across 79 countries. No malware, no exploit, just the system doing exactly what it was told to do.

TL;DR

On March 11th, 2026, an Iran-linked group reportedly used Stryker's own Microsoft Intune console to remotely wipe tens of thousands of devices around the world. They didn't break in through some complex vulnerability or deploy ransomware. They used a compromised admin credential through a normal management channel.

The fallout was immediate and life-threatening. Surgeries were delayed, hospitals couldn't order necessary equipment, and Stryker filed an SEC 8-K.

What made this possible wasn't some exotic attack technique or AI phishing scheme. It was a much simpler issue. The system had no reliable way to tell the difference between a real admin sitting at a trusted workstation from an attacker using valid credentials from somewhere else.

That's the issue, and it's a bigger deal than most teams realize.

Where It All Begins to Fall Apart

Most identity systems are built to answer one question really well: who is this?

They're much less reliable when it comes to answering a second, equally important question: where is this request coming from?

In environments like Stryker's, access decisions are often based on things like user credentials, MFA, and device posture signals. Those signals can be helpful, but they're still just signals. They can be replayed, proxied, or inherited in ways that make an attacker look legitimate.

So when a valid admin credential shows up, the system tends to assume everything else checks out too.

In this case, that assumption is what opened the door to the attack.

Why MFA and Conditional Access Didn't Stop It

Based on public reporting, MFA wasn't consistently enforced on the admin account involved. That alone is a serious issue, especially for something with that level of control.

But even if MFA had been in place everywhere, this type of attack is still not fully addressed.

Modern phishing attacks don't necessarily try to bypass MFA. Instead, they capture the session after MFA has already been completed. From that point on, the attacker is effectively operating inside a valid session.

Conditional Access adds another layer of protection, but it's still relying on device-reported information like OS version, encryption status, or enrollment. Those checks can be useful, but they don't definitively prove that the request is coming from a specific, known piece of hardware.

So the system ends up validating a real user and what appears to be a compliant device, without actually proving that the device itself is legitimate.

What Actually Happened

The attackers gained access to an administrative credential and used Stryker's Intune console to issue a mass remote wipe.

There's no indication that malware was deployed or that any software vulnerability was exploited. The tools involved were the same ones Stryker's IT team uses every day.

Reports also suggest that the credential may have been weak, static, and in some cases not protected by consistent MFA. Multi-admin approval controls were reportedly not enabled either.

The attack didn't require much beyond obtaining valid credentials and using them through the intended administrative interface at the right time.

The Real Impact

Stryker isn't just another enterprise, they manufacture medical equipment that hospitals rely on every day around the globe.

When systems went offline, the impact reached directly into clinical environments. Hospitals reported delays in surgeries, and ordering systems for equipment and replacement parts were disrupted.

This wasn't about financial gain or ransom demands -- the group that claimed responsibility is reportedly linked to Iranian state interests and appears to have been focused solely on disruption.

The most concerning part of all of this is how little effort it may have taken to create that level of impact.

The Underlying Issue

At its core, this wasn't a failure to detect something unusual. It was a failure to enforce a stronger boundary.

The system trusted a session because the credentials were valid, but it had no way to verify the physical device behind that trusted session.

That leaves a critical question unanswered: Is this request coming from a device we actually issued and still control?

In many environments today, the honest answer is still "we think so" and that kind of assumption is unacceptable.

The Reality for Many Organizations Today

This isn't unique to just Stryker -- a lot of organizations today look like this without even realizing the risk.

For example, admin access can often be initiated from any device that appears compliant, management tools are centralized with the ability to take action across an entire fleet, and the same credentials may work across both on-prem and cloud environments. Add in BYOD devices sitting in the same scope as corporate systems and privileged access that isn't tied to a specific piece of hardware, and you end up in a place where one compromised credential can have an outsized impact.

The Benefits of Being Able to Actually Trust The Device

This is where the model really shifts.

Instead of asking a device to report on itself, you require it to prove itself cryptographically using hardware-backed keys stored in something like a TPM or Secure Enclave. With ACME Device Attestation, that proof is tied to a specific physical device that has been enrolled and is still under your control.

So even if someone has valid credentials, they can't use them from an unknown or unmanaged machine, so access doesn't even start.

From a user perspective, nothing changes, there are no extra prompts or steps, the device handles the proof automatically. From a security perspective, it removes a major source of ambiguity and answers a question most systems still can't: is this request coming from a device we actually trust?

It's also worth being clear about what device identity does and doesn't solve. This approach won't stop an insider already using a trusted device, and it won't protect against a device that's already been fully compromised. What it does address is the exact scenario we saw here with Stryker, a situation where a credential is valid, but the origin of the session isn't, which is a gap a lot of organizations still have today.

Security teams already put a lot of effort into MFA, PAM, and limiting access to only what's necessary, and all of that matters. Still, there's one question that often goes unanswered: can you prove that privileged access is coming from a device you actually control?

That's the gap that still exists in a lot of environments, and it's a big reason incidents like this keep happening.

The Bottom Line

The Stryker incident wasn't about sophisticated malware or a zero-day exploit, it came down to trusting credentials without fully verifying where they were being used. If your systems can't verify the device behind a login, any credential you trust can be reused by someone you don't. Closing that gap means moving beyond assumptions and requiring proof.