Entra Conditional Access Licensing Overage Warning: What the New Banner Actually Means

By early August 2026, administrators opening the Conditional Access page in the Microsoft Entra admin center were seeing a new banner. The Entra Conditional Access licensing overage warning tells you that some of your policies are protecting more users than your current licensing entitlements allow — and it has been widely misread as the opening move of automated billing. It is not. It is a visibility signal. More importantly, the number behind it is calculated in a way that almost certainly understates how many Microsoft Entra ID P1 licences your policy scope actually requires.

What Is the Entra Conditional Access Licensing Overage Warning

Microsoft shipped the notice without an announcement, and the first public accounts of it landed within days of each other. ourcloudnetwork (11 August 2026) reported it appearing "over recent weeks" on the Conditional Access overview page, and LazyAdmin (12 August 2026) placed it on the same page. Both render the full banner as: "Licensing overage. Some Conditional Access policies are protecting more users than your current licensing entitlements allow." Microsoft 365 MVP Tony Redmond documented it on 13 August 2026, quoting the message as telling tenants that "Some Conditional Access policies are protecting more users than your current licensing entitlements".

The link inside the message opens Microsoft's license usage insights documentation, which is where the underlying numbers live.

The licensing baseline itself has not changed. Microsoft's Conditional Access overview states plainly that "Using this feature requires Microsoft Entra ID P1 licenses", adds that Microsoft 365 Business Premium customers can also use Conditional Access features, and notes that risk-based policies (sign-in risk and user risk) require Microsoft Entra ID Protection, a P2 feature.

How Microsoft Counts Conditional Access Users

The figure driving the banner comes from the License usage page, reachable at Billing > Licenses in the Entra admin center. Microsoft's documentation describes a deliberately simplified model: one "hero metric" per licence tier, split across two tabs.

Each tab carries a feature usage report that charts consumption against entitlements using three indicators: Licenses Used, Licenses Not Used, and Usage Spike — the last being, in Microsoft's words, "usage that exceeds your entitled license count". Entitlements are not just standalone P1/P2 purchases: the count "reflects the total number of licenses across all products that include each tier of Microsoft Entra ID functionality", which sweeps in Microsoft Entra Suite, ID Governance, Verified ID, Private Access, and Internet Access.

Three operational caveats matter before you act on the number:

• The data shows last month's usage and "might take up to three days to update". You are never looking at today.
• The least-privileged role that can read the page is Reports Reader; Global Reader, Security Reader, Security Operator, Security Administrator, Application Administrator, and Cloud Application Administrator also work.
• The feature is only available in public clouds.

Redmond corroborated where the data comes from by querying the sign-in logs directly and matching the result against the portal figure. The reconciliation only works once guests are separated out: his tenant returned ten unique users with a successful Conditional Access sign-in, but only three of them were members — and three was exactly what the portal reported. On that basis he judged it "likely that sign-in logs are the basis for the information shown in the admin center."

Connect-MgGraph -Scopes AuditLog.Read.All

$Start = (Get-Date).AddDays(-14).ToString('yyyy-MM-dd')
$End   = (Get-Date).AddDays(1).ToString('yyyy-MM-dd')

[array]$Logs = Get-MgAuditLogSignIn -All `
    -Filter "createdDateTime gt $Start and createdDateTime lt $End and conditionalAccessStatus eq 'success'"

[array]$Users = $Logs | Sort-Object UserPrincipalName -Unique |
    Select-Object UserPrincipalName, AdditionalProperties

$TenantId = (Get-MgOrganization).Id
$Guests   = ($Users | Where-Object {
    $_.AdditionalProperties.homeTenantId -ne $TenantId }).Count

Write-Host ("{0} unique users, {1} members, {2} guests" -f `
    $Users.Count, ($Users.Count - $Guests), $Guests)

Compare the member figure against the portal's Conditional Access users count, never the total. Guests are evaluated by your policies too, but they are billed as monthly active users rather than P1 seats, so leaving them in is the fastest way to convince yourself the portal is wrong when it is not.

Why the Warning Undercounts Your Real Licensing Exposure

