Gobernanza de Microsoft Entra Conditional Access en 2026

Son las 09:12 de un martes cuando María, la CISO de una fintech europea en rápido crecimiento, abre un informe de preparación para DORA que debería haber sido rutinario. Su panel de Microsoft Entra Conditional Access parece sólido. MFA se aplica a los administradores. La autenticación heredada está bloqueada. Los inicios de sesión de alto riesgo se someten a verificación adicional o se deniegan. Las aplicaciones financieras sensibles exigen dispositivos conformes. El acceso mediante navegador desde endpoints no gestionados está restringido.

Entonces lee el hallazgo del auditor.

“Sus reglas de Conditional Access son técnicamente sólidas, pero existen en el vacío. Muéstrenos la política aprobada por el Consejo de Administración que exige estos ajustes. Muéstrenos el registro de cambio de la regla modificada el mes pasado. Muéstrenos cómo la política de inicio de sesión de alto riesgo estaba activa durante el presunto ataque de credential stuffing. Muéstrenos cómo estas evidencias respaldan ISO 27001, DORA, NIS2 y GDPR.”

El equipo de identidad puede exportar la configuración. El SOC puede mostrar los registros de inicio de sesión. El responsable de cumplimiento puede señalar una carpeta de políticas. Pero nadie puede presentar una narrativa de evidencias gobernada que conecte riesgo, política, aprobación, configuración, excepciones, monitorización, respuesta a incidentes, obligaciones de privacidad y revisión por la dirección.

Ese es el problema de gobernanza de Conditional Access en 2026.

Microsoft Entra Conditional Access ya no es solo una configuración de identidad. Es un sistema de control a nivel del Consejo de Administración que decide quién puede acceder a servicios en la nube, bajo qué condiciones, desde qué dispositivos, con qué nivel de autenticación y con qué restricciones de sesión. Para las organizaciones reguladas, esas decisiones deben ser explicables, defendibles y estar mapeadas con las obligaciones de ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST y COBIT 2019.

Conditional Access ya es un sistema de control auditable

Conditional Access se sitúa en la intersección entre identidad, postura del dispositivo, sensibilidad de la aplicación, ubicación, riesgo de inicio de sesión, riesgo de usuario, comportamiento de sesión y registro de eventos. Una sola política puede exigir MFA, requerir un dispositivo conforme, bloquear el acceso desde una ubicación de riesgo, restringir descargas desde navegadores no gestionados o forzar la reautenticación cuando cambia el riesgo.

Esto lo convierte en uno de los puntos de aplicación de Zero Trust más potentes en entornos de nube de Microsoft. También lo convierte en un elemento altamente auditable.

Bajo ISO/IEC 27001:2022, un control no es maduro simplemente porque exista en un portal. La organización debe comprender su contexto, evaluar los riesgos de seguridad de la información, seleccionar tratamientos de riesgos, documentar la Declaración de Aplicabilidad, operar los controles, monitorizar su eficacia y mejorar con el tiempo. Las cláusulas relevantes incluyen la cláusula 6.1.2 para evaluación de riesgos, la cláusula 6.1.3 para tratamiento de riesgos, la cláusula 7.5 para información documentada, la cláusula 8.1 para planificación y control operacional, la cláusula 9.1 para monitorización y la cláusula 9.3 para revisión por la dirección.

El Anexo A, alineado con ISO/IEC 27002:2022, proporciona el lenguaje práctico de control que reconocerán los auditores. Conditional Access suele respaldar:

• 5.15 control de acceso
• 5.16 gestión de identidades
• 5.17 información de autenticación
• 5.18 derechos de acceso
• 8.1 dispositivos de usuario final
• 8.2 derechos de acceso privilegiado
• 8.3 restricción del acceso a la información
• 8.5 autenticación segura
• 8.15 registro de eventos
• 8.16 actividades de monitorización

