Securing the Administrative Layer: What the Stryker Cyberattack Has Taught Us

In March 2026, the medical technology company Stryker Corporation experienced a major cyberattack that highlighted the risks around critical infrastructure [source]. The attack was claimed by the hacker group Handala and caused a global network disruption that reportedly wiped or disabled around 200,000 corporate and personal devices across 79 countries.

Stryker’s stock dropped by about 4%, and the company had 56,000 idle employees for some time. For organizations dealing with modern cyber threats, this attack shows how legitimate management tools can be exploited and turned against a company’s own systems.

The Problem: Abusing Privileged Administrative/Management Tools

The details of the Stryker attack revealed a significant issue in traditional security architectures. This was not an attack involving utilizing a bug or using malware, but rather a high-impact operation where attackers utilized legitimate native tools already present and used by Stryker.

Specifically, the attack began by compromising credentials for Stryker’s Microsoft Entra ID (an IdP used by Stryker) through phishing. After the attackers gained administrative access, they were able to utilize Microsoft Intune, which is a tool used to manage security policies and remotely wipe lost or stolen devices.

By using Intune, the attackers managed to issue a mass remote wipe command. Because the command originated from a trusted platform, traditional endpoint detection and response (EDR) tools did not flag the command, as the action appeared to be a legitimate request. The results were catastrophic:

• Handala wiped clean more than 200,000 devices, including laptops, servers, and mobile devices, in minutes.
• The group claimed to have exfiltrated 50 terabytes of critical data, potentially including sensitive research information.
• Login screens were defaced with Handala's logo and propaganda.

The attack also affected patient safety since it disrupted Stryker’s Lifenet, a system used by emergency medical services to transmit electrocardiogram data to hospitals during cardiac events. Following the attack, the system became non-functional across most of Maryland, forcing emergency responders to revert to radio consultations. Importantly, this attack demonstrated that patient safety can be affected through a cyberattack on a vendor without a single hospital network being directly breached.

Regulatory Directives

Foreseeing that such scenarios can happen, governments and regulators are increasing cybersecurity requirements for organizations that operate critical infrastructure. Since nowadays a cyberattack affecting a single technology provider can disrupt entire industries, operational resilience is of top priority.

In Europe, for example, key frameworks include the NIS2 Directive and the Digital Operational Resilience Act (DORA). These regulations require organizations to manage cyber risk, protect their supply chains, and maintain strong incident responses and business continuity plans.

Similarly in the United States healthcare organizations must follow HIPAA to safeguard sensitive patient data, and many U.S. organizations adopt the NIST Cybersecurity Framework to guide risk management, incident response, and system resilience.

Together, these directives/frameworks show that organizations must assume that administrative accounts can be compromised and design systems that prevent a single privileged account or management platform from causing large-scale disruption.

The Solution: Building a Digital Embassy with Fortanix

The Stryker attack provides a case study for the issues and failures these directives/frameworks were designed to prevent. To meet the demands of such directives, organizations must move away from implicit trust in administrative consoles and adopt a "digital embassy" model where security is enforced by hardware, isolated from the vulnerabilities of the host network.

Fortanix Confidential Computing (CC) and the Data Security Manager (DSM) provide the foundation to address the specific failure points exploited in the Stryker attack:

• Enforcing quorum approval: To satisfy resilience requirements, Fortanix allows organizations to configure destructive actions, such as a mass wipe, to require quorum approval [https://support.fortanix.com/docs/users-guide-account-quorum-policy ] (multi-admin approval). This ensures that a single compromised account cannot be acted alone. In addition, the command logic is executed within a hardware-secured Trusted Execution Environment (TEE) that cryptographically requires signatures from multiple authorized parties before any command is released.
• Securing administrative secrets: The Stryker attack succeeded because high-level credentials were left unguarded. Fortanix DSM ensures that administrative secrets and cryptographic keys are stored in FIPS 140-2 Level 3 HSMs. This prevents attackers from extracting the underlying tokens required to weaponize management platforms like Intune.
• Protecting data in use: By using CC, organizations protect sensitive administrative sessions even while they are being processed in memory. This addresses the core requirement of regulations like DORA to protect data "in use," ensuring that even if an attacker manages to compromise the host operating system, they cannot see or modify the data within the TEE.

Conclusion

The attack on Stryker demonstrates that in a period of active geopolitical conflict, relying on a single login credential to protect a global infrastructure is an unacceptable risk. By adopting the Fortanix Confidential Computing Platform, enterprises can transition to a model where security is enforced by hardware, not just software policies.

This "digital embassy" approach ensures that mission-critical systems remain operational, secure, and fully compliant with NIS2, DORA, HIPAA, NIST, regardless of the threats targeting the administrative layer.