Directiva de Conditional Access no aplicada: cómo diagnosticar y corregir problemas en Microsoft Entra

By Mirko Peters · 2026-04-23 · Updated 2026-07-28

Una directiva de Conditional Access no aplicada requiere un escenario de negocio claro, límites de seguridad y de datos validados, y una propiedad con responsabilidades definidas. Empieza por el resultado que buscas, prueba la configuración y los efectos de la directiva con usuarios representativos, documenta la decisión y el proceso de soporte, y revisa el enfoque con regularidad a medida que cam

Automatically translated with AI from the original post. Read the English original

Una directiva de Conditional Access no aplicada requiere un escenario de negocio claro, límites de seguridad y de datos validados, y una propiedad con responsabilidades definidas. Empieza por el resultado que buscas, prueba la configuración y los efectos de la directiva con usuarios representativos, documenta la decisión y el proceso de soporte, y revisa el enfoque con regularidad a medida que cambian los requisitos y las capacidades de Microsoft 365.

Directiva de Conditional Access no aplicada: lista de verificación práctica

• Define el escenario, el propietario y los criterios de decisión.
• Valida los permisos, la directiva, la seguridad y el impacto en los usuarios.
• Prueba con un piloto y documenta las decisiones de soporte y revisión.

Consulta Microsoft Learn para obtener orientación actualizada.

Última revisión: julio de 2026.

Conditional Access es la base de la protección de identidades en Microsoft Entra (antes Azure AD). Pero cuando ves esos temidos estados "NotApplied" en tus registros, significa que los controles de acceso no están haciendo su trabajo, y tu organización podría quedar abierta a las personas equivocadas. Este problema pasa desapercibido hasta que las auditorías de cumplimiento, la respuesta a incidentes o los usuarios conflictivos dejan al descubierto las brechas.

¿Lo difícil? Rara vez hay una sola razón por la que una directiva de Conditional Access no se aplica. Puede ser un ajuste que se pasó por alto, una entidad de servicio que se escapa por las grietas o la típica proliferación de directivas que complica todo. Cuando Conditional Access no funciona, la resolución de problemas se complica rápidamente. Por eso es fundamental entender cómo Microsoft Entra evalúa y omite las directivas. Así es como corriges estas brechas invisibles, eliminas los problemas de los usuarios y tranquilizas a tu equipo de seguridad.

Con esta guía tendrás un camino claro para diagnosticar por qué no se aplicó una directiva, evitar las trampas más comunes y empezar a crear directivas de Conditional Access que hagan exactamente lo que pretendes, ni más ni menos.

Cómo funciona la evaluación de Conditional Access en Azure y por qué las directivas aparecen como No aplicadas

Conditional Access en Microsoft Entra puede parecer blanco o negro (aplicas la regla y obtienes el resultado), pero por debajo las cosas se complican rápido. Antes de intentar corregir un problema "NotApplied", necesitas saber cómo Entra procesa cada directiva en el momento en que alguien intenta iniciar sesión. No todas las directivas se activan o se omiten solo según lo que revisaste en el centro de administración.

Cuando una directiva aparece como "NotApplied", significa que Entra evaluó el inicio de sesión frente a la directiva, pero determinó que la regla no encajaba en la situación. Quizá el usuario, el dispositivo, la aplicación o el contexto del inicio de sesión no coincidían con el ámbito de la directiva, o quizá otra directiva de mayor prioridad se adelantó y ya produjo el resultado requerido.

Todo depende del orden de evaluación y de cómo Entra decide qué directivas prevalecen cuando se solapan. Además, están las exclusiones de directivas, los flujos de entidades de servicio, las particularidades de las ubicaciones con nombre y la forma en que ciertos servicios de Microsoft 365 tienen sus propias peculiaridades. Muchas directivas se omiten, a veces por motivos poco evidentes, y la etiqueta "NotApplied" es la única pista de que algo no va bien.

Si no profundizas en estos motivos y no reconoces "NotApplied" por lo que realmente es, corres el riesgo de dejar pasar brechas de seguridad o de causar problemas de inicio de sesión a usuarios legítimos. Ahí es donde los registros de inicio de sesión te ayudan a distinguir las directivas aplicadas, omitidas e ignoradas, y te dan una imagen real de lo que está sucediendo. Para profundizar en Conditional Access y el riesgo, este episodio del podcast sobre la proliferación de directivas y la gobernanza ofrece estrategias probadas en batalla para organizaciones de gran escala.

Cómo los registros de inicio de sesión de Microsoft Entra ayudan a identificar brechas en la aplicación de directivas