Para organizaciones reguladas en la UE, la carga de gobernanza es aún más clara. NIS2 Article 20 asigna a los órganos de dirección la responsabilidad de aprobar y supervisar las medidas de gestión de riesgos de ciberseguridad. NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas, incluidos control de acceso, gestión de activos, ciberhigiene, gestión de incidentes, seguridad de la cadena de suministro, evaluación de la eficacia y autenticación multifactor o continua cuando proceda. NIS2 Article 23 introduce la notificación escalonada de incidentes significativos, incluida una alerta temprana en un plazo de 24 horas, una notificación de incidente en un plazo de 72 horas y un informe final en el plazo de un mes.

DORA plantea expectativas similares para las entidades financieras. Article 5 exige un marco interno de gobernanza y control. Article 6 exige un marco de gestión del riesgo de las TIC. Article 9 cubre protección y prevención, incluidas restricciones de acceso y prácticas de gestión de identidades. Articles 10, 11, 17, 18 y 19 conectan detección, respuesta, recuperación, gestión de incidentes relacionados con las TIC, clasificación y notificación. Dado que DORA es aplicable desde el 17 de enero de 2025, las entidades financieras deben tratar Conditional Access como parte de las evidencias de resiliencia operativa, no solo como endurecimiento de identidad.

GDPR añade la perspectiva de privacidad. Si Conditional Access protege sistemas que tratan datos personales, respalda los principios de responsabilidad proactiva de Article 5, la responsabilidad del responsable del tratamiento de Article 24, la protección de datos desde el diseño de Article 25 y la seguridad del tratamiento de Article 32. Si se sospecha un acceso no autorizado, los registros de Conditional Access pueden formar parte de la evaluación de una violación de seguridad y de las evidencias de notificación.

El error consiste en tratar todo esto como solicitudes de auditoría separadas. El enfoque maduro es un único modelo de gobernanza de Conditional Access que pueda segmentarse por marco, regulador, cliente o audiencia del Consejo de Administración.

La configuración no es gobernanza

La mayoría de las organizaciones pueden responder a la pregunta: “¿Qué está configurado?”. Muchas menos pueden responder a preguntas más exigentes:

• ¿Por qué esta política de Conditional Access está configurada de esta manera?
• ¿Qué escenario de riesgo trata?
• ¿Qué cláusula de la política la exige?
• ¿Quién aprobó el cambio?
• ¿Qué usuarios, aplicaciones y dispositivos están excluidos?
• ¿Cómo se prueba?
• ¿Qué registros demuestran que funcionó?
• ¿Con qué frecuencia se revisa?
• ¿Qué ocurre cuando falla?

Aquí es donde suelen aparecer los hallazgos de auditoría. Existen políticas, pero no están vinculadas a la configuración de Microsoft Entra. El cumplimiento de dispositivos es responsabilidad de Operaciones de TI, pero no está mapeado al riesgo de control de acceso. Las políticas de riesgo de inicio de sesión están habilitadas sin umbrales documentados ni reglas de escalado. Las restricciones de sesión están configuradas, pero nunca se prueban desde dispositivos no gestionados. Los registros se conservan, pero no se preparan como evidencias de auditoría.

Clarysec trata esto como un problema de trazabilidad. Cada decisión de Conditional Access debe conectar política, riesgo, control, configuración, evidencia y revisión.

La Política de Uso de la Nube para pymes Política de Uso de la Nube para pymes establece:

Autenticación multifactor (MFA) para cuentas administrativas y de usuario

De la sección “Requisitos de implementación de la política”, cláusula de política 6.2.2.

Esa cláusula es el mandato. La regla de Conditional Access es la aplicación. El registro de inicio de sesión es la evidencia. El registro de revisión demuestra la supervisión.

La Política de Seguridad de Redes para pymes Política de Seguridad de Redes para pymes añade el requisito de postura del endpoint:

Los sistemas sin antivirus actualizado, parches o una postura de dispositivo aceptable deben bloquearse o ponerse en cuarentena

De la sección “Requisitos de implementación de la política”, cláusula de política 6.4.3.

En términos de Microsoft Entra, esto puede convertirse en “exigir dispositivo conforme”, “bloquear plataformas no soportadas”, “restringir sesiones de navegador no gestionadas” o “denegar el acceso a aplicaciones de alto riesgo desde dispositivos desconocidos”. Pero el control no está completo hasta que la organización pueda demostrar alcance, aprobación, pruebas, excepciones y monitorización.

