Microsoft Entra ID Principios de agosto de 2026: retiro de MemberOf, campañas de adopción de passkeys y reemplazo de VPN con Zero Trust

Agosto se perfila como un mes decisivo para los administradores de Microsoft Entra ID. Entre el inminente despliegue de passkeys como método predeterminado el 1 de septiembre y un flujo constante de nuevos anuncios, hay mucho que seguir. La actualización de hoy trae tres novedades significativas: un cambio disruptivo para los grupos dinámicos que obligará a muchas organizaciones a replantear su arquitectura de grupos, una herramienta impulsada por IA para ayudar a gestionar la migración a passkeys y un nuevo liderazgo de pensamiento sobre cómo ir más allá de las VPN tradicionales.

1. Retiro del operador de reglas MemberOf — un cambio disruptivo para los grupos dinámicos (MC1448379)

Anunciado hoy mediante la notificación del Message Center MC1448379, Microsoft pone fin a la vista previa pública del operador de reglas memberOf en Entra ID el 3 de noviembre de 2026. Este operador, que ha estado en vista previa desde aproximadamente 2022, permitía a los administradores crear reglas de pertenencia dinámica que toman miembros de grupos existentes en lugar de depender de atributos de usuarios o dispositivos. No pasará a disponibilidad general.

Qué se ve afectado

El retiro afecta a tres áreas:

• Grupos de pertenencia dinámica que usan reglas memberOf
• Unidades administrativas dinámicas que usan reglas memberOf
• Políticas de asignación automática de entitlement management que usan reglas memberOf

Fechas clave

No hay opción de exclusión ni extensión disponible.

Por qué Microsoft lo retira

La decisión se reduce a la escala y la confiabilidad. Microsoft descubrió que incluso una sola regla memberOf en un tenant puede causar demoras de procesamiento en todo el tenant en TODOS los grupos dinámicos, no solo en el que usa el operador. Este impacto en el rendimiento fue tan fundamental que Microsoft decidió que la característica no podía soportarse a escala y, en lugar de seguir permitiendo que las organizaciones dependieran de una característica en vista previa con estas limitaciones, la están retirando.

Impacto de no actuar

Si no migra antes de las fechas límite, las consecuencias son graves:

• Acceso desactualizado: los nuevos usuarios no recibirán el acceso que necesitan, mientras que los antiguos miembros conservarán el acceso a Teams, SharePoint y otros recursos
• Conditional Access roto: las políticas que evalúan las pertenencias a grupos trabajarán con datos obsoletos
• Deriva de licencias: el licenciamiento basado en grupos no asignará ni eliminará licencias correctamente: los usuarios pueden conservar licencias que no deberían tener o perder licencias que necesitan
• Ámbito administrativo obsoleto: las unidades administrativas dinámicas tendrán una pertenencia desactualizada, lo que afecta el ámbito administrativo delegado
• Entitlement management congelado: las políticas de asignación automática ya no agregarán ni eliminarán asignaciones de paquetes de acceso

Cómo identificar las configuraciones afectadas

Empiece ejecutando estos comandos de PowerShell con el módulo Microsoft Graph PowerShell:

# Find dynamic groups using memberOf
Get-MgGroup -Filter "startsWith(membershipRule,'user.memberOf') or startsWith(membershipRule,'device.memberOf')" | Select-Object DisplayName, Id, MembershipRule, MembershipRuleProcessingState

# Find dynamic AUs using memberOf
Get-MgDirectoryAdministrativeUnit -All -Property Id, DisplayName, MembershipRule, MembershipType | Where-Object { $_.MembershipType -eq "Dynamic" -and $_.MembershipRule -match "memberOf" } | Select-Object DisplayName, Id, MembershipRule

Para las políticas de asignación automática de entitlement management, use Graph PowerShell para consultar las políticas de paquetes de acceso que hacen referencia a memberOf en sus reglas de asignación.

