Eccedenza licenza accesso condizionale Entra: cosa significa davvero il nuovo banner

All'inizio di agosto 2026, gli amministratori che aprivano la pagina Accesso condizionale nell'interfaccia di amministrazione di Microsoft Entra hanno iniziato a vedere un nuovo banner. Questa eccedenza licenza accesso condizionale Entra indica che alcune delle tue policy proteggono più utenti di quanti ne consentano i tuoi attuali diritti di licenza — ed è stata ampiamente fraintesa come la prima mossa verso una fatturazione automatizzata. Non lo è. È un segnale di visibilità. Cosa più importante, il numero che c'è dietro viene calcolato in un modo che quasi certamente sottostima quante licenze Microsoft Entra ID P1 richiede realmente l'ambito delle tue policy.

Che cos'è l'eccedenza licenza accesso condizionale entra

Microsoft ha distribuito l'avviso senza alcun annuncio, e i primi resoconti pubblici sono comparsi a distanza di pochi giorni l'uno dall'altro. ourcloudnetwork (11 agosto 2026) ha segnalato la sua comparsa «nelle ultime settimane» sulla pagina di riepilogo dell'Accesso condizionale, e LazyAdmin (12 agosto 2026) l'ha individuata sulla stessa pagina. Entrambi riportano il banner completo così: «Eccedenza di licenza. Alcune policy di Accesso condizionale proteggono più utenti di quanti ne consentano i tuoi attuali diritti di licenza.» L'MVP Microsoft 365 Tony Redmond l'ha documentata il 13 agosto 2026, citando il messaggio che informa i tenant che «alcune policy di Accesso condizionale proteggono più utenti di quanti ne consentano i tuoi attuali diritti di licenza».

Il link all'interno del messaggio apre la documentazione Microsoft sugli approfondimenti sull'utilizzo delle licenze, dove risiedono i numeri sottostanti.

Il requisito di licenza di base non è cambiato. La panoramica dell'Accesso condizionale di Microsoft afferma chiaramente che «l'utilizzo di questa funzionalità richiede licenze Microsoft Entra ID P1», aggiunge che anche i clienti Microsoft 365 Business Premium possono utilizzare le funzionalità di Accesso condizionale, e specifica che le policy basate sul rischio (rischio di accesso e rischio utente) richiedono Microsoft Entra ID Protection, una funzionalità P2.

Come Microsoft conta gli utenti dell'Accesso condizionale

Il numero che genera il banner proviene dalla pagina Utilizzo licenze, raggiungibile da Fatturazione > Licenze nell'interfaccia di amministrazione di Entra. La documentazione Microsoft descrive un modello deliberatamente semplificato: una «metrica principale» per ogni livello di licenza, suddivisa in due schede.

Ogni scheda include un report sull'utilizzo delle funzionalità che confronta il consumo con i diritti di licenza tramite tre indicatori: Licenze utilizzate, Licenze non utilizzate e Picco di utilizzo — quest'ultimo è, nelle parole di Microsoft, «utilizzo che supera il numero di licenze a cui hai diritto». I diritti non sono solo acquisti autonomi di P1/P2: il conteggio «riflette il numero totale di licenze in tutti i prodotti che includono ciascun livello di funzionalità di Microsoft Entra ID», il che comprende Microsoft Entra Suite, ID Governance, Verified ID, Private Access e Internet Access.

Tre avvertenze operative contano prima di agire su questo numero:

• I dati mostrano l'utilizzo del mese precedente e «potrebbero richiedere fino a tre giorni per aggiornarsi». Non stai mai guardando l'oggi.
• Il ruolo con privilegi minimi che può leggere la pagina è Lettore report; funzionano anche Lettore globale, Lettore sicurezza, Operatore sicurezza, Amministratore sicurezza, Amministratore applicazioni e Amministratore applicazioni cloud.
• La funzionalità è disponibile solo nei cloud pubblici.

Redmond ha confermato l'origine dei dati interrogando direttamente i log di accesso e confrontando il risultato con il numero del portale. La riconciliazione funziona solo una volta separati gli ospiti: il suo tenant ha restituito dieci utenti univoci con un accesso riuscito soggetto ad Accesso condizionale, ma solo tre di loro erano membri — e tre era esattamente ciò che riportava il portale. Su questa base ha ritenuto «probabile che i log di accesso siano la base delle informazioni mostrate nell'interfaccia di amministrazione».

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)