Construya la base de gobernanza antes del conjunto de reglas

Un programa sólido de Conditional Access empieza fuera del portal de Entra. Empieza con el SGSI, el Registro de Riesgos, la Política de Control de Acceso, la Política de Uso de la Nube, la SoA y el modelo de evidencias.

Zenith Blueprint de Clarysec: una hoja de ruta de 30 pasos para auditores Zenith Blueprint proporciona una secuencia práctica. En la fase de gestión de riesgos, paso 13, Planificación del Tratamiento de Riesgos y Declaración de Aplicabilidad, indica a las organizaciones que conecten controles con riesgos e impulsores regulatorios:

Referenciar regulaciones de forma cruzada: si determinados controles se implementan específicamente para cumplir GDPR, NIS2 o DORA, puede indicarlo en el Registro de Riesgos, como parte de la justificación del impacto del riesgo, o en las notas de la SoA.

Para Conditional Access, esto cambia la narrativa de evidencias. En lugar de decir “hemos habilitado MFA”, la organización puede afirmar:

• Escenario de riesgo: credenciales de usuario comprometidas permiten acceso no autorizado a datos de clientes en Microsoft 365 y SaaS financiero.
• Propietario del riesgo: responsable de seguridad de TI.
• Tratamiento: Microsoft Entra Conditional Access exige MFA fuerte para roles privilegiados, MFA para usuarios, bloqueo por riesgo de inicio de sesión, dispositivos conformes para aplicaciones sensibles y restricciones de sesión para endpoints no gestionados.
• Mapeo ISO/IEC 27002:2022: 5.15, 5.16, 5.17, 5.18, 8.1, 8.2, 8.3, 8.5, 8.15 y 8.16.
• Mapeo regulatorio: NIS2 Articles 20, 21 y 23, DORA Articles 5, 6, 9, 10, 17 y 18, GDPR Articles 24, 25, 32 y 33.
• Evidencias: aprobación de la política, exportación de Conditional Access, ticket de cambio, resultados de pruebas, registros de inicio de sesión, informes de cumplimiento de dispositivos, registro de excepciones, tickets del SOC y actas de revisión por la dirección.

Zenith Blueprint también explica en la fase Controles en acción, paso 19, por qué la postura del endpoint debe formar parte de la decisión de acceso:

El acceso a la información a través de endpoints debe ser sensible al contexto. Por ejemplo, ¿cumple el dispositivo los estándares mínimos de seguridad antes de acceder a los recursos de la empresa? ¿Ha superado recientemente un análisis de malware? ¿Se conecta desde una ubicación o red inusual? Integrada con los principios de Zero Trust, la postura de endpoint puede alimentar el acceso condicional y denegar la entrada hasta que el dispositivo demuestre que es seguro.

Ese es el principio central de gobernanza. Conditional Access debe estar basado en riesgos, ser sensible al contexto y producir evidencias.

Mapee las decisiones de Conditional Access a objetivos de control

Un programa maduro define decisiones de acceso estándar y después mapea cada una con la intención de gobernanza y con las evidencias. Esto evita la proliferación de políticas y facilita las conversaciones de auditoría.

La Política de Uso de la Nube empresarial Política de Uso de la Nube respalda la integración central de identidades:

La integración de inicio de sesión único (SSO) con el IdP de la organización es obligatoria para garantizar la coherencia de la autenticación.

De la sección “Requisitos de implementación de la política”, cláusula de política 6.2.4.

La Política de Gestión de Cuentas de Usuario y Privilegios empresarial Política de Gestión de Cuentas de Usuario y Privilegios explicita la monitorización:

El uso de sistemas de inicio de sesión único (SSO) debe integrarse con proveedores de identidad centrales, por ejemplo, Active Directory (AD) y Azure AD, y supervisarse para detectar actividad anómala de inicio de sesión.

De la sección “Requisitos de implementación de la política”, cláusula de política 6.3.4.

