Microsoft Defender is no longer a single product. It is a family covering Endpoint, Office 365, Identity, Cloud Apps, Cloud workloads, IoT, and External Attack Surface Management. Most enterprises buy Defender three different ways at once: bundled inside M365 E5, attached through the E5 Security add on, and as standalone Defender SKUs for workloads that sit outside M365. The result is a security line that is consistently over licensed and under deployed.
Defender is the umbrella brand for what used to be Advanced Threat Protection, Microsoft Cloud App Security, Azure Defender, and Azure ATP. Microsoft consolidated the brand. The licensing did not consolidate at the same pace, which is the buyer side problem.
The user based Defenders are licensed per user and follow the M365 estate. They appear inside E5, inside E5 Security, and as standalone subscriptions for organizations that want endpoint or identity protection without the full M365 commit.
Defender for Cloud is consumption billed at the Azure subscription level rather than per user. It protects servers, databases, storage, containers, and Key Vault. Several plans exist within the umbrella and they are not bundled in any M365 line.
Most of the Defender stack you need is already entitled inside M365 E5. The next most common purchase path, the E5 Security add on, exists for organizations on E3 that want the Defender stack without stepping up to full E5. Knowing which line entitles which workload is the precondition to negotiating either.
M365 E5 already bundles Defender for Endpoint Plan 2, Defender for Office 365 Plan 2, Defender for Identity, and Defender for Cloud Apps. Buyers on E5 should not be paying Defender twice.
The E5 Security add on attaches to E3 and entitles the same four Defender user based SKUs, plus Entra ID P2. It is the standard step toward E5 functionality for organizations not ready to commit the full bundle.
Each Defender user based SKU can be purchased as its own subscription. Most relevant for organizations running Office 365 rather than M365, or for frontline populations on F SKUs that need Defender attach.
The Defender stack is unusual in how often the licensing is fully paid and the deployment is partial. The shelfware is rarely about unwilling users. It is about telemetry not configured, integrations not built, and analyst capacity to consume the signal that was never funded.
Defender for Identity needs sensors on domain controllers and a configured identity infrastructure to produce signal. We routinely find E5 estates where the SKU is fully entitled and zero domain controllers report sensor data, which means the buyer paid for the feature and the SOC has no view into identity threat. This is the single most common Defender shelfware pattern we see.
Defender for Cloud Apps shows a similar pattern. The CASB capability requires connectors to each sanctioned SaaS application, log ingestion from edge devices, and policy authoring. Most deployments cover three or four applications, often M365 only, while the licensed entitlement covers the whole SaaS estate.
Defender for Cloud workload plans bill against the Azure subscriptions they cover. Buyers enable Defender for Servers Plan 2 organization wide as a default. We find subscriptions covered that hold a handful of low value VMs or dev test workloads, and the workload billing runs against them anyway. The fix is selective enablement, not blanket activation.
External Attack Surface Management is a separate Defender line with its own asset based pricing. Buyers who already pay for asset inventory and external scanning through a third party tool are commonly billed twice. The buyer side question is whether the Microsoft signal materially adds to what already exists.
The Defender conversation at renewal is rarely about the unit price on each SKU. It is about which entitlement path the estate sits on, which populations actually need which Defender plan, and where workload protection should be activated selectively rather than estate wide.
The economic case for E5 over E3 plus add ons usually hinges on Defender attach. We model the step up against the actual Defender plans the security organization will operate, not against the marketing bundle. The result is a population specific recommendation. Knowledge workers on E5, frontline on F3, contractors on E1 plus targeted Defender for Endpoint Plan 1 standalone.
Modeling the Defender attach this way is the same diagnostic that surfaces the EA renewal position. The Defender line and the M365 line do not negotiate independently.
The Defender SKU stack reshapes faster than most Microsoft product lines. SKUs are renamed, plans are split, features are moved between plans. The buyer side response is contractual rather than commercial. Future use language covering Defender equivalents, capped uplift on renamed Defender SKUs, and the right to swap between user based and workload based plans where appropriate.
The buyer keeps Defender flexibility for the contract term. Microsoft does not get to reprice the security line by renaming the SKU stack mid contract.
The Defender engagement runs in parallel with the M365 step up modeling. The deliverable is a population segmented Defender attach plan, a workload scoped Defender for Cloud activation, and a contract that prevents forced repricing as Microsoft reshapes the SKU stack.
We pull telemetry on which Defender plans are actually producing signal into the SOC, which sensors and connectors are configured, and where the licensed entitlement is wider than the deployed footprint. The output is a population by population recommendation for Defender plan attach across the next contract term.
The diagnostic surfaces the over license that exists today and the targeted attach that should replace it. In most engagements the result is fewer dollars spent on Defender, not more, because the estate stops paying twice for the same capability.
The renewal lands with a Defender attach plan, scoped Defender for Cloud activation against the workloads that warrant it, and contract language that survives Microsoft renaming or splitting the Defender stack. The mechanism is pre approved expansion rights at originally contracted unit pricing on the user based and workload based plans.
The result is a security line priced to consumption rather than to marketing bundle. The CISO keeps the capability the program of record requires. The CFO stops paying for capability the organization is not consuming.
The diagnostic surfaces where E5 entitlement is duplicated by separately purchased Defender add ons, where Cloud Apps and Identity are licensed but not deployed, and where workload protection runs blanket activation instead of scoped enablement. We deliver the position that takes Defender into the renewal.