Confronta il numero dei membri con il conteggio degli utenti Accesso condizionale del portale, mai con il totale. Anche gli ospiti vengono valutati dalle tue policy, ma vengono fatturati come utenti attivi mensili anziché come posti P1 — lasciarli inclusi è il modo più rapido per convincersi che il portale sbaglia quando in realtà non è così.

Perché l'avviso sottostima la tua reale esposizione di licenza

Ecco il divario che rende il banner fuorviante in entrambe le direzioni. Il portale misura gli utenti i cui accessi sono stati valutati il mese scorso. La licenza, come generalmente intesa, si applica agli utenti che sono target di una policy — che si siano connessi oppure no.

Una policy con ambito Tutti gli utenti mette nel suo ambito ogni account membro. Il personale in congedo parentale, i lavoratori stagionali, gli account inattivi ma licenziati, e chiunque semplicemente non abbia effettuato l'accesso durante la finestra di misurazione, ricadono tutti fuori dal conteggio «valutato» pur rimanendo nell'ambito della policy. Il portale riporterà tranquillamente un numero rassicurante mentre il tuo reale fabbisogno di licenze è molto più alto.

Redmond ammette con franchezza che Microsoft non ha risolto questa ambiguità. In un approfondimento pubblicato il 18 agosto 2026 ha scritto che «i requisiti per le policy di accesso condizionale sono un po' vaghi», che «non trovo nessun'altra dichiarazione Microsoft con una definizione più precisa del requisito di licenza», e che «le recenti notifiche sul divario di licenza non spiegano nemmeno come viene calcolato l'ambito di licenza». La sua lettura pratica propende per il lato target-non-valutato: «se un tenant ha distribuito policy di accesso condizionale per proteggere le connessioni, è probabile che la maggior parte, se non tutti, gli account utente (membri) debbano essere licenziati».

Due ulteriori complicazioni distorcono il confronto:

• Gli ospiti vengono fatturati diversamente. La documentazione sui prezzi di External ID di Microsoft conferma che il modello di fatturazione a utenti attivi mensili (MAU) «si applica a tutti gli utenti ospiti» con UserType impostato su Guest, e precisa esplicitamente che «non si applica agli utenti che hanno origine all'interno dell'organizzazione e hanno un valore UserType di Member». Il traffico degli ospiti che raggiunge le tue policy non è un problema di posti P1 — ma può comunque gonfiare i conteggi grezzi degli accessi, come è successo nello stesso tenant di Redmond. Se le identità esterne rappresentano una quota rilevante del tuo traffico, esamina separatamente l'esposizione degli account ospite.
• I diritti possono esistere senza raggiungere le persone giuste. Nel tenant di Redmond, le licenze erano disponibili eppure due dei tre account che utilizzavano effettivamente l'Accesso condizionale possedevano Office 365 E3, che non include né P1 né P2. Il pool era adeguato; l'assegnazione no.

Cosa succede davvero se le tue licenze Entra ID P1 scadono

Questo è il punto che vale la pena interiorizzare, perché è un comportamento documentato e non una speculazione. La panoramica dell'Accesso condizionale di Microsoft afferma: «Quando le licenze richieste per l'Accesso condizionale scadono, le policy non vengono disabilitate né eliminate automaticamente. Questo stato di grazia consente ai clienti di migrare via dalle policy di Accesso condizionale senza un cambiamento improvviso della loro postura di sicurezza. Puoi visualizzare ed eliminare le policy rimanenti, ma non puoi aggiornarle.»

Leggi con attenzione. La tua applicazione dei controlli non collassa — il che è, di fatto, un buon design. Ma il tuo piano principale di controllo degli accessi entra in un blocco delle modifiche: visualizzazione ed eliminazione restano disponibili, l'aggiornamento no. Un incidente che richiede di inasprire urgentemente una policy, aggiungere un'esclusione per un account di accesso di emergenza (break-glass), o restringere un ambito, diventa qualcosa che non puoi fare finché la situazione delle licenze non viene risolta. È un rischio di disponibilità e di risposta agli incidenti, non un rischio di fatturazione — ed è la vera ragione per riconciliare i numeri ora.

Rilevamento

Parti dal numero fornito da Microsoft per risalire a quello che governa realmente la tua posizione di licenza.

Il portale non può rispondere a quest'ultima riga, quindi devi enumerare tu stesso l'ambito delle policy. Solo le policy abilitate applicano effettivamente qualcosa — le policy in modalità solo report valutano ma non concedono né bloccano:

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

