Microsoft 365 Add-On Costs: Evaluation Framework

Add-ons are the licensing equivalent of supermarket impulse buys. Each one looks reasonable in isolation, none of them feel expensive on their own, and the total at the till is always a surprise. Microsoft's add-on catalogue is the most profitable shop window in enterprise IT, and most organisations walk into it without a budget.

You buy E3 because that is what enterprise productivity costs. You add Entra ID P1 because Conditional Access is non-negotiable. Then someone in security wants Defender for Endpoint P2, the identity team needs lifecycle workflows, the records manager needs Insider Risk. The leadership team has been reading about Copilot, and the comms team has just been pitched Teams Premium. Six months later the per-user cost has nearly doubled and nobody can articulate why, beyond a vague sense that all of it was probably necessary.

This post is the framework I use to stop that happening. We will map the add-on landscape, work through the compounding maths on a real-world example, walk through an evaluation framework that forces honest conversations before you sign, and finish with a PowerShell audit you can run against your own tenant to see what add-ons you are already paying for. Procurement teams will recognise this as software asset management and licence optimisation; in M365 it is inseparable from architecture.

If you have not already worked through The M365 Licensing Audit Nobody Wants to Do or Microsoft 365 E3 vs E5: Decision Framework for Architects, start there. This post assumes you have a baseline understanding of what your users are licensed for today. You cannot evaluate add-ons sensibly until you know what is already in the box.

Note on pricing: Every figure in this post is based on Microsoft list price for Enterprise Agreement customers in the UK, ex VAT, as of April 2026. Your CSP, EA, or MCA discount will move the absolute numbers. The relative comparisons and the framework hold regardless.

The Add-On Landscape

Microsoft sells more than thirty distinct add-ons that attach to E3, E5, or Business Premium (BP) tenants. Most architects can name about six of them. Here are the ones that materially change your total cost per user, grouped by what they actually do.

A user on E3 with Entra ID P2 plus Intune Suite plus Copilot is paying around £74 per month before you add a single security or compliance feature. The same user on E5 is around £55. This is the pattern I see most often: organisations buy E3 to save money, then bolt on enough add-ons that they have effectively rebuilt E5 at higher cost and lower coherence. The framework in E3 vs E5 covers when that flip makes sense. The framework in this post covers what to do when it does not.

Why Add-On Sprawl Happens

Add-on sprawl is not a procurement failure. It is a structural feature of how Microsoft sells, and how internal teams ask for things.

Add-ons are sold one team at a time. The security team gets a Defender briefing. The HR transformation team gets a Viva pitch. The records and compliance team gets walked through Purview. The CIO gets the Copilot demo. None of these conversations include the licensing team, finance, or anyone with a view of the running total. By the time procurement notices, the business case for each individual add-on has already been written and the answer is yes.

Each add-on looks cheap in isolation. £8 a month for a feature that solves a real problem is an easy yes. £8 a month times 1,500 users times twelve months is £144,000 a year, which is suddenly a project with executive sponsorship attached. Architects need to be the people who do the maths in the room before the decision is made, not after.

Microsoft's bundling strategy actively rewards sprawl. The Intune Suite, Entra ID Governance, Teams Premium, Viva Suite, and Copilot are all explicitly bundled to push customers towards a "stack" mentality. Once you own three of them the marginal cost of the fourth feels small, even when the marginal value is zero. The Microsoft account team will reinforce this with offers structured around stacking discounts.

Nobody owns deprecation. Add-ons get bought, they get rolled out to a pilot group, the pilot generates a positive-but-vague report, and the licences stay on. Five years later nobody can remember which features are in use, which are switched off, and which were only ever needed for a specific project that finished in 2023. The default state of an add-on is "still being paid for".

The result is a per-user cost that drifts upward steadily and is almost impossible to walk back without a politically unpopular conversation. The only defence is a framework that forces those conversations before the add-on is purchased.

The Compounding Maths: A Worked Example

Take a financial services client I reviewed last year, a 1,500-user organisation on E3, and walk through what add-on sprawl actually cost them. Every user started at the E3 list price of £33.10 per month, which is £595,800 per year for the base SKU.

Year one, the security team negotiates Defender for Endpoint P2, Defender for Office 365 P2, and Defender for Identity for the full estate. That is £12.80 per user per month, or £230,400 per year. The business case is sound: the organisation has had two phishing incidents and the board wants visible action. Total per-user cost is now £46.

