Microsoft 365 licensing is normally fairly intuitive. You buy a licence for a user, assign it to them and that user gets access to the features included within it.
Except it doesn't always work like that.
Some Microsoft security, identity and compliance capabilities operate across the tenant rather than behaving like a conventional application. In some cases, buying and assigning a licence can make functionality technically available that can then be configured to affect users who don't have that licence themselves.
Conditional Access is a good example. If your tenant has the appropriate Microsoft Entra ID licence, an administrator can create Conditional Access policies and potentially apply those policies much more broadly.
The important question is:
Just because Microsoft lets you configure something, does that mean you're licensed to use it that way?
The answer is no.
This matters because Microsoft doesn't necessarily use the technical controls within a Microsoft 365 tenant to enforce every aspect of its licensing terms.
Having a capability available in the portal doesn't automatically give everyone in the business the right to benefit from it.
Thinking about Microsoft Entra ID P1, again, Conditional Access can be configured across the directory. The licensing requirement, however, follows the users evaluated by those premium policies. Assigning Entra ID P1 to the administrator configuring Conditional Access doesn't therefore license all the other users subsequently protected by it.
That can create a slightly counter-intuitive situation.
Imagine a business with 500 users. It has Microsoft 365 licences that don't include Entra ID P1 but purchases a small number of standalone P1 licences for its IT team.
Conditional Access becomes technically available.
An administrator could then create a Conditional Access policy applying to all 500 users.
The fact that the policy works doesn't mean those 500 users are correctly licensed.
The licence follows the users benefiting from or being evaluated by the premium capability, not simply the administrator who switched it on.
And this isn't confined to Conditional Access.
Microsoft Entra ID P2 adds capabilities such as Identity Protection, risk-based Conditional Access and Privileged Identity Management.
Again, these are capabilities that can appear at tenant level, but the licensing obligation follows their use.
For risk-based Conditional Access, that means the users whose identities are being evaluated. For PIM, the population can include people with eligible or time-bound assignments, members or owners of PIM-managed groups, activation approvers and users involved in access reviews.
So, purchasing a few P2 licences for the security team isn't necessarily sufficient simply because those are the people administering the service.
There's another distinction worth making here too.
Entra ID P1 and P2 are user licences. They shouldn't be assumed to cover non-human identities such as service principals. Microsoft has separate licensing arrangements for premium workload identity controls.
Microsoft Purview Suite provides another good example because many compliance controls naturally operate across data rather than presenting themselves to the user as an application.
You might configure a policy covering Exchange mailboxes, SharePoint sites, Teams conversations, OneDrive data or devices.
It would be easy to assume that the people configuring and administering those controls are therefore the ones who need the Purview licences.
That's generally the wrong way to look at it.
For Microsoft's premium Purview capabilities, the licensing population is driven primarily by the users benefiting from or falling within the scope of the relevant capability. That can include users associated with mailboxes, OneDrive accounts and endpoints, as well as owners and members of shared locations where premium features are applied.
Microsoft's own licensing guidance gives the example of a premium retention policy applied to all SharePoint files. In that scenario, the licensing requirement follows the SharePoint users benefiting from the service rather than simply the compliance administrator who created the policy.
The scope of the policy can determine the scope of your licensing requirement.
That's important if you've purchased Purview Suite for a limited population. If premium policies extend significantly beyond that population, you need to understand whether you've also extended the population that requires licensing.
There are nuances around shared locations, resource mailboxes and non-Microsoft 365 data, and some Purview capabilities use separate pay-as-you-go charging rather than the normal per-user model.
But the basic principle remains useful: don't judge your licensing requirement by counting the people who can see the Purview portal.
Agent 365 makes this subject even more relevant.
It provides central governance and security capabilities for a business' AI agents, but interestingly, Agent 365 isn't licensed per agent. It's licensed per user.
A business could ultimately have many agents under management. You don't purchase an Agent 365 licence for each of them.
Instead, licensing is associated with the humans connected to that activity.
For delegated agents, this includes users who delegate access to agents. For agents operating with their own access, the relevant person may be the owner, sponsor or manager. Users interacting with agents through premium Agent 365 capabilities and administrators using those premium capabilities can also form part of the licensing population.
A single licensed user can be associated with multiple agents without purchasing another Agent 365 licence for every agent. But that doesn't mean assigning one licence to an administrator or nominal agent owner turns Agent 365 into a tenant licence.
That's an important distinction as businesses begin deploying agents at scale.
It's a reasonable question.
If a user isn't licensed for a feature, why doesn't Microsoft prevent the policy from being applied to them?
The problem is that some Microsoft 365 services are designed to operate at tenant level. Technical activation and licensing entitlement aren't necessarily the same boundary.
In Purview, for example, Microsoft recognises tenant-level services that can be activated broadly even though appropriate user licensing remains necessary for the people benefiting from them. Agent 365 similarly exposes foundational tenant-wide agent inventory and administrative capabilities while retaining a per-user model for its premium capabilities.
“Microsoft lets us do it” isn't the same thing as “our licences allow us to do it.”
No, and this is an important qualification.
The answer isn't to assume that enabling one premium capability automatically means purchasing the highest licence for every person in the business.
Licensing still depends on the particular product and capability you're using.
You might legitimately deploy Entra ID P2 to a defined privileged population using PIM. Purview Suite might cover a particular set of users subject to premium compliance controls. Agent 365 licensing can similarly follow the people associated with agents using its premium capabilities.
The important thing is that the technical scope and licensed population need to agree.
If you've licensed 100 people for a premium capability and deliberately restricted that capability to those 100 people, that can be entirely different from purchasing 100 licences and applying a premium policy across 2,000 users.
We don't think the answer is to start buying additional Microsoft licences simply because a premium feature exists somewhere within your tenant.
Equally, relying on licence assignment alone isn't enough to understand whether you're compliant.
The better approach is to look at what you're actually doing with those licences.
For Entra, that means reviewing Conditional Access, Identity Protection and privileged identity policies and understanding which users are being evaluated or governed.
For Purview, it means looking at the scope of premium retention, DLP, investigation and other compliance policies rather than simply counting the people assigned a Purview licence.
For Agent 365, it means understanding the people associated with your managed agents, including users, owners, sponsors, managers and administrators, and determining where premium Agent 365 capabilities are actually being used.
The same exercise should separately identify guests, service principals, workload identities, agent identities, shared mailboxes and non-Microsoft 365 data because these aren't necessarily covered by the same per-user licensing rules.
Microsoft's licensing models are increasingly reflecting how its services actually operate. Identity protection works across identities. Purview works across information. Agent 365 governs agents that can operate across applications, data and users.
That makes simply comparing purchased licences with the number of assignments less useful than it once was.
The more valuable question is:
Who is actually benefiting from the premium capabilities you've enabled?
We recommend periodically comparing your Microsoft licensing position with the policies and services you've actually configured.
That doesn't just identify potential under-licensing. It can highlight the opposite problem too: premium licences assigned to users who aren't benefiting from the capabilities you're paying for.
For businesses using a mixture of Microsoft 365 E3, E5, Business Premium and individual security, identity or compliance add-ons, that exercise can become particularly valuable.
Licensing compliance shouldn't be based on whether Microsoft happens to prevent you from clicking a button.
It should be based on understanding the capabilities you've deployed, who benefits from them, and whether the licences you've purchased reflect the way the environment is actually configured.
Because in Microsoft 365, being able to switch something on and being licensed to use it aren't always the same thing.
Licensing note: Microsoft licensing terms and service descriptions can change. Businesses should validate their position against the current Microsoft Product Terms, relevant service descriptions and their applicable customer agreement before making licensing decisions.