Do admin accounts need their own licence?
Overview
Many organisations create separate admin accounts for IT staff alongside their day-to-day user accounts — a recognised security best practice. A common question arising from this is whether each account requires its own Microsoft Entra ID P2 licence, or whether a single licence per person is sufficient.
Microsoft has now formally clarified this in its official licensing FAQ, confirming the long-standing ‘One Person, One Licence’ (OPOL) philosophy. This article explains what that means, how it works in practice, and what your organisation needs to do to remain audit-ready.
We have seen a number of our clients purchasing a separate Entra ID P2 licence for their admin accounts — an understandable approach given the lack of any formal guidance to the contrary. Until now, there has been nothing in Microsoft’s official licensing documentation to clearly advise otherwise. The FAQ update changes that and may represent a direct cost-saving opportunity for your organisation at your next renewal.
What Microsoft’s Licensing FAQ Confirms
Microsoft’s licensing FAQ at microsoft.com now includes two explicit statements under the Entra ID section:
|
Q: Do we need a separate Microsoft Entra ID licence for the same employee who has different internal identities within the same tenant? No, you do not need a separate Entra ID licence for the same employee with different internal identities within the same tenant. Q: Do I need a separate Microsoft Entra ID licence for the same employee who has multiple internal identities or accounts across different tenants within the same cloud? No, a separate Entra ID licence is not needed in this case either. |
Source: Microsoft Licensing FAQs – microsoft.com/licensing/faqs/48 (Entra ID section). Note: Microsoft states this content is for informational purposes only and does not carry contractual weight.
Quick Reference: Who Needs a Licence?
| Account | Licence Required? | Notes |
| Primary user account | ✅ Yes | P2 standalone, M365 E5, or EMS E5 |
| Admin account – same person, same tenant | ❌ No | Covered by One Person, One Licence |
| Admin account – same person, different tenant (same cloud) | ❌ No | Also confirmed in Microsoft FAQ |
How It Works in Practice
The licence follows the human being, not the account. If an IT administrator holds a Microsoft Entra ID P2 licence — whether as a standalone licence, or via Microsoft 365 E5 or EMS E5 — on their primary account, that licence covers their use of Entra ID P2 features — even when they are signed in to a separate admin account.
The admin account itself is left unlicensed. This is intentional. Assigning a second licence to the admin account would consume an additional licence unnecessarily and would contradict the OPOL principle.
How Entra ID P2 Features Are Activated
Entra ID P2 features operate at two levels. Understanding this distinction helps explain why the admin account does not need its own licence.
| Feature | Activation Model | Impact on Admin Account |
| Privileged Identity Management (PIM) | Tenant-level enablement | Admin account can use PIM; human is licensed |
| Conditional Access (risk-based) | Tenant-level enablement | Policy applies across all accounts in tenant |
| Identity Protection | Tenant-level enablement | Risk signals apply to all sign-ins |
| Multi-Factor Authentication (MFA) | Tenant-level enablement | Available to all accounts once P2 is active |
| Self-Service Password Reset | Per-user benefit | User who resets must be licensed — admin account covered by OPOL |
In short: once your tenant has sufficient P2 licences for your workforce, tenant-level features are active for all accounts. Per-user features are considered satisfied where the human behind the account is already licensed on their primary account.
Compliance Risk: Tenant-Level Activation
Because Entra ID P2 features are enabled at the tenant level rather than assigned to individual accounts, there is an important compliance implication that organisations must not overlook: once P2 is active in your tenant, every user in that tenant is potentially benefiting from those features — regardless of whether they hold a P2 licence.
This means that if your organisation has purchased Entra ID P2 licences for only a subset of users — for example, just your IT administrators — but those P2 features are applied tenant-wide through Conditional Access policies or Identity Protection, then all users who are covered by those policies should technically be licensed. Microsoft’s product terms require that any user who benefits from a per-user feature must hold the appropriate licence.
Critically, Microsoft does not currently provide a technical mechanism to restrict P2 features exclusively to licensed users. Entra ID will not block an unlicensed user from benefiting from a Conditional Access policy or Identity Protection risk signal simply because they lack a P2 licence. The platform will apply those features to whoever falls within the policy scope — irrespective of licence assignment. This is precisely what makes the compliance exposure real: the system will not self-correct, so the responsibility sits entirely with your organisation.
The best available mitigation is policy scoping. Rather than applying P2 features to all users, administrators should scope Conditional Access policies, Identity Protection, and PIM to a security group containing only licensed users. A dynamic group using the assignedPlans attribute can automatically include only users with an active P2 service plan, keeping membership current without manual intervention. This will not prevent all unlicensed benefit, but it significantly reduces exposure and demonstrates clear compliance intent.
|
⚠️ Compliance Action Required There is no technical enforcement in Entra ID that automatically prevents an unlicensed user from receiving P2 feature benefits. Microsoft will not block unlicensed users — but your organisation remains contractually liable for their benefit. The recommended steps to manage this exposure are: • Audit your tenant. Review the scope of all Conditional Access, Identity Protection, and PIM configurations to identify how many users are currently within scope and cross-reference against your P2 licence count. • Scope policies to a licensed-users group. Rather than applying P2 policies to all users, target a security group containing only P2-licensed users. This is the primary control available to limit unlicensed benefit. • Use a dynamic group with the assignedPlans attribute. Build a dynamic group that automatically includes only users with an active Entra ID P2 service plan. This keeps membership current as licences are assigned or removed, without manual maintenance. • Understand the limits of scoping. Scoping policies to a licensed group significantly reduces exposure and demonstrates compliance intent, but it does not eliminate all unlicensed benefit — some tenant-level signals (such as Identity Protection risk detection) will still operate across all users. The only fully compliant position is to ensure every user in scope holds a P2 licence, or to hold sufficient licences to cover all users in the tenant. The SAM Club can assist in reviewing your Entra ID licence position, mapping current feature usage against your licence count, and identifying the most cost-effective path to compliance. |
What You Should Not Do
| ⚠️ Do not assign a P2 licence to the admin account. Doing so consumes an additional licence, increases your licence costs, and is unnecessary under the One Person, One Licence model. |
Audit Readiness: What You Must Have in Place
Microsoft does not technically enforce the OPOL rule at the account level — there is no system that automatically links a primary account to its associated admin account. That means the onus is on your organisation to maintain a clear, auditable record that demonstrates each admin account maps back to a licensed individual.
Without this, an auditor may treat every unlicensed admin account as a compliance gap.
Recommended approach
- Extension attribute: Use an Entra extension attribute on each admin account to record the UPN of the corresponding primary account. For example:
extensionAttribute1 = jane.doe@contoso.com
- Ensure both accounts share consistent attributes where possible — same manager, same department, same cost centre — so the relationship is verifiable from multiple sources.
- Document the process in your internal SAM or identity governance procedures.
- Maintain a mapping register (a simple spreadsheet is sufficient) that lists each admin account alongside the corresponding licensed primary account.
- If you use an HR system integrated with Entra ID, confirm that the admin account can be traced back to the HR record for that individual.
During a genuine Microsoft licence audit, auditors are asking one question: is every human who benefits from Entra ID P2 features covered by a licence? If you can demonstrate that clearly, unlicensed admin accounts will not be treated as a shortfall.
|
The SAM Club view This is a genuine cost-saving opportunity for organisations that have been assigning Entra ID P2 licences to both primary and admin accounts. If that applies to you, at The SAM Club we will be reviewing this with you so that you can reduce your licence count at the next renewal. As always, the key is documentation. The licence benefit is real, but it only holds up under scrutiny if you can prove the link between accounts. |
Key Points Summary
- One Entra ID P2 licence per person is sufficient, regardless of how many internal accounts that person holds.
- The admin account should remain unlicensed — assigning it a licence wastes money.
- Entra ID P2 features are largely enabled at tenant level; the admin account benefits automatically.
- You must be able to demonstrate the link between an unlicensed admin account and its licensed primary account in the event of an audit.
- Use extension attributes, shared HR data, or a mapping register to maintain that evidence.
Reference – Microsoft Licensing FAQs – Entra ID section: https://www.microsoft.com/licensing/faqs/48 (see Entra ID section) Note: Microsoft states this FAQ content is provided for informational purposes only and does not form part of your licence agreement.