Conditional Access en Microsoft 365: políticas de acceso sin afectar la operación

Por Nicolás Echavarría, Managing Director y CAIO de ne Digital
Última revisión: 21 de octubre de 2026

Para diseñar políticas de acceso condicional sin interrumpir el negocio, hay que organizarlas por perfiles de usuario, desplegar cada política primero en modo solo informe y validar su impacto con los registros de inicio de sesión y la herramienta What If. Después se aplican por fases. Así se refuerzan los controles Zero Trust sin bloquear usuarios ni romper aplicaciones.

La mayoría de las organizaciones ya usan el acceso condicional, pero muchas han ido creando sus políticas de forma reactiva, una incidencia o una petición urgente cada vez. El resultado es predecible:

• Reglas solapadas.
• Grupos de exclusión cada vez más amplios.
• Excepciones sin documentar.
• Políticas que nadie se atreve a modificar.

Esa combinación produce brechas de seguridad, interrupciones del negocio o, con frecuencia, las dos cosas. Un acceso condicional sin interrupciones no se consigue aplicando menos controles, sino diseñándolos mejor.

¿Qué es el acceso condicional en Microsoft Entra ID?

El acceso condicional es el motor de políticas de Microsoft Entra ID que evalúa señales en cada inicio de sesión y decide si permite, bloquea o exige verificaciones adicionales. Las señales incluyen la identidad del usuario, el estado del dispositivo, la ubicación, la aplicación y el riesgo.

Es el plano de control de Zero Trust en los entornos Microsoft: todas las decisiones de acceso a Microsoft 365, Azure y las aplicaciones integradas pasan por él. Por eso, la calidad del diseño determina a la vez la seguridad y la experiencia de usuario.

Cada política combina tres elementos:

• Asignaciones: a quién y a qué recursos se aplica.
• Condiciones: cuándo se aplica (plataforma del dispositivo, ubicaciones, riesgo de inicio de sesión o aplicaciones cliente).
• Controles: los de concesión, como exigir MFA o un dispositivo compatible, y los de sesión, como la frecuencia de inicio de sesión o las restricciones aplicadas por la aplicación.

Por qué las políticas de acceso condicional interrumpen el negocio

Las interrupciones rara vez se deben a los controles en sí. Casi siempre tienen su origen en fallos de diseño predecibles:

• Políticas aplicadas sin análisis de impacto, que bloquean a usuarios con dispositivos no compatibles o aplicaciones que no admiten MFA.
• Grupos de exclusión amplios, que acumulan miembros con el tiempo y se convierten en brechas permanentes.
• Políticas solapadas, con resultados contradictorios que el equipo de soporte no sabe explicar.
• Dependencias ocultas, como cuentas de servicio, escáneres o integraciones heredadas que nadie inventarió.
• Bloqueo de los propios administradores, cuando una política mal configurada deja fuera a quien debe corregirla.

Principios de un diseño de acceso condicional sin interrupciones

Cinco principios separan un diseño resiliente de uno frágil.

1. Mínimo privilegio. Cada perfil recibe solo el acceso que necesita, con los controles más fuertes que pueda cumplir de forma realista.

2. Cobertura total por defecto. Las políticas básicas deben dirigirse a Todos los usuarios y Todos los recursos (antes "Todas las aplicaciones en la nube"), con exclusiones mínimas y justificadas. Si se empieza por aplicaciones concretas, las nuevas aplicaciones quedan sin protección.

   Este principio es hoy más importante que nunca. Desde el 15 de junio de 2026, Microsoft aplica progresivamente las políticas dirigidas a Todos los recursos que incluyen exclusiones de recursos también a los inicios de sesión que solo solicitan permisos básicos ("baseline scopes"). Antes, esos inicios de sesión quedaban fuera de la evaluación. Las organizaciones que dependían de exclusiones pueden ver nuevas solicitudes de MFA o de cumplimiento del dispositivo.

3. Una política por objetivo. Cada política debe hacer una sola cosa para un solo perfil. Combinar controles distintos en una misma política complica el análisis de impacto y la resolución de incidencias.

4. Convención de nombres. El nombre debe indicar de un vistazo el número, el perfil, el recurso y el control. Por ejemplo:

   • CA001-Admins-TodosRecursos-ExigirMFAResistentePhishing
   • CA002-TodosUsuarios-TodosRecursos-BloquearAutenticacionHeredada
   • CA003-TodosUsuarios-TodosRecursos-ExigirMFA
   • CA010-Invitados-TodosRecursos-ExigirMFA-FrecuenciaSesion
   • CA020-Usuarios-iOSAndroid-ExigirDirectivaProteccionApps
   • CA030-IdentidadesCarga-TodosRecursos-BloquearFueraUbicacionesConfianza

5. Responsables documentados. Cada política necesita un responsable, una justificación de negocio y una fecha de revisión. Una política sin responsable es una política que nadie modificará con seguridad.

Cómo crear un marco de acceso condicional por perfiles

Los perfiles agrupan identidades con un riesgo y unas necesidades de acceso similares, para aplicar a cada grupo un conjunto coherente de políticas.