La comunidad también ha dado un paso al frente: AdminDroid publicó un script completo de PowerShell que examina los tres tipos de configuración y genera informes CSV: Find Entra ID Configurations with Deprecated MemberOf Operator

Opciones de migración

La guía oficial de Microsoft ofrece dos rutas principales, pero hay una tercera opción práctica:

Opción 1: Reemplazar con reglas dinámicas basadas en atributos. Si la misma pertenencia puede expresarse con atributos de usuario o dispositivo (department, extensionAttribute, jobTitle, etc.), reescriba la regla. Por ejemplo, si su grupo memberOf incorporaba a miembros de los grupos “Sales” y “Marketing” que a su vez se definían por departamento, puede crear una regla como user.department -in ['Sales','Marketing'].

Opción 2: Convertir a pertenencia asignada. Cambie el grupo de Dinámico a Asignado en el centro de administración de Entra (Groups > All Groups > abrir el grupo > cambiar Membership type de Dynamic a Assigned). Gestione la pertenencia manualmente o mediante automatización. Es la mejor opción para grupos pequeños o que no cambian con frecuencia.

Opción 3: Script de sincronización con PowerShell. Cree un script programado que lea la pertenencia de sus grupos de origen y la sincronice con el grupo de destino. Es la opción más flexible y replica de cerca el comportamiento de memberOf, pero agrega sobrecarga operativa y el script se convierte en un punto de mantenimiento.

Validación antes de cambiar

Cualquiera que sea el reemplazo que elija, valídelo antes de implementarlo en producción. Exporte los miembros de su antiguo grupo memberOf, cree el reemplazo, espere a que el procesamiento termine, exporte los miembros del nuevo grupo y compare:

# Export members of the old memberOf group
$oldGroupId = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"
Get-MgGroupMember -GroupId $oldGroupId -All | Select-Object @{N='Id';E={$_.Id}} | Export-Csv -Path .\OldGroup-Members.csv -NoTypeInformation

# Export members of the new replacement group
$newGroupId = "yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy"
Get-MgGroupMember -GroupId $newGroupId -All | Select-Object @{N='Id';E={$_.Id}} | Export-Csv -Path .\NewGroup-Members.csv -NoTypeInformation

# Compare
$old = Import-Csv .\OldGroup-Members.csv
$new = Import-Csv .\NewGroup-Members.csv
$diff = Compare-Object -ReferenceObject $old.Id -DifferenceObject $new.Id
if ($diff) { Write-Host "Differences found:" -ForegroundColor Yellow; $diff | Format-Table -AutoSize }
else { Write-Host "Membership matches. Safe to switch." -ForegroundColor Green }

Reacción de la comunidad

El anuncio ha generado un importante rechazo por parte de la comunidad de IAM. En el r/sysadmin de Reddit, Spiceworks y LinkedIn, los administradores han expresado su frustración porque una característica en vista previa durante cuatro años se está retirando sin un reemplazo directo. Muchas organizaciones construyeron sus arquitecturas de licenciamiento, Conditional Access y asignación de aplicaciones en torno a memberOf durante su prolongado periodo de vista previa. La falta de una alternativa 1:1 para la lógica de grupos anidados significa un retrabajo significativo para los tenants afectados.

Esta es una preocupación legítima. Si bien el razonamiento de rendimiento de Microsoft es sólido (la degradación del procesamiento en todo el tenant causada por una sola regla es un problema real), el prolongado periodo de vista previa creó una falsa sensación de permanencia. Las organizaciones que adoptaron memberOf de buena fe ahora enfrentan un cronograma comprimido para rehacer sus arquitecturas de grupos.

2. Campañas de adopción de passkeys con el Conditional Access Optimization Agent (vista previa pública)

En una noticia mejor sincronizada, Microsoft ha presentado una nueva y potente herramienta para ayudar a las organizaciones a gestionar la próxima migración a passkeys. El Conditional Access Optimization Agent, basado en Security Copilot, ahora admite campañas de adopción de passkeys en vista previa pública.