Un valore IncludeUsers pari a All mette ogni utente nell'ambito, ospiti inclusi — filtra su userType eq 'Member' prima di contare, perché solo i membri generano fabbisogno di posti P1. Quando l'ambito è definito da un gruppo o da un ruolo di directory, risolvilo in modo transitivo — sia i gruppi annidati sia l'appartenenza ai ruoli ampliano l'insieme effettivo, motivo per cui Get-MgGroupTransitiveMemberAsUser e Get-MgDirectoryRoleMember hanno un posto in qualsiasi versione seria di questo script. Lo script di riconciliazione completo di Redmond, su cui si basano le query di questa sezione, fa esattamente questo ed è pubblicato nel repository GitHub di Microsoft 365 for IT Pros.

Stabilisci quindi chi possiede realmente un piano di servizio P1 o P2 attivo. Gli ID dei piani di servizio sono pubblicati nel riferimento ai piani di servizio di Microsoft: AAD_PREMIUM è 41781fb2-bc02-4b7c-bd55-b576c07bb09d e AAD_PREMIUM_P2 è 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)

Il controllo di CapabilityStatus non è opzionale. Un piano di servizio può ancora comparire su un account dopo la rimozione di una licenza, quindi la sola presenza sovrastima la tua popolazione licenziata.

Considera l'output come un punto di partenza per l'indagine, non come un certificato di conformità. Redmond è esplicito sul limite di questo tipo di script: «non affermo che lo script dimostri la conformità del tenant ai requisiti di licenza Microsoft. Programmare partendo da informazioni imprecise è sempre difficile, e Microsoft non pubblica una definizione precisa del consumo di licenze dell'Accesso condizionale».

Remediation

1. Riconcilia prima di acquistare. Confronta l'insieme degli account target ma non licenziati, derivato da Graph, con la tua riserva di diritti. Un banner di eccedenza causato da un'assegnazione errata non costa nulla da correggere.
2. Spiega il divario con prove, non supposizioni. Identità duplicate, account secondari amministrativi, account di servizio e ospiti spiegano il divario ciascuno a modo suo. Documenta come ogni account secondario corrisponde a una persona licenziata — questo documento è ciò che un audit o una conversazione di regolarizzazione richiederà.
3. Restringi l'ambito deliberatamente, non difensivamente. Restringere una policy riduce contemporaneamente l'esposizione di licenza e la copertura di sicurezza. Non eliminare mai la copertura di base per amministratori, tutti gli utenti o tutte le applicazioni solo per migliorare un numero.
4. Verifica le esclusioni già che ci sei. Gli elenchi di esclusione si accumulano. Le esclusioni obsolete a livello utente e le esclusioni di gruppo sovradimensionate rimuovono silenziosamente persone dall'applicazione dei controlli, e distorcono anche il conteggio degli utenti valutati. Mantieni quelle deliberate — i tuoi account di accesso di emergenza (break-glass) devono rimanere esclusi e monitorati.
5. Conferma P2 separatamente. Le policy basate sul rischio di accesso e sul rischio utente richiedono ID Protection. Se la scheda ID Protection mostra un utilizzo che non riesci a spiegare, verifica per cosa sono realmente licenziate le tue funzionalità P2.
6. Ricontrolla dopo il ritardo. I dati di utilizzo riflettono il mese precedente e possono richiedere fino a tre giorni per aggiornarsi. Non giudicare una remediation dal portale lo stesso pomeriggio in cui l'hai applicata.

Come EtcSec rileva questo problema

Il banner di licenza è il sintomo di qualcosa che EtcSec verifica direttamente: il divario tra ciò che le tue policy di Accesso condizionale dichiarano di coprire e ciò che effettivamente applicano. Un audit Azure di EtcSec enumera l'ambito delle policy abilitate nello stesso modo delle query Graph sopra riportate, poi segnala CA_NO_POLICY_ALL_USERS quando nessuna policy è rivolta all'intera popolazione di membri, CA_POLICY_REPORT_ONLY quando le policy valutano ma non applicano mai, CA_EXCESSIVE_EXCLUSIONS e CA_USER_EXCLUSIONS_STALE quando gli elenchi di esclusione sono cresciuti oltre la loro giustificazione, CA_NO_BREAK_GLASS_EXCLUSION quando l'accesso di emergenza non ha alcun percorso protetto, e CA_NO_RISK_BASED_SIGNIN quando i diritti P2 sono pagati ma non utilizzati.

Quest'ultimo punto vale in entrambe le direzioni: una capacità P2 inutilizzata è un'eccedenza di licenza al contrario. Per una revisione più ampia della progettazione delle policy, consulta la nostra guida sulle lacune dell'Accesso condizionale Entra ID e la guida pratica all'audit di sicurezza di Entra ID.