Los registros de inicio de sesión de Microsoft Entra son tu principal herramienta de investigación para aclarar los misterios de Conditional Access. Cada entrada del registro detalla qué directivas se evaluaron para un inicio de sesión, y verás estados explícitos como "Applied", "NotApplied", "Failure" o "Success". "NotApplied" no significa que Entra ignorara la directiva; significa que no se cumplieron las condiciones o que otra directiva tuvo prioridad.

Consulta los registros de inicio de sesión en la pestaña "Conditional Access". Aquí puedes cruzar el contexto de usuario, dispositivo y aplicación para averiguar por qué una directiva no se activó. Fíjate en artefactos como los inicios de sesión de entidades de servicio o los flujos solo de aplicación: a menudo aparecen como "NotApplied" porque CA no procesa tokens no interactivos. Saber leer estos registros es fundamental para detectar huecos y descartar configuraciones incorrectas. Si quieres profundizar en las directivas de referencia y en el seguimiento de problemas de confianza, consulta esta guía sobre huecos de confianza en Conditional Access.

Las configuraciones incorrectas más comunes de Conditional Access que impiden la aplicación de directivas

Seamos realistas: Conditional Access es una de esas herramientas en las que pequeños errores pueden convertirse en grandes dolores de cabeza de seguridad. ¿El principal culpable del estado "NotApplied"? La mala configuración, sin más. Una exclusión mal colocada, un umbral de riesgo demasiado permisivo o protocolos heredados que no se tuvieron en cuenta pueden dejar abiertas puertas de seguridad que todos creían bien cerradas.

Los desajustes de alcance y de condiciones son muy frecuentes, sobre todo con la configuración de ubicaciones o la lógica de inicio de sesión de riesgo. Ya sea un usuario en un lugar inesperado o una aplicación que usa una autenticación obsoleta, la aplicación de la directiva se rompe de formas que no son evidentes de antemano. Si a eso le sumas las particularidades de los controles de acceso, como confundir "requerir todos" con "requerir cualquiera", es fácil ver cómo las reglas previstas acaban escapándose por las rendijas.

Además, la autenticación heredada funciona como un callejón trasero que rodea Conditional Access y MFA: un agujero que muchas organizaciones olvidan hasta que una revisión de cumplimiento les da una mala noticia. Los mejores administradores se mantienen alerta revisando su trabajo y siguiendo los nuevos agujeros a medida que Microsoft 365 crece. Si quieres ver cómo una deriva sutil de la configuración puede alterar incluso los resultados de cumplimiento de Microsoft, este podcast sobre la deriva de cumplimiento en Microsoft 365 es muy revelador.

Errores habituales con ubicaciones y condiciones de riesgo en las directivas de Conditional Access

• Ubicaciones con nombre mal configuradas: si las ubicaciones con nombre tienen un intervalo de IP incorrecto, les faltan direcciones de confianza o los países están incompletos, algunos inicios de sesión pueden eludir tu directiva sin que te des cuenta.
• Niveles de riesgo inadecuados: si estableces umbrales de usuario de riesgo o de inicio de sesión de riesgo demasiado altos (o demasiado bajos), los riesgos legítimos pueden pasar desapercibidos o los usuarios pueden quedar bloqueados por falsas alarmas.
• Ubicaciones omitidas o demasiado amplias: olvidar incluir todos los intervalos de IP necesarios, aplicaciones en la nube o dejar geografías "de confianza" heredadas provoca una aplicación irregular de la directiva.
• Puntos ciegos en el estado del dispositivo: no tener en cuenta el cumplimiento del dispositivo o la unión híbrida a Azure AD deja fuera los inicios de sesión desde endpoints no administrados.

Para evitar estos errores, las auditorías periódicas y una gobernanza clara, tal como se explica en esta guía de gobernanza de Azure, marcan toda la diferencia.

Controles de acceso y reglas de concesión que hacen que Conditional Access falle

1. Controles de concesión en conflicto ("requerir todos" frente a "requerir cualquiera"): configurar directivas que exigen todos los controles de concesión, como MFA más dispositivo conforme más aplicación aprobada, crea una situación en la que un único requisito no cumplido provoca un "NotApplied" o una denegación no deseada.
2. Lógica de bloqueo de acceso poco clara: habilitar accidentalmente tanto los controles de "conceder" como los de "bloquear" en una misma directiva puede anularlos entre sí, lo que da lugar a una aplicación impredecible (o a un resultado "NotApplied" si las condiciones de bloqueo no se activan).
3. Grupos de usuarios superpuestos o excluidos: incluir grupos amplios en una directiva de alta prioridad puede anular a otras más específicas, que aparecen como "NotApplied" porque sus condiciones nunca llegan a activarse.
4. Destino incorrecto de aplicaciones en la nube: aplicar directivas a las aplicaciones en la nube equivocadas, o no incluir una aplicación clave, hace que las restricciones previstas simplemente no se apliquen.