Qué hace

El agente ofrece un enfoque estructurado y dirigido por IA para implementar la autenticación resistente al phishing:

1. Evalúa la preparación de usuarios y dispositivos — Identifica qué usuarios tienen dispositivos compatibles, cuáles necesitan actualizaciones de dispositivo y cuáles ya tienen passkeys registradas
2. Genera un plan de implementación — Incluye la duración estimada de la campaña, el número de usuarios objetivo y un desglose de las categorías de preparación de los usuarios
3. Guía a los usuarios a través de los pasos — Envía notificaciones de Microsoft Teams que les piden actualizar dispositivos, registrar passkeys o prepararse para la aplicación de las políticas
4. Aplica políticas de Conditional Access — Crea automáticamente políticas de CA primero en modo solo informe y luego aplica los requisitos de autenticación resistente al phishing una vez que los usuarios están listos

El agente se ejecuta automáticamente cada 24 horas para evaluar el progreso y avanzar a los usuarios por las etapas de la campaña a medida que se cumplen los requisitos previos.

Por qué esto importa ahora

Con las passkeys convirtiéndose en el método de autenticación predeterminado en Entra ID a partir del 1 de septiembre de 2026, y con la autenticación por SMS/voz proporcionada por Microsoft que se retirará el 1 de febrero de 2027, las organizaciones necesitan herramientas estructuradas para gestionar esta migración a escala. El agente de campañas de adopción de passkeys aborda directamente esta necesidad.

Comenzar con los usuarios administradores privilegiados de forma predeterminada es el enfoque correcto de seguridad primero: son los objetivos de mayor valor para los atacantes y las cuentas donde la autenticación resistente al phishing ofrece la reducción de riesgo más inmediata.

Requisitos y limitaciones

Requisitos:

• Licencia mínima de Microsoft Entra ID P1
• Unidades de cómputo de seguridad (SCU) disponibles: en promedio, menos de 1 SCU por ejecución del agente
• Las passkeys deben estar habilitadas en la Authentication Methods Policy
• Se requiere el rol de Security Administrator (el rol de Conditional Access Administrator por sí solo es insuficiente)

Limitaciones a tener en cuenta:

• La configuración de la campaña (público objetivo, periodos de gracia, aplazamientos) no puede modificarse una vez iniciada la campaña: planifique a fondo antes de lanzarla
• El agente no verifica si los usuarios objetivo tienen habilitadas las passkeys en la Authentication Methods Policy: debe configurar este requisito previo con antelación
• El aplazamiento actualmente solo se admite para usuarios con los roles de Security Copilot Owner o Security Copilot Contributor
• Los dispositivos inactivos se filtran automáticamente (por ejemplo, portátiles que no se usan desde hace 8 meses)
• Las cuentas de break-glass deben excluirse explícitamente

Cómo habilitarlo

1. Inicie sesión en el centro de administración de Microsoft Entra como mínimo como Security Administrator
2. Vaya a Conditional Access Optimization Agent > Settings
3. En Agent capabilities, seleccione Allow agent to create passkey adoption campaigns
4. El agente comienza a analizar su tenant para identificar a los usuarios elegibles para una campaña de passkeys

Para obtener documentación detallada, consulte Deploy passkey adoption campaigns with the Conditional Access Optimization Agent (Preview).

3. Elimine las brechas de la VPN con acceso centrado en la identidad: nuevo liderazgo de pensamiento

El 5 de agosto, Microsoft publicó una nueva entrada de blog de Janice Ricketts titulada “End VPN gaps with identity-first access”. Si bien no es un anuncio de producto, vale la pena leerla para cualquiera que esté planificando una iniciativa de modernización de VPN.

El argumento central

