Entra tiers, Defender, and Purview: what is bundled in E5, what is sold separately, and the overlap with tools you already own. Three knowledge checks along the way, and 1 clip from a senior cloud advisor.
The presenter in this session is an AI generated avatar. The curriculum and guidance are real, produced by Redress Compliance analysts from our consulting engagements and market network.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. Once in the session the frame splits and a senior cloud advisor gives the view from inside real Oracle negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome back, session twenty five of forty, and this closes module five. We have covered the Azure commitment, the server estate, Dynamics, and Power Platform. Today is security and identity, and I want to be clear about what this session is and is not. It is not a view on which controls you should run. That belongs to your security team and they are better placed than any licensing course to decide it. What this session is about is a specific and expensive fact: the same protection can be assembled several ways at very different prices, and most organisations assemble it more than once. Because security selects the controls and procurement buys the licences, and those two activities frequently happen without a shared list. Every duplicate in this part of the estate exists because both purchases were individually correct and nobody ever saw them side by side.
Five takeaways. One, four pillars: Defender, Entra, Purview, and Sentinel, each licensable inside a suite or bought alone, which is exactly where the confusion and the overlap begin. Two, Defender is a family: Endpoint, Office 365, Cloud Apps, and Defender for Cloud are separate entitlements, so a Defender licence is not one thing you either have or do not have. Three, Entra Plan 1 and Plan 2: Plan 1 sits in E3 and E5, Plan 2 sits in E5, and buying Entra separately on those seats duplicates a right you already hold. Four, the duplication rate: standalone Defender or Entra SKUs duplicated rights already inside E5 on ten to twenty five percent of seats across the engagements reviewed. Five, the E5 Security route: the E5 Security add on layers the security stack onto an E3 base, and targeted add ons moved fifteen to thirty percent against a blanket E5 upgrade.
Four pillars and many SKUs, three things that make this harder than it should be. Every pillar sells three ways: inside a suite, as an add on, or standalone, which is why the same protection can be assembled at very different prices, and why two organisations running identical controls can be paying very differently for them. Defender is four products: Endpoint protects devices, Office 365 protects mail and collaboration, Cloud Apps governs SaaS, and Defender for Cloud covers workloads, each with its own entitlement, so any conversation about buying Defender needs a second word attached to it or it means nothing. And two teams buy it: security selects controls, procurement buys licences, frequently without a shared view, and that split is the underlying cause of most overlap here. Which means nothing in the purchasing process detects a duplicate, because both purchases are individually correct. The duplicate only exists when somebody looks at both lists at once.
What sits where, and read the last column as an audit list rather than a description. Entra Plan 1 is included in E3 and E5, and gets bought standalone on seats that already hold either. Entra Plan 2 is in E5, and gets bought standalone on E5 seats, which is a straight duplicate and the cleanest test in this whole session. Defender for Endpoint Plan 2 is in E5, and gets bought standalone on E5 seats or run alongside a third party EDR. Defender for Office 365 Plan 2 is in E5, and gets run alongside a retained email gateway, which is the session twelve retirement problem. Purview advanced is in E5, and standalone compliance SKUs get bought on seats that already hold it. And Sentinel is in nothing at all, priced separately and largely on ingestion, so it is not a duplicate, it is a separate line that surprises people. Every row except that last one accounted for ten to twenty five percent of seats.
First check. Your identity team asks to buy Entra Plan 2 for three thousand users. Those users hold E5. What do you say? A, approve it, identity security is a priority. B, Entra Plan 2 is already included in E5, so this would duplicate a right those seats already hold, and the useful question is what capability they believe is missing. C, refuse it, the budget is committed. D, approve it for half the users as a compromise. Pause it. The request here is entirely legitimate, so as you think, ask yourself what would actually change if you bought it.
The answer is B. Entra Plan 1 sits in E3 and E5, and Plan 2 sits in E5, so buying Plan 2 for users who already hold E5 purchases a right they have. A is exactly how that happens in practice: a legitimate request from a team with genuine authority over the subject, approved without a licensing check, which is the split I described a moment ago doing its work. C is the wrong response to the right instinct, because refusing on budget grounds leaves the identity team believing they lack a capability they actually hold, and they will simply ask again next quarter with more urgency. D halves the waste and preserves the confusion entirely. The productive move is the second half of B, which is to ask what capability they believe is missing. Nine times out of ten the answer is that it is not deployed rather than not licensed, and that is a configuration project rather than a purchase, which is a much better conversation for everybody.
Where buyers pay twice, five overlaps in the order you will find them. Standalone on top of the suite: Defender or Entra SKUs bought separately on seats already carrying the right, which was ten to twenty five percent of seats across the engagements reviewed. Microsoft on top of a third party: E5 security features overlapped existing third party tools in one estate out of two, which is the session twelve retirement test arriving with a hard number attached. The suite bought for one capability: organisations upgraded the whole base to E5 when twenty to forty percent of users needed only one or two security capabilities. Licensed but not deployed, which is the most common finding overall and is not overlap at all, it is a capability you are paying for and not using. And Sentinel modelled separately, where ingestion costs got modelled after the security SKUs were set and surprised people. The first three are money already spent. The fourth is money spent on something nobody switched on.
Guest analyst The security licensing review I use as the standard example took about two hours to produce its main finding, and about four months to get the two lists into the same room, which tells you where the difficulty actually sits. A healthcare group, roughly twelve thousand users, and they had asked us to look at security spend because it had grown faster than anything else in their Microsoft relationship. The security team had a list of everything they had bought. Procurement had a list of every licence on the tenant. Those two lists had never been compared, not out of dysfunction, but because each team considered the other's list to be somebody else's business, which is a completely reasonable assumption to make. When we joined them, three things fell out. About two thousand seats held a standalone identity SKU on top of E5, which already carried it. A third party endpoint tool was running alongside Defender for Endpoint on the same devices, and both were configured, both were generating alerts, and the security operations team had been treating that as deliberate defence in depth when in fact nobody had ever decided it. And the largest single line was a compliance capability they had held for two years and never switched on. Now, what I want to highlight is the reaction. The head of security did not get defensive about any of it. He said, quite reasonably, nobody has ever shown me what these things cost. And that sentence is the whole problem in this area, because he was right, and it was fixable in an afternoon.
Nobody had ever shown him what the controls cost. Two lists, one room. Second check.
Check two. Twenty to forty percent of your users need one or two security capabilities. The proposal on the table is E5 for everyone. What is the alternative? A, E5 for everyone, the bundle is simpler to administer. B, targeted standalone add ons on an E3 base for that population, which delivered the required controls at thirty to fifty percent less than the full E5 step. C, no additional security, the current baseline is adequate. D, E5 for the security team only. Pause it. This is the session thirteen crossover with a specific number attached to it, so the shape of the answer should be familiar.
The answer is B. At one or two capabilities the components win, and here they won by thirty to fifty percent against the full E5 step. The blanket E5 upgrade was the most common over purchase across the estates reviewed, and A is the argument that produces it, with administrative simplicity once again standing in for a decision nobody priced. C ignores a stated control requirement, which is not procurement's call to make and which will be remembered very clearly if anything ever goes wrong. D confuses who operates security tooling with who is protected by it, and it is a surprisingly common misunderstanding worth naming: the controls protect the users, not the analysts. And there is a genuine caveat on the winning answer, which I want to state rather than bury: where a population truly needs the breadth of the stack, the bundle can beat stacked add ons. So run the arithmetic per population rather than adopting either route as a policy.
The E5 Security route, three things about the middle option, and it exists precisely for the population that needs the security stack and not the rest of E5. What it is: the E5 Security add on layers the E5 security capabilities onto an E3 base, one purchase rather than a stack of individual components, and cheaper than the full E5 step for a population that wants protection rather than the analytics and voice that come bundled with the suite. When it wins: where buyers on E5 used only a fraction of the security stack, the E5 Security add on sitting on E3 was cheaper, which is a specific measurable comparison rather than a preference, and it needs your own usage data to settle. And where it is negotiated: the enterprise agreement renewal, which is module six, so bring the population analysis to that conversation rather than discovering the option afterwards. Three routes then, not two, and you price all three per population on the same sheet.
Sentinel and the ingestion line, the one that is not per user at all. Priced on ingestion: cost follows data volume rather than seat count, so you forecast from log volume rather than from headcount, and that is a different skill from everything else in this session. Not inside E5: no suite carries it, so it is always an added line and should never be assumed covered by a security bundle. Modelled late: ingestion costs surprised buyers after the SKUs were set, so model it before the security SKUs rather than after. Volume is controllable, because what you ingest is a configuration decision, which makes table selection and retention genuine cost levers. And it behaves like consumption: it grows with activity, there is no headcount ceiling, so apply the session seventeen habits, meter it, attribute it, review it monthly. Sentinel belongs in this session because it is where a security conversation stops being about licences and becomes a conversation about consumption.
Last check. You find a capability licensed across the estate but never deployed. Is that a licensing finding? A, yes, cancel it at the next renewal. B, it is both: a cost question for procurement and a protection question for security, because you are paying for a control that is not protecting anybody. C, no, deployment is an IT matter. D, yes, and it proves the security team over specified. Pause it, and as you think, notice that two different people should care about this finding, for two genuinely different reasons.
The answer is B. This is the most common finding in this part of the estate and the one most often mishandled, in both directions. A cancels a control somebody decided was necessary, on the grounds that nobody got round to switching it on, which means a decision about risk is being taken by whoever happened to notice the cost. C hands the problem to a team that never sees the invoice and therefore has no prompt to act on it. D is the version that damages a working relationship, and it is usually unfair, because the reason a capability sits undeployed is almost always capacity rather than judgement. The right move is to take the list to the security owner with both framings attached: here is what we are paying for, here is what it would protect, deploy it or release it. Either answer is acceptable. What is not acceptable is the current state, which is paying without protecting, and framing it that way gets a much better reception.
The security licensing method, three steps, and the first one crosses a team boundary, which is the actual work. One, join the three lists: base plans, Microsoft security SKUs, and third party security tools, matched by user or by scope. Every duplicate in this estate sits at the intersection of two of those three, and no single team currently holds all three, which is why the join is the finding. Two, price three routes per population: full E5, the E5 Security add on over E3, and individual components over E3, same population, same sheet, your own rates, and expect different populations to land on different routes. Three, split licensed from deployed: for everything you hold, is it switched on, and that list goes to the security owner as a deploy or release decision, which is the fastest way to convert a licensing exercise into something the security team actually values. That closes module five.
Session twenty five, three sentences. One: Microsoft security spans Defender, Entra, Purview, and Sentinel, each sellable inside a suite, as an add on, or standalone, so the same protection can be assembled several ways at very different prices. Two: Entra Plan 1 sits in E3 and E5 and Plan 2 sits in E5, and standalone Defender or Entra SKUs duplicated rights already held on ten to twenty five percent of seats, because security selects controls and procurement buys licences without a shared list. Three: price three routes per population, full E5, the E5 Security add on over E3, and individual components, because targeted add ons moved fifteen to thirty percent against a blanket upgrade and delivered the same controls at thirty to fifty percent less for narrow needs. That completes the estate. Next session opens module six and the event where all of it gets repriced at once.
Homework, about an hour, and this week you find the duplicates. One, list the security SKUs: every Microsoft security or identity licence you hold, standalone or bundled, with seat counts. Two, join to base plans: which of those sit on seats already holding E5, and start with Entra because Plan 2 inside E5 is the cleanest test in the whole exercise. Three, list the third party tools: every security product you pay for outside Microsoft, because half of estates had an overlap there. Four, mark deployed or not: for each Microsoft capability you hold, switched on, partially, or never, and that column is usually where the surprise is. Five, take it to the security owner, and please take it as a deploy or release list with the cost of each row beside it, rather than as a savings paper, because the framing decides whether you get a collaborator or an opponent.
Five reads before next session, all free on redress compliance dot com. First, the Microsoft security licensing guide, which carries the four pillars, the SKU structure, and where buyers pay twice. Second, maximising security and compliance with E5 add ons, on the targeted add on route and what it moved against a blanket upgrade. Third, Defender for Endpoint P1 against P2, which is the single most misunderstood entitlement in the Defender family and worth twenty minutes on its own. Fourth, Sentinel licensing optimisation, for the ingestion line and the levers that control it. And fifth, Microsoft 365 add ons and duplicate cost, which is the same reconciliation applied across the wider add on estate. Next session opens module six: the renewal timeline. The twelve month programme, backwards from the notice window, and why renewals discovered at T minus sixty are already priced. See you there.