Aviso de Excesso de Licenciamento do Acesso Condicional Entra: O Que o Novo Banner Realmente Significa

No início de agosto de 2026, administradores que abriam a página de Acesso Condicional no Microsoft Entra admin center começaram a ver um novo banner. O Aviso de Excesso de Licenciamento do Acesso Condicional Entra informa que algumas de suas políticas estão protegendo mais usuários do que suas licenças atuais permitem — e foi amplamente mal interpretado como o primeiro passo de uma cobrança automatizada. Não é isso. É um sinal de visibilidade. Mais importante ainda: o número por trás dele é calculado de uma forma que quase certamente subestima quantas licenças Microsoft Entra ID P1 o escopo das suas políticas realmente exige.

O Que É o Aviso de Excesso de Licenciamento do Acesso Condicional Entra

A Microsoft lançou o aviso sem anúncio, e os primeiros relatos públicos sobre ele surgiram com poucos dias de diferença entre si. A ourcloudnetwork (11 de agosto de 2026) relatou que ele vinha aparecendo "nas últimas semanas" na página de visão geral do Acesso Condicional, e a LazyAdmin (12 de agosto de 2026) situou-o na mesma página. Ambas reproduzem o banner completo como: "Licensing overage. Some Conditional Access policies are protecting more users than your current licensing entitlements allow." O MVP da Microsoft 365 Tony Redmond documentou isso em 13 de agosto de 2026, citando a mensagem que informa aos tenants que algumas políticas de Acesso Condicional estão protegendo mais usuários do que suas licenças atuais permitem.

O link dentro da mensagem abre a documentação de License Usage Insights da Microsoft, de onde vêm os números subjacentes.

A base de licenciamento em si não mudou. A visão geral do Acesso Condicional da Microsoft afirma claramente que o uso desse recurso exige licenças Microsoft Entra ID P1, acrescenta que clientes do Microsoft 365 Business Premium também podem usar recursos de Acesso Condicional, e observa que políticas baseadas em risco (risco de sign-in e risco do usuário) exigem o Microsoft Entra ID Protection, um recurso P2.

Como a Microsoft Conta os Usuários de Acesso Condicional

O número por trás do banner vem da página License usage, acessível em Billing > Licenses no Entra admin center. A documentação da Microsoft descreve um modelo deliberadamente simplificado: uma "métrica principal" por nível de licença, dividida em duas abas.

Cada aba traz um relatório de uso do recurso que compara o consumo com as licenças usando três indicadores: Licenses Used, Licenses Not Used e Usage Spike — este último sendo, nas palavras da Microsoft, "uso que excede a quantidade de licenças a que você tem direito". As licenças não são apenas compras isoladas de P1/P2: a contagem "reflete o número total de licenças em todos os produtos que incluem cada nível da funcionalidade do Microsoft Entra ID", o que abrange o Microsoft Entra Suite, ID Governance, Verified ID, Private Access e Internet Access.

Três ressalvas operacionais importam antes de agir com base nesse número:

• Os dados mostram o uso do mês passado e "podem levar até três dias para atualizar". Você nunca está vendo o dia de hoje.
• O papel com menos privilégios que consegue ler a página é Reports Reader; Global Reader, Security Reader, Security Operator, Security Administrator, Application Administrator e Cloud Application Administrator também funcionam.
• O recurso está disponível apenas em clouds públicas.

Redmond corroborou a origem dos dados consultando diretamente os logs de sign-in e comparando o resultado com o número do portal. A reconciliação só funciona depois de separar os convidados: seu tenant retornou dez usuários únicos com um sign-in de Acesso Condicional bem-sucedido, mas apenas três deles eram members — e três foi exatamente o que o portal informou. Com base nisso, ele julgou "provável que os logs de sign-in sejam a base das informações mostradas no 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 o número de members com a contagem de usuários de Acesso Condicional do portal, nunca com o total. Convidados também são avaliados pelas suas políticas, mas são cobrados como usuários mensais ativos em vez de assentos P1 — incluí-los é a forma mais rápida de se convencer de que o portal está errado quando não está.

