The most important lesson from the Stryker incident isn't encryption. It's what happens when identity and endpoint management infrastructure — Entra ID, Intune, Conditional Access — become the attack surface itself.
In March 2026, Stryker went dark.
Manufacturing halted. Customer communications were disrupted. Global operations ground to a stop. And while early coverage reached for the familiar frame — "another ransomware attack on a major corporation" — the details that emerged told a different, more unsettling story.
There was no encryption. No ransom note. No demand.
Instead, early reporting suggests the incident involved a destructive identity-plane attack targeting the management infrastructure organizations depend on to respond to incidents. Security researchers at Sygnia, analyzing available public information, focused specifically on Entra ID and Intune as attack vectors in their assessment of the management plane compromise pattern.
That distinction matters enormously to anyone running Microsoft 365, Entra ID, and Intune.
Most organizations built ransomware recovery plans. Far fewer built identity recovery plans.
When the Attack Surface Is Your Recovery Tool
Traditional ransomware is disruptive because it encrypts your data. The recovery path is legible: restore from backup, rebuild systems, negotiate or don't. The adversary is in your data plane. Catastrophic — but comprehensible.
What the Stryker incident appears to represent is something different: a management plane compromise. Not your data — your ability to manage, configure, and recover your devices and identities.
Think about what Entra ID, Intune, and Conditional Access actually do in a modern enterprise:
- Device enrollment and compliance enforcement
- Conditional Access — who gets in, from where, under what conditions
- Configuration profile and application deployment
- MFA policy and privileged identity management
- The trust relationship between every managed endpoint and your tenant
Now consider what happens when Conditional Access, Intune compliance, and device trust become unreliable simultaneously. Organizations can lose:
- VPN access
- Administrative access to managed endpoints
- Endpoint management and configuration delivery
- Device enrollment and re-enrollment capability
- Remote remediation capability
All at the same time. That is the blast radius of an identity-plane attack — and it has nothing to do with encrypted files.
When the management plane is the attack surface, your ransomware recovery plan doesn't help you. Because the tools you built that plan around are part of the failure.
No Encryption. No Ransom Note. Still a Global Outage.
A threat actor with sufficient privileges in your tenant doesn't need to encrypt anything. Based on public reporting, adversaries executing an identity-plane attack can issue device wipe commands at scale, revoke sessions, invalidate Conditional Access baselines, and destroy the trust relationships between on-premises infrastructure and the cloud — triggering Entra ID recovery scenarios that most organizations have never rehearsed.
The operational paralysis that follows a management plane compromise can be more severe than ransomware — because the Intune recovery and Conditional Access recovery paths are less understood. Most organizations have a backup strategy. Fewer have thought through what it means to rebuild a device trust fabric from scratch while the business is stopped.
As we covered in MFA Isn't Enough: How AiTM Phishing Steals Microsoft 365 Sessions, the authentication layer is already a mature attack surface. The Stryker incident suggests the management layer beneath it is next.
Organizations built ransomware recovery plans. The Stryker identity-plane attack is a signal that identity recovery planning needs the same investment.
What Your Microsoft Environment Actually Depends On
Before you can build a real identity recovery plan, you need an honest map of operational dependencies. Here's what most Microsoft-heavy organizations haven't fully documented:
Device trust chain. If Entra ID is the attack surface in a management plane compromise, hybrid join trust may be invalidated. Windows Hello for Business credentials may not work. The device shows as enrolled — and untrusted. What's the Entra ID recovery path?
Admin access paths. If your admin accounts live in Entra ID and Entra ID is compromised, how do you get back in? LAPS covers local admin on endpoints. What's your Tier-0 offline path for tenant-level identity recovery?
Conditional Access dependencies. CA policies that enforce compliant devices and block legacy auth are excellent posture decisions — until your compliance baseline is poisoned by a malicious policy change. A fleet marked non-compliant simultaneously is a Conditional Access recovery scenario that locks everyone out.
Break-glass accounts. You probably have two. When did you last test them? Are they excluded from every Conditional Access policy that could block them? Are the credentials stored somewhere that doesn't depend on the systems you're recovering?
Entra Connect / hybrid sync. If your on-premises AD is the blast-radius boundary and Entra Connect is actively syncing into a compromised cloud tenant, you may be propagating the failure upstream — turning an identity-plane attack into a full management plane compromise.
What to Validate Now
An identity-plane attack or management plane compromise doesn't have to be catastrophic if your recovery architecture is solid. These are the five things worth validating before an incident surfaces the gaps:
- Break-glass account validation — sign-in tested within the last quarter, with documented proof, exclusions verified across all CA policies
- Conditional Access recovery review — every admin path explicitly excluded and audited; no assumed exclusions
- Emergency admin path isolation — offline credentials, split custody, FIDO2 hardware keys stored physically separate from managed systems
- Critical Intune configuration export — documented baselines for compliance policies, configuration profiles, and enrollment settings so Intune recovery starts from a known state
- Identity recovery procedure test — at least one tabletop or drill where primary identity systems are assumed unavailable; who does what, in what order, with what tools
If any of these prompts "I think so" instead of a definitive yes, that's the gap most likely to become the bottleneck during an actual Entra ID recovery or Conditional Access recovery event.
What a Real Identity Recovery Architecture Looks Like
1. Tier-0 isolation. Microsoft's guidance on emergency access accounts is more specific than "printed in a safe." You need two cloud-only accounts — never federated, never synced from on-premises AD. For at least one, use a FIDO2 hardware security key stored in a physically secure offline location (corporate safe, safe deposit box). For password-based accounts, use split custody: divide the credential between two or more senior administrators so no single person holds complete access. Both accounts must be explicitly excluded from every Conditional Access policy — not assumed excluded, verified. Any sign-in from either account should trigger an immediate alert. Validate the accounts can actually authenticate on a regular cadence — most organizations discover breakage during a drill, not an incident.
2. Offline admin paths — tested, not assumed. Not "we have LAPS." Last-quarter tested, with results written down. There's a meaningful difference between assuming an Intune recovery path works and knowing it does.
3. Conditional Access recovery audit. Every service account, break-glass account, and emergency admin path should be explicitly named in CA exclusion groups. Not assumed present — verified on a schedule. This is the single most common gap in Conditional Access recovery planning.
4. Device trust recovery runbook. If every managed device lost its Entra registration tomorrow, what's step one? Who executes it? How long per cohort? Has anyone rehearsed it? Our breakdown of real-world FIDO2 coexistence and recovery flows covers the TAP-based identity recovery path in detail — the same mechanics apply in a management plane compromise.
5. Intune dependency mapping. Which operations fail if Intune is unavailable for 24 hours? 72 hours? Most organizations find the answer — when they actually map it — is more than they expected.
The Question Worth Sitting With
The Stryker incident — if public reporting accurately reflects what occurred — isn't a story about a company getting unlucky with ransomware. It's a preview of an identity-plane attack class that's been developing for years: now mature enough to trigger global operational paralysis without encrypting a single file.
Your defenses were built for ransomware. Your recovery plans were built for ransomware. Your tabletop exercises were built for ransomware.
The organizations that weather the next wave are building identity recovery plans — not just data recovery plans. Management plane compromise, Entra ID recovery, Conditional Access recovery, Intune recovery: these aren't edge cases anymore.
The question worth asking this week:
Can you rebuild when your management plane is part of the failure?
If the answer is "I'm not sure" — that's the gap worth closing before it becomes the incident to manage.
Concerned your organization isn't ready for a destructive identity-plane attack or management plane compromise? Schedule an Identity Recovery Readiness Assessment.
The Intune Pros helps organizations harden Microsoft endpoint environments — including break-glass architecture, Conditional Access recovery planning, Entra ID recovery architecture, and Intune dependency mapping.
Want more patterns like this?
Get the full 6-part guide — what Intune doesn't tell you, but you'll hit in production.
Running into this in production? 30 minutes — I will tell you directly if it is worth fixing.
Book a Fit Call →