Las VPN tradicionales extienden el acceso a la red, pero no evalúan continuamente la identidad, la postura del dispositivo, la ubicación, el riesgo del usuario ni el contexto de la sesión. Esto deja a las aplicaciones de IA, SaaS, aplicaciones locales, servicios no gestionados y el tráfico de internet con protección desigual. Zero Trust cierra esta brecha al poner la identidad y las políticas en el centro de cada decisión de acceso.

La publicación posiciona a Conditional Access como el motor de políticas y a Global Secure Access (que comprende Entra Internet Access y Entra Private Access) como la capa de aplicación que extiende los controles basados en identidad a todos los tipos de recursos.

Conclusiones clave

• Aplique los principios de Zero Trust en todas partes, no solo en Microsoft 365 y las aplicaciones SaaS principales
• Use el mismo modelo basado en identidad en aplicaciones de IA, aplicaciones locales, SaaS y tráfico de internet
• Extienda el Conditional Access basado en riesgo más allá de las aplicaciones en la nube para proteger todos los recursos
• Reduzca la complejidad y los costos retirando las arquitecturas con gran dependencia de VPN en favor del acceso basado en políticas
• El objetivo es un único modelo de seguridad reutilizable en todos los tipos de recursos en lugar de modelos de políticas separados para cada uno

Valor práctico

Para las organizaciones que justifican ante la dirección las iniciativas de reemplazo de VPN, esta publicación ofrece un marco conciso para el caso de negocio: menor riesgo de filtración mediante respuestas automatizadas basadas en políticas, operaciones más rápidas al reducir la complejidad de las VPN, mejor experiencia de usuario y mayor eficiencia de costos al reducir el hardware local y las herramientas de seguridad superpuestas.

Qué significa esto para su organización

Acciones inmediatas (esta semana)

1. Audite el uso de memberOf — Ejecute los comandos de PowerShell anteriores para identificar todos los grupos dinámicos, unidades administrativas y políticas de entitlement management afectados. La fecha límite del 27 de octubre para las políticas de entitlement management está a menos de 12 semanas.

2. Inventarie sus usuarios de MFA por SMS/voz — Use el script de PowerShell entra-sms-voice-usage-analyzer para identificar a los usuarios que todavía usan SMS/voz antes de la habilitación automática del 1 de septiembre.

3. Evalúe el CA Optimization Agent — Si tiene licencias de Security Copilot, explore la función de campañas de adopción de passkeys para automatizar la migración a passkeys de sus usuarios privilegiados.

Planificación a corto plazo (próximos 30 días)

1. Elabore su plan de migración de memberOf — Para cada configuración afectada, documente su propósito (licenciamiento, Conditional Access, acceso a Teams, asignación de aplicaciones), elija una estrategia de reemplazo y priorice por complejidad e impacto.

2. Pruebe el registro de passkeys — Verifique que sus perfiles de passkeys, la política de métodos de autenticación y la compatibilidad de dispositivos estén listos para el despliegue del 1 de septiembre.

3. Revise la hoja de ruta de reemplazo de VPN — Si todavía depende de VPN tradicionales para acceder a recursos locales o en la nube, use el marco de Global Secure Access para evaluar una iniciativa de modernización hacia Zero Trust.

Resumen de fechas clave

Manténgase informado

El panorama de Entra ID está evolucionando rápidamente. Entre la migración a passkeys, el retiro de memberOf y el cambio más amplio hacia la gestión de identidades impulsada por IA, los equipos de TI deben mantenerse proactivos. Seguiremos dando seguimiento a estos cambios y brindando guías prácticas a medida que surjan nuevos anuncios.

Siga la conversación en X en https://x.com/kkaminsk para obtener actualizaciones y análisis en tiempo real.

Big Hat Group Inc. es un socio de Microsoft con más de 20 años de experiencia ayudando a organizaciones a sortear transformaciones de identidad y seguridad. Contáctenos para analizar cómo estos cambios afectan su entorno y cómo podemos ayudarle a planificar su migración.