En conjunto, estas cláusulas exigen más que SSO. Exigen una arquitectura central de identidad, autenticación coherente, monitorización de inicios de sesión anómalos y evidencias de que las decisiones de acceso se revisan.

Cumplimiento de dispositivos: el control que los auditores pueden probar

El cumplimiento de dispositivos es una de las áreas más fáciles de sobreestimar. Un panel puede mostrar un 92 % de dispositivos conformes, pero un auditor preguntará si la regla se aplica a las aplicaciones relevantes, si se permiten dispositivos personales, si se bloquean plataformas no soportadas y si las excepciones están aprobadas.

La Política de Trabajo Remoto empresarial Política de Trabajo Remoto establece la base de aprobación:

Los dispositivos BYOD deben aprobarse explícitamente y:

De la sección “Requisitos de gobernanza”, cláusula de política 5.2.2.

Esa frase breve importa. BYOD no es solo un estado técnico. Es una decisión de gobernanza. En Conditional Access, debe traducirse en reglas de titularidad del dispositivo, configuraciones de referencia mínimas de cumplimiento, requisitos de cifrado, comprobaciones de parches y protección contra malware, protección de aplicaciones móviles, tratamiento de contratistas y revisión de excepciones.

Zenith Controls de Clarysec: la guía de cumplimiento transversal Zenith Controls mapea el control ISO/IEC 27002:2022 5.15 control de acceso como preventivo, protegiendo la confidencialidad, integridad y disponibilidad en la capacidad operativa de gestión de identidades y accesos. También conecta el control de acceso con los dispositivos de usuario final, porque los portátiles, móviles y equipos de sobremesa no gestionados pueden debilitar la aplicación centralizada del acceso.

Un paquete práctico trimestral de evidencias de dispositivos para Conditional Access debe incluir:

• Configuración de referencia de cumplimiento de dispositivos aprobada.
• Políticas de Conditional Access que exigen dispositivos conformes.
• Aplicaciones protegidas por esas políticas.
• Exportación de usuarios, grupos, aplicaciones y plataformas excluidos.
• Informe de tendencias de dispositivos no conformes.
• Muestra de registros de inicio de sesión bloqueados para dispositivos no conformes.
• Registro de excepciones con propietario, motivo, fecha de caducidad y aceptación del riesgo.
• Registro de revisión por la dirección.

Este paquete de evidencias respalda el control operacional de ISO/IEC 27001:2022, la ciberhigiene de NIS2, la protección y prevención de DORA y la responsabilidad proactiva de GDPR.

Riesgo de inicio de sesión: la detección debe convertirse en evidencia de decisión

Conditional Access basado en riesgos es el punto en el que la detección de identidad se convierte en gobernanza de accesos. Microsoft Entra puede evaluar señales como propiedades de inicio de sesión desconocidas, direcciones IP anónimas, viaje imposible y credenciales filtradas. Pero los auditores no aceptarán “política de riesgo habilitada” como respuesta final. Preguntarán por qué se seleccionaron esos umbrales, quién revisa los eventos de riesgo y cuándo un inicio de sesión de alto riesgo se convierte en incidente.

La Política de Registro y Monitorización para pymes Política de Registro y Monitorización para pymes define un requisito mínimo de registro:

Registros de autenticación: intentos de inicio de sesión correctos y fallidos, duración de sesión, uso de MFA

De la sección “Requisitos de gobernanza”, cláusula de política 5.4.2.

La Política de Registro y Monitorización empresarial Política de Registro y Monitorización amplía el conjunto esperado de eventos:

Tipos de eventos que deben capturarse, por ejemplo, inicios de sesión, fallos de acceso, cambios de configuración, comandos administrativos, detección de malware

De la sección “Requisitos de gobernanza”, cláusula de política 5.1.1.

Para Conditional Access, las evidencias útiles deben incluir inicios de sesión correctos, inicios de sesión fallidos, resultado de la política de Conditional Access, método de MFA, riesgo de inicio de sesión, riesgo de usuario, estado de cumplimiento del dispositivo, aplicación accedida, ubicación, aplicación cliente, resultado del control de sesión, historial de cambios de política y acciones administrativas.

