Entra Conditional Access Lizenzueberschreitung Warnung: Was das neue Banner wirklich bedeutet

Anfang August 2026 sahen Administratoren, die die Conditional-Access-Seite im Microsoft Entra Admin Center öffneten, ein neues Banner. Die Entra Conditional Access Lizenzueberschreitung Warnung teilt mit, dass einige Ihrer Richtlinien mehr Benutzer schützen, als Ihre aktuellen Lizenzberechtigungen erlauben — und sie wurde vielfach als Auftakt einer automatisierten Abrechnung fehlgedeutet. Das ist sie nicht. Sie ist ein Sichtbarkeitssignal. Wichtiger noch: Die zugrunde liegende Zahl wird auf eine Weise berechnet, die mit ziemlicher Sicherheit unterschätzt, wie viele Microsoft Entra ID P1-Lizenzen Ihr Richtlinien-Scope tatsächlich erfordert.

Was ist die Entra Conditional Access Lizenzueberschreitung Warnung

Microsoft hat den Hinweis ohne Ankündigung ausgerollt, und die ersten öffentlichen Berichte darüber erschienen innerhalb weniger Tage. ourcloudnetwork (11. August 2026) berichtete, dass es „in den letzten Wochen" auf der Conditional-Access-Übersichtsseite erschienen sei, und LazyAdmin (12. August 2026) verortete es auf derselben Seite. Beide geben das vollständige Banner wortgleich wieder als: "Licensing overage. Some Conditional Access policies are protecting more users than your current licensing entitlements allow." Microsoft 365 MVP Tony Redmond dokumentierte es am 13. August 2026 und zitierte die Meldung, die Tenants mitteilt, dass einige Conditional-Access-Richtlinien mehr Benutzer schützen als ihre aktuellen Lizenzberechtigungen erlauben.

Der Link in der Meldung öffnet Microsofts Dokumentation zu License Usage Insights, wo die zugrunde liegenden Zahlen herstammen.

Die Lizenzgrundlage selbst hat sich nicht geändert. Microsofts Conditional-Access-Übersicht stellt klar fest, dass die Nutzung dieser Funktion Microsoft Entra ID P1-Lizenzen erfordert, ergänzt, dass auch Kunden von Microsoft 365 Business Premium Conditional-Access-Funktionen nutzen können, und weist darauf hin, dass risikobasierte Richtlinien (Sign-in-Risiko und Benutzerrisiko) Microsoft Entra ID Protection erfordern, eine P2-Funktion.

Wie Microsoft Conditional Access-Benutzer zählt

Die Zahl hinter dem Banner stammt von der Seite License usage, erreichbar über Billing > Licenses im Entra Admin Center. Microsofts Dokumentation beschreibt ein bewusst vereinfachtes Modell: eine „Hero-Kennzahl" pro Lizenzstufe, aufgeteilt auf zwei Tabs.

Jeder Tab enthält einen Feature-Usage-Bericht, der den Verbrauch anhand von drei Indikatoren gegen die Berechtigungen abbildet: Licenses Used, Licenses Not Used und Usage Spike — Letzteres ist in Microsofts Worten „Nutzung, die Ihre berechtigte Lizenzanzahl übersteigt". Berechtigungen sind nicht nur eigenständige P1/P2-Käufe: Die Zählung „spiegelt die Gesamtzahl der Lizenzen über alle Produkte hinweg wider, die jede Stufe der Microsoft-Entra-ID-Funktionalität enthalten", was Microsoft Entra Suite, ID Governance, Verified ID, Private Access und Internet Access mit einschließt.

Drei operative Einschränkungen sind wichtig, bevor Sie auf Basis der Zahl handeln:

• Die Daten zeigen die Nutzung des letzten Monats und „können bis zu drei Tage brauchen, um aktualisiert zu werden". Sie sehen nie den heutigen Stand.
• Die Rolle mit den geringsten Rechten, die die Seite lesen kann, ist Reports Reader; Global Reader, Security Reader, Security Operator, Security Administrator, Application Administrator und Cloud Application Administrator funktionieren ebenfalls.
• Die Funktion ist nur in Public Clouds verfügbar.

Redmond bestätigte die Herkunft der Daten, indem er die Sign-in-Logs direkt abfragte und das Ergebnis mit der Portalzahl abglich. Der Abgleich funktioniert erst, wenn Gäste herausgerechnet werden: Sein Tenant lieferte zehn eindeutige Benutzer mit einem erfolgreichen Conditional-Access-Sign-in, aber nur drei davon waren Members — und drei war genau das, was das Portal meldete. Auf dieser Grundlage urteilte er, es sei „wahrscheinlich, dass Sign-in-Logs die Basis für die im Admin Center angezeigten Informationen sind".

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)

Vergleichen Sie die Member-Zahl mit der Conditional-Access-Benutzerzahl des Portals, niemals mit der Gesamtzahl. Gäste werden ebenfalls von Ihren Richtlinien ausgewertet, aber sie werden als monatlich aktive Benutzer abgerechnet statt als P1-Sitzplätze — wer sie mitzählt, überzeugt sich am schnellsten fälschlich davon, dass das Portal falschliegt, obwohl es das nicht tut.

