M365 add ons are sold as simple upgrades, but almost every one carries a prerequisite: it can only be assigned to a user who already holds a qualifying base plan. Stack an E5 Compliance, an E5 Security, a Teams Phone, or a Power BI Pro add on onto a user whose base does not qualify, and the add on is out of compliance no matter how correctly it was purchased. The reverse happens too, where estates buy a full E5 for a user who needed only a single add on capability, paying for an entire suite to obtain one feature. Microsoft reads the assignment from the tenant and maps every add on to its prerequisite. The buyer side defense reconciles each add on against its base before the auditor does, work that across the practice supports the 79% average audit exposure reduction.
The M365 catalog is layered. A base plan such as E3 or E5, or a Business Premium or a frontline F plan, sits at the bottom. On top of it sit add ons that extend a single capability: advanced security, advanced compliance, telephony, analytics, or industry features. Each add on names the base plans it is allowed to sit on. Assign it correctly and the user is licensed. Assign it to a user whose base does not qualify and the add on is non compliant, because the add on never grants the underlying rights it depends on. Stacking, in licensing terms, is the discipline of confirming that every add on rests on a qualifying base, and the absence of that discipline is what creates exposure.
M365 exposure starts with the layering, because the audit reads each add on as a dependent license that only counts when its prerequisite base is present.
An add on can be bought entirely legitimately and still be out of compliance once assigned, because compliance depends on the base the user holds, not on the purchase. An E5 Security add on assigned to an E1 user, or a compliance add on assigned to a user with no qualifying base, is non compliant from the moment of assignment. The tenant records the assignment, and the audit checks each add on against its allowed base list. The most common M365 finding is not an unlicensed user but an add on resting on a base that never qualified it.
The M365 add on catalog changes constantly, prerequisites shift between releases, and the same capability can be obtained through several different paths at very different prices. That complexity is not accidental, and it works in Microsoft's favor at audit. Estates assemble their add on stack over years of incremental purchases, nobody holds the full prerequisite map, and the assignment drifts. Microsoft pushes here because the mismatches are numerous, the per user values add up, and the tenant assignment data makes every mismatch easy to surface.
Most estates run a mix of E1, E3, E5, F1, and F3 bases. Add ons assigned uniformly across that mix inevitably land on bases that do not qualify them. A security or compliance add on rolled out tenant wide will sit correctly on the E3 and E5 population but be non compliant on the E1 and F1 users who lack the qualifying base. The audit isolates exactly those users.
The reverse error is just as costly. Estates that needed a single E5 capability, such as advanced compliance or telephony, sometimes bought full E5 for the affected users rather than the matching add on on top of their existing E3. The user is compliant but the estate is overspending substantially. The reconstruction surfaces this overspend as a savings opportunity, not a finding, but it matters just as much to the cost position.
Frontline F1 and F3 plans carry strict use limitations and a narrower set of qualifying add ons than the enterprise bases. Estates that assigned enterprise grade add ons to frontline users, or that used F plans for workers whose actual usage exceeded the frontline scenarios, carry exposure on both the base and the add on. The audit tests frontline usage against the plan limits as well as the add on prerequisites.
Beyond mismatches, stacking creates duplication. An add on bought standalone may already be included in a higher base a user holds, so the estate pays twice for the same entitlement. A user on E5 who is also assigned a security or compliance add on that E5 already includes is double licensed for that capability. The reconstruction maps what each base already contains against the add ons layered on top, and removes the overlaps. This is the same entitlement mapping discipline the practice applies in the broader audit defense review, where included rights are netted against separately purchased licenses before any number is accepted.
Some add ons reach into adjacent product families, and their prerequisites are easy to miss as a result. Defender plans, analyzed in detail under Defender licensing gaps, attach to specific bases and protect specific workloads, so a Defender add on on the wrong base leaves the workload uncovered. Power BI Pro and Premium Per User similarly assume a base and a usage pattern. Because these add ons span security, analytics, and telephony, the prerequisite map is wider than a single product team usually tracks, which is exactly why the mismatches accumulate.
The defense posture is to pull the full assignment from the tenant and reconcile every add on against its prerequisite base and against what that base already includes. Mismatches are corrected, duplications are removed, and overspend where a full suite was bought for one feature is converted to the right add on. Establishing the correct stack on the buyer's evidence is what prevents the auditor from pricing every mismatch at the highest remedy.
The reconstruction pulls the full M365 license assignment per user from the tenant and builds, for each user, the base plan held and every add on layered on top. Each add on is checked against its allowed base list and against what the base already includes, so mismatches and duplications are both surfaced.
The output is a per user stack map that answers the M365 portion of any data request with the customer's own assignment data, framed against the prerequisite rules, rather than leaving the auditor's mismatch list unchallenged.
With the stack mapped, the remediation moves add ons onto qualifying bases or removes them, strips duplicated entitlements a base already includes, and converts any full suite bought for a single feature into the matching add on on the existing base. Frontline assignments are aligned to plan limits.
The renewal is the moment to rationalize the base and add on mix across the whole estate. The EA renewal framework sets the base plan distribution and the add on structure so the stack stays compliant and lean through the term.
The practice runs an M365 stack engagement that reconciles every add on against its base and what that base includes into a defensible and rationalized position across the estate.
The engagement produces a documented M365 position covering each user, the base plan held, every add on layered on top, the prerequisite compliance of each, and any duplication or overspend. The position is the basis for any compliance review and the foundation for the M365 commercial structure at the next renewal.
Three questions that recur once the stack mapping begins.
Because compliance depends on the base the user holds, not on the purchase. An add on extends a qualifying base; it never grants the underlying rights itself. If the add on is assigned to a user whose base is not on its allowed list, the add on is out of compliance from assignment regardless of how it was bought. The tenant records the assignment, and the audit checks each add on against its prerequisite base.
Because an add on bought standalone may already be included in a higher base the user holds. A user on E5 assigned a separate security or compliance add on that E5 already contains is double licensed for that capability. The reconstruction maps what each base includes against the add ons layered on top and removes the overlaps, which usually converts directly into recovered spend rather than a compliance finding.
Rarely. A uniform E5 estate is compliant but almost always overspent, because many users need only one or two E5 capabilities that a targeted add on on their existing E3 would deliver far more cheaply. The right answer is a deliberate base and add on mix sized to what each population actually uses. The reconstruction produces that mix, and the renewal is where it is locked into the commercial structure.
The worksheet the practice uses to reconcile every M365 add on against its prerequisite base and against what that base already includes, with the duplication and overspend tests built in.
Two analyst calls. We map every base and add on across the estate, reconcile each add on to its prerequisite, and remove the duplication while it is still recoverable. Full audit defense practice.