Cómo diseñar y desplegar políticas de acceso condicional en 7 pasos

Paso 1: Inventariar políticas, aplicaciones y flujos de autenticación

Antes de cambiar nada, hay que entender qué hacen las políticas actuales. Exporta todas las políticas y documenta sus asignaciones, condiciones, controles y exclusiones. Después, usa los registros de inicio de sesión para identificar:

• Qué aplicaciones se utilizan.
• Qué clientes siguen usando protocolos heredados.
• Qué cuentas se autentican de forma no interactiva.

Comprueba también si siguen activos los valores predeterminados de seguridad (security defaults). Hay que desactivarlos para que el acceso condicional tome el relevo, así que la transición necesita su propio plan.

Este inventario forma parte de un proceso más amplio de bastionado avanzado de Microsoft 365.

Paso 2: Definir perfiles, convención de nombres y proceso de excepciones

Traslada el modelo de perfiles a grupos de Entra, asigna a cada política un número y un responsable, y define cómo se solicitan, aprueban y caducan las excepciones. Esta estructura es la que mantiene ordenado el conjunto de políticas a medida que crece el tenant.

Paso 3: Proteger primero las cuentas de emergencia y los administradores

Antes de aplicar cualquier otra política, asegúrate de que no puedes quedarte fuera:

• Crea al menos dos cuentas de emergencia (break-glass) solo en la nube.
• Protégelas con credenciales resistentes al phishing, como llaves de seguridad FIDO2.
• Exclúyelas de las políticas de acceso condicional.
• Configura alertas ante cualquier inicio de sesión con ellas.

Después, aplica MFA resistente al phishing a los roles privilegiados y el acceso privilegiado just-in-time con Privileged Identity Management.

Paso 4: Crear las políticas en modo solo informe

Crea cada política nueva o modificada en modo solo informe (Report-only). En este modo la política se evalúa en cada inicio de sesión y el resultado se registra, sin pedir verificaciones ni bloquear el acceso.

Esto incluye las políticas más básicas, como exigir MFA a todos los usuarios. Hasta la política más obvia puede romper una integración olvidada.

Paso 5: Analizar el impacto con los registros de inicio de sesión, el workbook de información de acceso condicional y What If

Usa tres herramientas complementarias:

• Registros de inicio de sesión: muestran el resultado del modo solo informe en inicios de sesión reales.
• Libro de información e informes de acceso condicional (Conditional Access insights and reporting workbook): agrega ese impacto por usuarios y aplicaciones.
• Herramienta What If: simula en el centro de administración de Microsoft Entra cómo se aplicarían las políticas a un usuario, aplicación, plataforma y ubicación concretos.

Mantén cada política en modo solo informe durante al menos un ciclo de negocio completo. Para la mayoría de las organizaciones, eso son dos semanas; más si hay procesos mensuales o trimestrales.

Estos registros, además, son una evidencia clave en cualquier investigación posterior. Por eso conviene preservarlos correctamente durante un ciberincidente.

Paso 6: Aplicar por fases (piloto → departamentos → toda la organización)

Pasa del modo solo informe a la aplicación por anillos:

1. Equipo de TI y usuarios piloto.
2. Un departamento cada vez.
3. El resto de la organización.

Comunica los cambios con antelación, informa al equipo de soporte y define un criterio de reversión para cada fase.

Paso 7: Supervisar, revisar y optimizar de forma continua

El acceso condicional se desvía con el tiempo como cualquier otra configuración. Revisa las políticas y exclusiones cada trimestre y configura alertas ante cambios en las políticas.

El agente de optimización de acceso condicional de Microsoft Security Copilot acelera este trabajo:

• Detecta usuarios, aplicaciones e identidades de agentes sin cobertura.
• Propone cambios o políticas nuevas, que siempre se crean en modo solo informe.
• Genera planes de despliegue por fases.

El agente no aplica políticas en modo activo por sí mismo. Por defecto puede crear políticas nuevas en modo solo informe, y se puede configurar para que lo haga solo tras la aprobación del administrador. La decisión de aplicarlas corresponde siempre al administrador.

Controles avanzados de acceso condicional

Una vez construida la base, los controles modernos van mucho más allá del MFA básico.

Hay otro cambio reciente a tener en cuenta: el control de concesión "Requerir aplicación cliente aprobada" se retiró en junio de 2026. Las políticas que dependían solo de él han dejado de restringir las aplicaciones cliente. En dispositivos móviles, sustitúyelo por "Requerir directiva de protección de aplicaciones", respaldado por una directiva de protección de aplicaciones de Intune.

Acceso condicional para identidades de carga de trabajo y agentes de IA

La seguridad de la identidad ya no termina en los usuarios. Las entidades de servicio, las identidades administradas y los agentes de IA se autentican de forma continua, a menudo con permisos amplios y poca supervisión.

Identidades de carga de trabajo. El acceso condicional para identidades de carga de trabajo permite bloquear entidades de servicio que se autentican desde ubicaciones no confiables o con riesgo detectado. Requiere licencias de Microsoft Entra Workload ID. Las identidades administradas no pueden protegerse de la misma forma, así que su protección depende de asignaciones de roles con mínimo privilegio.