Autenticación heredada y omisiones de MFA que dejan huecos

• Protocolos heredados: protocolos clásicos como POP, IMAP y SMTP omiten Conditional Access y MFA, colándose por las defensas a través de Exchange Online y otros endpoints clásicos.
• Registros de aplicaciones no gestionados: Las aplicaciones registradas antes de que se aplicara el acceso condicional (o que usan el flujo de credenciales de cliente) no están sujetas a las comprobaciones de directivas modernas, lo que permite que atacantes o usuarios desprevenidos accedan a los recursos sin ningún desafío.
• Exclusiones de MFA para cuentas de servicio: Las exclusiones generalizadas para sistemas heredados o buzones compartidos desactivan protecciones básicas y crean puntos ciegos que los atacantes aprovechan.
• Brechas entre aplicaciones: Una integración defectuosa entre aplicaciones cliente puede eliminar las solicitudes de MFA incluso donde esperas que aparezcan. Para más información sobre cómo cerrar estas brechas de Zero Trust, consulta esta guía de Zero Trust en Microsoft 365/Dynamics 365.

Solución de problemas de acceso condicional en las aplicaciones de Microsoft 365, B2B y plataformas de dispositivos

La aplicación del acceso condicional solo es tan sólida como su eslabón más débil. Microsoft 365 tiene sus propias peculiaridades de servicio, los inicios de sesión de invitados B2B y de socios se comportan de forma diferente, y la aplicación de directivas a los dispositivos no siempre es lo que cabría esperar. Estos matices pueden hacer fallar incluso directivas bien diseñadas y dejar rastros de "NotApplied".

Las cuentas de invitado, especialmente las que quedan olvidadas tras un proyecto con un socio, son un ejemplo claro. Sus límites de confianza y su ciclo de vida no son como los de los usuarios internos, así que las directivas pueden pasarlas por alto o activarse de forma irregular. Los comportamientos específicos de los servicios de Microsoft 365, como Exchange Online o SharePoint, añaden otra capa de complejidad, desde los permisos de las aplicaciones hasta los tiempos de espera de sesión.

Y luego está el lado de los dispositivos: cómo se une, se inscribe o se administra el endpoint de un usuario (piensa en la unión híbrida a Azure AD, el cumplimiento de Intune o las plataformas de dispositivos móviles) determina qué directivas se aplicarán o se omitirán. Si quieres llegar al fondo de la aplicación del acceso condicional en todos los entornos, crea una lista de comprobación específica para cada entorno que te permita detectar brechas en tiempo real, antes de que te cuesten una llamada de soporte a altas horas de la noche. Para más información sobre los riesgos de gobernanza con usuarios invitados y la gobernanza de Teams, consulta estrategias para el riesgo de cuentas de invitado y mejoras en la gobernanza de Teams para tener una visión más amplia del riesgo en evolución.

Particularidades del servicio de Microsoft 365 que afectan al acceso condicional

No todas las cargas de trabajo de Microsoft 365 siguen las mismas reglas en lo que respecta al acceso condicional. Servicios como Exchange Online, SharePoint y Teams tienen API, endpoints y lógica de gestión de sesiones propios. Algunos protocolos o el acceso desde aplicaciones móviles no siempre respetan la configuración más reciente de acceso condicional, sobre todo cuando intervienen endpoints heredados o aplicaciones con consentimiento OAuth.

Puede que veas una directiva como "NotApplied" porque la aplicación usa métodos de autenticación distintos, como Exchange Online PowerShell o SharePoint Online a través de un flujo heredado. Esto puede abrir cadenas de ataque mediante phishing de consentimiento o robo de tokens, lo que subraya la necesidad de una remediación específica en cada carga de trabajo. Para más información sobre estos vectores de ataque a nivel de servicio y su protección, consulta remediación de la cadena de ataque de Microsoft 365.

Acceso condicional para la colaboración B2B y usuarios invitados

