Novedades de Entra ID: Access Reviews GA, Teams passwordless

Microsoft Entra ID abrió septiembre de 2026 con una de las mayores tandas de actualizaciones mensuales del año: dos capacidades de gobernanza disponibles de forma general, una victoria más amplia de la autenticación sin contraseña para los dispositivos Teams, dos versiones preliminares públicas que amplían la identidad híbrida en ambas direcciones y dos anuncios de cambios relacionados con la seguridad. Si gestionas la identidad a escala, este es el mes para actualizar tu hoja de ruta.

El tema común de los siete puntos es la consolidación: consolida cómo revisas el acceso, consolida cómo autenticas los dispositivos compartidos, consolida cómo aprovisionas la identidad y consolida qué roles pueden responder a los incidentes.

Esto es lo que ha cambiado, por qué importa y qué hacer al respecto.

1. Revisiones de acceso centradas en el usuario — Disponibilidad general

Estado: GA Acción requerida: Evalúalas para tu programa de revisiones de acceso

Access Reviews ahora funciona como piensan realmente los revisores: por usuario, no por recurso. Las revisiones de acceso centradas en el usuario (UAR, por sus siglas en inglés) permiten a un revisor ver todos los recursos a los que puede acceder un único usuario dentro de una sola revisión, en lugar de ejecutar revisiones separadas por grupo o por aplicación.

Qué incluye

• Vista unificada: grupos, aplicaciones conectadas y aplicaciones no conectadas (con datos personalizados) en un único ámbito de revisión
• Compatibilidad con aplicaciones no conectadas: carga datos de acceso en CSV para que las aplicaciones que nunca se integran con Entra ID también puedan gobernarse
• Experiencia del revisor: las decisiones se toman en el portal My Access frente a una lista de recursos centrada en el usuario
• Licencias: requiere Microsoft Entra ID Governance o Entra Suite

Por qué es importante

Las revisiones de acceso tradicionales están centradas en los recursos: elige un grupo, revisa sus miembros y repite para cada grupo y aplicación. Para un usuario con acceso a 30 recursos, eso significa que su acceso se evalúa 30 veces por 30 revisores distintos — o, más probablemente, nunca se revisa de forma exhaustiva.

Las revisiones centradas en el usuario invierten el modelo. Un único revisor responsable de un usuario puede evaluar todo el acceso de ese usuario en una sola pasada. La compatibilidad con aplicaciones no conectadas es la función estrella aquí: incorpora el shadow IT y las SaaS no integradas a tu programa de gobernanza sin escribir ni una línea de código de integración.

Qué deben hacer los administradores

1. Identifica a tus usuarios de mayor riesgo — comienza las UAR con los usuarios privilegiados o proveedores que acumulan más accesos
2. Prepara los datos CSV de las aplicaciones no conectadas — inventaría las aplicaciones que están fuera de Entra ID y mapea quién tiene acceso
3. Asigna propietarios — cada recurso del catálogo y cada usuario debe tener un revisor claro
4. Ejecuta una UAR piloto junto a tus revisiones existentes antes de reestructurar el programa completo

2. Clonación de flujos de trabajo en Lifecycle Workflows — Disponibilidad general

Estado: GA Acción requerida: Simplifica tu cartera de flujos de trabajo

Los administradores de Lifecycle Workflows ahora pueden clonar un flujo de trabajo existente y usarlo como punto de partida para uno nuevo. Toda la configuración, las tareas, las condiciones de ejecución y los ajustes se copian; el clon se abre en la página Revisar y crear, donde puedes ajustar cualquier cosa antes de guardarlo.

Qué incluye

• Dos puntos de entrada: la acción Clonar en la lista de flujos de trabajo o la tarjeta «Clonar un flujo de trabajo existente» al crear un flujo de trabajo
• Fidelidad total: las tareas, los desencadenadores (triggers) y los ajustes se transfieren
• Ámbito: disponible en el centro de administración de Entra (no a través de Microsoft Graph)
• Rol necesario: Lifecycle Workflows Administrator

Por qué es importante

Muchos inquilinos ejecutan decenas de Lifecycle Workflows que solo difieren en uno o dos parámetros: departamentos distintos, desencadenadores distintos, secuencias de tareas distintas. Antes, cada uno tenía que construirse desde cero o a partir de una plantilla. La clonación convierte un flujo de trabajo existente y probado en un punto de partida, lo que reduce el tiempo de configuración de horas a minutos y disminuye los errores que conlleva reconstruir lógica de tareas compleja a mano.

