So your CISO walked in on Monday morning, read about Stryker's 200,000 devices getting wiped by Iranian hackers, and now wants to rip out Intune immediately. Sound familiar? You're not alone. That Reddit thread blew up because it hit a nerve—every security team using Microsoft's ecosystem just got a massive wake-up call. The question isn't whether your boss is overreacting (spoiler: they're not entirely wrong). The real question is: what do you do about it?
I've been in those meetings. The panic is real, but knee-jerk reactions can create more problems than they solve. Let's break down what actually happened with Stryker, whether ditching Intune is the right move, and—if you do decide to move—how to do it without creating a security nightmare of your own.
The Stryker Incident: What Actually Happened (And What It Means)
First, let's get the facts straight, because the headlines didn't tell the whole story. In early 2026, Stryker Medical—a major healthcare equipment manufacturer—suffered a devastating attack. Iranian state-sponsored hackers compromised their Microsoft 365 tenant, gained administrative access to Intune, and remotely wiped approximately 200,000 devices. This included corporate laptops, tablets, and critically, BYOD iPhones that employees used for work.
But here's what most reports missed: this wasn't just an Intune problem. It was a perfect storm of several failures. The attackers used sophisticated spear-phishing to compromise administrator credentials. Once they had those keys to the kingdom, they had access to everything—email, files, and device management. Stryker's architecture, with everything in Azure and web hosting on AWS, created what security folks call a "monoculture risk." One breach, total devastation.
What should scare you isn't the specific tool. It's the pattern. Your CISO is right to be worried about your people falling for spear-phishing. They probably will. The question becomes: how do you architect your systems so that one successful phish doesn't mean game over?
The Single-Vendor Dilemma: Convenience vs. Resilience
Microsoft's ecosystem is incredibly seductive. One login. One admin panel. One bill. The integration between Azure AD, Intune, Defender, and Office 365 creates efficiency that's hard to walk away from. But that efficiency comes at a cost—what security professionals call "blast radius."
When everything's connected, compromise one component and you potentially compromise them all. The Stryker attack demonstrated this brutally. The admin credentials that managed email also managed devices. There was no segmentation, no separation of duties at the infrastructure level.
This isn't a Microsoft-specific problem, by the way. You'd face similar risks with Google's ecosystem or Apple's Business Manager if you put all your eggs in one basket. The real issue is architectural, not vendor-specific.
That said, Microsoft's market dominance makes them a particularly attractive target. Nation-state actors invest significant resources finding vulnerabilities in Microsoft products precisely because so many enterprises rely on them. When they find a way in, the payoff is enormous.
Should You Actually Leave Intune? A Realistic Assessment
Before you start migrating 50,000 devices to a new platform, let's ask the hard question: is leaving Intune actually the right solution?
In my experience consulting with enterprises post-Stryker, I've seen three types of reactions. The first group panics and wants to rip and replace immediately. The second group does nothing, assuming "it won't happen to us." The third—and smartest—group uses the incident as a catalyst for meaningful security improvements.
If your entire security posture relies on "don't get phished," you've already lost. Phishing works. It will always work. The goal shouldn't be preventing every phishing attempt (impossible), but limiting the damage when one inevitably succeeds.
For many organizations, the better approach isn't abandoning Intune, but implementing additional controls around it. Think about privileged access management (PAM), conditional access policies that require multiple authentication factors for sensitive actions, and segmentation that separates device management from other administrative functions.
But if your CISO has made up their mind, or if your risk assessment genuinely calls for diversification, let's look at what alternatives actually work in 2026.
Top MDM Alternatives in the Post-Stryker Landscape
The Reddit thread asked specifically: "What MDM software do you use right now?" Based on hundreds of conversations with security teams this year, here are the platforms getting serious consideration:
Jamf for Apple-Only Environments
If your organization is heavily Apple-based (or moving that way), Jamf remains the gold standard. Their security model differs significantly from Intune's, with more granular controls over Apple-specific features. The trade-off? You'll need separate management for Windows and Android devices. For mixed environments, this means managing multiple consoles—which actually provides some of that segmentation security teams now crave.
VMware Workspace ONE (Now part of Broadcom)
Workspace ONE offers what many are calling "defense in depth" for device management. Its access controls can be configured independently of your identity provider, creating that crucial separation between "who users are" and "what they can do to devices." The Broadcom acquisition created some uncertainty, but their 2026 roadmap shows renewed investment in security features specifically designed to address Stryker-like scenarios.
Hexnode MDM
Here's one that kept coming up in those Reddit comments. Hexnode provides a cloud-based MDM that's vendor-agnostic. It doesn't try to be your identity provider or your email platform—it just manages devices. This simplicity appeals to teams wanting to avoid the "monoculture" problem. Their pricing is transparent, and they support every major platform.
ManageEngine Mobile Device Manager Plus
For organizations with existing ManageEngine investments, this offers integrated management without going all-in on Microsoft. Their on-premise option appeals to highly regulated industries where cloud-only solutions raise compliance concerns. The interface isn't as polished as Intune's, but the security model is fundamentally different—and sometimes, different is what you need.
The Hybrid Approach: When Two MDMs Are Better Than One
Here's a strategy gaining traction among security-conscious enterprises: run two MDMs simultaneously. Before you dismiss this as too complex, hear me out.
You keep Intune for day-to-day management—application deployment, compliance policies, the routine stuff. Then you implement a second, more specialized MDM for critical security functions: remote wipe, encryption enforcement, and high-risk device actions.
The second MDM lives in a completely separate environment. Different admin accounts. Different authentication. Different network paths. An attacker who compromises your Microsoft tenant can't touch your wipe capabilities. They'd need to breach an entirely separate system.
Yes, this adds complexity. Yes, it costs more. But compare that cost to recovering 200,000 wiped devices. Suddenly, the math looks different.
I've seen this implemented successfully with Intune handling Windows devices and Jamf managing Apple products, with both systems configured so critical security functions require approval from both platforms. It's not for every organization, but for high-value targets, it's worth considering.
Practical Migration Strategy: How to Move Without Breaking Everything
If you decide to move away from Intune, do it right. I've seen migrations rushed after security incidents, and they almost always create more vulnerabilities than they solve.
Phase 1: Pilot with Low-Risk Devices
Start with test devices. Then move to a single department that doesn't handle sensitive data. Monitor everything. Look for gaps in policies, applications that break, user complaints about functionality. This phase isn't about speed—it's about learning what you didn't know you didn't know.
Phase 2: Implement Parallel Management
During transition, keep both MDMs active. Enroll devices in the new system while maintaining their Intune enrollment. This gives you a rollback option if something goes wrong. It also lets you compare policies side-by-side to ensure you're not losing security capabilities in the move.
Phase 3: Segment by Risk Profile
Don't migrate everyone at once. Move your highest-risk users first—executives, IT admins, finance teams. These are the most likely targets for sophisticated attacks, so they benefit most from the new security model. Then move department by department, learning and adjusting as you go.
Throughout this process, document everything. What works, what breaks, how users react. This documentation becomes invaluable for training and for justifying the migration to stakeholders.
Common Mistakes (And How to Avoid Them)
Based on what I've seen in the field, here are the pitfalls that derail most post-incident migrations:
Mistake 1: Focusing only on the MDM. Remember, Stryker wasn't just an MDM breach. It was an identity breach that led to an MDM breach. If you migrate to a new MDM but keep the same weak identity management practices, you haven't solved the real problem.
Mistake 2: Underestimating application dependencies. Modern applications often have deep ties to specific management platforms. Your custom line-of-business app might rely on Intune APIs for licensing or updates. Test every critical application during your pilot phase.
Mistake 3: Forgetting about BYOD. Those personal iPhones that got wiped at Stryker? They're often an afterthought in migrations. But they're exactly what attackers target—less secured, more vulnerable devices with access to corporate data. Your migration plan must include BYOD with clear communication to users about what's changing.
Mistake 4: Neglecting training. Your help desk needs to support the new system. Your security team needs to understand its capabilities and limitations. Your users need to know what's different. Budget time and resources for training, or you'll create a security gap through confusion.
The Human Element: Your Biggest Vulnerability (And Defense)
Let's return to your CISO's concern: "Our people will fall for spear-phishing if targeted." They're absolutely right. Technical controls matter, but humans remain both the weakest link and the first line of defense.
No MDM migration should happen without a corresponding investment in security awareness. But not the boring, checkbox-compliance training most organizations use. I'm talking about continuous, engaging, realistic training that actually changes behavior.
Simulate attacks. Send fake phishing emails that match current threat actor techniques. When employees click (and they will), provide immediate, constructive feedback. Make reporting suspicious emails dead simple and positively reinforce those who do.
Consider implementing a phishing simulation campaign through security specialists on Fiverr if you don't have internal resources. The cost is minimal compared to a breach.
Also, think about physical security resources. I always recommend Yubico YubiKey 5C NFC hardware security keys for administrative accounts. They're not perfect, but they make credential theft significantly harder.
Conclusion: Beyond the Knee-Jerk Reaction
The Stryker breach exposed a fundamental tension in modern enterprise security: the convenience of integrated platforms versus the resilience of segmented systems. Your CISO's concern is valid, but the response should be strategic, not reactive.
Whether you stay with Intune, migrate to another platform, or implement a hybrid approach, the goal remains the same: limit the damage when (not if) attackers get in. That means segmentation. It means privileged access controls. It means assuming breach and architecting accordingly.
Don't let fear drive your decisions. Let risk assessment. Evaluate your actual threat model, your regulatory requirements, your technical capabilities. Then build a device management strategy that protects what matters most—your data, your operations, and your ability to recover when things go wrong.
The tools matter, but they're just part of the picture. The real security comes from how you use them, how you connect them, and how you prepare your people for the attacks that will inevitably come.
