Exceso licencia acceso condicional Entra: qué significa realmente el nuevo banner

A principios de agosto de 2026, los administradores que abrían la página de Acceso condicional en el centro de administración de Microsoft Entra empezaron a ver un nuevo banner. Este exceso licencia acceso condicional Entra indica que algunas de tus políticas protegen a más usuarios de los que permiten tus derechos de licencia actuales — y se ha interpretado ampliamente, y de forma errónea, como el primer paso hacia una facturación automatizada. No lo es. Es una señal de visibilidad. Más importante aún, la cifra que hay detrás se calcula de una manera que casi con toda seguridad subestima cuántas licencias de Microsoft Entra ID P1 requiere realmente el alcance de tus políticas.

Qué es el exceso licencia acceso condicional entra

Microsoft desplegó el aviso sin anuncio previo, y los primeros relatos públicos aparecieron con pocos días de diferencia. ourcloudnetwork (11 de agosto de 2026) informó que llevaba apareciendo «en las últimas semanas» en la página de resumen de Acceso condicional, y LazyAdmin (12 de agosto de 2026) lo situó en la misma página. Ambos reproducen el banner completo así: «Exceso de licencias. Algunas políticas de Acceso condicional protegen a más usuarios de los que permiten tus derechos de licencia actuales.» El MVP de Microsoft 365 Tony Redmond lo documentó el 13 de agosto de 2026, citando el mensaje que indica a los tenants que «algunas políticas de Acceso condicional protegen a más usuarios de los que permiten tus derechos de licencia actuales».

El enlace dentro del mensaje abre la documentación de Microsoft sobre información de uso de licencias, donde residen las cifras subyacentes.

El requisito de licencia en sí no ha cambiado. La presentación de Acceso condicional de Microsoft indica claramente que «usar esta función requiere licencias de Microsoft Entra ID P1», añade que los clientes de Microsoft 365 Business Premium también pueden usar las funciones de Acceso condicional, y señala que las políticas basadas en riesgo (riesgo de inicio de sesión y riesgo de usuario) requieren Microsoft Entra ID Protection, una función P2.

Cómo cuenta Microsoft a los usuarios de Acceso condicional

La cifra que impulsa el banner proviene de la página Uso de licencias, accesible en Facturación > Licencias dentro del centro de administración de Entra. La documentación de Microsoft describe un modelo deliberadamente simplificado: una «métrica principal» por nivel de licencia, repartida en dos pestañas.

Cada pestaña incluye un informe de uso de funciones que compara el consumo con los derechos de licencia mediante tres indicadores: Licencias usadas, Licencias no usadas y Pico de uso — este último es, en palabras de Microsoft, «uso que supera el número de licencias a las que tienes derecho». Los derechos no son solo compras independientes de P1/P2: el recuento «refleja el número total de licencias en todos los productos que incluyen cada nivel de funcionalidad de Microsoft Entra ID», lo que abarca Microsoft Entra Suite, ID Governance, Verified ID, Private Access e Internet Access.

Tres advertencias operativas importan antes de actuar sobre esta cifra:

• Los datos muestran el uso del mes anterior y «pueden tardar hasta tres días en actualizarse». Nunca estás viendo el presente.
• El rol con menos privilegios que puede leer la página es Lector de informes; Lector global, Lector de seguridad, Operador de seguridad, Administrador de seguridad, Administrador de aplicaciones y Administrador de aplicaciones en la nube también funcionan.
• La función solo está disponible en nubes públicas.

Redmond corroboró de dónde proceden los datos consultando directamente los registros de inicio de sesión y comparando el resultado con la cifra del portal. La reconciliación solo funciona una vez se separan los invitados: su tenant devolvió diez usuarios únicos con un inicio de sesión de Acceso condicional exitoso, pero solo tres de ellos eran miembros — y tres era exactamente lo que reportaba el portal. Con esta base, concluyó que es «probable que los registros de inicio de sesión sean la base de la información mostrada en el centro de administración».

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)

Compara la cifra de miembros con el recuento de usuarios de Acceso condicional del portal, nunca con el total. Los invitados también son evaluados por tus políticas, pero se facturan como usuarios activos mensuales en lugar de asientos P1 — dejarlos incluidos es la forma más rápida de convencerte de que el portal está equivocado cuando no lo está.