Year two, the identity team rolls out Entra ID P2 to enable PIM and risk-based Conditional Access. P2 alone is £8.10 per user per month, but they also want Lifecycle Workflows, so Entra ID Governance gets added at £6 per user per month. That is another £14.10 per user per month, or £253,800 per year. Total per-user cost is now £60.

Year three, leadership wants Copilot. They start with 200 licences "for the executive team and their assistants" at £24.70 per user per month. That is £59,280 per year for 200 users, but a year later it has expanded to 600 users because the demand is real, taking the spend to £177,840 per year. Per-user cost on the Copilot users is now £85.

Year four, the records manager presents an Insider Risk business case. Communications Compliance follows six months later as part of the same regulatory programme. Both at £9 per user per month, applied to the full estate because nobody wants to argue about scope. That is £324,000 per year. Per-user cost without Copilot is now £78. With Copilot it is £103.

Year five, the comms team buys Teams Premium for 400 users to support all-hands events. £8.10 per user per month, £38,880 per year.

By year five, the organisation has added £826,920 per year in add-on costs to a base E3 spend of £595,800. The total bill has grown from £33 per user per month to £80 per user per month for the average user, and significantly more for the Copilot and Teams Premium subset. None of these decisions were unreasonable in isolation. None of them were ever evaluated as part of a coherent strategy. And nobody has ever revisited whether the original Defender or Insider Risk deployments are still delivering the value that justified them.

This is the pattern I see in nearly every mid-size tenant I am brought in to review. The good news is that it is fixable. The bad news is that fixing it requires a framework, and a willingness to ask uncomfortable questions.

The Evaluation Framework: Five Questions Before You Sign

Before any add-on is added to a tenant, the architect's job is to put these five questions in front of the people asking for it. If you cannot get clear answers to all five, the answer is not yet.

1. What problem does this solve, and what evidence do we have that we have it?

Vendors sell features. Buyers should buy outcomes. If the request is "we should have Insider Risk", the question is "what specific risk are we mitigating, and what is the evidence base?" If the answer is "we read about a competitor having a data leak", you do not have a problem yet, you have a fear. Fear is not a budget line.

Good answers look like this: "We have had three confirmed insider data exfiltration incidents in the last twelve months that took an average of 47 days to detect." Bad answers look like this: "It is best practice." Best practice is a phrase used when nobody has done the analysis.

2. What is the total annual cost at full rollout?

Not the per-user-per-month price. The annual cost, multiplied by every user who will end up with the licence, including the inevitable scope expansion. Double it if the request is for a pilot, because pilots that succeed expand and pilots that fail still cost money. Put that number in front of the requester and watch what happens.

This is the single most powerful intervention in licensing governance. Most requests evaporate at this step, not because the feature is unwanted, but because the requester had genuinely not done the maths.

3. Can we deliver the outcome with what we already own?

This is the build-versus-buy question framed around outcomes rather than features. Most add-on capabilities have free or in-box equivalents that are 70 percent as good. Exchange Online Protection ships with E3 and covers the basics of mail security; Defender for Office 365 P1 is a paid add-on if you need Safe Attachments and Safe Links. Conditional Access in P1 covers most realistic policy needs. Entra ID Governance Lifecycle Workflows are powerful, but for simpler scenarios a well-written Logic App and a Graph script can do the same job for the cost of an Azure consumption bill.

The honest answer is sometimes "no, we cannot do this without the add-on". That is a fine answer. But it should be the result of a deliberate analysis, not a default assumption.

4. Who owns this after deployment, and how will we measure value in twelve months?

Add-ons without owners become shelfware. If nobody is going to be accountable for "the Insider Risk programme" or "the Viva rollout" twelve months after the contract is signed, do not buy it. The owner needs to be a named person, with an explicit success metric, and a calendar reminder to report progress to the licensing review board. If you do not have a licensing review board, this is the moment to start one.

5. What is the exit plan?

The most overlooked question in M365 licensing. Every add-on contract has an end date. What happens if, in twelve months, the value is not there? Can you turn it off cleanly? Are there data retention obligations? Will users notice? Will the contract auto-renew at a higher tier? The exit plan does not need to be elaborate, but it needs to exist. "We will renew because we cannot face the project to switch it off" is how you end up paying for things forever.