Qué deben hacer los administradores

1. Audita los flujos de trabajo existentes — detecta los flujos casi duplicados que puedan regenerarse a partir de una única fuente
2. Establece una convención de clonación — define estándares de nomenclatura y documentación para que los clones sigan siendo manejables
3. Prueba los clones en un inquilino de ensayo (staging) antes de aplicarlos a los calendarios de producción

3. Entra Resource Accounts para dispositivos Teams — Disponibilidad general

Estado: GA para Teams Rooms, Teams Panels y Common Area Phones Acción requerida: Planifica la migración de las cuentas de dispositivos compartidos

La autenticación sin contraseña para los dispositivos compartidos de Teams ya está disponible de forma general en toda la gama de dispositivos. Las Microsoft Entra Resource Accounts sustituyen el inicio de sesión heredado basado en contraseña por credenciales vinculadas al dispositivo y protegidas por hardware — el mismo modelo que Microsoft usa para las cuentas de recurso sin contraseña en Teams Rooms en Windows, ahora ampliado a más dispositivos.

Qué incluye

• Ruta de migración: Portal de administración de Teams Rooms Pro → Planificación → Resource Accounts → pestaña Migración
• Licencias: se requiere una licencia de Teams Rooms o Teams Shared Space
• Identidad: la cuenta de recurso puede ser solo de Entra ID, sincronizada desde AD o respaldada por un IdP federado de terceros
• Limitación conocida: un dispositivo de reemplazo debe configurarse primero con una contraseña y migrarse después

Por qué es importante

Las contraseñas de los dispositivos compartidos son un problema de seguridad crónico: se comparten por naturaleza, se rotan con poca frecuencia y se guardan en lugares que acaban filtrándose. Si una contraseña de Teams Room se vio comprometida alguna vez, un atacante tenía inicio de sesión interactivo como usuario con licencia en un hardware que no controlas. Las credenciales vinculadas al dispositivo eliminan la contraseña por completo: no hay nada que suplantar con phishing, rociar con password spraying ni robar. Esto también reduce la carga de soporte que provocan las contraseñas obsoletas al romper el inicio de sesión de las salas en el peor momento posible.

Qué deben hacer los administradores

1. Inventaría las cuentas de dispositivos compartidos — cada Teams Room, Panel y teléfono con una cuenta basada en contraseña es candidato
2. Verifica la preparación de los dispositivos — comprueba la compilación de Windows, la versión de Android y las versiones de la aplicación Teams frente a los requisitos
3. Escalona las migraciones — usa primero la herramienta de migración del Portal de administración Pro en una sala piloto
4. Actualiza el gestor de contraseñas — elimina las credenciales de los dispositivos compartidos de tu gestión de secretos una vez migrados

4. Sincronización de sAMAccountName con Entra Domain Services — Versión preliminar pública

Estado: Versión preliminar pública Acción requerida: Evalúala para la compatibilidad de las aplicaciones heredadas

Los dominios administrados de Entra Domain Services ahora pueden sincronizar los valores de sAMAccountName desde el atributo onPremisesSamAccountName en Entra ID — lo que permite que las aplicaciones heredadas que dependen de sAMAccountName sigan funcionando cuando trasladas cargas de trabajo a Azure.

Qué incluye

• Dominios nuevos: habilitado de forma predeterminada
• Dominios existentes: opción de incorporación (opt-in) en la configuración de seguridad de Domain Services
• Requisitos: SKU Enterprise o Premium (no Standard); roles de Application Administrator y Groups Administrator para cambiar el ajuste
• Usuarios solo de nube: continúan usando la generación basada en mailNickname cuando no existe onPremisesSamAccountName
• Restricciones: sAMAccountName debe ser único, de 20 caracteres o menos y estar libre de caracteres especiales no admitidos

Por qué es importante

Muchas aplicaciones locales se escribieron antes de que los UPN fueran universales. Autentican o autorizan contra sAMAccountName y, cuando elevas esas cargas de trabajo a Azure con Entra Domain Services detrás, los nombres de cuenta que no coinciden rompen los recursos compartidos de archivos, los inicios de sesión SQL y las cuentas de servicio. Que Entra DS respete el sAMAccountName real elimina toda una clase de fallos de migración del tipo «en local funcionaba».

