Aunque la página oficial «Novedades» de Microsoft Entra en Microsoft Learn todavía no se ha actualizado con una sección de julio de 2026 (sigue mostrando junio de 2026 como la más reciente), Microsoft ha estado muy activo publicando nuevos anuncios en entradas del blog de Tech Community, notificaciones del Centro de mensajes de M365, Azure Updates y la documentación de Microsoft Graph API. La revisión de esta semana detectó seis novedades que los equipos de identidad y seguridad deben conocer.

Esto es lo nuevo, por qué importa y qué acciones debería tomar tu organización.

1. Propiedades mejoradas en los registros de auditoría para entidades de servicio

Anunciado: principios de julio de 2026 Estado: disponibilidad general Fuente: Microsoft Learn

Microsoft Entra ahora captura metadatos ampliados en los registros de auditoría cuando se crean entidades de servicio (service principals), lo que facilita mucho entender el origen y la intención detrás de cada evento de creación.

Qué hay de nuevo

Ahora se registran tres propiedades nuevas en la actividad «Add service principal» dentro de la categoría ApplicationManagement:

  • ServicePrincipalProvisioningType: una enumeración que describe cómo y por qué se creó la entidad de servicio. Los valores incluyen:

    • defaultMicrosoft: creada por Microsoft como parte de un proceso de elegibilidad predeterminada o administrado por el sistema
    • subscription: creada porque tu inquilino (tenant) tiene una suscripción/SKU elegible (aprovisionamiento JIT basado en comercio)
    • managerApplications: creada por una aplicación «administradora» gestionada por Microsoft con permiso para administrar otras entidades de servicio
    • AzureResourceProvider: creada por un proveedor de recursos de Azure durante la incorporación de un servicio (p. ej., Azure Data Explorer)
    • Other: otros mecanismos de aprovisionamiento, incluidos los flujos delegados y de solo aplicación

  • SubscribedSkus: una matriz JSON que vincula una entidad de servicio de Microsoft creada mediante aprovisionamiento JIT basado en comercio con las suscripciones y planes de servicio concretos que la hicieron elegible

  • AppOwnerOrganizationId: el ID del tenant de origen del registro de aplicación propietario de la entidad de servicio

Por qué importa

Los eventos de creación de entidades de servicio han sido durante mucho tiempo un punto ciego para los equipos de seguridad. Cuando aparece una nueva SP en un tenant, la pregunta crítica es: «¿La creó una persona o la aprovisionó automáticamente un servicio de Microsoft?». Antes, responder a esa pregunta exigía cruzar llamadas a Microsoft Graph API, revisar los detalles de las suscripciones y, a veces, rebuscar en registros de actividad de varios sistemas.

Con estas nuevas propiedades, los equipos de seguridad pueden distinguir de inmediato entre el aprovisionamiento impulsado por Microsoft (comportamiento esperado de la plataforma) y las acciones iniciadas por el tenant (que pueden justificar una investigación). Esto es especialmente valioso para detectar posibles escenarios de compromiso en los que un atacante crea una entidad de servicio para establecer persistencia en un tenant.

Cómo usarlo

Estas propiedades aparecen en la sección Additional details de los eventos «Add service principal» en los registros de auditoría del Centro de administración de Entra (Monitoring & health > Audit logs). También están disponibles mediante consultas a Microsoft Graph API y en la tabla AuditLogs de Log Analytics.

Roles necesarios: Administrador de seguridad, Lector de seguridad o Lector de informes.

2. Política de validación de tokens federados más estricta: aplicación en agosto de 2026

Anunciado: 9 de julio de 2026 (MC1303719) Aplicación: mediados de agosto de 2026 Actuar antes del: 11 de agosto de 2026 Fuente: Centro de mensajes de M365