Where Add-Ons Actually Earn Their Keep

The framework above is generic. Here is how I apply it across the most common add-ons I see organisations adopt.

Intune Suite

Worth it when: You have field, frontline, or specialty device populations that need MAM Tunnel, or your service desk currently uses a third-party remote support tool that costs more than £8 per user per month, or you have a clear Endpoint Privilege Management programme to retire local admin rights.

Skip it when: Remote Help is the only feature anyone has actually mentioned. The full Intune Suite is rarely the right answer if you only want one of its components: Endpoint Privilege Management is still available as a standalone SKU and is frequently cheaper at scale, while Remote Help is now bundled into Intune Plan 2 or the Suite rather than sold on its own. Advanced Analytics and Tunnel for MAM are only available via the Suite.

Entra ID P2 and Entra ID Governance

Worth it when: You have privileged access risk that PIM materially reduces, or compliance obligations (SOX, ISO 27001) that mandate access reviews and separation of duties. Entra ID Governance is genuinely powerful for organisations with high joiner-mover-leaver volumes; lifecycle workflows can replace a lot of bespoke scripting.

Skip it when: Your privileged access model is "everyone in IT is a Global Admin" because PIM does not fix bad role design, it just adds friction to it. Fix the role design first, then evaluate whether you still need PIM.

Microsoft 365 Copilot

Worth it when: You have specific, measurable productivity use cases with named owners, and you have done the data governance work to make sure Copilot will not surface things it should not. Copilot in Outlook for executive comms drafting is a defensible business case. Copilot in Excel for analysts who actually use Excel as a modelling tool is a defensible business case.

Skip it when: The business case is "everyone should have AI" or "we cannot fall behind". Copilot is expensive enough that you cannot afford to deploy it without a measurable productivity outcome, and "feeling more productive" does not count. The data governance prerequisite is also non-trivial; if your SharePoint and OneDrive estates have not been through a sensitivity labelling and oversharing review, Copilot will surface things you do not want surfaced. See Why Your M365 Tenant Is a Mess for a starting point.

Teams Premium

Worth it when: You run regular regulated meetings that need watermarking and sensitivity labels, or you host genuine large-scale Town Halls (the base Town Hall tops out at 10,000 attendees; Premium takes it to 20,000), or your service desk has measurable demand for intelligent meeting recap.

Skip it when: The business case is "the recap feature looks cool". Teams Premium is one of the easiest add-ons to buy and one of the hardest to demonstrate ROI on. Apply it narrowly, to the specific user populations who need the specific features, and resist the urge to buy it for the whole organisation.

Viva Suite

Worth it when: You have an HR transformation programme with a named owner, executive sponsorship, and a measurement plan. Viva Insights and Viva Learning can deliver real value, but only as part of a deliberate change management effort. Viva Topics was retired in February 2025 and Viva Goals end-of-service was December 2025, so the suite is narrower than older marketing material suggests.

Skip it when: HR has been pitched the suite, likes the look of it, and wants to "see what it can do". This is the most common Viva failure mode. Without a programme behind it, Viva becomes a set of dashboards that nobody opens, paid for indefinitely.

Purview Add-Ons

Worth it when: You have a specific regulatory obligation (financial services, healthcare, defence) that mandates the capability, or you have a documented insider risk pattern that needs detection. Purview is some of the most powerful tooling in the M365 stack, and also some of the most operationally expensive to run well.

Skip it when: Compliance has heard about it and wants it "for completeness". Purview Insider Risk in particular requires significant analyst time to operate; the licence is the cheap part. If you do not have the operational capacity to triage cases, the licence is wasted.

Auditing Your Current Add-On Estate

Before any of the framework above is useful, you need to know what add-ons you are already paying for and who has them. Most organisations cannot answer this question accurately without a script. Here is the one I use.

# Inventory current add-on assignments via Graph
# Delegated scopes, least-privilege. For app-only, swap Directory.Read.All
# for Organization.Read.All.
Connect-MgGraph -Scopes "User.Read.All", "Directory.Read.All"
 
# Pull the SKU catalogue for the tenant
$skus = Get-MgSubscribedSku |
    Select-Object SkuId, SkuPartNumber,
        @{n='Purchased';e={$_.PrepaidUnits.Enabled}},
        ConsumedUnits
 