Por Que o Aviso Subestima Sua Exposição Real de Licenciamento

Aqui está a lacuna que torna o banner enganoso nos dois sentidos. O portal mede usuários cujos sign-ins foram avaliados no mês passado. O licenciamento, como geralmente entendido, se aplica a usuários visados por uma política — tenham eles feito login ou não.

Uma política com escopo em Todos os usuários coloca cada conta member no escopo. Funcionários em licença parental, trabalhadores sazonais, contas inativas mas licenciadas, e qualquer pessoa que simplesmente não fez login durante a janela de medição — todos ficam fora da contagem "avaliada" enquanto permanecem dentro do escopo da política. O portal vai relatar de bom grado um número confortável, enquanto sua necessidade real de licenciamento é muito maior.

Redmond é franco ao dizer que a Microsoft não fechou essa ambiguidade. Em um follow-up publicado em 18 de agosto de 2026, ele escreveu que "os requisitos para políticas de acesso condicional são um pouco vagos", que "não consigo encontrar nenhuma outra declaração da Microsoft com uma definição mais precisa para o requisito de licenciamento", e que "as notificações recentes de lacuna de licenciamento também não explicam como o escopo de licenciamento é calculado". Sua leitura prática pende para o lado "visado, não avaliado": "se um tenant implantou políticas de acesso condicional para proteger conexões, é provável que a maioria, senão todas as contas de usuário (member) precisem ser licenciadas".

Duas outras nuances distorcem a comparação:

• Convidados são cobrados de forma diferente. A documentação de preços de External ID da Microsoft confirma que o modelo de cobrança por usuários mensais ativos (MAU) "se aplica a todos os usuários convidados" com UserType definido como Guest, e explicitamente "não se aplica a usuários que se originam de dentro da organização e têm um valor de UserType igual a Member". Tráfego de convidados atingindo suas políticas não é um problema de assento P1 — mas ainda pode inflar as contagens brutas de sign-in, como aconteceu no próprio tenant de Redmond. Se identidades externas forem uma grande parte do seu tráfego, revise a exposição das contas de convidado separadamente.
• Licenças podem existir sem chegar às pessoas certas. No tenant de Redmond, havia licenças disponíveis, mas duas das três contas que realmente usavam Acesso Condicional tinham Office 365 E3, que não inclui nem P1 nem P2. O pool era suficiente; a atribuição não era.

O Que Realmente Acontece Se as Licenças Entra ID P1 Expirarem

Esta é a parte que vale a pena internalizar, porque é um comportamento documentado, não especulação. A visão geral do Acesso Condicional da Microsoft afirma: "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."

Leia isso com atenção. Sua aplicação não desmorona — o que é um design genuinamente bom. Mas seu plano de controle de acesso primário entra em um congelamento de mudanças: visualizar e excluir estão disponíveis, atualizar não está. Um incidente que exija apertar urgentemente uma política, adicionar uma exclusão para uma conta break-glass ou restringir um escopo se torna algo que você não pode fazer até que o licenciamento seja resolvido. Isso é um risco de disponibilidade e resposta a incidentes, não um risco de cobrança — e é o verdadeiro motivo para reconciliar os números agora.

Detecção

Trabalhe partindo do próprio número da Microsoft até o número que realmente rege sua posição de licenciamento.

O portal não consegue responder à última linha, então enumere o escopo da política você mesmo. Apenas políticas ativadas aplicam alguma coisa — políticas em modo somente relatório avaliam, mas não concedem nem bloqueiam:

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

