Justo cuando pensabas que el ciclo de noticias de Entra ID podría ralentizarse antes del lanzamiento de passkeys por defecto del 1 de septiembre, Microsoft ha publicado otro lote de actualizaciones. Esta vez el enfoque está en eliminar la fricción de la autenticación resistente al phishing, extender Zero Trust al tráfico de agentes de IA y dar a los administradores un poco más de margen en la aplicación de SSPR. Esto es lo que cambió en la semana previa al 8 de agosto de 2026.

1. Los passkeys ahora se pueden registrar como tu primer método MFA (MC1450133)

Este es uno de esos cambios que te hacen preguntar: “Espera, ¿eso no era ya así?”. Hasta ahora, Microsoft Entra ID exigía que los usuarios registraran un método de autenticación más débil — como SMS, voz o un Temporary Access Pass — antes de poder inscribir un passkey. Era un problema del huevo y la gallina: las organizaciones que querían ser passwordless desde el primer día tenían que aprovisionar primero un método que estaban tratando activamente de eliminar.

Ese requisito ha desaparecido. Los usuarios ahora pueden registrar un passkey o un método de inicio de sesión passwordless como su primer factor MFA, sin necesidad de un método más débil previo.

Por qué es importante

Este cambio respalda directamente el próximo lanzamiento de passkeys por defecto del 1 de septiembre. Los nuevos usuarios que se incorporan a una organización pueden pasar directamente al registro de passkeys durante su experiencia inicial de inicio de sesión. Se acabó eso de inscribir SMS “solo para empezar” y luego migrar a passkeys más tarde. La fricción ha desaparecido.

Para las organizaciones que están creando inquilinos de Entra ID desde cero (greenfield) o incorporando nuevas cohortes de usuarios, esto simplifica drásticamente el flujo de configuración de autenticación. También se alinea con la tendencia más amplia de la industria hacia la autenticación resistente al phishing como línea base, y no como una mejora.

Detalles clave

  • Implementación: Por fases, de enero de 2026 a noviembre de 2027
  • Acción del administrador: No se requieren cambios de configuración — pero revisa tu política de métodos de autenticación y la configuración de la campaña de registro para asegurarte de que reflejan esta nueva capacidad
  • Centro de mensajes: MC1450133

2. Windows Hello for Business y macOS Platform SSO se convierten en factores MFA independientes (MC1450134)

A partir de octubre de 2026, Microsoft Entra ID reconocerá Windows Hello for Business y macOS Platform SSO como factores MFA independientes. Esto significa que los usuarios en dispositivos administrados con Windows y macOS podrán cumplir los requisitos de MFA mediante la biometría o el PIN integrados de su dispositivo — sin necesidad de registrar por separado un passkey u otro método MFA.

Por qué es importante

Si tu organización ya ha implementado Windows Hello for Business o macOS Platform SSO en dispositivos administrados, en esencia has tenido autenticación con capacidad MFA todo este tiempo — pero Entra ID no la reconocía plenamente como tal para todos los escenarios de Conditional Access. Eso cambia en octubre.

Para los administradores, esto significa:

  • Flujos de incorporación más sencillos para usuarios de dispositivos administrados
  • Menos métodos registrados que gestionar y auditar
  • Las políticas de Conditional Access que exigen MFA pueden satisfacerse con la propia credencial de la plataforma
  • Sin necesidad de inscripción adicional de passkeys para usuarios que ya tienen Windows Hello o macOS Platform SSO

Detalles clave

  • Cronología: A partir de octubre de 2026
  • Acción del administrador: No se necesitan cambios de configuración, pero actualiza la documentación de incorporación y revisa tus políticas de intensidad de autenticación de Conditional Access para confirmar que estos métodos se aceptan donde se pretende
  • Centro de mensajes: MC1450134

3. MCP Firewall de Global Secure Access — Zero Trust para el tráfico de agentes de IA (Vista previa)

A medida que los agentes de IA proliferan en los entornos empresariales, ha surgido una nueva superficie de ataque: el tráfico del Model Context Protocol (MCP) que fluye entre los agentes de IA y los servidores MCP remotos. La respuesta de Microsoft es el firewall MCP de Global Secure Access, ahora en vista previa.

Qué hace

El firewall MCP es un control de seguridad de red, centrado en la identidad, que inspecciona el tráfico MCP (JSON-RPC 2.0 sobre HTTP transmisible y Server-Sent Events) y aplica decisiones de Permitir o Bloquear en el borde de Global Secure Access. Extiende Zero Trust a la capa de protocolo MCP — sin requerir cambios en los clientes, hosts o servidores MCP.

Las capacidades clave incluyen:

  • Bloquear todo el tráfico MCP en todo el inquilino mientras revisas y apruebas los servidores de confianza
  • Permitir/bloquear servidores MCP por patrón de URL — crear listas de permitidos y listas de bloqueados
  • Control selectivo de primitivas — permitir o bloquear Tools, Resources o plantillas de Prompt por servidor
  • Aplicación de métodos y versiones de protocolo — bloquear conexiones HTTP sin cifrar, aplicar higiene de protocolo bloqueando versiones obsoletas de MCP