# Pull all licensed users and their assigned SKUs
$users = Get-MgUser -All -Property Id, DisplayName, UserPrincipalName, AssignedLicenses |
    Where-Object { $_.AssignedLicenses -and $_.AssignedLicenses.Count -gt 0 }
 
# Build a per-SKU usage report
$report = foreach ($sku in $skus) {
    try {
        $assigned = ($users | Where-Object {
            ($_.AssignedLicenses | Select-Object -ExpandProperty SkuId) -contains $sku.SkuId
        }).Count
 
        [pscustomobject]@{
            Sku        = $sku.SkuPartNumber
            Purchased  = $sku.Purchased
            Assigned   = $assigned
            Unassigned = $sku.Purchased - $assigned
            UtilPct    = if ($sku.Purchased) {
                [math]::Round(($assigned / $sku.Purchased) * 100, 1)
            } else { 0 }
        }
    }
    catch {
        Write-Warning "Failed to process $($sku.SkuPartNumber): $_"
    }
}
 
# Interactive view. Swap for Export-Csv when running on a schedule,
# or the output disappears into the console buffer.
$report | Sort-Object UtilPct | Format-Table -AutoSize

The output will tell you two things immediately: which SKUs you have purchased but not assigned (pure waste), and which add-ons you are paying for that you may not have realised. The first time most organisations run this, they discover at least one add-on bought as part of an EA renewal that nobody internally remembers requesting.

The next step is to map those add-ons against actual usage signals. For Defender, that means checking whether the relevant policies are configured and the relevant alerts are being triaged. For Copilot, that means querying the Microsoft Graph reports API for active usage per user. For Viva, that means looking at the Insights dashboard adoption metrics. The pattern is always the same: licence assignment is necessary but not sufficient evidence of value.

The Decision Matrix

The framework can be collapsed into a single matrix that I pin to the wall when running licensing reviews.

Any red answer means the add-on does not get bought yet. Three or more amber answers means it goes back for more analysis. Five greens means it goes through the licensing review board for approval. This is not bureaucracy for its own sake; it is the only way I have found to keep the add-on bill from drifting upward by 10 to 15 percent every year for reasons nobody can later defend.

Getting Started

You will not fix add-on sprawl in a single sprint. You will fix it by establishing a repeatable process and applying it consistently. In order:

1. Run the audit script. Get a current inventory of what you own and what is actually assigned. Find the orphaned licences first; those are the easy wins.
2. Pick one add-on to evaluate seriously. Not the most expensive, not the most contentious. Pick one with a clear owner and run it through the five-question framework as a worked example for your team.
3. Establish a licensing review board. Monthly is fine. Membership is architecture, security, finance, and a rotating business representative. Every new add-on request goes through it. Every existing add-on gets reviewed annually.
4. Document the exit plans. For every add-on you currently own, write down what would have to happen to switch it off cleanly. Most organisations have never thought about this. The exercise is uncomfortable and useful.
5. Build the audit into your monthly reporting. The script above can run on a schedule and email a delta report. Drift detection on licence assignments is one of the highest-value, lowest-effort governance controls you can implement.

If you want a deeper structural fix, this is exactly the kind of capability that belongs in a configuration-as-code pipeline. Licence assignment via group-based licensing, group membership via lifecycle workflows or scripts, and a Git-tracked record of every change. That is the long road. The short road is the audit script and the review board. Start there.

The Bottom Line

If you are not prepared to push back on a Copilot request from the CIO with a worked annual cost, you are not doing solution architecture, you are doing order-taking. Add-on sprawl is not a Microsoft problem; it is a governance problem that Microsoft happens to be very good at exploiting. Every add-on you buy is reasonable in isolation; the failure mode is the absence of a coherent view across all of them. Architects are the people best placed to provide that view, because they are the only ones in the room with both the technical understanding to evaluate the features and the organisational position to ask the uncomfortable questions about value.

The five-question framework is not complicated. The audit script is not long. The decision matrix fits on a single page. What is hard is the discipline of applying them consistently, especially when the request comes from a senior stakeholder who has already been sold on the outcome. That is the job. The role exists precisely because someone needs to be the person who does the maths in the room.

Run the audit. Pick the first add-on to evaluate. Put the matrix in front of the next requester. The first time you stop a £200,000 per year add-on from being adopted because the business case did not survive five questions, you will have paid for your own salary several times over. Do it often enough and you change the culture. That is the entire game.