Microsoft Entra cambiará el comportamiento predeterminado de federatedTokenValidationPolicy para bloquear los inicios de sesión federados cuando la configuración de internalDomainFederation no coincida con el dominio del UPN del usuario. Es una medida de refuerzo de seguridad que impide los inicios de sesión federados entre dominios causados por relaciones de confianza de federación mal configuradas o demasiado permisivas.

Qué cambia

  • Antes: bloquear los inicios de sesión federados entre dominios requería una configuración explícita del tenant
  • Después: los inicios de sesión entre dominios se bloquean de forma predeterminada a partir de mediados de agosto de 2026
  • Alcance: todos los dominios federados con un objeto internalDomainFederation, en especial los configurados antes de diciembre de 2025 (los dominios añadidos desde diciembre de 2025 ya tienen este comportamiento más estricto)
  • Error en los inicios de sesión bloqueados: AADSTS5000820: Sign-in blocked by Federated Token Validation policy. Contact your administrator for details.

A quién afecta

  • Organizaciones que usan autenticación federada (AD FS o IdP de terceros)
  • Tenants con dominios federados configurados antes de diciembre de 2025
  • Solo afecta a entornos donde realmente se producen inicios de sesión federados entre dominios

Qué hacer

  1. Haz un inventario de tus dominios federados con PowerShell:

    powershell
    Connect-MgGraph -Scopes "Domain.Read.All"
Get-MgDomain | Select-Object Id, AuthenticationType, IsVerified

  2. Busca discrepancias entre UPN y dominio de federación: compara los sufijos UPN de los usuarios con los nombres de los dominios federados

  3. Revisa los registros de inicio de sesión en busca de inicios de sesión federados entre dominios (Centro de administración de Entra > Monitoring & health > Sign-in logs, filtrando por autenticación = federada)

  4. Si necesitas inicios de sesión entre dominios (muy desaconsejado), crea una federatedTokenValidationPolicy personalizada con rootDomains = none mediante Microsoft Graph

  5. Informa al servicio de asistencia: los usuarios podrían ver el error AADSTS5000820 a partir de mediados de agosto si se estaba produciendo federación entre dominios

Organizaciones solo en la nube y con sincronización de hash de contraseñas: no se requiere ninguna acción.

3. SFTP de Azure Blob Storage con Microsoft Entra ID: disponibilidad general

Anunciado: 9 de julio de 2026 Estado: disponibilidad general Fuente: Azure Updates

SFTP de Azure Blob Storage ahora admite identidades basadas en Microsoft Entra ID para la gestión del acceso, lo que elimina la necesidad de credenciales específicas de SFTP independientes.

Qué hay de nuevo

  • Los usuarios se autentican en SFTP de Azure Blob Storage con su identidad de Microsoft Entra ID
  • Admite identidades de Entra tanto internas como externas
  • Permite aplicar directivas de acceso condicional al acceso SFTP (MFA, cumplimiento del dispositivo, restricciones de red)
  • Centraliza la gestión del acceso mediante la gobernanza de Entra ID en lugar de administrar credenciales SFTP locales

Por qué importa

SFTP ha sido tradicionalmente un dolor de cabeza en la gestión de credenciales: cada usuario necesita un conjunto de credenciales independiente, no hay integración con la gobernanza de identidades y no se pueden aplicar directivas de acceso condicional. Al llevar la autenticación de Entra ID a SFTP, Microsoft elimina la proliferación de credenciales y extiende los controles de seguridad basados en identidad a un protocolo que antes quedaba fuera del perímetro de identidad moderno.

Para las organizaciones con cargas de trabajo reguladas que necesitan SFTP para el intercambio de datos con socios o B2B, esto significa que el acceso SFTP ahora puede seguir el mismo modelo de gobernanza que el resto del acceso a recursos en la nube, con registros de auditoría completos, aplicación del acceso condicional y gestión del ciclo de vida a través de Entra ID.

Primeros pasos