Here is the gap that makes the banner misleading in both directions. The portal measures users whose sign-ins were evaluated last month. Licensing, as generally understood, attaches to users who are targeted by a policy — whether or not they logged in.

A policy scoped to All users puts every member account in scope. Staff on parental leave, seasonal workers, dormant-but-licensed accounts, and anyone who simply did not sign in during the measurement window all fall outside the "evaluated" count while remaining inside the policy scope. The portal will happily report a comfortable number while your actual entitlement requirement is far higher.

Redmond is candid that Microsoft has not closed this ambiguity. In a follow-up published on 18 August 2026 he wrote that "The requirements for conditional access policies are a little fuzzy", that "I can find no other Microsoft statement with a more precise definition for the licensing requirement", and that "The recent licensing gap notifications also do not explain how the licensing scope is calculated." His practical reading lands on the targeted-not-evaluated side: "if a tenant has deployed conditional access policies to protect connections, it is likely that most if not all user (member) accounts need to be licensed."

Two further wrinkles distort the comparison:

• Guests are billed differently. Microsoft's External ID pricing documentation confirms the monthly active users (MAU) billing model "applies to all guest users" with UserType set to Guest, and explicitly "doesn't apply to users who originate from within the organization and have a UserType value of Member." Guest traffic hitting your policies is not a P1 seat problem — but it can still inflate raw sign-in counts, as it did in Redmond's own tenant. If external identities are a large share of your traffic, review guest account exposure separately.
• Entitlements can exist without reaching the right people. In Redmond's tenant, licences were available yet two of the three accounts actually using Conditional Access held Office 365 E3, which includes neither P1 nor P2. The pool was adequate; the assignment was not.

What Actually Happens If Entra ID P1 Licences Lapse

This is the part worth internalising, because it is documented behaviour rather than speculation. Microsoft's Conditional Access overview states: "When the licenses required for Conditional Access expire, policies aren't automatically disabled or deleted. This graceful state lets customers migrate away from Conditional Access policies without a sudden change in their security posture. You can view and delete remaining policies, but you can't update them."

Read that carefully. Your enforcement does not collapse — which is genuinely good design. But your primary access-control plane enters a change freeze: view and delete are available, update is not. An incident that requires urgently tightening a policy, adding an exclusion for a break-glass account, or narrowing a scope becomes something you cannot do until licensing is resolved. That is an availability and incident-response risk, not a billing one, and it is the real reason to reconcile the numbers now.

Detection

Work outward from Microsoft's own number to the one that actually governs your licensing position.

The portal cannot answer the last row, so enumerate policy scope yourself. Only enabled policies enforce anything — report-only policies evaluate but do not grant or block:

Connect-MgGraph -Scopes Policy.Read.All, Directory.Read.All, User.Read.All

[array]$Policies = Get-MgIdentityConditionalAccessPolicy -All -Filter "state eq 'enabled'"

ForEach ($Policy in $Policies) {
    $Scope = $Policy.Conditions.Users
    [PSCustomObject]@{
        Policy         = $Policy.DisplayName
        IncludedUsers  = ($Scope.IncludeUsers -join ', ')
        IncludedGroups = $Scope.IncludeGroups.Count
        IncludedRoles  = $Scope.IncludeRoles.Count
        ExcludedUsers  = $Scope.ExcludeUsers.Count
        ExcludedGroups = $Scope.ExcludeGroups.Count
    }
}

An IncludeUsers value of All puts every user in scope, guests included — filter to userType eq 'Member' before you count, because only members drive P1 seat requirements. Where scope is set by group or directory role, resolve it transitively — nested groups and role membership both expand the effective set, which is why Get-MgGroupTransitiveMemberAsUser and Get-MgDirectoryRoleMember belong in any serious version of this script. Redmond's full reconciliation script, on which the queries in this section are based, does exactly that and is published in the Microsoft 365 for IT Pros GitHub repository.