• Límites de confianza B2B: Las organizaciones de origen de los usuarios invitados pueden tener sus propias reglas de seguridad, y es posible que tu acceso condicional no siempre prevalezca sobre ellas, por lo que las activaciones de directivas pueden ser irregulares.
• Flujos de invitación frente a flujos de inicio de sesión: El acceso condicional se aplica al iniciar sesión, no a la invitación. Si un invitado nunca inicia sesión, tus directivas nunca llegan a ejecutarse.
• Supervisión y alertas: Vigila las anomalías en los inicios de sesión de invitados configurando alertas y revisando los registros de Entra. Así evitas que el uso compartido externo o los accesos de invitados que siguen activos deriven en riesgos de cumplimiento.
• Revisión y caducidad: Las revisiones periódicas de acceso y las invitaciones con tiempo limitado ayudan a mantener el entorno ordenado y a reducir la superficie de ataque. Para obtener mejores resultados, organiza procesos de auditoría continuos con una cobertura ampliada, como se describe en esta guía práctica sobre los controles de uso compartido externo.

Desafíos de Windows y cumplimiento de dispositivos en el acceso condicional

• Exclusiones de plataforma de dispositivo: Las directivas aplicadas a Windows, iOS o Android pueden omitir por completo a los usuarios si su dispositivo no se reconoce o no cumple con los requisitos de conformidad.
• Errores comunes con Hybrid Azure AD Join: Los dispositivos que no están unidos correctamente (de forma híbrida o de otro tipo) no superarán las comprobaciones de dispositivo de Acceso condicional, lo que impide que se apliquen las directivas.
• Lagunas en la integración con Intune: Las directivas de conformidad basadas en Intune pueden tardar en registrarse, lo que crea un periodo en el que la aplicación de directivas parece inconsistente.
• Dispositivos no conformes o sin certificar: Los inicios de sesión desde dispositivos con jailbreak, desactualizados o no administrados normalmente no activan las directivas protegidas por dispositivo. Encontrarás más orientación sobre la integración de conformidad y protección contra amenazas en esta descripción general de Microsoft 365 Defender y Purview.

Cómo controlar la proliferación y los solapamientos de directivas que causan un Acceso condicional impredecible

En entornos grandes, es fácil excederse con las directivas de Acceso condicional. Quieres una cobertura hermética, pero eso puede generar rápidamente tantas reglas superpuestas o contradictorias que nadie puede prever qué se aplicará. Demasiadas directivas aumentan la complejidad, crean lagunas ocultas y complican la solución de problemas.

La proliferación de directivas, cuando administradores bienintencionados añaden "una directiva más" encima de las existentes, genera puntos ciegos de aplicación ocultos, sobre todo si confías en inclusiones de grupos o excepciones, o si olvidas limpiar las directivas de prueba. Las dependencias de servicios complican aún más la situación: un cambio en una aplicación en la nube o una nueva integración puede romper una cadena de directivas que antes era fiable.

Lo más inteligente es auditar y racionalizar las directivas con regularidad. Céntrate en directivas de referencia e inclusivas, y reduce al mínimo las excepciones temporales. Asegúrate de que cada directiva tenga un propósito claro y un resultado documentado, y de que esté acompañada de informes procesables. Nunca des por hecho que tu entorno está "configurado y olvidado". Para ver enfoques sobre la supervisión de brechas de confianza y la gestión de Shadow IT en Acceso condicional, consulta este manual sobre problemas de confianza en CA y la guía sobre la remediación de Shadow IT.

Cómo gestionar las dependencias de servicios y evitar la proliferación de directivas

• Auditar las directivas actuales: Inventaría y documenta periódicamente todas las directivas de CA activas, y vigila los solapamientos innecesarios o las reglas obsoletas.
• Mapear los servicios interconectados: Identifica las dependencias de CA entre Azure, Microsoft 365 y las aplicaciones de terceros para detectar las lagunas de aplicación que introducen las nuevas integraciones.
• Consolidar y racionalizar: Combina las directivas similares y retira las antiguas o no utilizadas, centrándote en reglas amplias y bien documentadas con excepciones específicas.
• Revisar los riesgos de IA y automatización: No olvides los procesos en segundo plano. Los agentes de IA y la automatización necesitan sus propios controles con alcance definido para bloquear los riesgos de Shadow IT, como se explica aquí: amenazas de Shadow IT de agentes de IA.

Cómo probar con seguridad el impacto de las directivas con Select All Consequences e informes