Por qué el aviso subestima tu exposición real de licencias

He aquí la brecha que hace que el banner sea engañoso en ambos sentidos. El portal mide a los usuarios cuyos inicios de sesión fueron evaluados el mes pasado. La licencia, tal como se entiende generalmente, se aplica a los usuarios que son objetivo de una política — se hayan conectado o no.

Una política con alcance Todos los usuarios pone en su alcance a cada cuenta de miembro. El personal en baja parental, los trabajadores estacionales, las cuentas inactivas pero licenciadas, y cualquiera que simplemente no inició sesión durante la ventana de medición, quedan fuera del recuento «evaluado» mientras permanecen dentro del alcance de la política. El portal reportará alegremente una cifra cómoda mientras tu necesidad real de licencias es mucho mayor.

Redmond reconoce con franqueza que Microsoft no ha resuelto esta ambigüedad. En un seguimiento publicado el 18 de agosto de 2026 escribió que «los requisitos para las políticas de acceso condicional son un poco difusos», que «no encuentro ninguna otra declaración de Microsoft con una definición más precisa del requisito de licencia», y que «las recientes notificaciones de brecha de licencia tampoco explican cómo se calcula el alcance de licencia». Su lectura práctica se inclina hacia el lado de objetivo-no-evaluado: «si un tenant ha desplegado políticas de acceso condicional para proteger conexiones, es probable que la mayoría, si no todas, las cuentas de usuario (miembros) necesiten estar licenciadas».

Dos complicaciones adicionales distorsionan la comparación:

• Los invitados se facturan de forma distinta. La documentación de precios de External ID de Microsoft confirma que el modelo de facturación por usuarios activos mensuales (MAU) «se aplica a todos los usuarios invitados» con UserType establecido en Guest, y precisa explícitamente que «no se aplica a los usuarios que se originan dentro de la organización y tienen un valor de UserType de Member». El tráfico de invitados que llega a tus políticas no es un problema de asiento P1 — pero puede seguir inflando los recuentos brutos de inicio de sesión, como ocurrió en el propio tenant de Redmond. Si las identidades externas representan una parte importante de tu tráfico, revisa por separado la exposición de cuentas invitadas.
• Los derechos pueden existir sin llegar a las personas correctas. En el tenant de Redmond, había licencias disponibles y, sin embargo, dos de las tres cuentas que realmente usaban Acceso condicional tenían Office 365 E3, que no incluye ni P1 ni P2. El fondo era suficiente; la asignación no lo era.

Qué ocurre realmente si caducan tus licencias Entra ID P1

Este es el punto que merece la pena interiorizar, porque es un comportamiento documentado y no una especulación. La presentación de Acceso condicional de Microsoft indica: «Cuando caducan las licencias necesarias para el Acceso condicional, las políticas no se deshabilitan ni se eliminan automáticamente. Este estado de gracia permite a los clientes migrar fuera de las políticas de Acceso condicional sin un cambio brusco en su postura de seguridad. Puedes ver y eliminar las políticas restantes, pero no puedes actualizarlas.»

Lee eso con atención. Tu aplicación de políticas no colapsa — lo cual es, de hecho, un buen diseño. Pero tu plano principal de control de acceso entra en congelación de cambios: ver y eliminar están disponibles, actualizar no. Un incidente que requiera endurecer una política con urgencia, añadir una exclusión para una cuenta de acceso de emergencia (break-glass), o restringir un alcance, se convierte en algo que no puedes hacer hasta que se resuelva la situación de licencias. Es un riesgo de disponibilidad y de respuesta a incidentes, no de facturación — y es la verdadera razón para reconciliar las cifras ahora.

Detección

Parte de la cifra que ofrece Microsoft para llegar a la que realmente rige tu posición de licencias.

El portal no puede responder a esta última fila, así que debes enumerar tú mismo el alcance de las políticas. Solo las políticas habilitadas aplican algo — las políticas en modo solo informe evalúan pero no conceden ni bloquean:

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 valor IncludeUsers de All pone a cada usuario en el alcance, invitados incluidos — filtra por userType eq 'Member' antes de contar, porque solo los miembros generan necesidades de asientos P1. Cuando el alcance se define por grupo o rol de directorio, resuélvelo de forma transitiva — tanto los grupos anidados como la pertenencia a roles amplían el conjunto efectivo, por lo que Get-MgGroupTransitiveMemberAsUser y Get-MgDirectoryRoleMember tienen su lugar en cualquier versión seria de este script. El script de reconciliación completo de Redmond, en el que se basan las consultas de esta sección, hace exactamente eso y está publicado en el repositorio de GitHub de Microsoft 365 for IT Pros.