Configura SFTP en tu cuenta de Azure Blob Storage y asigna permisos basados en Entra ID mediante asignaciones de roles de Azure. Así, los usuarios pueden autenticarse con sus credenciales de Entra en lugar de contraseñas SFTP locales.

4. Nuevos planes de servicio de Entra ID para la seguridad de agentes

Anunciado: principios de julio de 2026 Fuente: Centro de mensajes de M365 / AdminDroid

Microsoft presenta dos nuevos planes de servicio para dar soporte a las capacidades de seguridad de agentes de IA en Microsoft Entra ID:

  • Entra Conditional Access for Agents: permite directivas de acceso condicional dirigidas específicamente a las identidades de agentes de IA
  • Entra ID Protection for Agents: extiende la detección y corrección de riesgos de Identity Protection a las cuentas de agentes de IA

Qué hay de nuevo

Estos planes de servicio se incluyen con:

  • Licencias de Microsoft E7
  • Licencias de Microsoft 365 Agent

Las organizaciones que quieran usar el acceso condicional e Identity Protection para agentes de IA tendrán que pasar al modelo de licencias actualizado.

Por qué importa

Este anuncio representa el marco comercial de la estrategia de seguridad de agentes de Microsoft. Aunque las capacidades técnicas para proteger agentes de IA (Agent ID, acceso condicional para agentes, detección de riesgos de agentes) se han ido lanzando durante los últimos meses, ahora se está formalizando el modelo de licencias.

Para las organizaciones que despliegan agentes de IA a escala, esto significa que:

  • Las directivas de acceso condicional pueden dirigirse a identidades de agentes con la misma precisión que a los usuarios humanos
  • Identity Protection puede detectar y responder a actividad de agentes de riesgo (credenciales de agentes comprometidas, patrones anómalos de acceso a API)
  • Las licencias se incluyen con la plataforma de agentes más amplia (Microsoft 365 Agent, E7) en lugar de requerir complementos de seguridad de identidad independientes

Qué hacer

  1. Revisa tus licencias actuales: determina si tu organización tiene licencias de E7 o de Microsoft 365 Agent
  2. Planifica la seguridad de los agentes: si estás desplegando agentes de IA, ten en cuenta la necesidad de estos planes de servicio
  3. Revisa la función Extended Conditional Access for Agent’s user accounts (anunciada en junio de 2026 como versión preliminar pública) para entender las capacidades técnicas que desbloquean estos planes

5. App Instance Lock habilitado de forma predeterminada para las aplicaciones nuevas

Anunciado: junio-julio de 2026 (MC1300584) Estado: disponibilidad general (implementación completada a finales de junio de 2026) Fuente: Centro de mensajes de M365, Microsoft Learn

App Instance Lock ahora está habilitado de forma predeterminada en todas las aplicaciones recién creadas en Microsoft Entra ID. Esto protege las propiedades sensibles de la entidad de servicio para que no puedan modificarse fuera del tenant de origen de la aplicación.

Qué se protege

Las siguientes propiedades están bloqueadas de forma predeterminada:

  • keyCredentials: credenciales basadas en certificados que se usan para firmar tokens
  • passwordCredentials: credenciales basadas en contraseñas que se usan para la verificación
  • tokenEncryptionKeyId: referencia a la clave de cifrado de tokens

Cuando están bloqueadas, cualquier intento de modificar estas propiedades desde fuera del tenant de origen devuelve un error 400 Bad Request y la modificación no se aplica.

Por qué importa

App Instance Lock aborda un tipo de ataque conocido como «secuestro de aplicaciones» (app hijacking), en el que un administrador de un tenant cliente crea credenciales en la entidad de servicio de una aplicación multiinquilino y luego usa esas credenciales para suplantar a la aplicación. Esta técnica se ha utilizado en ataques reales, incluida la famosa campaña de SolarWinds.