Um valor IncludeUsers igual a All coloca todos os usuários no escopo, convidados incluídos — filtre por userType eq 'Member' antes de contar, porque só os members geram a necessidade de assentos P1. Onde o escopo é definido por grupo ou função de diretório, resolva-o de forma transitiva — grupos aninhados e associação a funções expandem o conjunto efetivo, e é por isso que Get-MgGroupTransitiveMemberAsUser e Get-MgDirectoryRoleMember pertencem a qualquer versão séria deste script. O script completo de reconciliação de Redmond, no qual as consultas desta seção se baseiam, faz exatamente isso e está publicado no repositório GitHub do Microsoft 365 for IT Pros.

Em seguida, determine quem realmente possui um plano de serviço P1 ou P2 ativo. Os IDs dos planos de serviço estão publicados na referência de planos de serviço da 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)

A verificação de CapabilityStatus não é opcional. Um plano de serviço pode continuar aparecendo em uma conta depois que uma licença é removida, então a mera presença superestima sua população licenciada.

Trate a saída como ponto de partida de uma investigação, não como um certificado de conformidade. Redmond é explícito quanto ao limite de qualquer script assim: "Não afirmo que o script comprove a conformidade do tenant com os requisitos de licenciamento da Microsoft. Programar com base em informações imprecisas é sempre difícil, e a Microsoft não publica uma definição precisa do consumo de licenças de Acesso Condicional."

Remediação (Remediation)

1. Reconcilie antes de comprar. Compare o conjunto de contas visadas mas não licenciadas, obtido via Graph, com seu pool de licenças. Um banner de excesso causado por atribuição incorreta não custa nada para corrigir.
2. Explique a diferença com evidências, não suposições. Identidades duplicadas, contas administrativas secundárias, contas de serviço e convidados explicam a lacuna cada um à sua maneira. Documente como cada conta secundária corresponde a uma pessoa licenciada — esse é o registro que uma auditoria ou uma conversa de true-up vai exigir.
3. Restrinja o escopo de forma deliberada, não defensiva. Restringir uma política reduz a exposição de licenciamento e a cobertura de segurança ao mesmo tempo. Nunca elimine a cobertura baseline para admins, todos os usuários ou todos os apps só para melhorar um número.
4. Audite as exclusões enquanto estiver nisso. Listas de exclusão se acumulam com o tempo. Exclusões obsoletas em nível de usuário e exclusões de grupo superdimensionadas removem pessoas da aplicação silenciosamente, e também distorcem a contagem de usuários avaliados. Mantenha as deliberadas — suas contas break-glass precisam continuar excluídas e monitoradas.
5. Confirme o P2 separadamente. Políticas de sign-in baseado em risco e risco de usuário exigem o ID Protection. Se a aba ID Protection mostrar uso que você não consegue explicar, verifique para que seus recursos P2 estão realmente licenciados.
6. Reverifique depois da defasagem. Os dados de uso refletem o mês passado e podem levar até três dias para atualizar. Não julgue uma correção pelo portal na mesma tarde em que você a aplicou.

Como o EtcSec Detecta Isso

O banner de licenciamento é sintoma de algo que o EtcSec audita diretamente: a lacuna entre o que suas políticas de Acesso Condicional afirmam cobrir e o que elas realmente aplicam. Uma auditoria Azure do EtcSec enumera o escopo de políticas ativadas da mesma forma que as consultas Graph acima, e então sinaliza CA_NO_POLICY_ALL_USERS quando nenhuma política visa toda a população de members, CA_POLICY_REPORT_ONLY quando políticas avaliam mas nunca aplicam, CA_EXCESSIVE_EXCLUSIONS e CA_USER_EXCLUSIONS_STALE quando listas de exclusão cresceram além da sua justificativa, CA_NO_BREAK_GLASS_EXCLUSION quando o acesso de emergência não tem um caminho protegido, e CA_NO_RISK_BASED_SIGNIN quando licenças P2 são pagas, mas não usadas.

Esse último ponto funciona nos dois sentidos: capacidade P2 não utilizada é um excesso de licenciamento invertido. Para uma revisão mais ampla do design de políticas, veja nosso guia sobre lacunas do Acesso Condicional no Entra ID e o passo a passo prático de auditoria de segurança do Entra ID.