A continuación, determina quién posee realmente un plan de servicio P1 o P2 activo. Los identificadores de plan de servicio se publican en la referencia de planes de servicio de Microsoft: AAD_PREMIUM es 41781fb2-bc02-4b7c-bd55-b576c07bb09d y AAD_PREMIUM_P2 es 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)

La comprobación de CapabilityStatus no es opcional. Un plan de servicio puede seguir apareciendo en una cuenta después de retirar una licencia, así que su sola presencia sobreestima tu población licenciada.

Trata el resultado como un punto de partida para la investigación, no como un certificado de cumplimiento. Redmond es explícito sobre el límite de este tipo de script: «no afirmo que el script demuestre el cumplimiento del tenant con los requisitos de licencia de Microsoft. Programar contra información imprecisa siempre es difícil, y Microsoft no publica una definición precisa del consumo de licencias de Acceso condicional».

Remediation

1. Reconcilia antes de comprar. Compara el conjunto de cuentas objetivo pero sin licencia, derivado de Graph, con tu reserva de derechos. Un banner de exceso causado por una mala asignación no cuesta nada corregir.
2. Explica la diferencia con evidencia, no con suposiciones. Identidades duplicadas, cuentas secundarias administrativas, cuentas de servicio e invitados explican la brecha cada uno a su manera. Documenta cómo cada cuenta secundaria corresponde a una persona licenciada — ese registro es lo que pedirá una auditoría o una conversación de regularización.
3. Ajusta el alcance de forma deliberada, no defensiva. Reducir una política disminuye a la vez la exposición de licencias y la cobertura de seguridad. Nunca elimines la cobertura base para administradores, todos los usuarios o todas las aplicaciones solo para mejorar una cifra.
4. Audita las exclusiones mientras estás en ello. Las listas de exclusión se acumulan. Las exclusiones obsoletas a nivel de usuario y las exclusiones de grupo sobredimensionadas retiran silenciosamente a personas de la aplicación de la política, y también distorsionan el recuento de usuarios evaluados. Conserva las deliberadas — tus cuentas de acceso de emergencia (break-glass) deben permanecer excluidas y monitorizadas.
5. Confirma P2 por separado. Las políticas de riesgo de inicio de sesión y riesgo de usuario requieren ID Protection. Si la pestaña ID Protection muestra un uso que no puedes justificar, verifica para qué están realmente licenciadas tus funciones P2.
6. Vuelve a comprobar después del retraso. Los datos de uso reflejan el mes anterior y pueden tardar hasta tres días en actualizarse. No juzgues una remediación por el portal la misma tarde en que la aplicaste.

Cómo lo detecta EtcSec

El banner de licencias es el síntoma de algo que EtcSec audita directamente: la brecha entre lo que tus políticas de Acceso condicional dicen cubrir y lo que realmente aplican. Una auditoría de Azure de EtcSec enumera el alcance de las políticas habilitadas de la misma forma que las consultas de Graph anteriores, y luego marca CA_NO_POLICY_ALL_USERS cuando ninguna política se dirige a toda la población de miembros, CA_POLICY_REPORT_ONLY cuando las políticas evalúan pero nunca aplican, CA_EXCESSIVE_EXCLUSIONS y CA_USER_EXCLUSIONS_STALE cuando las listas de exclusión han crecido más allá de su justificación, CA_NO_BREAK_GLASS_EXCLUSION cuando el acceso de emergencia no tiene ninguna ruta protegida, y CA_NO_RISK_BASED_SIGNIN cuando los derechos P2 se pagan pero no se usan.

Este último caso funciona en ambos sentidos: la capacidad P2 no utilizada es un exceso de licencia a la inversa. Para una revisión más amplia del diseño de políticas, consulta nuestra guía sobre las brechas de Acceso condicional en Entra ID y la guía práctica de auditoría de seguridad de Entra ID.