Novedades de Entra ID: SSPR, Passkeys, SCIM

La primera semana de septiembre de 2026 de Microsoft Entra ID trajo una combinación de aplicación, documentación y consolidación de dominios. El elemento más grande entra en vigor hoy: SSPR dejó de aceptar datos de contacto de directorio no registrados para restablecimiento de contraseña. Pero hay más debajo de la superficie — la guía de campaña de passkeys recibió una revisión documental, SCIM 2.0 API ganó permisos granulares, cuatro portales de autoservicio se están consolidando bajo un solo dominio, y Viva Engage está endureciendo su modelo de administración.

Si gestiona la identidad para una organización, al menos tres de estos elementos necesitan su atención antes de fin de mes.

Esto es lo que cambió, por qué importa y qué hacer al respecto.

1. Aplicación de SSPR Activa — Datos de Contacto No Registrados Ya No Aceptados

Estado: Aplicación activa el 7 de septiembre de 2026 Acción requerida: Identificar usuarios sin métodos de autenticación registrados

A partir de hoy, Microsoft Entra ID terminó el uso de datos de contacto de directorio no registrados para el autoservicio de restablecimiento de contraseña (SSPR). Los números de móvil, teléfonos de trabajo y correos electrónicos secundarios almacenados como atributos de directorio — mobilePhone, businessPhone, otherMails — ya no funcionan como métodos de verificación a menos que el usuario los haya registrado explícitamente a través del portal de registro de métodos de autenticación.

Qué Cambió

• Antes: SSPR aceptaba datos de contacto de atributos de directorio como prueba de identidad válida, incluso si el usuario nunca había confirmado personalmente esos contactos
• Después: Solo se aceptan métodos de autenticación que los usuarios o administradores hayan registrado explícitamente
• Campaña de registro: Comenzó el 6 de julio de 2026, solicitando a los usuarios afectados registrar métodos después del inicio de sesión
• Alcance: Todos los usuarios incluidos administradores, en nube pública, GCC, GCC High y DoD
• Impacto estimado: Aproximadamente el 14% de las verificaciones SSPR dependían previamente de datos de contacto de directorio no registrados

Por Qué Importa

Este cambio cierra una brecha de seguridad que socavaba toda la premisa del autoservicio de restablecimiento de contraseña. Cuando SSPR acepta datos de directorio no verificados, cualquiera que pueda poblar el atributo mobilePhone o otherMails de un usuario — incluida una cuenta de administrador comprometida o un proceso de sincronización de directorio con controles débiles — puede interceptar el flujo de restablecimiento de contraseña de ese usuario. La corrección asegura que los métodos de verificación estén vinculados a la intención del usuario y prueba de posesión, no solo a datos ingresados por el administrador.

El riesgo práctico hoy es la sobrecarga del servicio de ayuda. Los usuarios que ignoraron la campaña de registro y dependían de campos de directorio heredados ahora están bloqueados del autoservicio de recuperación. Un administrador debe establecer manualmente una contraseña temporal y guiarlos through del registro. Las organizaciones que ejecutaron proactivamente la campaña de registro y habilitaron políticas de acceso condicional que requieren registro de métodos verán una interrupción mínima.

Qué Deben Hacer los Administradores

1. Verificar el informe de registro — En el centro de administración de Entra, vaya a Seguridad → Métodos de autenticación → Detalles de registro de usuario. Exporte la lista de usuarios sin método registrado y priorice cuentas privilegiadas
2. Preparar el servicio de ayuda — Informe al personal de soporte sobre la aplicación, proporcione un script para restablecimiento manual de contraseña más registro guiado
3. Habilitar aplicación de registro — Considere una política de acceso condicional que requiera a los usuarios registrar métodos de autenticación, con alcance a redes de confianza o dispositivos administrados
4. Comunicarse con los usuarios — Envíe notificaciones dirigidas a cuentas sin métodos registrados, con enlaces directos al portal de registro

2. Guía de Campaña de Registro de Passkeys — Tres Estados Definidos

Estado: Documentación actualizada el 5 de septiembre de 2026 Acción requerida: Revisar configuración de campaña

La documentación de Microsoft Learn para campañas de registro de passkeys y Authenticator ahora define tres estados de campaña explícitos, reemplazando la guía anterior menos estructurada. La actualización llega mientras el despliegue de passkeys por defecto — activado el 1 de septiembre de 2026 — continúa hasta finales de mes.

Los Tres Estados de Campaña

Elegibilidad Específica por Método

La documentación ahora especifica condiciones de elegibilidad y aviso para cada tipo de método:

• Campañas de Authenticator: Requieren que la aplicación Authenticator esté configurada como método de autenticación en el inquilino. Los usuarios con métodos fuertes existentes pueden no ser solicitados.
• Campañas de passkeys: Requieren passkeys habilitados en la política de métodos de autenticación. Los usuarios habilitados para SMS o voz son automáticamente elegibles.
• Ventana de despliegue: La experiencia actualizada se está implementando hasta finales de septiembre de 2026. El comportamiento del inquilino puede variar durante el despliegue — no todos los inquilinos verán los nuevos estados inmediatamente.

Por Qué Importa

El despliegue de passkeys por defecto es el cambio de autenticación más significativo en Entra ID este año. Los usuarios habilitados para SMS o voz están siendo automáticamente habilitados para passkeys y solicitados para registrar en su próximo inicio de sesión MFA. El modelo de tres estados da a los administradores una palanca clara: dejar a Microsoft gestionar la campaña, tomar control explícito, o suprimirla completamente (útil para inquilinos con sus propios planes de despliegue de passkeys).

La API de exclusión temporal (Graph Beta, propiedad passkeyDynamicMigration) permanece disponible hasta el 1 de febrero de 2027, pero solo retrasa la habilitación automática de septiembre de 2026. La retirada de SMS/voz de febrero de 2027 no tiene exclusión.

Qué Deben Hacer los Administradores

1. Verificar el estado de la campaña — En el centro de administración de Entra, navegue a Métodos de autenticación → Campaña de registro. Verifique qué estado está activo
2. Revisar la política de métodos de autenticación — Asegúrese de que los passkeys estén habilitados en la política para que la campaña funcione correctamente
3. Monitorear el progreso de registro — Use el informe de uso de métodos de autenticación para rastrear cuántos usuarios han registrado passkeys frente a cuántos aún usan SMS/voz
4. Planificar para febrero 2027 — Incluso si se excluye ahora, comience a construir el plan de transición. El SMS/voz proporcionado por Microsoft se retirará completamente en esa fecha sin extensión

3. Referencia de SCIM 2.0 API — Permisos Granulares y Límites de Página Más Altos

Estado: Documentación actualizada el 5 de septiembre de 2026 Acción requerida: Revisar permisos de aplicaciones de aprovisionamiento SCIM

La referencia de SCIM 2.0 API para Microsoft Entra ID recibió una actualización documental sustancial el 5 de septiembre, cubriendo tamaños de página, filtros, permisos granulares y correcciones de esquema. Estos son cambios documentales, no nuevas capacidades de API — las APIs ya soportaban estas características, pero la referencia ahora las documenta apropiadamente.

Nuevo en la Referencia

Tamaños de página y filtros:

• Hasta 999 usuarios por página cuando la proyección excluye el atributo manager
• Nuevos tipos de filtro documentados: usuarios activos, coincidencias de sufijo negadas, membresía de grupo, propiedad de grupo
• Guía de rendimiento para elegir combinaciones de tamaño de página y filtro

Permisos de mínimo privilegio granulares:

• Permisos específicos por operación para lecturas básicas de usuario, creación y actualización de usuarios, creación de grupos y cambios de membresía de grupo
• Las aplicaciones de aprovisionamiento ahora pueden alinear solicitudes de consentimiento con sus operaciones de flujo de trabajo reales en lugar de solicitar permisos amplios
• La tabla de permisos reemplaza enlaces individuales en línea con una referencia consolidada de permisos de Microsoft Graph

Correcciones de esquema:

• User:ownedGroups y Group:owners documentados como atributos de solo lectura, multivalor
• Sus IDs se pueden usar en consultas de filtro pero nunca se devuelven en cuerpos de respuesta
• Corregida la descripción del cuerpo de respuesta members.value para grupos

Por Qué Importa

El aprovisionamiento SCIM es cómo la mayoría de las organizaciones automatizan la gestión del ciclo de vida del usuario a través de aplicaciones SaaS. La brecha documental anterior significaba que los desarrolladores sobreasignaban permisos (solicitando lectura/escritura completa de usuario cuando solo necesitaban crear usuarios) o descubrían capacidades de filtro por ensayo y error. El mapeo de permisos granulares permite implementar acceso de mínimo privilegio para aplicaciones de aprovisionamiento — una mejor práctica de seguridad que también simplifica la aprobación de aplicaciones y revisiones de cumplimiento.

El tamaño de página de 999 usuarios es una mejora de rendimiento significativa para inquilinos grandes. Combinado con los nuevos tipos de filtro, los trabajos de aprovisionamiento pueden recuperar conjuntos de usuarios objetivo más eficientemente y reducir el volumen de llamadas API.