Al habilitar este bloqueo de forma predeterminada para todas las aplicaciones nuevas, Microsoft se asegura de que la ruta de ataque más común para comprometer aplicaciones multiinquilino quede bloqueada sin que los desarrolladores tengan que activarla. Las aplicaciones existentes no se ven afectadas por este cambio.

Qué hacer

  1. Para aplicaciones nuevas: no hace falta hacer nada; el bloqueo se habilita automáticamente
  2. Para aplicaciones existentes: considera habilitar App Instance Lock manualmente si aún no está configurado
  3. Revisa la automatización/los scripts: asegúrate de que los flujos de aprovisionamiento no dependan de modificar credenciales de entidades de servicio desde fuera del tenant de origen
  4. Si necesitas hacer cambios: los administradores pueden deshabilitar el bloqueo por aplicación desde el Centro de administración de Entra o con Microsoft Graph

Para habilitarlo en aplicaciones existentes con PowerShell:

powershell
Connect-MgGraph -Scopes "Application.ReadWrite.All"
$params = @{
    servicePrincipalLockConfiguration = @{
        isEnabled = $true
        allProperties = $true
    }
}
Update-MgApplication -ApplicationId "<APPLICATION_OBJECT_ID>" -BodyParameter $params

6. Actualizaciones de identidad de Microsoft Graph API en julio de 2026

Anunciado: 8 de julio de 2026 Estado: versión preliminar pública Fuente: Novedades de Microsoft Graph

Las actualizaciones de Microsoft Graph API de julio de 2026 introducen varias capacidades nuevas de identidad y gobernanza en versión preliminar pública, lo que permite una gestión de identidades más programable y automatizada.

Registro programático de claves de acceso FIDO2

Nuevas API permiten registrar claves de acceso (passkeys) FIDO2 mediante programación:

  • Usa la función creationOptions para generar las opciones de creación de credenciales WebAuthn
  • Completa el registro publicando la propiedad publicKeyCredential en el recurso fido2AuthenticationMethod

Por qué importa: permite el aprovisionamiento masivo/automatizado de passkeys para organizaciones que incorporan grandes cantidades de usuarios a la autenticación resistente al phishing, en lugar de exigir que cada usuario se registre manualmente.

Sugerencias de paquetes de acceso

Nuevo tipo de recurso accessPackageSuggestion y métodos relacionados:

  • Descubre paquetes de acceso sugeridos en función de información sobre personas relacionadas y del historial de asignaciones
  • Función filterByCurrentUser para sugerencias personalizadas
  • Nuevo recurso endUserSettings para configurar el comportamiento de las sugerencias y la visibilidad de los detalles del aprobador

Por qué importa: aporta recomendaciones inteligentes a Entitlement Management y ayuda a los usuarios a descubrir los paquetes de acceso que podrían necesitar según lo que tienen usuarios similares, reduciendo tanto el exceso de aprovisionamiento como las carencias de acceso.

Mejoras de Lifecycle Workflows

  • Método cancelProcessing para cancelar ejecuciones de flujos de trabajo en curso o en cola
  • Cuarentena automática cuando los flujos de trabajo procesan más usuarios de lo esperado, con umbrales configurables mediante la propiedad quarantineConfiguration en lifecycleManagementSettings
  • clearQuarantine para eliminar el estado de cuarentena
  • Operaciones de vista previa para validar tareas sin afectar a los usuarios de producción

Por qué importa: mejora la fiabilidad y la seguridad de los flujos de trabajo automatizados del ciclo de vida. El comportamiento de cuarentena impide que flujos de trabajo descontrolados afecten a más usuarios de los previstos, mientras que la capacidad de cancelación da a los administradores un freno de emergencia. El modo de vista previa permite probar sin riesgo.

