The digital landscape for medical technology is a high stakes environment where availability equals patient safety. On March 11, 2026, this reality was brought into sharp focus when Stryker Corporation disclosed a massive disruption to its global internal networks and Microsoft systems. The incident left thousands of employees locked out of corporate systems and rendered a significant portion of their device fleet inoperable. While the company initially reported no signs of traditional ransomware or malware, the operational impact was just as severe.
The Anatomy of the Stryker Incident
The timeline of the attack reveals a surgical strike rather than a broad infection. Before the official SEC filing, reports from within the organization indicated that managed devices were being wiped remotely and login pages were defaced with logos of threat actors. Open source intelligence suggests the attackers did not need to deploy a complex wiper malware payload. Instead, they weaponized the existing management infrastructure. By compromising high privileged credentials, the perpetrators utilized Microsoft Intune to issue legitimate remote wipe commands across the organization.
The persona claiming responsibility, Handala, alleged that this was a destructive operation tied to geopolitical tensions in Iran. While Stryker has been cautious in verifying these claims, the pattern is pretty clear. This was not a breach of a perimeter but an abuse of trust within the cloud management plane. The attack vector was essentially “living off the land” at the administrative level, turning a tool meant for security and compliance into a weapon of mass deletion.
The Conventional Wisdom: Multi Admin Approval
In the wake of the incident, the immediate industry reaction is often to implement stricter governance. Microsoft provides a feature known as Multi Admin Approval, which requires a second authorized administrator to sign off on high impact operations like remote wipes or bulk policy changes. On paper, dual approval helps protect against human error. But as a side effect it also ensures, no single compromised account can trigger a catastrophic event.
For many organizations, this is the “golden bullet” solution. The logic is simple: if Admin A is compromised and tries to wipe 1,000 laptops, Admin B will see the request and deny it. However, as an experinces security engineer, I argue that this approach is fundamentally flawed and often provides a false sense of security.
Why Multi Admin Approval is Security Theater
| Limitation | Explanation |
|---|---|
| Implicit Trust Between Admins | If the attacker controls two admin accounts (or one compromised admin and a co‑admin that blindly approves), the multi-approval policy offers no protection. Reddit’s sysadmin thread notes this exact failure mode. r/sysadmin |
| Operational Overhead | Small or mid‑size companies often have only 2–3 admins. Requiring a second approval can stall urgent patches, leading to business‑process friction rather than security gains. |
| Human Error & Social Engineering | Admins may approve changes based on ticket titles (“Urgent wipe”) without reviewing the underlying request. This mirrors QA reviews that are bypassed in high‑pressure environments. |
| Defensive Depth Mismatch | The multi-admin policy sits at a service policy level, but does not enforce device‑level validation or MFA for each change, resulting in a single point of failure. |
The heavy reliance on a second approver introduces several avenues of failure that are often overlooked in high level policy discussions. First, there is the issue of operational labor. For small to mid sized companies, requiring two senior engineers to be available and attentive for every bulk change is an unsustainable tax on productivity. This leads to “approval fatigue.”
Second, this does not constitute a true defense in depth strategy. It moves the vulnerability from a technical exploit to a psychological one at best. In most corporate environments, implicit trust relationships govern administrative actions. When Admin B receives a notification that Admin A has requested a wipe, they rarely perform a full review of why that request was made. Instead, they check their ticketing system or Slack history. If there is a linked ticket or if Admin A is known to be working on a project, Admin B will likely click “Approve” without hesitation.
The Failure of Blind Trust in Multi Admin Approval
Explanation:
The attacker only needs one compromised admin. The second admin, trusting the ticket system, approves without verifying device legitimacy or MFA status—similar to the flaw exposed by the Stryker incident.
Moving Beyond Identity: The Case for Device Trust
If we accept that user identity can be compromised and human approval is fallible, where does the real defense lie? The answer is shifting from a purely user based identity model to one that incorporates Certificate Based Device Identity.
Currently, most organizations focus on the “Who” (User + MFA). But in a high privilege environment, we must also validate the “What” (The Device). A compromised admin credential is often used from an attacker controlled machine or a virtual private server. Even with MFA, if the session token is stolen via Adversary in the Middle (AiTM) or Push Fatigue attacks, the attacker has full access.
A more effective solution is to enforce a Conditional Access policy where administrative changes can only be initiated from a known, corporate managed device that possesses a hardware backed certificate stored in a TPM (Trusted Platform Module). By binding the administrative session to a specific physical asset, you create a barrier that is significantly harder to bypass than a just second admin account approval.
In this model, Intune would not just ask “Is this Admin A?” it would ask “Is this Admin A, and are they using their assigned, encrypted, and compliant workstation with a valid device certificate?” If the request comes from an unknown IP or a device without the proper certificate, the request is blocked regardless of whether the user has the correct password and MFA token.
Note: Microsoft Entra has flexible options for implementing Certificate based Authentication (CBA), but so does many of the most common Identity Providers like Keycloak, Authentik, Okta, OneLogin, and Auth0.
Secure Architecture via Intune Device Trust Security
Explanation:
- The admin logs in and must pass MFA.
- Entra/IdP verifies the device’s certificate before allowing policy changes.
- Only certificates issued by a trusted CA are accepted, tying the request to a known device.
Strategic Recommendations for Enhanced Defense
To prevent a repeat of the Stryker scenario, organizations should move away from relying solely on human checkpoints and implement a technical hardware root of trust.
- Implement Conditional Access Policies that require compliant devices for all administrative roles. This ensures that only managed devices can access the Microsoft Endpoint Manager console.
- Transition to Phishing Resistant MFA, such as FIDO2 security keys, to eliminate the possibility of session hijacking and AiTM attacks that bypass standard TOTP or push notifications.
- Audit the “Remote Wipe” permission specifically. Not every global admin needs the ability to wipe devices. Use Privileged Identity Management (PIM) to ensure that wipe capabilities are only active for a limited window and require a documented justification.
- Establish an immutable log of all MDM commands shipped to a separate, read only security information and event management (SIEM) system. This prevents attackers from clearing their tracks after initiating a destructive command.
The Stryker attack serves as a warning that our most powerful management tools are also our greatest liabilities. While multi admin approval is a step in the right direction, it is an administrative band aid on a technical wound. By integrating device trust and certificate based identity into the core of the access policy, we move from a model of implicit trust to one of verifiable cryptographic trust. Security should not rely on whether Admin B is paying attention today; it should rely on the mathematical impossibility of an attacker spoofing a hardware backed certificate from a managed device.