¿Quieres que MSAdvance diseñe e implemente tus políticas de Conditional Access sin “apagones” para el negocio?
El Acceso Condicional (Conditional Access) es una de las formas más efectivas de reducir accesos no autorizados en Microsoft 365, Azure y aplicaciones corporativas… pero también es una de las más fáciles de “romper” si se despliega sin método.
En MSAdvance aterrizamos un enfoque práctico: políticas base + piloto + report-only + telemetría + excepciones bien justificadas. Con esto se reduce riesgo sin convertir cada inicio de sesión en un ticket.
- Definición de un baseline de Conditional Access alineado a Zero Trust y al tipo de usuarios (oficina, remoto, frontline, terceros).
- Despliegue por fases (report-only → piloto → activación) con validación real por procesos de negocio.
- Integración con MFA, Intune, Defender y Purview para que identidad, dispositivo y datos trabajen juntos.
Contacta con nuestro equipo Ver servicio de Seguridad & Cumplimiento
Recursos relacionados: Guía de MFA en Entra ID · Guía práctica de Microsoft Intune · Auditoría de seguridad en Microsoft 365
Conditional Access (Acceso Condicional) es el “cerebro” de políticas de Microsoft Entra que decide si un inicio de sesión se permite, se bloquea o se permite con condiciones (por ejemplo, MFA, dispositivo compatible, app protegida o ubicación). En 2026, un baseline realista suele incluir 10 políticas base: proteger administradores, forzar MFA de forma gradual, bloquear autenticación heredada, controlar dispositivos no gestionados, asegurar móviles con MAM, limitar ubicaciones, reducir exposición de sesión y bloquear el device code flow salvo casos justificados.
Resumen rápido: Conditional Access en 10 ideas (sin romper la operativa)
- Primero seguridad “anti-bloqueo”: cuentas de emergencia (break-glass), piloto y report-only antes de activar nada.
- Empieza por administradores: MFA fuerte + sesiones más cortas en portales sensibles.
- MFA para todos, pero con cariño: despliegue gradual, excepciones mínimas y soporte al usuario.
- Corta lo antiguo: bloquear autenticación heredada (legacy auth) reduce mucho el riesgo con poco impacto si se hace con inventario.
- Dispositivos importan: donde hay datos sensibles, pide dispositivo compatible (Intune) o limita a web con restricciones.
- Móvil bien hecho: MAM/App Protection para BYOD evita “bloqueos” y protege datos.
- Ubicaciones: no bloquees “el mundo” a lo loco; usa países/zonas solo si el negocio lo permite.
- Sesiones: reduce persistencia en apps críticas (sobre todo para admins).
- Device code flow: si no lo necesitas, bloquéalo; si lo necesitas, acótalo.
- Mide todo: Sign-in logs + workbook de insights para ver impacto real y ajustar sin improvisar.
Introducción: por qué Conditional Access (Acceso Condicional) importa más en 2026
Hace años, “poner MFA” parecía suficiente. Hoy, con robo de tokens, phishing más convincente y accesos desde dispositivos no gestionados, la pregunta ya no es solo “¿quién eres?”, sino también “¿desde dónde entras, con qué dispositivo y con qué señales de riesgo?”. Ahí es donde Microsoft Entra Conditional Access se vuelve imprescindible: te permite aplicar reglas simples del tipo “si pasa X, entonces exige Y” (por ejemplo, “si es admin, exige MFA y sesión corta”).
Y hay un punto importante: Conditional Access no es “poner muchas políticas”, es poner las correctas, en el orden correcto, y con un despliegue que no convierta la seguridad en fricción. Este artículo te deja una base sólida: 10 políticas de Conditional Access que suelen encajar en la mayoría de organizaciones, con notas prácticas para que el negocio siga trabajando.
Antes de empezar: licencias, cuentas de emergencia y “modo seguro”
1) Licencias: ¿qué necesitas para usar Conditional Access?
Para usar Conditional Access como tal (políticas personalizadas), la referencia habitual es Microsoft Entra ID P1. Muchas organizaciones ya lo tienen incluido en planes como Microsoft 365 E3 o Microsoft 365 Business Premium; si no, se puede licenciar aparte.
2) Dos cuentas de emergencia (break-glass) o te acabarás bloqueando
Antes de activar políticas, crea al menos dos cuentas de emergencia (muy bien guardadas, con contraseñas fuertes, acceso monitorizado y uso excepcional) y exclúyelas de las políticas más agresivas. Es tu “airbag” por si una condición se aplica donde no debía (pasa más de lo que la gente admite).
3) Un grupo piloto y el hábito de “report-only”
La forma más tranquila de desplegar Acceso Condicional es crear un grupo piloto (usuarios representativos: IT, negocio, dirección, movilidad) y usar el modo report-only para ver qué habría pasado sin aplicarlo todavía.
Si quieres una implantación ordenada de base (MFA + Conditional Access + soporte al usuario), te puede ayudar también la guía de MFA en Entra ID.
Metodología de despliegue sin sustos (report-only → piloto → activación)
En la práctica: una buena política mal desplegada se siente como un fallo; una política normal bien desplegada se siente como “todo sigue funcionando”.
Fase A — Inventario
- ¿Quién usa legacy auth?
- ¿Qué apps críticas existen?
- ¿Cuánta gente trabaja móvil/BYOD?
- ¿Qué países/ubicaciones son reales?
Fase B — Report-only
- Crear políticas desde plantillas cuando aplique.
- Mirar impacto en Sign-in logs.
- Detectar excepciones necesarias (las mínimas).
Fase C — Activación
- Activar primero admins.
- Luego piloto (negocio).
- Después, despliegue por oleadas.
Tabla rápida: las 10 políticas base (riesgo vs fricción)
| Política | Qué reduce | Fricción típica | Licencia |
|---|---|---|---|
| 1. MFA para administradores | Compromiso de cuentas privilegiadas | Baja/Media | P1 |
| 2. MFA gradual para usuarios | Robo de credenciales | Media | P1 |
| 3. Bloquear autenticación heredada | Password spray / bypass MFA | Baja (si inventario OK) | P1 |
| 4. Proteger portales de administración | Acceso a consolas críticas | Baja/Media | P1 |
| 5. Dispositivo compatible en apps sensibles | Acceso desde equipos no controlados | Media | P1 + Intune |
| 6. No gestionados: web con restricciones | Exfiltración de datos | Media | P1 |
| 7. Móvil: App Protection (MAM) | Fuga de datos en BYOD | Baja/Media | Intune |
| 8. Ubicaciones: reducir superficie | Acceso desde regiones “ruidosas” | Baja/Media | P1 |
| 9. Sesiones en apps críticas | Tokens persistentes | Baja/Media | P1 |
| 10. Bloquear device code flow | Abuso de flujos de autenticación | Baja (salvo casos especiales) | P1 |
Las 10 políticas base de Conditional Access (explicadas y aterrizadas)
En la práctica: cada política aquí tiene un objetivo claro. Si no puedes explicarlo en una frase, probablemente sobra o está mal enfocada.
Política 1 — Exigir MFA (o autenticación resistente al phishing) para administradores
Si hay una política que casi siempre merece el “sí” inmediato, es esta. Las cuentas con roles administrativos son las más atacadas, y cuando caen, el impacto no es “un buzón”, es todo el tenant.
- Ámbito: roles de administrador (Global Admin, Exchange Admin, SharePoint Admin, etc.).
- Aplicaciones: todas, o al menos las de administración (Admin Center, Azure, Intune).
- Control: “Require MFA” o, si tu organización ya usa llaves FIDO2 / passkeys, “authentication strength” resistente al phishing.
Política 2 — MFA gradual para usuarios (sin castigar a todos el mismo día)
MFA para todos es buena idea. El problema es el cómo. Si lo activas sin preparación, el lunes tendrás soporte colapsado. Si lo haces por fases, el negocio lo nota poco y la seguridad sube mucho.
- Semana 1: piloto (IT + usuarios avanzados + un par de perfiles críticos).
- Semana 2–3: departamentos con menos riesgo operativo.
- Semana 4: generalización y cierre de excepciones.
En esta fase, lo que marca la diferencia es la experiencia del usuario: guía rápida, recordatorios, canal de soporte y “qué hago si cambio de móvil”. Si quieres llevarlo bien armado, apóyate en una guía base de adopción y registro de métodos.
Política 3 — Bloquear autenticación heredada (legacy authentication)
Legacy auth (por ejemplo, protocolos antiguos sin MFA) sigue siendo un punto de entrada típico para ataques automáticos. La buena noticia: en muchas organizaciones ya no se usa “de verdad”… solo queda algún resto. Por eso esta política es tan rentable: reduce mucho riesgo con impacto controlable si haces inventario.
- Antes: identifica quién usa legacy auth (sign-in logs, informes).
- Durante: report-only una semana para detectar sistemas olvidados.
- Después: bloquear y documentar excepciones (si existen).
Política 4 — Proteger portales de administración (y acortar sesiones donde duele)
Admin Center, Azure Portal, Intune… son puertas de alto impacto. Aquí conviene ser más estricto: MFA siempre, y sesiones menos “eternas”.
- Control de concesión: MFA / fuerza de autenticación.
- Controles de sesión: “sign-in frequency” para obligar a revalidar cada cierto tiempo (según tu operativa).
- Extra: bloquear acceso desde dispositivos no gestionados si tu IT lo permite.
Si tu organización tiene equipos de IT distribuidos o turnos 24×7, esto se calibra con el equipo: “más seguro” no significa “más sufrimiento”.
Política 5 — Para apps sensibles: exigir dispositivo compatible (compliant) en lugar de “fiarte” del usuario
Si hay datos sensibles (finanzas, RRHH, dirección, propiedad intelectual), el enfoque “usuario + contraseña + MFA” se queda corto. Ahí entra el dispositivo: solo accede quien debe, desde un dispositivo que cumple políticas.
- Control: “Require device to be marked as compliant”.
- Requisito: Intune y políticas de cumplimiento (PIN, cifrado, versión mínima, etc.).
- Aplicación inteligente: no lo pongas para todo; ponlo para lo que de verdad lo necesita.
Política 6 — Dispositivos no gestionados: permitir solo web con restricciones (o bloquear descargas)
Esto es muy útil cuando el negocio necesita flexibilidad (por ejemplo, un proveedor, un equipo temporal o un BYOD que no quieres gestionar completo). En vez de bloquear “porque sí”, limitas qué se puede hacer: ver en web, pero no descargar, no sincronizar, no copiar a lo loco.
- Objetivo: reducir fuga de datos en SharePoint/OneDrive/Exchange.
- Enfoque: “desde no gestionado, experiencia limitada”.
- Resultado: negocio sigue trabajando, pero con menos riesgo.
Política 7 — Móvil (BYOD) sin dramas: exigir App Protection (MAM) para proteger datos
Mucha gente trabaja desde el móvil. Y no todos esos móviles son corporativos. Si tu respuesta es “bloqueo todo lo móvil”, el negocio te lo hará notar. La alternativa madura es App Protection (MAM): proteges los datos dentro de la app (PIN, cifrado, no copiar/pegar a apps personales…).
- Ámbito: iOS/Android.
- Control: “Require app protection policy”.
- Ventaja: no necesitas gestionar el teléfono completo para proteger el dato corporativo.
Política 8 — Ubicaciones: reducir superficie de ataque sin “romper” viajes y teletrabajo
Bloquear países puede ser útil… si tu negocio realmente no opera allí. Pero si tienes gente viajando, clientes globales o equipos distribuidos, un bloqueo agresivo se vuelve una fábrica de excepciones.
Dos enfoques que suelen funcionar mejor que el “bloqueo total del mundo”:
- En ubicaciones no habituales: exigir MFA (o fuerza de autenticación más alta).
- Solo bloquear: países/regiones donde sabes que nunca habrá trabajo legítimo.
Consejo: documenta por qué se bloquea una región. Si no puedes justificarlo en una frase, probablemente no es buena idea.
Política 9 — Controles de sesión: menos persistencia en apps críticas (y especialmente para admins)
No todo es “login”. Una sesión que dura demasiado puede ser un regalo si el token se roba. Los session controls te ayudan a ajustar el equilibrio: que el usuario no se autentique cada 10 minutos, pero que tampoco tenga sesiones eternas donde no toca.
- Sign-in frequency: útil en portales de administración y apps sensibles.
- Persistent browser session: desactívalo donde no tenga sentido mantener sesiones largas.
- Aplicación: empieza por admins y apps críticas; no lo apliques globalmente sin medir impacto.
Política 10 — Bloquear device code flow (salvo casos justificados y acotados)
El device code flow existe para dispositivos con poca capacidad de entrada (pantallas, dispositivos compartidos, señalización, etc.). El problema: también es un flujo atractivo para abuso si no se controla. En 2026, la recomendación práctica en muchas organizaciones es: bloquearlo por defecto y permitirlo solo donde sea estrictamente necesario.
- Si no lo usas: bloqueo total.
- Si lo usas: permite solo por plataforma/ubicación/grupo muy específico y con documentación.
- Despliegue: report-only primero para descubrir “usos sorpresa”.
Bonus (muy recomendable) — MFA para registro o unión de dispositivos
Si permites que usuarios registren o unan dispositivos a Entra ID, exigir MFA en esa acción reduce abuso y altas no deseadas. No siempre es imprescindible, pero cuando aplica, suele ser una mejora limpia.
Observabilidad: cómo saber si Conditional Access está reduciendo riesgo (y no solo molestando)
En la práctica: si no lo mides, terminarás tomando decisiones “a ojo” y eso siempre acaba en excepciones permanentes.
Qué mirar cada semana (sobre todo durante el despliegue)
- Sign-in logs: fallos por política, por aplicación y por tipo de cliente.
- Qué políticas se aplican de verdad: no lo supongas; verifícalo.
- Cuántas excepciones estás creando: si sube rápido, algo está mal diseñado o mal comunicado.
Workbook de Conditional Access: tu mejor amigo para desplegar sin caos
Microsoft ofrece un workbook de insights y reporting que te ayuda a ver impacto por política a lo largo del tiempo: qué se habría bloqueado, qué se está bloqueando y dónde se concentra el dolor.
Errores típicos (los que generan tickets y enfados)
1) Activar todo “en ON” el primer día
Conditional Access no es un interruptor de luz. Sin report-only, sin piloto y sin cuentas de emergencia, es cuestión de tiempo que algo crítico deje de funcionar.
2) Excluir aplicaciones “por si acaso”
Las exclusiones de recursos suelen empezar como algo temporal… y se quedan para siempre. Si una app se excluye, hay que saber por qué, cuánto tiempo y qué alternativa se implementará.
3) Móvil bloqueado sin alternativa
Si mucha gente trabaja desde el móvil, bloquear sin MAM/App Protection suele convertir seguridad en fricción. Lo razonable es proteger el dato sin exigir gestión completa del dispositivo cuando no aplica.
4) Ubicaciones demasiado agresivas
“Bloqueo todos los países menos el mío” suena bien… hasta que hay viajes, roaming, proveedores o equipos en remoto. Mejor exigir MFA extra fuera de ubicaciones confiables, y bloquear solo donde estés seguro.
Checklists operativos (pre, durante, post)
Antes
- 2 cuentas break-glass creadas y probadas.
- Grupo piloto definido (representativo).
- Inventario de legacy auth y apps críticas.
- Plan de comunicación al usuario (qué cambia, por qué, qué hacer).
- Políticas creadas en report-only.
Durante
- Revisión diaria de Sign-in logs (errores por política).
- Soporte a usuarios (registro de métodos, cambios de móvil, etc.).
- Documentar excepciones y justificar cada una.
Después
- Convertir “excepciones temporales” en remediaciones reales (o cerrar).
- Revisar políticas cada trimestre (y tras cambios grandes: M&A, nuevas apps, teletrabajo).
- Establecer KPIs simples (tasa de bloqueos legítimos, tickets por usuario, etc.).
Preguntas frecuentes (FAQ) sobre Conditional Access
¿Conditional Access (Acceso Condicional) requiere licencias específicas?
Normalmente se requiere Microsoft Entra ID P1 para crear y aplicar políticas de Conditional Access. En muchos casos está incluido en planes como Microsoft 365 E3 o Microsoft 365 Business Premium. Si no, se puede licenciar Entra ID por separado.
¿Cuál es la primera política que debería activar?
En la práctica, la más rentable suele ser “MFA para administradores”. Reduce mucho el riesgo con impacto controlable. A partir de ahí, se suele avanzar con report-only y piloto para el resto.
¿Cómo evito bloquear a toda la empresa?
Con dos cuentas break-glass excluidas, un grupo piloto y despliegue en report-only antes de activar. Además, usa el “What If” y revisa Sign-in logs durante el piloto.
¿Qué hago si tengo muchos usuarios móviles (BYOD)?
En vez de bloquear, suele funcionar mejor exigir App Protection (MAM) en móvil: protege el dato dentro de la app sin necesidad de gestionar el dispositivo completo.
¿Bloquear legacy auth puede romper algo?
Puede, si existen aplicaciones o dispositivos antiguos que dependen de protocolos heredados. Por eso se recomienda report-only y un inventario previo: así detectas “restos” antes de bloquear.
¿Tiene sentido bloquear device code flow?
Si no lo usas, sí: reduce superficie de abuso. Si lo usas (por ejemplo, dispositivos específicos), se recomienda permitirlo solo en ese caso, muy acotado, y bloquearlo en el resto.
¿Cada cuánto debo revisar mis políticas de Acceso Condicional?
Como mínimo trimestralmente y siempre que haya cambios relevantes: nuevas aplicaciones, nueva forma de trabajo (teletrabajo), fusiones/adquisiciones o cambios de seguridad (por ejemplo, incidentes o nuevas recomendaciones).
Recursos oficiales y enlaces externos
- Microsoft Entra Conditional Access (overview)
- Plan a Conditional Access deployment
- Conditional Access policy templates (common policies)
- Building Conditional Access policies
- Session controls (sign-in frequency, persistent browser)
- Conditional Access insights & reporting workbook
- What If tool
- Authentication flows (device code flow)
- Block authentication flows (device code flow)
- Licencias de Microsoft Entra (Microsoft Learn)
Servicios relacionados de MSAdvance: Seguridad & Cumplimiento · Modern Workplace · Suministro de licencias · Todos los servicios
Conclusión y siguientes pasos
Un buen baseline de Conditional Access no se mide por cuántas políticas tienes, sino por dos cosas: cuánto riesgo reduces y cuánta fricción evitas. Con estas 10 políticas base, desplegadas con report-only, piloto y telemetría, es habitual lograr una mejora real sin paralizar el negocio.
Siguientes pasos recomendados (rápidos y realistas)
- Crear cuentas break-glass y grupo piloto.
- Levantar inventario de legacy auth y movilidad.
- Crear las 10 políticas en report-only y revisar impacto.
- Activar primero administradores, después piloto, después oleadas.
¿Quieres que MSAdvance lo deje operativo y documentado?
Diseñamos e implementamos un baseline de Acceso Condicional alineado a tu negocio: mínimo riesgo, mínimo ruido, máxima claridad.