1. Activa primero el modo de solo informes: Antes de implementar una directiva, usa el modo de solo informes para simular su impacto sin bloquear a los usuarios legítimos. Analiza el efecto con los paneles de informes integrados.
2. Usa "Select All" con precaución: Aplica todas las acciones de aplicación en un entorno de prueba seguro para detectar resultados inesperados o exclusiones no previstas antes de la implementación completa.
3. Documenta los usuarios y las aplicaciones afectados: Lleva un registro de cada usuario, grupo y aplicación afectados por los cambios, para poder comunicarte con las partes interesadas y revertir la situación si las cosas salen mal.
4. Recopila los comentarios de usuarios y sistemas: Anima a los usuarios a informar de los problemas de inmediato y revisa los registros de errores del sistema por si hay bloqueos causados por directivas.
5. Usa los registros de auditoría para la respuesta a incidentes: Utiliza Microsoft Purview Audit y los registros del inquilino para hacer seguimiento de la actividad de los usuarios y verificar los resultados de las directivas. Para orientación sobre auditoría, consulta este análisis detallado de Purview Audit.

Qué hacer si te quedas bloqueado o si una directiva de Acceso condicional no se aplica

Todo administrador de Acceso Condicional ha vivido esta pesadilla: despliegas una nueva directiva y, de repente, tú o todo tu equipo os quedáis fuera del inquilino, o la directiva que creías que iba a salvar la situación no funciona en absoluto. Las llamadas de escalado se acumulan y te das cuenta de que necesitas una estrategia de recuperación sólida solo para que el negocio siga funcionando.

¿La buena noticia? Existe un plan de acción para recuperar el acceso rápidamente, sin empeorar las cosas. Conviene tener preparadas cuentas de emergencia (break-glass), contar con tácticas de reversión y de exclusión, y escalar con el soporte de Microsoft o con tu equipo de seguridad si es necesario.

Pero no nos quedemos solo en la recuperación. Si no abordas la causa raíz, volverás a estar en este lío la próxima vez que modifiques una directiva. Por eso, una revisión posterior al incidente, la comunicación con las partes interesadas, las pruebas continuas y el registro documentado de las lecciones aprendidas son tan importantes como activar el interruptor adecuado para restablecer el servicio. Para entender por qué la propiedad fragmentada de las herramientas hace naufragar la gobernanza, consulta este análisis en profundidad sobre los fallos de gobernanza.

Recuperación paso a paso cuando falla el Acceso Condicional

1. Usa una cuenta de emergencia (break-glass): Mantén al menos una cuenta de emergencia con derechos de administrador global y sin directivas de Acceso Condicional aplicadas. Inicia sesión con ella para recuperar el acceso en cualquier momento.
2. Aplica directivas de exclusión temporales: Si estás bloqueado, crea o activa una directiva de exclusión para tu cuenta o grupo afectado, para que puedas recuperar el acceso normal y corregir la causa raíz.
3. Escala para una anulación por parte de administración: Si fallan los pasos iniciales, contacta con el soporte de Microsoft o con tu equipo de seguridad para una intervención directa o el desbloqueo del inquilino.
4. Revierte los cambios recientes en las directivas: Vuelve a la última configuración conocida como correcta las reglas de Acceso Condicional nuevas o modificadas recientemente, y revisa los registros de inicio de sesión para confirmar que el problema se ha resuelto.

Próximos pasos y revisión eficaz de directivas tras identificar problemas de «no aplicada»

• Documenta las lecciones aprendidas: Registra exactamente qué salió mal, qué funcionó como solución y dónde se necesitan controles o auditorías futuros.
• Prueba en modo de solo informe: Antes de volver a activar una directiva, usa el modo de solo informe de Entra para asegurarte de que detectas los problemas sin provocar nuevas interrupciones.
• Recopila y aplica los comentarios: Solicita opiniones a los usuarios afectados y revisa los registros del sistema, y utiliza esa información para cerrar las brechas pendientes.
• Comunícate con las partes interesadas: Informa a todos los equipos afectados, a la dirección de TI, a los socios externos y a los usuarios sobre el incidente, la resolución y los planes de prevención a largo plazo.
• Compromete una gobernanza periódica: Programa revisiones continuas, informes y actualizaciones de tus directivas de Acceso Condicional, porque una buena gobernanza, como recuerda este podcast sobre la ilusión de la gobernanza, es una práctica continua y no un ejercicio de marcar una casilla y olvidarse.

🎧 También te recomendamos escuchar

• Identity Governance in Microsoft Entra

  Aprende sobre los controles de acceso y del ciclo de vida.

• Microsoft Purview – Simply Explained

  Explora el contexto de protección y cumplimiento.

• Microsoft 365 Governance Operating Model

  Comprende la propiedad sostenible y la toma de decisiones.