Then establish who actually holds an active P1 or P2 service plan. The service plan IDs are published in Microsoft's service plan reference: AAD_PREMIUM is 41781fb2-bc02-4b7c-bd55-b576c07bb09d and AAD_PREMIUM_P2 is eec0eb4f-6444-4f95-aba0-50c24d67f998.

$EntraP1 = "41781fb2-bc02-4b7c-bd55-b576c07bb09d"
$EntraP2 = "eec0eb4f-6444-4f95-aba0-50c24d67f998"

Get-MgSubscribedSku -All |
    Where-Object { $_.ServicePlans.ServicePlanId -contains $EntraP1 -or
                   $_.ServicePlans.ServicePlanId -contains $EntraP2 } |
    Select-Object SkuPartNumber, ConsumedUnits,
                  @{Name = 'Prepaid'; Expression = { $_.PrepaidUnits.Enabled }}

[array]$LicensedUsers = Get-MgUser -All -ConsistencyLevel eventual -CountVariable Records `
    -Property Id, UserPrincipalName, AssignedPlans `
    -Filter "(assignedPlans/any(s:s/servicePlanId eq $EntraP1) or assignedPlans/any(s:s/servicePlanId eq $EntraP2)) and userType eq 'Member' and accountEnabled ne false"

[array]$EffectivelyLicensed = $LicensedUsers | Where-Object {
    $_.AssignedPlans | Where-Object {
        $_.ServicePlanId -in @($EntraP1, $EntraP2) -and $_.CapabilityStatus -eq 'Enabled' }
}

Write-Host ("{0} enabled member accounts hold an active Entra P1/P2 service plan" -f $EffectivelyLicensed.Count)

The CapabilityStatus check is not optional. A service plan can still appear on an account after a licence is removed, so presence alone overstates your licensed population.

Treat the output as an investigation starting point, not a compliance certificate. Redmond is explicit about the ceiling on any such script: "I do not claim that the script proves tenant compliance with Microsoft licensing requirements. Coding against imprecise information is always difficult, and Microsoft does not publish a precise definition of Conditional Access licence consumption."

Remediation

1. Reconcile before you purchase. Compare the Graph-derived set of targeted-but-unlicensed accounts against your entitlement pool. An overage banner driven by misassignment costs nothing to fix.
2. Explain the delta with evidence, not assumption. Duplicate identities, administrative secondary accounts, service accounts, and guests each account for the gap differently. Document how every secondary account maps to a licensed person — that record is what an audit or a true-up conversation will ask for.
3. Tighten scope deliberately, not defensively. Narrowing a policy reduces licensing exposure and security coverage at the same time. Never drop baseline coverage for admins, all users, or all apps to make a number look better.
4. Audit exclusions while you are in there. Exclusion lists accumulate. Stale user-level exclusions and oversized group exclusions quietly remove people from enforcement, and they distort the evaluated-user count too. Keep the deliberate ones — your break-glass accounts must stay excluded and monitored.
5. Confirm P2 separately. Risk-based sign-in and user-risk policies require ID Protection. If the ID Protection tab shows usage you cannot account for, verify what your P2 features are actually licensed for.
6. Re-check after the lag. Usage data reflects last month and can take up to three days to refresh. Do not judge a remediation by the portal the same afternoon you applied it.

How EtcSec Detects This

The licensing banner is a symptom of something EtcSec audits directly: the gap between what your Conditional Access policies claim to cover and what they actually enforce. An EtcSec Azure audit enumerates enabled policy scope the same way the Graph queries above do, then flags CA_NO_POLICY_ALL_USERS where no policy targets the full member population, CA_POLICY_REPORT_ONLY where policies evaluate but never enforce, CA_EXCESSIVE_EXCLUSIONS and CA_USER_EXCLUSIONS_STALE where exclusion lists have grown past their justification, CA_NO_BREAK_GLASS_EXCLUSION where emergency access has no protected path, and CA_NO_RISK_BASED_SIGNIN where P2 entitlements are paid for but unused.

That last one cuts both ways: unused P2 capability is a licensing overage in reverse. For a broader review of policy design, see our guide to Entra ID Conditional Access gaps and the practical Entra ID security audit walkthrough.