La semana del 10 al 15 de agosto de 2026 trae una historia coherente en Microsoft Entra ID: endurecimiento de la autenticación tanto para humanos como para máquinas, madurez de la identidad externa y actualizaciones significativas de la guía de Agent ID. Microsoft retiró el inicio de sesión con SMS como primer factor para los inquilinos gratuitos de Entra ID el 11 de agosto. Los nuevos tutoriales de federación de identidades de carga de trabajo para Google Cloud y SPIFFE/SPIRE impulsan las arquitecturas sin secretos. La guía de Agent ID pasó de los registros de aplicaciones a los planos de identidad. Y Dynamics 365 Commerce incorpora pedidos en nombre de terceros para Entra External ID. Esto es todo lo que necesita saber.
1. Retirada del primer factor por SMS para inquilinos gratuitos de Entra ID (MC1448374)
El 11 de agosto de 2026, Microsoft retiró oficialmente el SMS como método de inicio de sesión de primer factor para los inquilinos gratuitos de Microsoft Entra ID. Esto significa que los usuarios de inquilinos gratuitos que dependían de recibir un código SMS de un solo uso como método de autenticación principal ya no pueden iniciar sesión de esa manera.
Por qué lo hizo Microsoft
La razón declarada es el riesgo de fraude. La autenticación basada en SMS es vulnerable a:
- Ataques de intercambio de SIM, en los que los atacantes se apoderan de un número de teléfono e interceptan los códigos
- Campañas de phishing que engañan a los usuarios para que introduzcan códigos en páginas de inicio de sesión falsas
- Ingeniería social, en la que los atacantes convencen a los usuarios de que compartan códigos
Estas debilidades convierten al SMS en uno de los métodos de autenticación menos seguros disponibles hoy en día.
Qué se ve afectado y qué no
- Afectado: SMS como método de inicio de sesión de primer factor (principal) en inquilinos gratuitos de Entra ID
- No afectado: SMS como método de autenticación multifactor (segundo factor): sigue funcionando
- No afectado: los planes de pago de Entra ID (aunque el cronograma más amplio de retirada de SMS/voz se aplica a todos)
El cronograma más amplio
Esta retirada es un hito temprano en el viaje de modernización de la autenticación de Microsoft:
| Fecha | Hito |
|---|---|
| 11 de agosto de 2026 | Primer factor por SMS retirado para inquilinos gratuitos de Entra ID |
| 1 de septiembre de 2026 | Las claves de acceso se convierten en la experiencia predeterminada: los usuarios de SMS/voz se habilitan automáticamente para claves de acceso |
| Octubre de 2026 | Comienza el registro de claves de acceso como primer método (Fase 1: claves de acceso sincronizadas, claves de acceso de Entra en Windows, claves FIDO2) |
| Enero de 2027 | Comienza la Fase 2 (Windows Hello para empresas, SSO de plataforma macOS, aplicación Authenticator) |
| 1 de febrero de 2027 | Retirada total del MFA por SMS y voz alojado por Microsoft |
Hay una API temporal de exclusión voluntaria disponible a través de Graph Beta (establezca optOutSettings.passkeyDynamicMigration en true) entre el 1 de septiembre de 2026 y el 1 de febrero de 2027, pero esto solo retrasa la habilitación automática: la retirada de febrero de 2027 no tiene opción de exclusión.
Qué deben hacer los administradores
- Identifique a los usuarios afectados en los inquilinos gratuitos de Entra ID que usan SMS como inicio de sesión principal
- Habilite métodos de autenticación alternativos: aplicación Microsoft Authenticator, claves de acceso, llaves de seguridad FIDO2
- Actualice las políticas de autenticación para reflejar la eliminación del primer factor por SMS
- Planifique el despliegue de claves de acceso del 1 de septiembre incluso si su inquilino no se ve afectado por la retirada del plan gratuito
Microsoft publicó el script de PowerShell entra-sms-voice-usage-analyzer en GitHub para ayudar a inventariar los usuarios que todavía utilizan autenticación por SMS o voz.
2. Pedidos en nombre de terceros de Dynamics 365 Commerce para Entra External ID (MC1453678)
Microsoft anunció soporte de pedidos en nombre de terceros para Microsoft Entra External ID en Dynamics 365 Commerce, con disponibilidad general programada para el 11 de septiembre de 2026.
Qué permite esto
Esta función permite que el personal autorizado (agentes de centros de llamadas, asociados de tienda, administradores de cuentas B2B) realice pedidos en nombre de una identidad externa (cliente o socio) representada en Entra External ID. El flujo de trabajo comercial respeta el perfil, las preferencias, el programa de fidelización y los derechos de la identidad externa incluso cuando un miembro del personal inicia la transacción.
Escenarios prácticos
- Agentes de servicio al cliente que realizan pedidos para clientes que llaman, con el pedido vinculado a la cuenta de cliente correcta y a los beneficios de fidelización
- Administradores de cuentas B2B que piden en nombre de organizaciones clientes según términos y contratos negociados
- Pedidos delegados en ecosistemas de socios donde las relaciones de identidad y el consentimiento se gestionan centralmente en Entra
Por qué es importante
Esto indica que External ID de Microsoft está madurando de un mecanismo puramente de autenticación a una construcción fundamental para las operaciones comerciales principales. Las identidades externas (clientes, socios) ahora están profundamente integradas en los flujos de trabajo comerciales, no solo como credenciales de inicio de sesión sino como entidades de primera clase que transportan contexto, preferencias y derechos a través de los procesos de negocio.
3. Nuevos tutoriales de federación de identidades de carga de trabajo: Google Cloud y SPIFFE/SPIRE
Microsoft publicó esta semana dos nuevos tutoriales de primera parte para la federación de identidades de carga de trabajo de Entra, reduciendo la barrera para las arquitecturas sin secretos multinube y multi-runtime.
Tutorial de Google Cloud
El nuevo tutorial de Google Cloud muestra cómo:
- Configurar una aplicación de Microsoft Entra para que confíe en un token de cuenta de servicio emitido por Google
- Intercambiar ese token por un token de acceso de Microsoft Entra
- Acceder a recursos de Azure (Key Vault, Storage, etc.) sin almacenar secretos de aplicación
La carga de trabajo que se ejecuta en Google Cloud solicita su propio token de ID al servidor de metadatos de Google y luego utiliza el intercambio de tokens (RFC 8693) para obtener un token de acceso de Entra. No se almacenan secretos de larga duración en el código ni en la configuración.
Tutorial de SPIFFE/SPIRE
El nuevo tutorial de SPIFFE/SPIRE demuestra:
- Cómo una carga de trabajo de Kubernetes puede obtener un SPIFFE JWT-SVID de su plano de control SPIRE
- Intercambiar el JWT-SVID por un token de acceso de Microsoft Entra
- Acceder a recursos de Azure sin secretos almacenados
SPIFFE (Secure Production Identity Framework for Everyone) proporciona una capa de identidad neutra respecto al proveedor que funciona en clústeres de Kubernetes, proveedores de nube y entornos locales.
El panorama general
Estos tutoriales refuerzan una historia paralela de modernización de la autenticación para las máquinas: así como Microsoft está alejando a los humanos del SMS hacia las claves de acceso, está alejando las cargas de trabajo de los secretos estáticos hacia tokens federados de corta duración. Los mismos principios de Zero Trust (verificar explícitamente, usar el privilegio mínimo, asumir la brecha) se aplican igualmente a las cuentas de servicio, los pipelines de CI/CD y los agentes de IA.
Los tutoriales también complementan el anuncio más amplio de Entra Agent ID para Dataverse de principios de agosto, que utiliza patrones de federación similares para las identidades de los agentes de IA.
4. Guía de Agent ID: planos de identidad, permisos de canal, grupos dinámicos
Microsoft actualizó significativamente la documentación de Agent ID esta semana, codificando cómo deben modelarse y gobernarse las identidades no humanas en Entra ID.
Arquitectura: planos de identidad en lugar de registros de aplicaciones
La guía de arquitectura actualizada ahora indica explícitamente a los administradores que creen agentes a partir de un plano de identidad de agente y del objeto Microsoft.Graph.AgentIdentity, en lugar de a través de las API estándar de registro de aplicaciones. Este es un cambio significativo en cómo Microsoft quiere que las organizaciones piensen sobre las identidades de los agentes de IA.
Puntos clave:
- Las identidades de agente no pueden usar consentimiento interactivo: los permisos delegados deben estar preautorizados a través de permisos de plano heredables
- El flujo de intercambio de tokens requiere que
Tc(token de cliente) tenga como destino el plano de identidad del agente, mientras queT1(token de recurso) tiene como destino el recurso de intercambio de tokens y se valida contra el plano y la identidad del agente secundario - Se documentan los canales de creación admitidos, roles, permisos y el uso de .NET
Permisos de canal: comunicación M365 para agentes
La nueva guía asigna los canales de comunicación de Microsoft 365 a los permisos que necesitan los agentes:
| Canal | Entrante (recepción) | Saliente (envío) |
|---|---|---|
| Correo de Outlook | Mail.Read | Mail.Send |
| Comentarios de OneDrive/SharePoint | Files.Read | Files.ReadWrite |
| Chats de Teams | Chat.Read | ChatMessage.Send |
| Canales de Teams | ChannelMessage.Read | ChannelMessage.Send |
Los administradores pueden usar esta tabla canal por canal para configurar el acceso de los agentes con precisión de privilegio mínimo.
Grupos dinámicos: cuentas de usuario de agente cubiertas
La guía de Microsoft Entra ID ahora explica explícitamente que las cuentas de usuario de agente se evalúan mediante reglas de pertenencia dinámica basadas en usuarios y pueden unirse a grupos de usuarios dinámicos. De forma predeterminada, las reglas dinámicas no distinguen las cuentas de agente de las cuentas de usuario normales, pero los administradores pueden incluirlas o excluirlas explícitamente, incluso filtrando por plano de identidad de agente.
Esto permite escenarios como:
- Agrupar automáticamente todos los agentes por entorno (dev/test/prod) mediante atributos de seguridad personalizados
- Excluir cuentas de agente de ciertos grupos de licencias
- Crear políticas de Acceso condicional dirigidas a grupos exclusivos de agentes
5. El registro de claves de acceso en Windows pierde la etiqueta de vista previa
La página de documentación “Register a Microsoft Entra passkey on Windows” (Registrar una clave de acceso de Microsoft Entra en Windows) ha eliminado la designación “(vista previa)” de su título y encabezados. Si bien Microsoft no ha emitido un anuncio oficial de disponibilidad general para el propio flujo de registro, este cambio indica preparación para producción.
Esto se alinea con la aceleración más amplia de las claves de acceso:
- MC1282568: Entra Passkeys en Windows alcanzó la disponibilidad general el 20 de julio de 2026 (mundial y GCC)
- MC1450133: Las claves de acceso como primer método MFA comienzan en octubre de 2026 (Fase 1: claves de acceso sincronizadas, claves de acceso de Entra en Windows, claves FIDO2)
- MC1440968: Optimizaciones de registro de claves de acceso en implementación a finales de agosto de 2026
Que la experiencia de registro pierda su etiqueta de vista previa reduce la fricción para los administradores que quieren promover las claves de acceso como método de inicio de sesión principal pero dudaban en implementar algo etiquetado como experimental.
6. Documentado el modelo de filtrado web de GSA V2
Un nuevo artículo de Microsoft Learn documenta el modelo de filtrado web de Global Secure Access V2, que introduce:
- Una política por perfil de seguridad (más simple que el enfoque de múltiples políticas de V1)
- Múltiples reglas con acciones individuales por política
- Una acción predeterminada para el tráfico no coincidente
- Destinos FQDN basados en URL para una segmentación más precisa
Las políticas existentes de filtrado de contenido web V1 continúan funcionando hasta que las organizaciones eligen migrar. El modelo V2 reduce la complejidad de las políticas y proporciona un control más granular sobre las decisiones de acceso web.
7. Actualizaciones adicionales de documentación
Esta semana se publicaron varias aclaraciones de documentación:
- Revisiones de acceso de catálogo: se eliminaron las etiquetas de vista previa, se amplió la terminología de revisores más allá de los administradores y se añadió la advertencia de frescura de datos de 12 horas (los cambios dentro de las 12 horas anteriores al inicio de una revisión pueden no aparecer)
- Identity Protection: “Deshabilitación de dispositivo” pasó a llamarse “Dispositivo agregado por atacante” con la respuesta documentada (dispositivo deshabilitado, emisión de tokens bloqueada, tokens de actualización revocados, sesiones revocadas)
- Redes de conjuntos de réplicas: todas las redes virtuales que alojan conjuntos de réplicas deben estar completamente en malla: se aclaró el requisito previo de implementación
- Staged Rollout: se documentaron escenarios adicionales de inicio de sesión interactivo para usuarios agregados o eliminados de Staged Rollout, incluidos los eventos de corrección de ID Protection
- Claims opcionales: guía de configuración granular de AMR para aplicaciones SAML (debe usar el manifiesto o Graph, sin interfaz de administración)
- Aprovisionamiento de Puzzel: autenticación de concesión de credenciales de cliente OAuth2 documentada
Conclusiones clave
Las actualizaciones de esta semana cuentan una historia clara sobre la estrategia de identidad de Microsoft:
El endurecimiento de la autenticación se está acelerando. El primer factor por SMS ya está retirado para los inquilinos gratuitos, las claves de acceso están perdiendo sus etiquetas de vista previa y la retirada de SMS/voz de febrero de 2027 se avecina. Las organizaciones que no han comenzado su migración a claves de acceso se están quedando sin margen de tiempo.
La identidad externa se está convirtiendo en una plataforma empresarial. Los pedidos en nombre de terceros de Dynamics 365 Commerce muestran que Entra External ID pasa de ser solo autenticación a una construcción fundamental para las operaciones comerciales.
La guía de Agent ID está madurando. El cambio de los registros de aplicaciones a los planos de identidad, combinado con el mapeo de permisos específicos por canal y el soporte de grupos dinámicos, brinda a las organizaciones una arquitectura de referencia adecuada para gobernar identidades de agentes de IA a escala.
Las arquitecturas sin secretos son cada vez más fáciles. Los nuevos tutoriales de federación de identidades de carga de trabajo para Google Cloud y SPIFFE/SPIRE reducen la barrera para que las organizaciones multinube eliminen los secretos almacenados.
Para las organizaciones que usan Entra ID, las prioridades de esta semana son claras: verifique la dependencia del primer factor por SMS en los inquilinos gratuitos, planifique campañas de registro de claves de acceso antes del despliegue de octubre, revise la arquitectura de Agent ID según la nueva guía de planos y explore si la federación de identidades de carga de trabajo puede reemplazar los secretos almacenados en sus cargas de trabajo multinube.
Siga a Kevin Kaminski en X en https://x.com/kkaminsk para obtener actualizaciones diarias sobre Microsoft Entra ID y Azure.