Can Microsoft 365 licence optimization be proven from assignment and usage data alone?

30-second answer

No. Two reads establish two different things. Neither of them, nor both together, establishes that removing a licence is safe.

Assignment establishes what a user holds. Usage establishes certain activity, in apps that report it, inside a window you chose. The question is it safe to remove this? is a third thing, and nothing above answers it.

What this proves

That a licence assignment exists and that some activity was or was not recorded for it. Both are facts and both are worth having.

It also proves how far a conclusion can be taken. With assignment and usage you can honestly say this assignment is a candidate for review. You cannot honestly say this licence can be removed, and the distance between those two sentences is the whole subject.

What it does not prove

• That nobody depends on it. Absence of recorded activity is not absence of need. A licence can be dormant for a quarter and carry a service plan that something else requires: a mailbox that receives, a group membership that grants access, a device policy, a retention hold, an application that authenticates as that user.
• That the activity you can see is the activity there was. Usage reports cover the apps that report usage. Nothing in them says this user did nothing; they say these apps recorded nothing for this identity in this window.
• That the figures can be attributed to a person at all. When the tenant conceals identifiable information, the reports return rows and name nobody. The activity is real and the attribution is not available.
• That a removal is reversible. Some service plans release state when unassigned. Whether a given one does is a property of the plan, not of the assignment, and it is established per plan or not at all.

PowerShell

These existing reads establish assignment and report-identifiability context, not dependency or a removal conclusion. Execute them only with authorization for the directory and the requested scopes.

# Read-only. What somebody holds.
Connect-MgGraph -Scopes 'Organization.Read.All','User.Read.All' -NoWelcome
Get-MgSubscribedSku | Select-Object SkuPartNumber, ConsumedUnits

# Read-only. Whether anything you read next can be attributed to a person.
Get-MgBetaAdminReportSetting | Select-Object DisplayConcealedNames

Example output

No tenant output is asserted here. Results depend on the directory and its reporting settings. The illustrative counts below are not output from these commands or an observed tenant.

Explanation

The three things a defensible decision needs

assignment    what this identity holds                     read, today
usage         what was recorded, in which window,          read, today
              and whether it can be attributed
dependency    what stops working if this is removed        NOT COLLECTED

Two of three is not two thirds of an answer. It is a candidate list. A decision that removes a licence rests entirely on the third, and the third is the one nobody sells you, because it is the one that requires reading what else in the tenant refers to that identity and that plan.

Why the market answer is different

Published licence-optimization claims run from ten to forty-five per cent of spend. The share of identified waste that organisations actually recover is a fraction of that, and the mechanism is not mysterious: a finding that cannot survive an argument never becomes a decision. Somebody has to sign the change, and they will be asked what happens if it is wrong.

A number produced from assignment and usage alone cannot answer that question, so it gets reviewed, doubted, and shelved. The saving was never real; only the report was.

What an honest surface says instead

Counts bound to what was established, and an explicit refusal where it was not:

137 assignments deserve review
 82 have sufficient usage evidence
 31 cannot be assessed. Usage identity is concealed in this tenant
 24 have incomplete dependency evidence

No saving is claimed for the 55 unresolved assignments.

That is less than a savings figure and more than a savings figure is worth. The 82 can be argued for. The 55 are named as unresolved rather than rounded into the total, and a reader can see exactly which question would resolve them.

Production considerations

• Do not change the tenant to make the answer easier. Turning off concealed names to obtain attribution alters what the organisation decided about its own reporting. If attribution is unavailable, that is the finding.
• Reports.Read.All is the least privileged permission Microsoft documents for the usage reports. Read-only throughout; nothing here needs a write scope and nothing here should hold one.
• A window is a choice and it belongs in the record. D7, D30, D90 and D180 produce different answers about the same tenant, and a conclusion that does not carry its window cannot be re-checked.
• A last activity date is not bounded by the window you asked for. Reading a seven-day report as seven days of behaviour is the most common way this goes wrong.

Related governance rules

No licence-removal rule is asserted by this article.

Where this stands in our own product

Assignment and report identifiability have been observed against a real directory. Usage attribution was not available in that tenant, and dependency evidence is collected by nothing. The engine publishes those four states separately and refuses to compose them into a recommendation, which is why it has none to show you yet.

That refusal is not a gap waiting to be filled with an estimate. It is the product.

References

• subscribedSku resource type (Microsoft Learn)
• servicePlanInfo resource type (Microsoft Learn)
• assignedLicense resource type (Microsoft Learn)
• adminReportSettings resource type (Microsoft Learn)
• reportRoot: getOffice365ActiveUserDetail (Microsoft Learn)
• Microsoft 365 admin center usage reports overview (Microsoft Learn)

Found something wrong? Suggest a correction. The article source is not public; the engine it cites is.