Qué Deben Hacer los Administradores

1. Auditar aplicaciones de aprovisionamiento SCIM — Revise los permisos otorgados a cada aplicación conectada SCIM y alínelos con las nuevas opciones granulares
2. Actualizar configuraciones de aprovisionamiento — Si sus clientes SCIM usan tamaños de página más pequeños, pruebe páginas de 999 usuarios con proyecciones que excluyan manager
3. Probar nuevos filtros — Evalúe si los filtros de membresía o propiedad de grupo pueden reemplazar lógica personalizada en sus flujos de trabajo de aprovisionamiento
4. Validar expectativas de esquema — Si su cliente SCIM espera ownedGroups u owners en cuerpos de respuesta, actualícelo para usar consultas de filtro

4. Migración de Dominio de My Account — Consolidación a cloud.microsoft

Estado: Plan de cambio — despliegue a finales de noviembre de 2026 Fuente: MC1462460 Acción requerida: Actualizar listas de permitidos de red

Microsoft Entra está consolidando sus portales de gestión de identidad de autoservicio bajo un solo dominio. A partir de finales de noviembre de 2026, cuatro portales separados convergirán bajo myaccount.cloud.microsoft.

Portales Siendo Consolidados

Qué Cambia

• Usuarios: No se requiere acción. Redirección automática de URLs antiguos al nuevo dominio
• Funcionalidad central: Sin cambios — todos los flujos de trabajo existentes continúan funcionando
• Administradores: Asegúrese de que los dominios *.cloud.microsoft estén permitidos en políticas de red, proxy, firewall y endpoints
• Documentación: Actualizar guías internas, marcadores y materiales de capacitación que referencian los URLs antiguos

Por Qué Importa

La consolidación se alinea con el movimiento más amplio de Microsoft al espacio de nombres de dominio cloud.microsoft, que comenzó con los servicios de Microsoft 365. Tener cuatro portales separados de autoservicio de identidad — My Account para gestión de perfil, My Apps para lanzador de aplicaciones, My Access para revisiones de acceso y My Staff para administración delegada — creaba una experiencia de usuario fragmentada. El dominio unificado proporciona un punto de entrada único mientras preserva las experiencias individuales detrás de él.

El requisito de lista de permitidos de red es el elemento de acción real. Si su organización restringe el acceso a dominios de Microsoft a través de políticas de proxy, firewall o endpoints, los usuarios perderán acceso a los cuatro portales cuando la migración entre en vigor a menos que *.cloud.microsoft esté permitido.

Qué Deben Hacer los Administradores

1. Auditar políticas de red — Verifique en listas de permitidos de proxy, firewall y endpoints myaccount.microsoft.com, myapps.microsoft.com, myaccess.microsoft.com y mystaff.microsoft.com. Añada *.cloud.microsoft donde aplique
2. Actualizar documentación interna — Revise guías de usuario, scripts de servicio de ayuda y materiales de capacitación con la nueva URL
3. Probar con anticipación — Microsoft no ha anunciado una ventana de prueba previa al despliegue, pero puede verificar que myaccount.cloud.microsoft resuelve correctamente desde su red hoy
4. Comunicarse con usuarios — Envíe una notificación a finales de octubre sobre el próximo cambio de URL, enfatizando que los marcadores se redirigirán automáticamente

5. Permisos de Viva Engage Endurecidos — Roles de Entra Requeridos

Estado: Plan de cambio — finales de septiembre de 2026 Fuente: MC1465773 Acción requerida: Revisar y actualizar asignaciones de roles

A partir de finales de septiembre de 2026, Microsoft Viva Engage requerirá permisos de Microsoft Entra para tareas de administración de comunidades y membresía que anteriormente estaban disponibles para administradores verificados y administradores de red sin asignaciones de rol de Entra específicas.

Qué Está Cambiando

• Creación y gestión de comunidades: Ahora requiere rol de administrador de Yammer o asignación de administrador de comunidad
• Gestión de membresía: Mismo requisito de rol de Entra — los administradores verificados y administradores de red sin estos roles perderán capacidades de gestión de comunidades
• Alcance: Todos los inquilinos de Viva Engage en todo el mundo
• Cronograma: Finales de septiembre de 2026 (fecha exacta no especificada en el Centro de mensajes)

Por Qué Importa

Viva Engage (anteriormente Yammer) ha operado durante mucho tiempo con su propio modelo de administración que no se alineaba completamente con RBAC de Entra. La gestión de comunidades era posible con roles de administración específicos de Yammer que no tenían equivalente en Entra. Este cambio alinea Viva Engage con el modelo de administración de identidad primero de Microsoft, donde cada acción administrativa se rige por un rol de Entra.

