Políticas de Acceso Condicional que toda organización debería revisar

Microsoft Entra Conditional Access es una de las capas de seguridad más importantes de Microsoft 365.

Su función no consiste simplemente en activar MFA. Conditional Access combina señales relacionadas con la identidad, el dispositivo, la aplicación, la ubicación y el riesgo para decidir si una solicitud de acceso debe permitirse, bloquearse o exigir controles adicionales.

El problema es que disponer de Conditional Access no significa necesariamente que esté bien configurado.

Con el tiempo aparecen exclusiones, aplicaciones nuevas, cambios en los métodos de autenticación, dispositivos no administrados, cuentas técnicas y políticas que permanecen indefinidamente en modo report-only.

Por eso Conditional Access debe revisarse como un sistema de controles relacionados, no como una colección de reglas independientes.

Estas son las políticas que toda organización que utiliza Microsoft 365 debería revisar.

Antes de revisar las políticas: proteja el acceso de emergencia

Antes de cambiar cualquier política de Conditional Access, confirme que existen cuentas de acceso de emergencia y que pueden utilizarse si una configuración incorrecta bloquea a los administradores.

Estas cuentas, conocidas habitualmente como cuentas break-glass, deben mantenerse separadas de las cuentas administrativas utilizadas diariamente.

Revise:

• Que existan al menos las cuentas de emergencia necesarias
• Que estén correctamente protegidas
• Que no dependan de los mismos controles que podrían provocar un bloqueo
• Que sus credenciales estén almacenadas de forma segura
• Que su funcionamiento se pruebe periódicamente
• Que cualquier uso genere una alerta

Cuando modifique controles importantes, utilice primero report-only y un grupo piloto.

Revise el impacto en los registros de inicio de sesión antes de pasar una política a modo activo.

Una política técnicamente correcta puede convertirse en un incidente operativo si nadie puede acceder al tenant para corregirla.

1. MFA para todos los usuarios y todos los recursos

La primera política que debe existir es una línea base de autenticación multifactor.

El objetivo debería ser proteger todos los usuarios y todos los recursos, manteniendo únicamente las exclusiones que estén realmente justificadas.

El error habitual consiste en proteger únicamente algunas aplicaciones.

Una política que enumera aplicaciones individualmente puede quedar obsoleta cuando aparecen nuevos servicios o aplicaciones empresariales.

Utilizar todos los recursos como punto de partida reduce la posibilidad de que una aplicación nueva quede fuera de la protección por accidente.

La revisión debería comprobar:

• Qué usuarios están excluidos
• Qué recursos están excluidos
• Si esas excepciones todavía son necesarias
• Si existen cuentas técnicas que necesitan un tratamiento diferente
• Si los usuarios pueden satisfacer el método de autenticación requerido
• Si existen exclusiones antiguas cuyo propietario ya no está identificado

Las excepciones deben documentarse y revisarse periódicamente.

2. MFA resistente al phishing para administradores

Una política general de MFA no debería ser necesariamente el nivel máximo de protección para las cuentas privilegiadas.

Las cuentas administrativas requieren controles más fuertes porque una identidad privilegiada comprometida puede permitir cambios en Conditional Access, Exchange Online, aplicaciones empresariales, roles administrativos y configuraciones de seguridad.

Para los principales roles administrativos, revise la posibilidad de exigir MFA resistente al phishing mediante Authentication Strength.

Esto permite utilizar métodos como passkeys/FIDO2 u otros mecanismos compatibles con el nivel de autenticación requerido.

Antes de activar esta política, asegúrese de que los administradores ya disponen de métodos compatibles.

Activarla sin preparar previamente las credenciales puede provocar un bloqueo administrativo.

Revise especialmente:

• Global Administrator
• Conditional Access Administrator
• Security Administrator
• Exchange Administrator
• Privileged Role Administrator
• Authentication Administrator
• Otros roles con capacidad para modificar configuraciones críticas

3. Bloquear la autenticación heredada

Los protocolos de autenticación heredada no pueden aplicar correctamente controles modernos como MFA y el estado del dispositivo.

Revise si todavía existen aplicaciones, dispositivos, scripts o procesos que dependan de estos métodos.

La mejor práctica no consiste en mantener una excepción permanente sin investigar su causa.

Si todavía existe una dependencia legítima, documente:

• Qué sistema la utiliza
• Quién es su propietario técnico
• Qué usuarios o cuentas están afectados
• Por qué continúa siendo necesaria
• Qué controles compensatorios existen
• Cuál es el plan para eliminarla

Una excepción que nadie recuerda por qué existe termina convirtiéndose en una vulnerabilidad invisible.

4. Responder al riesgo de inicio de sesión

No todos los inicios de sesión presentan el mismo nivel de riesgo.

Microsoft Entra ID Protection puede proporcionar señales que ayudan a determinar si una solicitud de autenticación podría no proceder del propietario legítimo de la identidad.

Conditional Access puede utilizar determinadas señales de riesgo para exigir controles adicionales o bloquear el acceso.

Esta política no sustituye a una política MFA general.

Añade una decisión basada en contexto cuando existen señales anómalas.

Al revisar esta política, compruebe:

• El nivel de riesgo utilizado
• La acción aplicada
• Las exclusiones
• Si los usuarios afectados disponen de MFA correctamente registrado
• Cómo se investigan los eventos de riesgo
• Quién revisa los incidentes después de producirse
• Si existe un procedimiento claro para diferenciar actividad legítima de actividad maliciosa

Las señales de riesgo deben formar parte de un flujo de investigación, no únicamente generar un bloqueo que nadie analiza después. Cuando una señal indique actividad sospechosa, el siguiente paso es investigar un posible compromiso de Microsoft Entra ID de forma estructurada.

5. Exigir dispositivos administrados para acceso privilegiado o sensible

Una contraseña correcta y MFA no siempre son suficientes.

Para administradores y aplicaciones con información sensible, puede ser apropiado exigir que el dispositivo cumpla requisitos adicionales de confianza.

Dependiendo de la arquitectura utilizada, esto puede incluir dispositivos marcados como compliant mediante Microsoft Intune u otros estados de dispositivo compatibles con Conditional Access.

El objetivo no es bloquear indiscriminadamente todos los dispositivos personales.

La política debe corresponder al nivel de riesgo del recurso.

Una aplicación financiera, un portal administrativo o información especialmente sensible pueden justificar controles de dispositivo diferentes a los de una aplicación de bajo riesgo.

La revisión debería comprobar:

• Qué recursos requieren dispositivos administrados
• Qué usuarios están incluidos
• Qué tipos de dispositivos pueden acceder
• Qué ocurre con dispositivos personales
• Qué excepciones existen
• Si las excepciones siguen siendo necesarias
• Cómo se gestiona el acceso administrativo desde dispositivos no confiables

6. Proteger el registro de métodos de autenticación

El proceso mediante el cual un usuario registra MFA, una passkey u otro método de autenticación también forma parte de la superficie de ataque.

Conditional Access permite proteger la acción Register security information y exigir condiciones adicionales antes de aceptar el registro de nuevas credenciales.

Este control merece especial atención en 2026.

Desde el 6 de julio de 2026, las políticas de Conditional Access dirigidas a Register security information también pueden afectar determinados procesos de registro de credenciales relacionados con Windows Hello for Business y macOS Platform SSO.

Las organizaciones que ya utilizan este tipo de política deberían volver a comprobar su comportamiento.

Revise:

• Qué usuarios están incluidos
• Qué condiciones se consideran confiables
• Qué Authentication Strength se exige
• Cómo se utiliza Temporary Access Pass durante el onboarding
• Qué comportamiento experimentan los usuarios nuevos
• Qué procesos utilizan Windows Hello for Business
• Qué procesos utilizan macOS Platform SSO
• Si se ha probado el impacto en report-only

Un atacante que consigue añadir su propio método de autenticación puede convertir un acceso temporal en persistencia.

7. Revisar cómo se protegen los usuarios invitados

Las cuentas B2B y otros usuarios externos también acceden a recursos del tenant.

Conditional Access puede aplicar controles a usuarios invitados y externos, pero estas políticas requieren especial cuidado.

No aplique automáticamente las mismas condiciones de dispositivo utilizadas para empleados internos.

Los dispositivos de usuarios externos normalmente no están administrados por su organización y una política mal diseñada puede bloquear la colaboración legítima.

Revise:

• Qué aplicaciones pueden utilizar los invitados
• Qué nivel de autenticación se exige
• Qué usuarios externos están excluidos
• Qué organizaciones externas reciben confianza
• Cómo se utilizan cross-tenant access settings
• Si existe una revisión periódica de invitados antiguos
• Si se eliminan cuentas externas que ya no necesitan acceso

La colaboración externa debe estar gobernada explícitamente en lugar de depender de excepciones permanentes.

Conditional Access necesita una revisión periódica

Una buena implementación de Conditional Access no es simplemente una lista de políticas activadas.

Debe existir una arquitectura comprensible: identidad → recurso → condición → control → resultado → evidencia.

Para cada política debería poder responder:

• ¿Quién está protegido?
• ¿Qué recurso está protegido?
• ¿Qué señal activa la política?
• ¿Qué control se exige?
• ¿Qué excepciones existen?
• ¿Quién aprobó esas excepciones?
• ¿Cuándo se revisaron por última vez?
• ¿Cómo se comprueba que la política continúa funcionando?

Los cambios deberían desplegarse por fases mediante grupos piloto y report-only siempre que sea apropiado.

Conditional Access es más eficaz cuando se administra como parte de un programa continuo de gobernanza de identidad, no como un proyecto que se configura una vez y se abandona.

De la prevención a la investigación

Incluso una buena arquitectura de Conditional Access no elimina completamente los incidentes.

Cuando aparece una cuenta comprometida, los resultados de Conditional Access deben correlacionarse con los registros de inicio de sesión, los métodos de autenticación, la actividad del buzón, Microsoft Purview, SharePoint, OneDrive y otras evidencias de Microsoft 365. Para ello resulta útil seguir un checklist de evidencias para investigar una cuenta comprometida en Microsoft 365.

Revisión de Conditional Access con Cleverina

Cleverina ayuda a las organizaciones a revisar Microsoft 365, Microsoft Entra ID, Conditional Access, gobernanza de identidades y preparación ante incidentes.

Una revisión estructurada permite identificar políticas ausentes, exclusiones innecesarias, controles obsoletos y configuraciones que pueden producir tanto riesgos de seguridad como bloqueos operativos.