I've been tasked with evaluating and potentially standardizing our endpoint security across a mixed estate of Windows, macOS, and Linux servers. Microsoft Defender for Endpoint (MDE) is a logical contender, given our existing Microsoft 365 footprint. However, mapping our actual needs—file integrity monitoring, EDR, vulnerability management—to the available SKUs has been an exercise in frustration.
The core issue isn't the features, but the licensing model. The official documentation speaks in bundles: Defender for Endpoint P1/P2, which are now seemingly rolled into Microsoft 365 E3/E5, but also available standalone? Then there's the Defender for Cloud integration for servers, which introduces another dimension. Trying to get a clear answer on whether, for example, the Linux EDR component requires a specific "Defender for Cloud Plan 2" add-on for a non-Azure, on-premises server leads down a rabbit hole of "it depends" and sales conversations.
For a platform built for clarity and unified signals, the procurement and licensing path feels antithetical to that goal. I'm looking for a deterministic mapping, something like:
```
Required Capability: Linux Server EDR
Required License: "Defender for Endpoint P2" (as standalone SKU or via M365 E5)
Additional Requirement: "Defender for Cloud Plan 2" *only if* using CSPM features on Azure ARC-enabled servers.
```
But this clarity doesn't exist in public materials. Has anyone successfully navigated this to build a coherent matrix, or is the opacity a deliberate gatekeeping mechanism? I'm particularly interested in experiences from hybrid/multi-cloud environments where you've managed to avoid both over-licensing and critical coverage gaps.
—J
—J
You're absolutely right, and the Linux EDR example is a perfect one. I recently had to untangle this for a client with an on-prem VMware environment. The official answer from our Microsoft partner was that the Linux EDR feature, as part of Defender for Endpoint, indeed requires Defender for Cloud Plan 2 attached to the subscription where you're managing the servers, even if they're not in Azure. It's not in the P1/P2 datasheet. That's the hidden dependency for non-Windows OS.
The real friction comes from the bundling strategy. The "Microsoft 365" part of the SKU name implies it's for the desktop OS suite, but the server components get licensed through Cloud even when the workloads aren't cloud-based. This creates two separate procurement tracks for what the product presents as a single pane of glass.
I ended up building a spreadsheet cross-referencing features against the Azure portal's actual "requirements" pop-ups. It's the only way to get that deterministic map you're after. Would a sanitized version of that matrix be useful?
- Mike
Oh, you're looking for a deterministic mapping? Good luck with that. That rabbit hole is where all the product managers hide their actual pricing sheets.
I'd disagree on one point, though. The fuzziness isn't antithetical to their goal. It *is* the goal. Opaque bundling drives you toward the bigger SKU, which is the whole business model. Want that one feature? Gotta buy the whole security suite, even if it's licensed through a separate portal with a different name.
For your specific Linux EDR on-prem, you nailed the hidden dependency: Defender for Cloud Plan 2 on the subscription. Doesn't matter where the VM runs. The answer is always "it depends" because the real answer is "you probably need E5."
Deploy with love