Qué deben hacer los administradores

1. Comprueba tu SKU — esta versión preliminar no se aplica a los dominios administrados de nivel Standard
2. Revisa la cobertura de onPremisesSamAccountName — los usuarios sincronizados necesitan el atributo poblado en Entra ID
3. Prueba primero en un dominio que no sea de producción — valida la autenticación de las aplicaciones heredadas antes de habilitarla de forma amplia

5. Cloud Sync: gestiona el ciclo de vida de la identidad desde la nube — Versión preliminar pública

Estado: Aprovisionamiento de grupos GA; aprovisionamiento de usuarios en versión preliminar pública Acción requerida: Evalúala como ruta de migración desde Connect Sync

Entra Cloud Sync ahora funciona en ambas direcciones. Además de aprovisionar desde AD hacia Entra ID, Cloud Sync puede aprovisionar usuarios, grupos y pertenencias a grupos desde Entra ID de vuelta a Active Directory local. Las organizaciones cloud-first ahora pueden mantener Entra ID como fuente autoritativa mientras siguen poblando AD para las aplicaciones heredadas, los servidores de archivos y los sistemas dependientes de Kerberos.

Qué incluye

• Identidades admitidas: usuarios nativos de nube, usuarios convertidos de Source of Authority, invitados B2B, grupos de seguridad
• Requisitos previos: agente de aprovisionamiento v1.1.3730.0 o posterior, esquema de AD DS con msDS-ExternalDirectoryObjectId (Windows Server 2016 o posterior), Entra ID P1
• Límites: no se admiten grupos de más de 50.000 miembros ni inquilinos de más de 150.000 objetos
• Cadencia de sincronización: el aprovisionamiento de grupos se ejecuta cada 20 minutos
• Nota sobre la conversión de SoA: conserva el SID del grupo y puede mantener la ruta de OU original

Por qué es importante

Esta es la pieza que faltaba en la historia de la migración de Connect Sync a Cloud Sync. La razón por la que muchos inquilinos se quedaron en Connect Sync no era el motor de sincronización en sí, sino la dependencia del directorio con AD. El aprovisionamiento inverso de Cloud Sync elimina ese bloqueo. Combinado con versiones anteriores, ahora puedes ejecutar un ciclo de vida de identidad genuinamente cloud-first: RR. HH. escribe en Entra ID, Entra ID aprovisiona los usuarios y AD recibe exactamente las cuentas que necesitan las cargas de trabajo locales — sin ningún servidor de Connect Sync en el camino.

Qué deben hacer los administradores

1. Mapea las aplicaciones dependientes de AD — conoce exactamente qué sigue necesitando cuentas locales antes de migrar
2. Planifica la huella del agente — el agente de aprovisionamiento sustituye a los servidores de Connect Sync en este modelo
3. Prueba el aprovisionamiento de invitados B2B — que los usuarios externos fluyan hacia AD es potente, pero necesita un control cuidadoso del ámbito
4. Vigila los límites de objetos — los inquilinos muy grandes seguirán necesitando Connect Sync

6. Ampliación del rol Security Administrator — Anuncio de cambio

Estado: Despliegue progresivo; completado a finales de septiembre de 2026 Acción requerida: Revisa las asignaciones de roles y los runbooks del SOC

El rol integrado Security Administrator se está ampliando para incluir acciones de respuesta a incidentes de identidad sobre usuarios no privilegiados: deshabilitar o habilitar cuentas de usuario, revocar sesiones activas y forzar restablecimientos de contraseña.

Qué incluye

• Nuevos permisos: deshabilitar usuario, habilitar usuario, revocar sesiones, forzar el restablecimiento de contraseña
• Ámbito: solo usuarios no privilegiados — no Global Administrators ni otras cuentas de alto privilegio
• Gobernanza: los controles de auditoría y privilegio mínimo existentes siguen aplicándose
• Contexto: continúa la línea del rol SOC Identity Responder (versión preliminar de junio de 2026) y de las extensiones de Security Operator de principios de este año

Por qué es importante