Requisitos previos

Esta es una capacidad en vista previa con requisitos específicos:

  • Inquilino de Microsoft Entra con licencia de Internet Access
  • Roles de Global Secure Access Administrator y Conditional Access Administrator
  • Dispositivo unido a Entra con el cliente de Global Secure Access instalado
  • TLS inspection habilitado (requerido porque los mensajes MCP viajan en el payload cifrado)

Flujo de configuración

  1. Crea una política MCP en el centro de administración de Entra, en Global Secure Access > Secure > MCP policies (Preview)
  2. Vincula la política MCP a un perfil de seguridad
  3. Configura una política de Conditional Access que aplique el perfil de seguridad

Por qué es importante

Si tu organización está usando agentes de IA — y cada vez más, la mayoría lo está — el tráfico MCP es un punto ciego en tu stack de seguridad. Los agentes pueden llamar a herramientas externas, acceder a recursos y ejecutar prompts en servidores remotos, todo ello sin que los controles de red tradicionales tengan visibilidad de lo que está sucediendo. El firewall MCP cierra esa brecha al llevar los mismos principios de Zero Trust que aplicamos a la identidad humana a las comunicaciones de los agentes de IA.

El equipo de Secure Access de Cisco anunció una capacidad similar de inspección semántica de MCP a principios de este año, lo que indica que este se está convirtiendo en un espacio competitivo entre los proveedores de SSE. El enfoque de Microsoft destaca por su profunda integración con Conditional Access y las señales de identidad de Entra ID.

4. Token Protection para aplicaciones web — Nueva guía de implementación (Vista previa)

Microsoft ha publicado una nueva guía de implementación para aplicar Token Protection con Conditional Access en aplicaciones basadas en navegador que acceden a Azure Resource Manager. Esto extiende la protección contra la repetición de tokens a las sesiones de navegador, un área donde el robo de tokens ha sido históricamente más difícil de prevenir.

Qué cubre

La guía recorre la configuración de Token Protection para aplicaciones basadas en navegador compatibles que acceden a Azure Resource Manager. Características clave:

  • Alcance: Limitado a aplicaciones, plataformas, navegadores y configuraciones de dispositivos específicamente enumerados
  • Requisitos: Entra ID P1, más configuración adicional de dispositivos Windows o macOS
  • Recomendación: Comenzar en modo de solo informe (report-only), ejecutar un piloto y luego aplicar
  • Estado: Vista previa — el soporte para aplicaciones basadas en navegador explícitamente aún no está disponible de forma general (GA)

Por qué es importante

El robo de tokens y los ataques de repetición siguen siendo un vector de amenaza significativo. Token Protection vincula los tokens de sesión de inicio de sesión al dispositivo de origen, haciendo que los tokens robados sean inútiles si se reproducen desde otra máquina. Hasta ahora, esta protección estaba disponible principalmente para aplicaciones cliente nativas. Extenderla a aplicaciones basadas en navegador — incluso en vista previa — cierra una brecha importante en el modelo de aplicación de la protección.

Para las organizaciones que usan Azure Resource Manager de forma intensiva a través de portales de navegador, vale la pena evaluarlo en capacidad piloto. La recomendación del modo de solo informe es sensata: la compatibilidad de las aplicaciones de navegador varía significativamente entre plataformas y configuraciones.

5. Fechas de aplicación de SSPR trasladadas — Más tiempo para registrar usuarios

Si has estado siguiendo el cambio de SSPR que exige métodos de autenticación explícitamente registrados, ahora tienes más tiempo. Microsoft ha reprogramado los hitos clave:

HitoFecha anteriorNueva fecha
Comienza la campaña de registro6 de agosto de 20265 de octubre de 2026
Solo se aceptan métodos registrados (aplicación)7 de septiembre de 20269 de noviembre de 2026

Por qué es importante

Después del 9 de noviembre de 2026, SSPR ya no aceptará información de contacto procedente del directorio (números de teléfono, direcciones de correo almacenadas como propiedades del objeto de usuario) para la verificación del restablecimiento de contraseña. Solo funcionarán los métodos de autenticación explícitamente registrados. La campaña de registro que precede a la aplicación incitará a los usuarios afectados a registrar métodos después del inicio de sesión.

El tiempo extra es bienvenido, pero no lo desperdicies. La fecha de aplicación del 9 de noviembre ahora está a solo tres meses de distancia. Las organizaciones deberían:

  1. Identificar a los usuarios que dependen de la información de contacto procedente del directorio para SSPR
  2. Ejecutar la campaña de registro cuando comience el 5 de octubre
  3. Comunicar el cambio a los usuarios con mucha antelación
  4. Asegurarse de que cada usuario tenga al menos un método de autenticación registrado antes del 9 de noviembre

