The Defender family is one of the most confusing parts of the Microsoft estate because the products are easy to turn on and hard to license correctly. Defender for Endpoint, for Office 365, for Identity, for Cloud Apps, and for Cloud each have distinct requirements, distinct plan tiers, and distinct rules about which users and workloads must be covered. The platform will happily protect machines and mailboxes that were never licensed, and it will protect them well, which is exactly how the gap forms. Microsoft reads the protected population from the tenant and the security telemetry, then maps it against the Defender entitlements actually owned. The buyer side defense reconstructs the protected estate against the licensed entitlement before the auditor frames the gap, work that across the practice supports the 79% average audit exposure reduction.
Defender is a brand covering a family of separate security products, and that single name is the root of most of the confusion. Defender for Endpoint protects devices and comes in two plans. Defender for Office 365 protects mail and collaboration and also comes in two plans. Defender for Identity, Defender for Cloud Apps, and Defender for Cloud protect identity, SaaS usage, and cloud infrastructure respectively, each on its own model. Some are included in E5 or in the security add on suites; others are standalone. The license requirement attaches to the users or workloads protected, and because activation is so easy, the protected population almost always grows past the entitlement that was bought for it.
Defender exposure starts with separating the products, because each is licensed on its own terms and the audit reconciles each against a different population.
Defender is built to deploy fast. An endpoint onboards with a script, a policy extends Office protection to every mailbox, and identity or cloud app connectors light up across the tenant. None of these actions checks entitlement at the point of activation, so a security team protecting the estate, doing exactly the right thing operationally, can protect far more users and devices than the license covers. The protected population is recorded in the security portal, and the audit reads it directly, which means the gap between protected and licensed is precise rather than estimated.
Security teams are rewarded for breadth of coverage, and Defender makes breadth trivial to achieve. That operational pressure to protect everything collides with a licensing model that requires a matching entitlement for every protected user or workload. Microsoft pushes here because the products are sticky and high value, the protected populations are large, and the security telemetry gives the auditor an exact count without any of the reconstruction effort an on premises product would require.
Defender for Endpoint and for Office 365 each split into Plan 1 and Plan 2, with Plan 2 carrying the advanced hunting, investigation, and automation features. Estates that own Plan 1 entitlements but use Plan 2 capabilities are under licensed on the difference. The audit examines which features are actually in use against the plan owned, and a Plan 2 capability running on a Plan 1 entitlement is a finding even when every user is otherwise covered.
E5 and the E5 Security add on include specific Defender products at specific plan levels, but not all of them, and not always at the top plan. Estates assume E5 covers everything Defender, extend protection accordingly, and discover that a product or plan tier they relied on was never included. The audit maps the E5 inclusions against the protection in use and isolates whatever sits outside the included set.
Protecting servers with Defender is licensed differently from protecting user devices. Server coverage runs through Defender for Servers under Defender for Cloud, metered per server resource, not through the user based endpoint plans. Estates that onboarded servers under the user endpoint model carry exposure on every protected server, and the audit separates server protection from user device protection to count it correctly.
Several Defender products carry a coverage requirement: if the capability is used in the organization, the eligible user or workload population must be licensed, not just the subset actively monitored. This prevents licensing only the users a team chooses to watch while the capability protects everyone. Estates that licensed a pilot population and then left protection running tenant wide carry exposure across the full eligible population, not the pilot. The reconstruction establishes the true eligible population so the coverage rule is satisfied deliberately rather than discovered at audit, the same population logic applied across the broader audit defense review.
Defender plans bought as add ons carry the same prerequisite logic as any M365 add on: they attach to qualifying base plans and protect defined workloads. A Defender add on assigned to a user on a non qualifying base, or layered on top of a base that already includes it, repeats the stacking errors covered under add on stacking. Reading the Defender position therefore means reconciling both the protected population and the base plan each protected user holds, because a gap can come from the protection outrunning the license or from the license resting on the wrong base.
The defense posture is to read the protected population from the security portal and reconcile it against the Defender entitlements owned, product by product and plan by plan. Plan 1 versus Plan 2 usage is tested, E5 inclusions are netted, server protection is separated, and the coverage requirement is established against the true eligible population. Building the real position on the buyer's evidence is what prevents the auditor's protected count from standing as the only number.
The reconstruction pulls the protected device and user population from the Defender portal, the protection policies in force, the feature usage that distinguishes Plan 1 from Plan 2, and the server protection running under Defender for Cloud. Each is reconciled against the Defender entitlement owned, including what the base plans already include.
The output answers the Defender portion of any data request with the customer's own security telemetry, framed against entitlement and the coverage rule, instead of leaving the auditor's protected count unchallenged.
With the protected estate reconstructed, the remediation aligns Defender entitlements to the population actually protected, upgrades Plan 1 to Plan 2 only where Plan 2 features are genuinely in use, moves server protection to the correct Defender for Cloud model, and confirms every add on rests on a qualifying base.
The renewal is the moment to set the Defender position deliberately, deciding which products belong in the base, which as add ons, and which plan tier each population needs. The EA renewal framework structures the security stack so protection and licensing stay matched through the term.
The practice runs a Defender coverage engagement that reads the protected estate and reconciles it against entitlement, product by product, into a defensible position.
The engagement produces a documented Defender position covering each product, the protected population, the plan tier in use, the server protection model, and the base plan prerequisites. The position is the basis for any compliance review and the foundation for the security commercial structure at the next renewal.
Three questions that recur once the coverage mapping begins.
No. E5 and the E5 Security add on include specific Defender products at specific plan levels, but not the entire family and not always at the top tier. Server protection under Defender for Cloud, and some advanced capabilities, sit outside the E5 inclusions. The reconstruction maps exactly what the held base plans include against the protection actually in use, so the gap is whatever protection runs beyond the inclusions.
Yes, and it is the most common Defender finding. Onboarding does not check entitlement, so a security team can protect more devices and users than the license covers while doing exactly the right thing operationally. The protected population is recorded in the portal and the audit reads it directly. The fix is to reconcile the protected estate against entitlement and align the licenses to the true protected population before the auditor frames the gap.
Server protection runs through Defender for Servers under Defender for Cloud, metered per server resource, while user devices are covered by the user based endpoint plans. The two models are separate, and onboarding servers under the user endpoint model leaves them outside the correct entitlement. The reconstruction separates server protection from user device protection so each is counted under its own model rather than blended into a single number.
The worksheet the practice uses to reconcile the protected estate against Defender entitlement, with the plan tier tests, E5 inclusions, server model, and coverage rule built in.
Two analyst calls. We read the protected population across every Defender product, reconcile it to entitlement and the coverage rule, and close the gaps while they are still cheap. Full audit defense practice.