Zenith Controls mapea el control ISO/IEC 27002:2022 8.16 actividades de monitorización como detectivo y correctivo, asociado con los conceptos de detectar y responder. Conecta la monitorización con el registro de eventos, la evaluación de eventos, la inteligencia de amenazas, la supervisión de proveedores y la gestión de incidentes. También mapea las actividades de monitorización con GDPR Articles 32 y 33, monitorización y notificación de incidentes de NIS2, seguimiento de incidentes relacionados con las TIC de DORA, monitorización continua de NIST y supervisión de seguridad de COBIT.

Un inicio de sesión de alto riesgo bloqueado por Conditional Access no es, por tanto, solo un éxito de seguridad. Es evidencia de que los procesos preventivos, detectivos y de respuesta están conectados.

Controles de sesión: el vínculo entre acceso y protección de datos

Las decisiones previas al acceso no son suficientes. Una vez autenticado el usuario, los controles de sesión determinan cuánta exposición permanece. Esto es especialmente importante para dispositivos no gestionados, contratistas, trabajo remoto, terminales compartidos, ubicaciones de riesgo y aplicaciones que tratan datos personales.

La Política de Requisitos de Seguridad de las Aplicaciones para pymes Política de Requisitos de Seguridad de las Aplicaciones para pymes establece:

Gestión de sesiones: los datos de sesión deben expirar tras 15 minutos de inactividad e incluir avisos de tiempo de espera cuando proceda.

De la sección “Requisitos de implementación de la política”, cláusula de política 6.1.1.3.

En la gobernanza de Microsoft Entra, esto puede mapearse con la frecuencia de inicio de sesión, restricciones de sesiones de navegador persistentes, Conditional Access App Control, restricciones impuestas por la aplicación, bloqueo de descargas, reautenticación tras cambios de riesgo y limitaciones de sesión basadas en sensibilidad.

Los controles de sesión respaldan el control ISO/IEC 27002:2022 8.3 restricción del acceso a la información y 8.5 autenticación segura. También respaldan GDPR Article 32 al reducir la visualización, descarga o persistencia no autorizada del acceso a datos personales. Para DORA, las restricciones de sesión ayudan a limitar la exposición en sistemas de TIC y respaldan la detección y respuesta. Para NIS2, son medidas proporcionadas de control de acceso y ciberhigiene.

Las evidencias deben explicar por qué existe el control de sesión. Por ejemplo, “bloquear descargas desde dispositivos no gestionados para aplicaciones de RR. HH. y finanzas” debe mapearse con fuga de datos personales, compromiso de endpoint y pérdida de confidencialidad. Las evidencias deben incluir configuración, alcance de aplicaciones, pruebas de inicio de sesión desde dispositivos gestionados y no gestionados, registros que muestren las restricciones y registros de aprobación.

Cree un Registro de Control de Conditional Access

Un Registro de Control de Conditional Access es el puente operativo entre el Registro de Riesgos, la Declaración de Aplicabilidad y la configuración de Microsoft Entra. No sustituye a esos documentos. Los hace utilizables.

Utilice un ciclo de revisión de cinco pasos:

1. Confirmar alcance: identifique aplicaciones en la nube que traten datos regulados, financieros, operativos o personales.
2. Mapear políticas a riesgos: vincule cada política de Conditional Access con al menos un escenario de riesgo y un propietario del riesgo.
3. Validar exclusiones: exporte usuarios, roles, aplicaciones, grupos, ubicaciones y dispositivos excluidos. Cada exclusión necesita propietario, motivo, aprobación y fecha de caducidad.
4. Probar la aplicación: utilice cuentas de prueba para verificar MFA, cumplimiento de dispositivos, bloqueo por riesgo, bloqueo de autenticación heredada y restricciones de sesión.
5. Empaquetar evidencias: almacene exportaciones, capturas de pantalla, registros y aprobaciones con metadatos.

La Política de Auditoría y Monitorización del Cumplimiento para pymes Política de Auditoría y Monitorización del Cumplimiento para pymes es crítica para la integridad de las evidencias:

Deben documentarse los metadatos, por ejemplo, quién los recopiló, cuándo y desde qué sistema.

