For years, the “One Person, One License” rule for Microsoft Entra was something you heard, never something you could point at. Microsoft employees said it on stage, in blog posts, and in the occasional forum reply. But it was never written down anywhere that mattered. No Product Terms, no contract clause, nothing you could hand to a licensing auditor with a straight face. So every time a customer asked the obvious question (does my admin account need its own license?), the honest answer was “probably not, but I can’t prove it.”
That changed quietly in June 2026. Microsoft added the relevant answers to the official Entra Licensing FAQs.
I want to add a slightly different layer to this, because licensing is exactly the kind of topic where a confident summary can quietly cost someone real money or real compliance trouble. The FAQ is good news. But the way it is being summarized around the community is, in a couple of places, a little more generous than what the text actually says. So this is the careful read: what is now black on white, what still needs reading between the lines, and where the fine print bites.
🧩 What “One Person, One License” actually says
Two answers in the FAQ carry the whole thing. Paraphrased:
- Same employee, multiple internal identities within the same tenant: no separate Entra ID license needed.
- Same employee, multiple internal identities or accounts across different tenants, within the same cloud (meaning the same Microsoft cloud instance, for example commercial/public to commercial/public, not commercial to a Government cloud like GCC, GCC High, or DoD, and not into a sovereign cloud): no separate license needed either.
The core principle is real and now documented: Entra ID licenses are user-bound, not tenant-bound. The textbook case is the one every consultant deals with weekly. A person has a daily-driver account and a separate administrative account in the same tenant. That is one human. One P1 or P2 (or a bundle like Business Premium, E3, or E5) covers them. You do not buy a second license for the admin account.
That alone is worth the price of admission. It is the question I have been answering “probably” to for years, and now I can answer “yes, and here is the link.”
⚠️ The two words everyone is dropping: “same cloud”
Look again at the second answer. It does not say “across any tenants.” It says across different tenants within the same cloud.
That qualifier is doing work. Microsoft’s commercial cloud, the US Government clouds (GCC, GCC High, DoD), and the various sovereign clouds are separate licensing universes. A commercial P2 does not stretch across that boundary. If the same person holds an account in your commercial tenant and an account in a GCC High tenant, you are not in the “one person, one license” scenario anymore. Those are two clouds, and you license accordingly.
For most Austrian and European commercial customers this is a non-issue. But if you work with public sector, defense, or anyone running in a sovereign cloud, do not let the headline summary lull you. Read the full sentence.
🪪 “Internal identities” is not the same as “guest”
This is the distinction I most want people to internalize, because it is where the MSSP question gets misread.
Both headline answers talk about internal identities or accounts. That means accounts that live inside the tenant: a member account, an admin account, a service-style human account. It does not say anything about B2B guests. In fact, the same FAQ section handles the guest case separately and punts it to the External ID licensing rules (the “Properties of a B2B guest user” documentation).
So “One Person, One License” does not translate to “a guest is always free everywhere.” The principle that resolves the multiple-internal-accounts case is not the same principle that governs what a guest does in a tenant they were invited into. Keep those two mentally separate, because the next section depends on it.
🤝 The consultant-as-guest and PIM-in-a-customer-tenant question
This is the part that trips people up, so let me separate three things that licensing docs love to blur: technical enablement, per-user licensing for members, and how guests are handled. The question in practice is always the same:
Can my technician use PIM in a customer tenant where they are only a B2B guest, without buying a separate P2 for them there?
Short answer: yes, and you are not missing anything in the new FAQ. The “one person, one license” answers are about internal accounts and do not address guests at all. The guest case is covered by a separate rule, and it holds up. Here is the clean version, in three parts.
1. The tenant needs P2 for PIM to exist. PIM lights up the moment a single P2 (or Governance) license sits in the directory. There is no per-user technical gate. One license in the tenant, feature visible, done. So for PIM to exist in a customer tenant at all, that tenant has to carry P2.
2. Members who use PIM each need their own P2. This is the part the “one tenant license covers it” shorthand gets wrong. Technical enablement and license compliance are not the same thing. Microsoft requires a P2 (or Governance) license for every member who actually uses PIM, meaning anyone with an eligible or time-bound role assignment managed through PIM. Entra does not enforce this per user, so you can technically elevate fifty admins on a single P2, but you would be out of compliance. Fifty PIM users, fifty P2 licenses.
3. Guests who use PIM are not licensed per user. This is where your consultant sits, and it is the good news. A guest does not get a P2 license object assigned in the customer tenant. Guest usage of premium P1/P2 features runs through the External ID MAU model, where the first 50,000 monthly active external users are free. And Microsoft is explicit that PIM, as a P2 feature, does not touch the governance guest billing meter at all. The guest licensing documentation states plainly that “Microsoft Entra P2 features are not billed,” and that linking an Azure subscription is not even required for P2 actions. For a handful of consultant guests you are far inside the free MAU tier and off the governance meter entirely.
| Who | License position | Mechanism |
|---|---|---|
| The customer tenant, for PIM to function | At least one P2 (or Governance) in the tenant | Technical enablement |
| Each member who uses PIM | One P2 per PIM-using member | Per-user compliance, not enforced technically |
| A guest consultant who uses PIM | No license object assigned to the guest | External ID MAU (first 50,000 free), P2 not billed to the governance meter |
One honest boundary worth flagging: the part of guest licensing that Microsoft is actively reworking is the Governance-exclusive guest features (inactive and machine-learning access reviews on guests, entitlement management with guests in scope, lifecycle workflows for guests). Microsoft began enforcing subscription linking for those in January 2026. Plain P2 PIM for a guest is not in that bucket, so that enforcement does not touch it.
Bottom line: the consultant-as-guest scenario is fine, and for normal numbers it is free. Make sure the customer tenant carries P2, license your own PIM-using members properly, and let the guests ride the MAU free tier. This reflects the licensing position as of today. Microsoft reworks the guest governance area regularly, so confirm it against your own tenant before you build a hard commitment on it.
🧪 Where it is a genuinely clean win: labs and staging
The multiple-internal-accounts-across-your-own-tenants answer is the unambiguous good news.
If you, as an organization, run demo, lab, or staging tenants in the same cloud, and the same engineers hold internal accounts in each, you are not double-licensing those people. That is now documented, not assumed. Building out a proper staging tenant or a long-lived demo environment just got easier to defend from a compliance standpoint. For anyone who maintains a separate dev or test tenant on principle (you should), this removes a nagging “are we even allowed to do this cheaply” question.
🤖 Workload ID Premium: the one part with zero ambiguity
The FAQ is refreshingly clear here, so I will be too.
Entra Workload ID Premium is a tenant-level enablement. One license in the tenant turns on the premium features for all workload identities. There is no per-identity license assignment. You license only the workload identities that actually use premium features (the enterprise apps and service principals shown in the Entra admin center, and for Access Reviews on managed identities, based on the number of managed identities involved).
That premium feature set is the one I keep telling people they are leaving on the table:
- Conditional Access for workload identities (bind service principals to trusted locations)
- Identity Protection risk signals for compromised app credentials
- Access Reviews for workload identities
If you read my earlier post on Conditional Access for workload identities, this is the licensing model that sits underneath it. Non-human identities are first-class attack targets. The licensing is not the reason to skip protecting them.
🧭 P2 is in maintenance mode for governance
One strategic point that is easy to miss in the licensing weeds.
The FAQ confirms it plainly: the governance features inside Entra ID P2 (PIM, access reviews, entitlement management) keep working and will get security and bug fixes. But no new major features land in P2 going forward. New governance capabilities (the machine-learning-assisted access reviews, lifecycle automation, the Verified ID integration) go into Entra ID Governance only, which is a superset of what P2 offers.
If you are on P2 today and your governance roadmap matters, factor in the step-up license to Entra ID Governance. You do not have to move now, nothing breaks, and your P2 governance features are not taken away. But “P2 is the governance tier” is no longer the forward-looking story. Plan for it rather than discovering it at renewal.
🧾 The caveat that matters most: this is an FAQ, not the Product Terms
Here is the part I will not skip, because skipping it would be exactly the kind of sloppy claim I am trying to avoid.
This clarification lives in a Licensing FAQ, not in the binding Product Terms. The page says it plainly: the content is for informational purposes only, Microsoft makes no warranties on it, and in any conflict between the FAQ and your actual agreement, your agreement controls. So the “One Person, One License” principle is now documented, which is a real step up from word-of-mouth, but it is still not written into the legal terms that govern your contract.
That does not make it worthless. It makes it directional. An auditor reading a published Microsoft FAQ that says exactly what your deployment does is a very different conversation than a forum screenshot. But treat it as strong guidance, not a contractual guarantee.
One practical habit worth building in: keep a mechanism that links the daily account to the admin account. An HR attribute, an extension attribute, a naming convention, anything that lets you (and an auditor) map the unlicensed admin account back to the one licensed human. Do this regardless. It is cheap, it keeps you honest, and it is the evidence that makes the “one person” claim self-evident if anyone ever asks.
✅ Final Thoughts
The headline is true and welcome: for a person with multiple internal accounts (the admin-plus-daily case, or member accounts across your own same-cloud tenants), one license is enough, and it is finally documented.
But the words doing the heavy lifting are internal and same cloud. Miss either one and the summary quietly becomes wrong:
- B2B guests are covered by a different rule (the host tenant’s P2 tier plus the free External ID MAU allowance), not by the one-person rule. The outcome is usually free, but the reasoning matters.
- Cross-cloud (commercial to GCC or sovereign) is out of scope of the one-person rule entirely.
- PIM in a customer tenant runs on that customer tenant’s own P2. Your home P2 does not travel with you and does not switch PIM on in someone else’s tenant. If the customer has no P2, you cannot use PIM there even when you hold P2 at home. What you avoid is a separate per-seat license for your guest account, and that comes from the customer tenant’s External ID MAU free tier, not from your home license.
For your own people across your own same-cloud tenants: relax, it is one license. For customer environments: license the tenant on its merits, because that is the answer that holds up. And remember it is an FAQ, not the Product Terms, so keep the paper trail that links each human to their accounts.
Useful change from Microsoft. Just read the whole sentence, not the headline.
Primary source: Microsoft Licensing FAQs, FAQ 48 (Microsoft Entra).
Disclaimer: this post is based on the linked Microsoft Licensing FAQs and reflects my own reading of them. It is not official licensing advice. For binding guidance on a specific deployment, talk to a Microsoft licensing specialist or your account team.
Leave a Reply