Warum die Warnung Ihre tatsächliche Lizenzexposition unterschätzt

Hier liegt die Lücke, die das Banner in beide Richtungen irreführend macht. Das Portal misst Benutzer, deren Sign-ins im letzten Monat ausgewertet wurden. Lizenzierung, wie sie allgemein verstanden wird, hängt an Benutzern, die von einer Richtlinie anvisiert werden — unabhängig davon, ob sie sich angemeldet haben.

Eine Richtlinie mit Scope Alle Benutzer nimmt jedes Member-Konto in den Scope auf. Mitarbeiter in Elternzeit, Saisonkräfte, ruhende, aber lizenzierte Konten und alle, die im Messzeitraum schlicht nicht angemeldet waren, fallen alle aus der „ausgewerteten" Zahl heraus, während sie innerhalb des Richtlinien-Scopes bleiben. Das Portal wird bereitwillig eine bequeme Zahl melden, während Ihr tatsächlicher Berechtigungsbedarf weit höher liegt.

Redmond räumt offen ein, dass Microsoft diese Unschärfe nicht beseitigt hat. In einem Follow-up vom 18. August 2026 schrieb er, dass „die Anforderungen für Conditional-Access-Richtlinien etwas unscharf" seien, dass er „keine andere Microsoft-Aussage mit einer präziseren Definition der Lizenzierungsanforderung finden" könne, und dass „die aktuellen Lizenzierungslücken-Benachrichtigungen ebenfalls nicht erklären, wie der Lizenzierungs-Scope berechnet wird". Seine praktische Lesart neigt zur Seite „anvisiert statt ausgewertet": „wenn ein Tenant Conditional-Access-Richtlinien zum Schutz von Verbindungen bereitgestellt hat, müssen wahrscheinlich die meisten, wenn nicht alle Benutzer(-Member)-Konten lizenziert werden".

Zwei weitere Feinheiten verzerren den Vergleich:

• Gäste werden anders abgerechnet. Microsofts Dokumentation zur External-ID-Preisgestaltung bestätigt, dass das Abrechnungsmodell nach monatlich aktiven Benutzern (MAU) „für alle Gastbenutzer" mit UserType gleich Guest gilt, und ausdrücklich „nicht für Benutzer gilt, die aus der Organisation selbst stammen und einen UserType-Wert von Member haben". Gast-Traffic, der auf Ihre Richtlinien trifft, ist kein P1-Sitzplatzproblem — kann aber trotzdem die rohen Sign-in-Zahlen aufblähen, wie es in Redmonds eigenem Tenant der Fall war. Wenn externe Identitäten einen großen Anteil Ihres Traffics ausmachen, prüfen Sie die Angriffsfläche von Gastkonten separat.
• Berechtigungen können existieren, ohne die richtigen Personen zu erreichen. In Redmonds Tenant waren Lizenzen verfügbar, doch zwei der drei Konten, die Conditional Access tatsächlich nutzten, hatten Office 365 E3, was weder P1 noch P2 enthält. Der Pool war ausreichend; die Zuweisung war es nicht.

Was tatsächlich passiert, wenn Entra ID P1-Lizenzen auslaufen

Dieser Teil ist es wert, verinnerlicht zu werden, denn es handelt sich um dokumentiertes Verhalten und nicht um Spekulation. Microsofts Conditional-Access-Übersicht stellt fest: "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."

Lesen Sie das genau. Ihre Durchsetzung bricht nicht zusammen — was ein wirklich gutes Design ist. Aber Ihre primäre Zugriffskontroll-Ebene tritt in einen Änderungsstopp ein: Ansehen und Löschen sind verfügbar, Aktualisieren nicht. Ein Vorfall, der es erfordert, dringend eine Richtlinie zu verschärfen, eine Ausnahme für ein Break-Glass-Konto hinzuzufügen oder einen Scope einzugrenzen, wird zu etwas, das Sie nicht tun können, bis die Lizenzierung geklärt ist. Das ist ein Verfügbarkeits- und Incident-Response-Risiko, kein Abrechnungsrisiko — und der eigentliche Grund, die Zahlen jetzt abzugleichen.

Erkennung

Arbeiten Sie sich von Microsofts eigener Zahl zu der Zahl vor, die Ihre Lizenzposition tatsächlich bestimmt.

Das Portal kann die letzte Zeile nicht beantworten, also müssen Sie den Richtlinien-Scope selbst auflisten. Nur aktivierte Richtlinien setzen etwas durch — Report-only-Richtlinien werten aus, gewähren oder blockieren aber nichts:

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
    }
}

Ein IncludeUsers-Wert von All nimmt jeden Benutzer in den Scope auf, Gäste eingeschlossen — filtern Sie vor dem Zählen auf userType eq 'Member', denn nur Members treiben den P1-Sitzplatzbedarf. Wo der Scope über eine Gruppe oder eine Verzeichnisrolle gesetzt ist, lösen Sie ihn transitiv auf — verschachtelte Gruppen und Rollenmitgliedschaft erweitern beide die effektive Menge, weshalb Get-MgGroupTransitiveMemberAsUser und Get-MgDirectoryRoleMember in jede ernsthafte Version dieses Skripts gehören. Redmonds vollständiges Abgleich-Skript, auf dem die Abfragen in diesem Abschnitt basieren, tut genau das und ist im GitHub-Repository von Microsoft 365 for IT Pros veröffentlicht.