De la sección “Requisitos de implementación de la política”, cláusula de política 6.2.3.

Las capturas de pantalla sin origen, fecha, recopilador y contexto del sistema son evidencias débiles. Las exportaciones de Conditional Access, los registros de inicio de sesión y los informes de revisión deben tratarse como registros de auditoría controlados.

Mapeo de cumplimiento transversal para evidencias de Conditional Access

El valor de Conditional Access es que un conjunto de controles puede satisfacer varias perspectivas de auditoría cuando está debidamente gobernado.

Zenith Controls también mapea 5.15 control de acceso con GDPR Article 32, NIS2 Article 21(2)(i), conceptos de gobernanza de accesos de DORA, familias de control de acceso de NIST SP 800-53 y COBIT 2019 DSS06.04. Mapea 8.5 autenticación segura con GDPR Articles 5, 24, 25 y 32, gestión del riesgo de ciberseguridad de NIS2, gestión del riesgo de TIC de DORA, identificación y autenticación de NIST, e identidad y acceso lógico de COBIT.

La lección es sencilla. Los marcos utilizan lenguaje diferente, pero esperan el mismo patrón de aseguramiento: los usuarios correctos, desde contextos aceptables, usando autenticación fuerte, mediante sesiones gobernadas, con registros que demuestren lo ocurrido.

Cómo examinarán los auditores Conditional Access

Un auditor de ISO/IEC 27001:2022 empezará por el SGSI. Preguntará si Conditional Access está dentro del alcance, qué riesgos trata, cómo aparece en la SoA, cómo se aprueban las políticas, cómo se controlan los cambios y si las evidencias demuestran la eficacia operativa. Espere muestreos de usuarios privilegiados, aplicaciones sensibles, exclusiones y cambios recientes de políticas.

Un auditor de DORA o NIS2 se centrará en resiliencia operativa, responsabilidad de la dirección y riesgo. Puede preguntar cómo los controles de acceso protegen funciones críticas o importantes, cómo el Consejo de Administración supervisa el riesgo de identidad, cómo se clasifican y priorizan los inicios de sesión de alto riesgo y si los fallos de acceso alimentan las decisiones de clasificación o notificación de incidentes.

Un auditor centrado en GDPR se interesará por los datos personales. Puede preguntar cómo se protegen los datos de RR. HH., finanzas o clientes frente a dispositivos no gestionados, cómo los controles de sesión reducen la visualización no autorizada, cómo se limita el acceso a usuarios autorizados y cómo los registros respaldan la evaluación de violaciones de seguridad.

Un revisor de COBIT 2019 buscará prácticas de gobernanza, propiedad, métricas, repetibilidad, monitorización del desempeño y mejora. Un evaluador orientado a NIST comparará los resultados de identidad, autenticación, autorización, monitorización y respuesta con evidencias técnicas.

La Política de Control de Acceso empresarial Política de Control de Acceso marca el tono para el acceso privilegiado:

El acceso administrativo debe controlarse estrictamente mediante:

De la sección “Requisitos de gobernanza”, cláusula de política 5.4.1.

Sus evidencias de Microsoft Entra deben completar esa frase operativamente. ¿Qué roles son privilegiados? ¿Cuáles exigen MFA fuerte o resistente al phishing? ¿Cuáles son elegibles mediante gestión de identidades privilegiadas? ¿Qué cuentas son break-glass? ¿Cuáles están excluidas de las políticas? ¿Quién las revisa? ¿A dónde se envían las alertas?

Métricas para el Consejo de Administración sobre gobernanza de Conditional Access

Dado que NIS2 y DORA enfatizan la responsabilidad de la dirección, los informes de Conditional Access deben ser comprensibles para el Consejo de Administración. Evite informar solo nombres de políticas. Informe sobre la postura de riesgo y el desempeño del control.

Entre las métricas útiles se incluyen:

• Porcentaje de cuentas privilegiadas protegidas con MFA fuerte.
• Número de exclusiones de Conditional Access por nivel de riesgo.
• Número de inicios de sesión de alto riesgo bloqueados, sometidos a verificación adicional o permitidos.
• Porcentaje de accesos a aplicaciones sensibles que exigen dispositivos conformes.
• Número de sesiones desde dispositivos no gestionados hacia aplicaciones reguladas.
• Tiempo de análisis inicial de eventos de inicio de sesión de alto riesgo.
• Número de cambios de políticas de Conditional Access durante el trimestre.
• Número de excepciones caducadas, renovadas y vencidas.
• Cobertura del registro de autenticación, sesiones y cambios de políticas.
• Casos de prueba fallidos en la validación trimestral de Conditional Access.

Estas métricas convierten la configuración de identidad en evidencias de supervisión. También ayudan a los órganos de dirección a demostrar aprobación, revisión, asignación de recursos y mejora continua.

Hallazgos habituales que eliminar antes de la auditoría

Los hallazgos sobre Conditional Access suelen deberse a debilidades de gobernanza, no a fallos tecnológicos. Los problemas más habituales incluyen:

• Las cuentas break-glass están excluidas, pero no monitorizadas.
• Las políticas se nombran de forma incoherente y carecen de propietarios.
• Faltan aplicaciones sensibles en las reglas de cumplimiento de dispositivos.
• Los usuarios invitados y colaboradores externos eluden los controles estándar.
• Las cuentas de servicio y las identidades de cargas de trabajo no se gobiernan por separado.
• Las detecciones de riesgo de inicio de sesión no se analizan ni se vinculan a incidentes.
• Los controles de sesión nunca se prueban desde dispositivos no gestionados.
• Los cambios de políticas se realizan directamente en producción sin registros de cambio.
• Las exclusiones son permanentes, no documentadas o aprobadas verbalmente.
• Los registros se conservan, pero no se revisan.
• Las evidencias carecen de metadatos, contexto de origen o cadena de custodia.

Un estado objetivo preparado para 2026 incluye gobernanza de accesos aprobada por la dirección, diseño de Conditional Access basado en riesgos, mapeo explícito con ISO/IEC 27001:2022 e ISO/IEC 27002:2022, soporte documentado para NIS2, DORA y GDPR, MFA fuerte por rol y riesgo, cumplimiento de dispositivos para accesos sensibles, restricciones de sesión para contextos no gestionados, autenticación y cambios de políticas monitorizados, un ciclo de vida de excepciones, pruebas trimestrales e informes a la dirección.

Convierta Microsoft Entra en evidencias preparadas para auditoría

Sus políticas de Conditional Access ya toman decisiones de seguridad cada minuto. La cuestión es si esas decisiones están gobernadas, basadas en riesgos, monitorizadas y mapeadas con las obligaciones que importan a sus auditores y reguladores.

Empiece con Zenith Blueprint Zenith Blueprint, especialmente el paso 13, para conectar las políticas de Conditional Access con riesgos, tratamientos, la Declaración de Aplicabilidad y notas regulatorias. Use Zenith Controls Zenith Controls para mapear control de acceso, autenticación segura, postura de endpoint, registro y monitorización en ISO/IEC 27001:2022, ISO/IEC 27002:2022, NIS2, DORA, GDPR, NIST y COBIT 2019.

Después, alinee sus requisitos internos con las políticas de Clarysec, incluidas Política de Uso de la Nube para pymes, Política de Seguridad de Redes para pymes, Política de Registro y Monitorización para pymes, Política de Auditoría y Monitorización del Cumplimiento para pymes, Política de Requisitos de Seguridad de las Aplicaciones para pymes, Política de Uso de la Nube, Política de Gestión de Cuentas de Usuario y Privilegios, Política de Trabajo Remoto, Política de Control de Acceso y Política de Registro y Monitorización.

Clarysec le ayuda a convertir Microsoft Entra Conditional Access de una colección de ajustes en un sistema de control aplicable, medible y preparado para auditoría. Descargue los toolkits relevantes de Clarysec, solicite una revisión de mapeo de políticas o reserve una evaluación para comprobar si sus evidencias de Conditional Access pueden resistir el escrutinio de ISO 27001, NIS2, DORA y GDPR.