Gestión de sujetos de paquetes de acceso

  • Métodos Get y Update en accessPackageSubject para gestionar el ciclo de vida de sujetos de usuarios de directorios externos
  • Propiedad approverInformationVisibility en accessPackageApprovalStage para controlar si la información del aprobador es visible para los solicitantes
  • Propiedad type en accessPackageResourceRole para indicar si los roles de recursos de Azure están activos o son elegibles (lo que permite asignaciones de roles basadas en PIM en paquetes de acceso)

Por qué importa: proporciona un control más granular sobre la gobernanza de los paquetes de acceso, desde la gestión del ciclo de vida de usuarios externos hasta el control de la visibilidad de la información en los flujos de aprobación y el soporte del acceso justo a tiempo basado en PIM mediante paquetes de acceso.

El panorama general: la maduración de la seguridad de identidades en 2026

Estos seis anuncios, aunque significativos por separado, cuentan en conjunto una historia sobre la maduración de la seguridad de identidades en 2026:

  1. La visibilidad está mejorando: las propiedades ampliadas de los registros de auditoría para entidades de servicio cierran una brecha crítica para entender lo que ocurre en tu tenant. Ahora puedes responder «¿quién creó esta entidad de servicio y por qué?» sin necesidad de una investigación forense.

  2. La seguridad predeterminada se está reforzando: App Instance Lock por defecto y la validación más estricta de tokens federados muestran a Microsoft elevando el nivel mínimo de seguridad sin requerir una activación explícita. La tendencia es clara: la seguridad por defecto se está convirtiendo en el estándar, no en una opción.

  3. La seguridad de los agentes de IA se está formalizando: los nuevos planes de servicio para el acceso condicional y la Identity Protection de agentes muestran que Microsoft está construyendo el marco comercial y técnico para gobernar los agentes de IA con el mismo rigor que las identidades humanas.

  4. La automatización se está ampliando: las actualizaciones de Graph API (registro programático de passkeys, cancelación/cuarentena de flujos de trabajo, sugerencias de paquetes de acceso) muestran que Microsoft invierte en la programabilidad de la gobernanza de identidades, facilitando la gestión de identidades a escala mediante código en lugar de procesos manuales.

  5. Los protocolos tradicionales se suman a la era de la identidad moderna: la autenticación basada en Entra ID para SFTP lleva un protocolo heredado al ámbito del acceso condicional y la gobernanza de identidades, eliminando una carencia de larga data.

Qué deberías hacer ahora

  1. Revisa los registros de auditoría de tus entidades de servicio: filtra los eventos «Add service principal» de los últimos 30 días y usa la nueva propiedad ServicePrincipalProvisioningType para identificar cualquier creación inesperada iniciada por el tenant.

  2. Audita tu configuración de federación: si usas AD FS o IdP de terceros, verifica que los dominios UPN coincidan con los dominios de federación antes de la aplicación de agosto de 2026. Los inicios de sesión entre dominios dejarán de funcionar.

  3. Habilita App Instance Lock en las aplicaciones multiinquilino existentes: aunque solo es predeterminado para aplicaciones nuevas, conviene habilitarlo de forma proactiva en las aplicaciones multiinquilino existentes.

  4. Evalúa tus licencias de seguridad para agentes: si los agentes de IA están en tu hoja de ruta (y deberían estarlo), determina si necesitas los nuevos planes de servicio Entra Conditional Access for Agents y Entra ID Protection for Agents.

  5. Explora las funciones en versión preliminar de Graph API: si gestionas identidades a escala mediante automatización, vale la pena probar en un tenant de desarrollo las API de registro programático de FIDO2 y de cuarentena de Lifecycle Workflows.

  6. Comprueba si usas SFTP en Azure Blob Storage: si es así, evalúa migrar de credenciales locales a la autenticación basada en Entra ID para mejorar la gobernanza y la seguridad.

Kevin Kaminski es el propietario de Big Hat Group Inc., un partner de Microsoft centrado en tecnologías de IA y nube. Síguelo en https://x.com/kkaminsk para obtener más análisis sobre Microsoft Entra.