Migrating from SentinelOne to Microsoft Defender for Endpoint, the right way

In our previous article we explained why a MITRE score doesn’t tell the whole story about Defender. This time we look at the field: an industrial customer of ours is running a Zero Trust pilot, removing SentinelOne from its devices and moving them to Defender, Intune and a full set of hardening policies, as part of a wider Microsoft 365 security project.

We’ll cover why organizations switch, the process step by step, and what to check so any gap in protection stays short and covered.

Why organizations switch

The first reason is almost always money: organizations on Microsoft 365 E5 (which includes Defender for Endpoint) or Business Premium (which includes Defender for Business) already pay for Microsoft’s EDR, and pay for another EDR on top. But cost is only part of it.

• ASR rules don’t work alongside another product. With a third-party antivirus installed, Defender Antivirus switches to passive mode, and ASR rules aren’t enforced at all. You lose the strongest preventive layer in Windows.
• No link to access. The risk level Defender calculates for each device can block access through Intune and Conditional Access. Defender feeds the device’s risk level into Intune compliance natively, with no extra connector or product.
• Two consoles, two stories. The SOC sees the endpoint in one product and identities, email and cloud in Microsoft’s portal. After the move to Defender, it all lands in the same incident.
• Core vulnerability management is included. Software inventory, vulnerabilities and recommendations come from the same agent, with no extra tool. Advanced capabilities need an add-on.

What the migration looks like in practice

The key principle: don’t switch the whole organization in one day. Build a pilot group in Entra ID, assign all the new policies to it, and move devices gradually. Here’s how it works at this customer:

1. Prepare in advance. All pilot policies are built in Intune and assigned to a dedicated device group. Production devices keep their current policies until they move.
2. Remove SentinelOne. Uninstall the agent with the passphrase from the SentinelOne console, then restart. On Windows 10 and 11, once the other product is gone, Defender Antivirus switches back to active mode automatically.
3. Add to the pilot group. The device joins the group and gets every policy automatically: Defender for Endpoint onboarding, antivirus settings, ASR rules, BitLocker, firewall and security baselines. Until Intune applies them, Defender Antivirus is already active with default settings.
4. Handle exceptions as groups. A device that needs inbound RDP or ping goes into a separate group with the right firewall rule, instead of opening it for everyone.
5. Check after 2–4 hours. In Intune the device should be compliant with settings in Succeeded. In the Defender portal the antivirus should be active and the risk level low or medium at most.
6. Escalate after 8 hours. If something still isn’t right, the project team looks at the device by name.

The route Microsoft recommends is coexistence: onboard devices to Defender for Endpoint with Defender Antivirus in passive mode alongside the existing product, configure everything, and only then remove the old product. In this pilot we chose the direct route, with a small group and a check on every device. Coexistence suits organizations that want both products running together, at the cost of a longer in-between phase.

What to check before and after removal

Most migration problems don’t come from Defender itself but from things forgotten along the way. These are the points we check in every project:

What you get after the move

In this pilot, replacing the EDR is really the opening for full endpoint hardening. Every device that moves gets these layers, all managed from one place in Intune:

• OS and app hardening: Microsoft security baselines for Windows, Defender for Endpoint, Microsoft 365 Apps and Edge.
• Active antivirus and EDR: Defender Antivirus in active mode, tamper protection and Defender’s configuration recommendations.
• ASR rules: in audit for now, on the way to block after the impact check.
• Encryption and firewall: managed BitLocker and firewall rules, with exceptions by group.
• Local passwords: local account lockout after 10 failed attempts.
• Limits on local AI agents: a dedicated baseline (in preview) that restricts AI tools running on the device, an increasingly important topic.
• Risk-based compliance: a device counts as healthy only if it has a password, Secure Boot, TPM and active antivirus, and its Defender risk level is medium at most. A device that falls out is blocked from company resources.

That last point is the heart of it: after the move, what Defender sees on the device directly affects what the user can access. That’s Zero Trust in practice.

The bottom line

Moving from SentinelOne to Defender for Endpoint saves paying twice, but its real value is what it unlocks: ASR rules that work, consistent hardening from Intune, and access that depends on the device’s actual state. The key is a staged process: a pilot group, clear checks on every device, and production only once everything is stable.

Sources

• Microsoft: Migrate to Defender for Endpoint from non-Microsoft endpoint protection
• Microsoft: Migrate to Defender for Endpoint, phase 3: onboard
• Microsoft: Defender Antivirus compatibility with other security products (active and passive mode)
• Microsoft: ASR rules requirements
• Microsoft: Mobile Threat Defense integration with Intune