Ermitteln Sie dann, wer tatsächlich einen aktiven P1- oder P2-Serviceplan besitzt. Die Serviceplan-IDs sind in Microsofts Referenz der Serviceplan-IDs veröffentlicht: AAD_PREMIUM ist 41781fb2-bc02-4b7c-bd55-b576c07bb09d und AAD_PREMIUM_P2 ist 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)

Die CapabilityStatus-Prüfung ist nicht optional. Ein Serviceplan kann auf einem Konto weiterhin erscheinen, nachdem eine Lizenz entfernt wurde, sodass die bloße Präsenz Ihre lizenzierte Population überzeichnet.

Behandeln Sie die Ausgabe als Ausgangspunkt einer Untersuchung, nicht als Compliance-Zertifikat. Redmond ist explizit, was die Obergrenze eines solchen Skripts angeht: „Ich behaupte nicht, dass das Skript die Einhaltung der Microsoft-Lizenzierungsanforderungen durch den Tenant belegt. Programmieren gegen ungenaue Informationen ist immer schwierig, und Microsoft veröffentlicht keine präzise Definition des Conditional-Access-Lizenzverbrauchs."

Behebung (Remediation)

1. Vor dem Kauf abgleichen. Vergleichen Sie die per Graph ermittelte Menge anvisierter, aber unlizenzierter Konten mit Ihrem Berechtigungspool. Ein Überschreitungsbanner, das durch Fehlzuweisung entsteht, kostet nichts, um es zu beheben.
2. Die Differenz mit Belegen erklären, nicht mit Vermutungen. Doppelte Identitäten, administrative Zweitkonten, Servicekonten und Gäste erklären die Lücke jeweils unterschiedlich. Dokumentieren Sie, wie jedes Zweitkonto einer lizenzierten Person zugeordnet ist — genau das wird ein Audit oder ein True-up-Gespräch verlangen.
3. Scope gezielt straffen, nicht defensiv. Eine Richtlinie zu verengen reduziert Lizenzierungsexposition und Sicherheitsabdeckung gleichzeitig. Entfernen Sie niemals die Baseline-Abdeckung für Admins, alle Benutzer oder alle Apps, nur um eine Zahl besser aussehen zu lassen.
4. Ausnahmen gleich mitprüfen. Ausnahmelisten wachsen mit der Zeit. Veraltete benutzerbezogene Ausnahmen und überdimensionierte Gruppenausnahmen entziehen leise Personen der Durchsetzung und verzerren auch die ausgewertete Benutzerzahl. Behalten Sie die bewussten — Ihre Break-Glass-Konten müssen ausgeschlossen und überwacht bleiben.
5. P2 separat bestätigen. Risikobasierte Sign-in- und Benutzerrisiko-Richtlinien erfordern ID Protection. Wenn der ID-Protection-Tab eine Nutzung zeigt, die Sie sich nicht erklären können, prüfen Sie, wofür Ihre P2-Funktionen tatsächlich lizenziert sind.
6. Nach der Verzögerung erneut prüfen. Die Nutzungsdaten spiegeln den letzten Monat wider und können bis zu drei Tage brauchen, um sich zu aktualisieren. Beurteilen Sie eine Behebung nicht anhand des Portals am selben Nachmittag, an dem Sie sie umgesetzt haben.

Wie EtcSec dies erkennt

Das Lizenzierungsbanner ist ein Symptom von etwas, das EtcSec direkt prüft: die Lücke zwischen dem, was Ihre Conditional-Access-Richtlinien abzudecken behaupten, und dem, was sie tatsächlich durchsetzen. Ein EtcSec-Azure-Audit listet den aktivierten Richtlinien-Scope auf dieselbe Weise auf wie die obigen Graph-Abfragen und markiert dann CA_NO_POLICY_ALL_USERS, wenn keine Richtlinie die gesamte Member-Population anvisiert, CA_POLICY_REPORT_ONLY, wenn Richtlinien auswerten, aber nie durchsetzen, CA_EXCESSIVE_EXCLUSIONS und CA_USER_EXCLUSIONS_STALE, wenn Ausnahmelisten über ihre Rechtfertigung hinausgewachsen sind, CA_NO_BREAK_GLASS_EXCLUSION, wenn der Notfallzugriff keinen geschützten Pfad hat, und CA_NO_RISK_BASED_SIGNIN, wenn P2-Berechtigungen bezahlt, aber ungenutzt sind.

Letzteres wirkt in beide Richtungen: ungenutzte P2-Fähigkeiten sind eine Lizenzueberschreitung in umgekehrter Richtung. Für eine breitere Betrachtung des Richtliniendesigns siehe unseren Leitfaden zu Entra ID Conditional Access Lücken und den praktischen Leitfaden zur Entra-ID-Sicherheitsprüfung.