Entra guests: licences and MAU billing

A company has eight thousand guests in its directory. Procurement is preparing eight thousand premium licences, the administrator reports fewer than a thousand active partners, and the security team is introducing advanced access reviews. Each team is using a different count. The budget cannot be settled until stored accounts, active identities and specific paid features are separated.

MAU means a monthly active user, rather than a sign-in, MFA challenge or invitation count. Basic External ID and guest Governance also use different events to determine billable activity. The basic offering's free tier therefore does not make every add-on free or give guests rights to any application.

Content reviewed on 21 October 2026. This article primarily addresses B2B guests in a corporate workforce tenant. It distinguishes them from a customer-facing external tenant and ordinary employees. Numerical examples are our hypothetical models, rather than customer measurements or quotations.

Establish the tenant and account type first

The External ID billing overview describes workforce tenants, where partners are invited to collaborate, and external tenants for customer applications. These are not interchangeable locations for the same solution. They differ in supported features, configuration and available add-ons.

For B2B collaboration, the documentation refers to guest identities and the UserType property. B2B user properties also distinguish the source of credentials from the user's relationship with the organisation. An address with a different domain or a renamed account is not a sufficient inventory. Record identity origin and access purpose too.

The current overview also includes internal guests authenticating with internal credentials. This does not establish that changing Member to Guest resolves an employee's licensing across all services. Identity classification, authentication billing and target-product entitlements are separate questions. This article does not count ordinary employee accounts as external business partners.

This table classifies a design; it is not advice to convert accounts to reduce licence counts. If an account inventory does not distinguish these cases, you do not yet have a reliable count of the entitlements to purchase.

One active guest is not counted for every sign-in

The basic MAU model tracks unique users with authentication activity within a calendar month. Repeated sign-ins by the same eligible guest in that month do not create additional MAUs. The number of sign-in log events is therefore not, without processing, the number of billable people.

The current pricing page lists the first 50,000 MAUs of the core offering as free. This tier applies to the basic product; premium add-ons have their own rules and do not automatically have the same free tier. The billing overview also combines MAUs from workforce and external tenants linked to a subscription. Do not allocate a fresh free tier to each application or directory without checking the billing arrangement.

Hypothetical example: one workforce tenant contains 8,000 eligible B2B guests. During the month, 900 distinct guests authenticate. Some do so repeatedly, producing 27,000 sign-ins. For simplicity, no other tenants contribute to the calculation under the same subscription.

The 900 basic MAUs are below the stated free tier in this model. This says nothing about SMS authentication charges, advanced Governance or access to other products. “Guest authentication fits within the tier” is not the total invoice for collaboration.

Governance measures different activity

Governance licensing for guests describes a separate model: monthly billing includes a record for each guest with one or more relevant governance actions that month. Features exclusive to ID Governance are billed. The document explicitly separates Entra P2 actions, which are not billed through this add-on and do not require an Azure subscription link for those actions.

The billable-event list includes certain advanced access package requests, assignments with custom extensions, automatic assignments and selected advanced access reviews. The specific feature and event in the current list determine treatment. The word “review”, without its configuration, is insufficient to classify every action as paid Governance.

This meter is not based only on people personally signing in. An administrator or workflow can perform an event targeting a guest. Look for the target identity in audit records, rather than only the actors' accounts and sign-in activity.

Continuing the hypothetical example: relevant billable Governance activity occurs for 70 distinct guests during the month. Fifty are also among the 900 guests who signed in; twenty did not sign in but were targets of the relevant governance action.

The figure 970 must not be presented as 970 different people in the organisation or as a single shared External ID meter. Nor can the 70 Governance MAUs be deducted from the basic free tier to eliminate their separate rate. An assignment made in a previous month does not itself establish a new billable action in the next month. Documentation explicitly mentions previously auto-assigned access without new activity.

Establish which guests generated Governance consumption

Microsoft identifies TargetId, TargetUserType = Guest and GovernanceLicenseFeatureUsed = True as audit properties for billable actions. For your own control report, use the event month, target Object ID, feature type and successful relevant action. Do not count repeated events for the same guest in one month as additional distinct guests.

Retain the original event detail too. A summary of seventy Object IDs establishes the count, but not which newly deployed policy changed consumption. Comparing the feature configuration before and after deployment is more useful than attributing every increase to a new Teams invitation.

Verify the Azure subscription link in the tenant using the relevant guide. Handover should identify cost ownership, the correct subscription and how to find the corresponding meter. Knowing that the organisation uses Azure somewhere is insufficient. Budget basic authentication and Governance separately.

Signing in does not grant application rights

External ID addresses identity and access scenarios. Basic MAUs do not consequently provide Power Automate, Power Apps or every other application licence a guest might need. For example, Power Automate guest support requires an appropriate licence from the host or home tenant. Assess portability for the particular service, rather than applying a general claim that guests “bring their licences”.

Also separate licensing from technical MFA behaviour. Authentication and Conditional Access for B2B distinguishes trust in a home tenant's MFA claim from resource-organisation requirements. A partner with MFA at home can face another challenge without appropriate trust configuration. A correct MAU calculation will not fix this.

If employees are protected too, see Conditional Access: who needs a licence. Do not copy employee rules onto guests without distinguishing them, or use the guest meter as coverage for the entire internal organisation.

Prepare before expanding collaboration

1. Distinguish workforce and external tenants, credential sources and actual UserType values.
2. List specific features: authentication, Conditional Access, individual governance scenarios and target applications.
3. Check every subscription and tenant contributing to the combined MAU calculation.
4. Obtain distinct active identities per calendar month and separate them from sign-in event counts.
5. Build a separate Governance report of target guests using the relevant audit properties and events.
6. Verify target-product rights and technical access with a representative partner account.
7. After feature changes, compare configuration, audit and actual billing. Directory growth alone does not explain costs.