En muchas organizaciones, la respuesta a incidentes de identidad requiere dos o tres roles: Security Administrator para el triaje, más Identity Administrator o User Administrator para las acciones de contención. Durante un incidente activo, ese traspaso cuesta minutos — y los minutos importan cuando una cuenta está comprometida. Esta ampliación permite que los equipos de SOC que usan Security Administrator contengan los incidentes de identidad directamente, mientras que el ámbito de usuarios no privilegiados mantiene bajo control el radio de impacto del propio rol. Los registros de auditoría siguen capturando cada acción.

Qué deben hacer los administradores

1. Revisa las asignaciones de Security Administrator — este rol se vuelve más potente; revalida quién lo ostenta
2. Actualiza los runbooks del SOC — documenta que las acciones de contención sobre usuarios no privilegiados ya no requieren escalado
3. Verifica la cobertura de auditoría — confirma que tu SIEM ingiere los eventos de deshabilitación, revocación de sesiones y restablecimiento de contraseña

7. Actualización del ámbito del permiso User.ReadBasic.All — Corrección de seguridad

Estado: Despliegue en curso Acción requerida: Audita las aplicaciones que usan User.ReadBasic.All

Microsoft está corrigiendo un problema de divulgación de información en Microsoft Graph: el permiso User.ReadBasic.All estaba permitiendo inadvertidamente que las aplicaciones leyeran asignaciones de roles de aplicación y detalles de licencias, y no solo las propiedades básicas del perfil para las que está diseñado.

Qué incluye

• La corrección: elimina el acceso no intencionado a appRoleAssignments y licenseDetails
• El ámbito previsto no cambia: displayName, givenName, id, mail, photo, securityIdentifier, surname, userPrincipalName
• Para las aplicaciones que necesitan más: usa User.Read.All para las asignaciones de roles de aplicación y LicenseAssignment.Read.All para los detalles de licencias (User.Read.All cubre ambos)
• Impacto: no es un cambio que rompa la compatibilidad para las aplicaciones que usan el permiso según lo previsto

Por qué es importante

Es el tipo de vulnerabilidad que rara vez aparece en los titulares pero importa en silencio: una aplicación aprovisionada con el mínimo privilegio posible — leer nombres y direcciones de correo — también podía enumerar qué roles tiene cada usuario y qué licencias posee. Eso convierte una aplicación de bajo privilegio en una herramienta de reconocimiento para planificar escaladas de privilegios. La corrección es la decisión correcta, y es un recordatorio de revalidar periódicamente qué exponen realmente tus permisos delegados y de aplicación.

Qué deben hacer los administradores

1. Audita las aplicaciones con User.ReadBasic.All — lista cada aplicación a la que se le ha concedido y qué datos necesita legítimamente
2. Mejora donde sea necesario — solicita User.Read.All o LicenseAssignment.Read.All para las aplicaciones que realmente necesitan datos de asignaciones o licencias
3. Revisa el historial de consentimiento y concesiones — busca aplicaciones que puedan haber estado explotando el acceso no intencionado
4. Documenta el cambio — actualiza tu matriz de permisos de aplicación antes de que la corrección llegue a tu inquilino

También en el resumen de septiembre

Tres elementos destacados en el resumen de Microsoft de septiembre de 2026 ya se habían cubierto en esta serie:

• Tenant Governance GA (10 de agosto de 2026) — los ajustes de gobernanza a nivel de inquilino ya están disponibles de forma general
• MCP Firewall en versión preliminar (6 de agosto de 2026) — control de acceso para los servidores de Model Context Protocol en la era de la IA agéntica
• Retirada de MemberOf (MC1448379) — el operador de regla MemberOf en grupos dinámicos, unidades administrativas y gestión de derechos (entitlement management) se retira el 3 de noviembre de 2026; hay orientación de migración disponible en Message Center

Fechas clave para seguir

• Finales de septiembre de 2026: la ampliación del rol Security Administrator estará completamente implementada
• 1 de octubre de 2026: retirada de las políticas de riesgo heredadas en Entra ID Protection
• 3 de noviembre de 2026: retirada del operador de regla MemberOf en grupos dinámicos, unidades administrativas (AU) y gestión de derechos

Sigue a Kevin en X en https://x.com/kkaminsk para obtener actualizaciones y análisis diarios sobre Microsoft Entra.