Agentes de IA. Microsoft Entra Agent ID permite aplicar el acceso condicional a las identidades de los agentes. Los controles son todavía limitados: la condición principal disponible es el riesgo del agente, y el uso más habitual es bloquear agentes de alto riesgo o no autorizados.

Hay un matiz importante: si un agente accede a recursos mediante una clave de API, el acceso condicional no se aplica, porque no pasa por Microsoft Entra ID. Para aplicar acceso condicional a agentes se necesita una licencia de Microsoft Agent 365 junto con Entra ID P1 o Microsoft 365 E3, o bien Microsoft 365 E7.

Para profundizar en este tema, consulta nuestra guía sobre la seguridad de las identidades de los agentes de IA.

Cómo gestionar excepciones sin crear brechas de seguridad

Las excepciones son inevitables. Las excepciones permanentes, no.

• Exclusiones con fecha de caducidad. Toda exclusión debe expirar. Los paquetes de acceso con caducidad de Microsoft Entra ID Governance pueden automatizarlo.
• Responsables con nombre. Cada excepción necesita un responsable de negocio que responda por ella, no solo el administrador que la creó.
• Controles compensatorios. Una cuenta excluida del requisito de dispositivo compatible debería tener restricciones más estrictas de ubicación, riesgo o sesión.
• Revisión periódica. Revisa cada grupo de exclusión trimestralmente, idealmente con revisiones de acceso, y elimina a quien ya no tenga justificación.

El objetivo es sencillo: ninguna identidad debe quedar fuera del acceso condicional sin una razón documentada y una fecha de fin.

Acceso condicional, ENS y NIS2

Un acceso condicional bien diseñado contribuye de forma directa a los requisitos de control de acceso del Esquema Nacional de Seguridad (ENS) y de NIS2, aunque no garantiza por sí solo su cumplimiento.

ENS (Real Decreto 311/2022). La medida op.acc.6, sobre el mecanismo de autenticación de los usuarios de la organización, exige un doble factor de autenticación para el acceso desde o a través de zonas no controladas. Como el acceso a Microsoft 365 se produce habitualmente a través de internet, ese requisito afecta de lleno al diseño de las políticas. La medida op.acc.5 regula de forma equivalente la autenticación de los usuarios externos, lo que afecta a invitados y proveedores.

Las guías del CCN para entornos Microsoft, como la CCN-STIC-885A de configuración segura para Office 365 y la CCN-STIC-884A para Azure, recomiendan controlar el acceso mediante directivas de acceso condicional. Son la referencia práctica para el sector público y sus proveedores.

NIS2. La directiva incluye la autenticación multifactor entre las medidas de gestión de riesgos de ciberseguridad. A octubre de 2026, la ley española de transposición, la Ley de Coordinación y Gobernanza de la Ciberseguridad, sigue en tramitación parlamentaria. Aun así, las entidades que quedarán dentro de su ámbito pueden usar el acceso condicional como evidencia técnica de esas medidas desde ahora.

Errores habituales que interrumpen el negocio

• Aplicar políticas directamente. Saltarse el modo solo informe convierte cada política en un experimento en producción.
• Excluir las cuentas de emergencia sin vigilarlas. Son objetivos de alto valor; cada inicio de sesión con ellas debe generar una alerta.
• Usar las ubicaciones de confianza como control principal. La ubicación de red es una señal débil por sí sola. Sirve para ajustar controles, no para sustituir al MFA.
• Bloquear la autenticación heredada sin inventario previo. Impresoras, escáneres y aplicaciones que usan SMTP o IMAP fallan sin avisar y generan incidencias.
• Dejar crecer los grupos de exclusión. Las exclusiones amplias se convierten silenciosamente en la mayor brecha del conjunto de políticas.
• Olvidar las identidades no humanas. Las cuentas de servicio y los agentes de IA suelen tener más privilegios que los usuarios, con menos supervisión.

Conclusión: diseñar el acceso condicional una vez y operarlo de forma continua

El acceso condicional es el punto en el que Zero Trust se hace realidad en los entornos Microsoft. Cuando se diseña de forma deliberada, con perfiles, cobertura total, validación en modo solo informe y aplicación por fases, la organización gana a la vez seguridad y mejor experiencia de usuario. Cuando crece de forma reactiva, se convierte en una fuente de riesgo y de interrupciones.

El impacto en el negocio es directo:

• Menos incidencias de soporte.
• Despliegues de controles más rápidos y seguros.
• Evidencias de gobierno del acceso para auditorías del ENS y para la futura NIS2.
• Una base que se extiende de forma natural a los agentes de IA.

ne Digital ayuda a las organizaciones a pasar de un conjunto de políticas reactivo a una arquitectura de acceso condicional gobernada:

• Auditamos las políticas y exclusiones actuales.
• Las rediseñamos con un modelo por perfiles.
• Modelamos su impacto con datos del modo solo informe y de los registros de inicio de sesión.
• Las desplegamos por fases, sin afectar a la operativa.

Si quiere conocer más sobre el acceso condicional, contacte a nuestros expertos en Microsoft 365.