El riesgo es operativo: las organizaciones que dependen de administradores de red de Yammer o administradores verificados para la gestión de comunidades verán esas capacidades eliminadas. Sin asignación proactiva de roles, la gestión de comunidades se rompe silenciosamente.

Qué Deben Hacer los Administradores

1. Inventariar administradores actuales de Viva Engage — Exporte la lista de usuarios con roles de administrador verificado o administrador de red en Yammer
2. Asignar roles de Entra — Para los usuarios que necesitan continuar gestionando comunidades, asigne el rol de administrador de Yammer de Entra o desígnelos explícitamente como administradores de comunidad
3. Actualizar materiales de capacitación — Revise la documentación del administrador para reflejar el requisito de rol de Entra
4. Monitorear después del despliegue — Vigile los tickets de servicio de ayuda sobre fallos de gestión de comunidades, que indicarán asignaciones de roles perdidas

6. Aclaración de Namespace de Identidad de Carga de Trabajo

Estado: Actualización documental el 5 de septiembre de 2026 Acción requerida: Revisar plantillas IaC y scripts CLI

Microsoft aclaró una distinción de namespace que estaba causando fallos de automatización: los comandos de Azure CLI y plantillas de Infrastructure as Code deben usar el namespace de proveedor Microsoft.Storage, no Microsoft.Storage/*. El formato * es solo una convención de visualización del portal de Azure y no es aceptado por la API.

Qué Cambió

• Visualización del portal: Muestra Microsoft.Storage/* para claridad visual
• API, CLI e IaC: Requiere Microsoft.Storage (sin comodín)
• La documentación ahora establece explícitamente: Los comandos de Azure CLI y plantillas IaC deben usar Microsoft.Storage

Por Qué Importa

Esta es una pequeña corrección documental que resuelve un problema real. Los scripts de automatización que copiaban el formato de visualización del portal literalmente fallarían en el momento del despliegue con errores de namespace. La aclaración elimina una fuente de confusión en configuraciones de federación de identidad de carga de trabajo que involucran Azure Storage.

Qué Deben Hacer los Administradores

1. Auditar plantillas IaC — Busque Microsoft.Storage/* en plantillas Bicep, Terraform y ARM y reemplácelo con Microsoft.Storage
2. Revisar scripts CLI — Verifique scripts de Azure CLI y Azure PowerShell que referencian federación de identidad de carga de trabajo para Storage
3. Actualizar documentación — Revise runbooks internos que pueden haber propagado el formato de visualización del portal

También Vale la Pena Rastrear

Expansión del Rol de Administrador de Seguridad

El rol integrado de administrador de seguridad se está expandiendo con acciones de respuesta de identidad para usuarios no privilegiados: deshabilitar/habilitar cuentas, revocar sesiones activas y forzar restablecimiento de contraseñas. La documentación ahora lista al administrador de seguridad junto al administrador de servicio de ayuda y administrador de usuarios para invalidar tokens de actualización de usuarios no administradores. El despliegue se completará a finales de septiembre de 2026. Esto se cubrió en detalle en nuestra actualización del 2 de septiembre de 2026.

Nuevos Elementos del Centro de Mensajes y Hoja de Ruta

• MC1423108 — Experiencia de restauración mejorada para passkeys de Authenticator en iOS
• RM567885 — Copia de seguridad y recuperación de Entra ID (hoja de ruta)
• MC1438571 — Visibilidad predeterminada de propiedades adicionales de tarjeta de perfil en tarjetas de perfil de M365
• RM568784 — Defender for Identity: Línea de tiempo de identidad unificada en la página de identidad
• RM569446 — Soporte mejorado de sAMAccountName para Entra Domain Services (hoja de ruta)

Fechas Clave a Vigilar

• Finales de septiembre de 2026: Despliegue completo de la expansión del rol de administrador de seguridad; cambio de permisos de Viva Engage en vigor
• 1 de octubre de 2026: Retirada de políticas de riesgo heredadas en Entra ID Protection
• 5 de octubre de 2026: Inicio de la campaña de registro SSPR (para cualquier fase restante)
• 3 de noviembre de 2026: Retirada del operador de regla MemberOf en grupos dinámicos, AUs y gestión de derechos
• Finales de noviembre de 2026: Migración de dominio de My Account a myaccount.cloud.microsoft
• 1 de febrero de 2027: Retirada completa de autenticación por SMS y voz proporcionada por Microsoft

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