6. Requisito de licencia de Agent 365 aclarado para Conditional Access para agentes

Microsoft ha actualizado la documentación de Conditional Access para agentes para indicar explícitamente que se requiere una licencia de Microsoft Agent 365. Esto reemplaza el texto anterior de “Próximamente” (Starting soon) por un requisito directo.

Detalles de licencia

Agent 365 es:

  • Incluido con Microsoft 365 E7
  • Disponible como complemento para Microsoft E5, A5, Business Premium o Defender Suite más Purview Suite

Por qué es importante

Si tu organización está usando o planea usar Entra Agent ID con políticas de Conditional Access, debes verificar tus licencias. La actualización de la documentación también aclara que tanto Entra Conditional Access para agentes como Entra ID Protection para agentes requieren licencias de Agent 365. Se trata de una aclaración de orientación más que del lanzamiento de un nuevo producto — el requisito ya se había anticipado antes — pero el lenguaje de “Próximamente” ya no existe.

7. La documentación de aprovisionamiento SCIM recibe una renovación de navegación

Varias páginas de documentación de aprovisionamiento SCIM se han actualizado con nuevas etiquetas de navegación y flujos de trabajo que se alinean con la experiencia actual del centro de administración de Entra:

  • “Mostrar opciones avanzadas” ahora es el menú desplegable Opciones avanzadas
  • “Editar lista de atributos para ScimOnPremises” ahora es Editar atributos de usuario de destino / Editar esquema
  • Expression Builder ahora se accede desde el menú de navegación izquierdo en lugar de Attribute Mapping > Advanced Options
  • El asistente de filtros de ámbito (Scoping filters) reemplaza los antiguos pasos basados en Mappings para el filtrado basado en asignaciones y en atributos
  • Las fechas de las páginas se actualizaron de marzo de 2025 al 6 de agosto de 2026
  • La documentación de registros de aprovisionamiento ahora incluye la integración con Microsoft MCP Server for Enterprise para análisis de solo lectura en lenguaje natural mediante permisos delegados

Por qué es importante

Si estás siguiendo documentación antigua para configurar el aprovisionamiento SCIM, notarás que las rutas de navegación han cambiado. Las actualizaciones ponen la documentación en línea con la experiencia actual del portal. Los administradores que configuran trabajos de aprovisionamiento con frecuencia deberían marcar las páginas actualizadas.

Resumen de fechas clave

FechaEvento
5 de octubre de 2026Comienza la campaña de registro de SSPR (trasladada desde el 6 de agosto)
Octubre de 2026Windows Hello y macOS Platform SSO reconocidos como factores MFA independientes
30 de octubre de 2026Se abre la configuración de socios de telecomunicaciones para la continuación de SMS/voz
3 de noviembre de 2026Retiro del operador de reglas MemberOf (los grupos dinámicos y las AU dejan de procesarse)
9 de noviembre de 2026Aplicación de SSPR — solo se aceptan métodos registrados (trasladada desde el 7 de septiembre)
Enero de 2026 – noviembre de 2027Implementación por fases de passkeys como primer MFA
1 de febrero de 2027Se retira la autenticación por SMS/voz proporcionada por Microsoft

Acciones para administradores

  1. Actualiza la documentación de incorporación para reflejar que los passkeys ahora pueden ser el primer método MFA — elimina cualquier guía que diga que los usuarios deben inscribir primero un método más débil
  2. Revisa las políticas de intensidad de autenticación de Conditional Access para Windows Hello y macOS Platform SSO antes del reconocimiento como MFA independiente de octubre de 2026
  3. Evalúa el firewall MCP si tu organización usa agentes de IA con MCP — verifica que cumples los requisitos previos (licencia de Internet Access, cliente GSA, TLS inspection)
  4. Prueba Token Protection para aplicaciones web en modo de solo informe si usas Azure Resource Manager a través de portales de navegador
  5. Revisa los planes de implementación de SSPR con las fechas actualizadas del 5 de octubre y el 9 de noviembre
  6. Verifica las licencias de Agent 365 si usas o planeas usar Conditional Access para agentes
  7. Marca la documentación actualizada de SCIM — las rutas de navegación han cambiado

Mantente informado

El ritmo de los cambios en Entra ID sigue acelerándose a medida que se acerca el hito de los passkeys por defecto del 1 de septiembre. Entre la evolución de la autenticación, la seguridad de los agentes de IA y las renovaciones de documentación, hay mucho que seguir. Seguiremos ofreciendo análisis accionables a medida que surjan nuevos anuncios.

Sigue la conversación en X en https://x.com/kkaminsk para 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 las organizaciones a navegar por las transformaciones de identidad y seguridad. Contáctanos para hablar sobre cómo afectan estos cambios a tu entorno y cómo podemos ayudarte a planificar tu migración.