El problema con la autenticación heredada
La autenticación heredada se refiere a protocolos más antiguos — POP, IMAP, SMTP AUTH, MAPI, ActiveSync con credenciales básicas, y clientes como Outlook 2010/2013 — diseñados antes de que existiera la autenticación moderna. No soportan autenticación multifactor. Punto.
Esto importa porque un atacante que ejecuta un ataque de relleno de credenciales o de pulverización de contraseñas no le importa que hayas habilitado MFA. Si tu tenant todavía acepta autenticación heredada, se salta la autenticación moderna por completo y va directo a IMAP o SMTP AUTH con una contraseña robada. La propia telemetría de Microsoft de 2024 muestra que más del 99% de los ataques de pulverización de contraseñas contra tenants de M365 apuntan específicamente a los endpoints de autenticación heredada.
Los tenants nuevos creados después de 2022 tienen la autenticación heredada deshabilitada por defecto mediante Security Defaults. El problema está en los tenants anteriores a esa fecha — especialmente todo lo que fue migrado desde Exchange on-premises o planes antiguos de Office 365. Esos tenants casi siempre tienen la autenticación heredada activa, y frecuentemente nadie la ha auditado.
Este post cubre cómo bloquear la autenticación heredada en Microsoft Entra ID usando una política de Conditional Access. Primero ejecutarás un reporte previo, crearás una cuenta de acceso de emergencia, pondrás la política en modo report-only, y luego la activarás. El entorno es M365 Business Premium o superior (se requiere licencia Entra ID P1 para Conditional Access). Todos los pasos fueron verificados en el centro de administración de Entra a partir del Q1 2026 — las rutas del portal han cambiado varias veces en 2024-2025, así que verifica la navegación en tu propio tenant antes de automatizar algo.
Requisitos previos
Antes de tocar cualquier cosa:
- Licencia Entra ID P1 o superior — P1 está incluida en M365 Business Premium, E3 y E5. Si estás en Business Basic o Standard, ve a la sección de Security Defaults más abajo.
- Rol de Global Administrator o Conditional Access Administrator en Entra ID.
- Acceso a los registros de inicio de sesión — disponible por defecto durante los últimos 30 días en tenants con P1.
- Al menos una hora de margen antes de cualquier ventana de cambio en producción. No quieres apresurarte en esto.
Paso 0: Generar un reporte de uso de autenticación heredada
No omitas este paso. Si bloqueas la autenticación heredada sin saber qué la está usando, romperás algo en producción y tendrás que improvisar.
Navega a: Identity → Monitoring → Sign-in logs
Filtra por Client app y selecciona cada entrada bajo la categoría “Other clients”. Estas corresponden a sesiones con protocolos de autenticación heredada. Como alternativa, usa el workbook integrado:
Identity → Workbooks → Sign-ins using Legacy Authentication
Exporta los resultados a CSV. Revisa cada entrada. Estás buscando:
- Cuentas de usuarios reales — estas necesitan migrarse a clientes de autenticación moderna (Outlook Mobile, Outlook desktop moderno)
- Cuentas de servicio — impresoras, escáneres, herramientas de monitoreo (PRTG, SolarWinds), aplicaciones de línea de negocio que usan EWS o IMAP
- Buzones compartidos siendo consultados por scripts
Este CSV es tu alcance de migración. Cada elemento en él debe resolverse — ya sea migrando a autenticación moderna o excluyéndolo explícitamente de la política con justificación documentada — antes de activarla en producción.
Ejemplo real: Un tenant de 50 usuarios activo desde 2018 sin controles de autenticación heredada mostró 47 cuentas distintas con hits de autenticación heredada en los últimos 30 días. Desglose: 41 eran teléfonos usando IMAP (migrados a Outlook Mobile), 4 eran un sistema de monitoreo (migrado a Graph API), 2 eran una impresora de oficina usando SMTP AUTH (migrada a un relay SMTP de M365, que es una configuración aparte y no cuenta como autenticación heredada).
Paso 1: Crear una cuenta de acceso de emergencia (break-glass)
Si ya tienes una cuenta de acceso de emergencia dedicada y excluida de todas las políticas de CA, omite este paso. Si no, créala ahora — antes de tocar Conditional Access.
Navega a: Identity → Users → New user → Create new user
- Username:
emergency-access@<yourdomain> - Password: Genera 32+ caracteres. Guárdala en un gestor de contraseñas offline (KeePass) o en una caja fuerte física. No en el mismo gestor de contraseñas que usas a diario.
- Role: Global Administrator
Una vez que exista la cuenta, exclúyela de todas las políticas de Conditional Access que crees a partir de este momento. Esta cuenta es tu camino de recuperación si una política mal configurada bloquea a todos los administradores. Trátala en consecuencia.
Paso 2: Crear la política de Conditional Access
Navega a: Identity → Protection → Conditional Access → Policies → New policy
Nombre de la política: BLOCK - Legacy Authentication - All Users
Las convenciones de nombres importan para la trazabilidad. El prefijo BLOCK - deja clara la intención en la lista de políticas.
Users:
- Include: All users
- Exclude: Tu cuenta de acceso de emergencia. Excluye también cualquier service principal que hayas confirmado en el Paso 0 que genuinamente no puede migrarse de la autenticación heredada todavía.
Target resources: All cloud apps
Conditions → Client apps:
- Activa el toggle en Yes (configure)
- Marca: Exchange ActiveSync clients
- Marca: Other clients
- Desmarca: Browser, Mobile apps and desktop clients — estos son autenticación moderna y no quieres tocarlos aquí.
Access controls → Grant:
- Selecciona Block access
No habilites la política todavía.
Paso 3: Ejecutar primero en modo report-only
Antes de activarla, configura Enable policy → Report-only y guarda.
Déjala ejecutándose durante 24 a 48 horas. Luego regresa a:
Identity → Monitoring → Sign-in logs
Filtra por: Conditional Access status → Report-only: Failure
Esta vista muestra exactamente qué inicios de sesión habrían sido bloqueados si la política estuviera aplicada. Compara esta lista con el CSV del Paso 0. Si aparece algo que no está en tu lista de alcance de migración — investígalo antes de continuar. Sesiones de autenticación heredada desconocidas en esta etapa significan que tienes algo que se te escapó.
Una vez que la lista de fallos en report-only coincida con tu alcance de migración y todo en ese alcance esté resuelto o excluido explícitamente, estás listo para activarla.
Paso 4: Habilitar la política
Vuelve a la política y configura Enable policy → On. Guarda.
La propagación normalmente se completa en pocos minutos.
Valida inmediatamente después de habilitar:
Si tienes acceso a un cliente Outlook 2010/2013 o cualquier cliente SMTP configurado con autenticación básica de usuario y contraseña, intenta conectarte a tu buzón. Debería fallar con un error similar a:
AADSTS50053: The account is locked.
AADSTS53003: Access has been blocked by Conditional Access policies.
Outlook moderno, Outlook Mobile, Teams y el acceso por navegador deben continuar funcionando sin interrupciones.
Validación después de 24 horas
Después de que la política haya estado activa durante 24 horas:
Identity → Monitoring → Sign-in logs
Filtra por Conditional Access status → Failure y busca el motivo de bloqueo que hace referencia al nombre de tu política.
Deberías ver un flujo constante de intentos de autenticación heredada bloqueados desde IPs externas — esto es normal y esperado. Los atacantes que sondean endpoints heredados no se detienen solo porque esos endpoints ahora devuelven un error; simplemente dejan de tener éxito.
Si ves un servicio que sabes que necesita autenticación heredada en la lista de fallos, tienes dos opciones:
- Preferida: Migrarlo a autenticación moderna (Graph API para acceso a buzones, OAuth para SMTP)
- Último recurso: Agregarlo a la lista de exclusiones de la política con justificación documentada y un responsable asignado para migrarlo
Procedimiento de rollback
Si algo falla y no puedes resolverlo de inmediato:
Identity → Protection → Conditional Access → Policies → [tu política] → Enable policy → Off → Save
La autenticación heredada queda permitida nuevamente en 1-2 minutos. Por eso configuras la política en Off en lugar de eliminarla — desactivarla es instantáneo. Recrear la política desde cero lleva tiempo que puede no tenerse durante un incidente.
¿Qué pasa con los tenants sin Entra ID P1?
Si tu tenant está en M365 Business Basic o Business Standard, Conditional Access no está disponible. Usa Security Defaults en su lugar:
Identity → Properties → Manage Security defaults → Enable Security defaults → Yes
Security Defaults bloquea la autenticación heredada a nivel de tenant. La contrapartida es que es todo o nada — sin exclusiones, sin excepciones para cuentas de servicio. Si una impresora o herramienta de monitoreo usa autenticación heredada, dejará de funcionar y no podrás excluirla sin deshabilitar Security Defaults por completo.
Para organizaciones con menos de 25 usuarios y sin dependencias de servicios heredados, Security Defaults es la decisión correcta — es gratuito, toma 30 segundos y cubre la mayor superficie de ataque. Para 25 o más usuarios con dependencias reales de servicios heredados, la respuesta correcta es actualizar a Business Premium para obtener la licencia P1 e implementar el enfoque de política de CA descrito arriba.
Una nota importante: No puedes tener Security Defaults y políticas de Conditional Access activas simultáneamente. Habilitar Security Defaults deshabilita Conditional Access. Si estás pasando de Security Defaults a políticas de CA, primero deshabilitas Security Defaults y luego construyes tu conjunto de políticas de CA.
Qué no hace esta política
Sé claro sobre el alcance:
- No aplica MFA — eso requiere una política de CA separada dirigida a inicios de sesión con autenticación moderna
- No bloquea el phishing — la autenticación resistente a phishing (FIDO2, passkeys) es un flujo de trabajo aparte
- No detecta cuentas comprometidas — usa los reportes de riesgo de Identity Protection para eso
- No reemplaza un marco completo de políticas de CA — esta política única maneja un vector de ataque específico
Resolución de problemas
La impresora o el escáner deja de enviar correo después de activar la política
Causa: El dispositivo está usando SMTP AUTH con credenciales básicas, que ahora está bloqueado por la política.
Solución: Reconfigura el dispositivo para usar el endpoint de direct send o relay SMTP de Microsoft 365, que no requiere autenticación del dispositivo y no es interceptado por la política de CA. La configuración específica depende del modelo de tu impresora — consulta la documentación de Microsoft “How to set up a multifunction device or application to send email using Microsoft 365”. Verifica el endpoint de relay en tu entorno.
El sensor de buzón de una herramienta de monitoreo (PRTG, SolarWinds, etc.) deja de funcionar
Causa: Estas herramientas frecuentemente usan IMAP o POP por defecto para monitorear buzones, ambos protocolos de autenticación heredada.
Solución: Verifica si la herramienta soporta Microsoft Graph API u OAuth 2.0 para acceso a buzones. PRTG, por ejemplo, soporta sensores de Microsoft 365 vía Graph API a partir de versiones recientes — consulta la documentación de tu versión instalada. Si la herramienta no tiene opción de autenticación moderna, el sensor debe reemplazarse con un método de monitoreo diferente.
Usuarios en Mac Mail.app pierden acceso al buzón
Causa: Mail.app en versiones antiguas de macOS usa autenticación heredada por defecto cuando se configura con el tipo de cuenta genérico “Other”.
Solución: El usuario elimina la cuenta de Mail.app y la vuelve a agregar usando el tipo de cuenta Microsoft Exchange (no “Other”). Esto obliga a Mail.app a negociar OAuth/autenticación moderna. Si el Mac es tan antiguo que el tipo de cuenta Exchange no soporta OAuth, el usuario necesita Outlook for Mac o Outlook Mobile.
Versiones antiguas de Outlook (2013 y anteriores) dejan de autenticarse
Causa: Outlook 2013 y anteriores no soportan autenticación moderna. Este es el comportamiento esperado, no una mala configuración.
Solución: Actualiza a Outlook 2016 o posterior (con las claves de registro de autenticación moderna habilitadas si es necesario — verifica en tu entorno), o migra los usuarios a Microsoft 365 Apps. No existe exclusión ni solución alternativa que mantenga funcionales estos clientes mientras se bloquea la autenticación heredada; sencillamente no tienen soporte para el protocolo.
Una aplicación de línea de negocio que usa Exchange Web Services (EWS) con autenticación básica deja de funcionar
Causa: La autenticación básica de EWS fue retirada por Microsoft en octubre de 2022, pero las aplicaciones que ya estaban conectadas a veces continuaron funcionando hasta que una política la bloqueó explícitamente. Esta política saca a la luz esos casos rezagados.
Solución: La aplicación necesita actualizarse para usar EWS con OAuth 2.0, o migrarse a Microsoft Graph API (preferible, ya que EWS está en modo de mantenimiento). Escala al proveedor de la aplicación si es software de terceros.
La política parece aplicarse a tu cuenta de acceso de emergencia
Causa: Olvidaste agregar la cuenta de acceso de emergencia a la lista de exclusiones al crear la política.
Solución: Edita la política, ve a Users → Exclude, agrega la cuenta de acceso de emergencia. Guarda. De ahora en adelante, verifica las exclusiones en cada política de CA antes de habilitarla.
Preguntas frecuentes
¿Qué es la autenticación heredada en Entra ID?
La autenticación heredada se refiere a un conjunto de protocolos y clientes que usan autenticación básica (usuario y contraseña enviados directamente) y no soportan protocolos de autenticación moderna como OAuth 2.0. Los ejemplos principales son POP3, IMAP, SMTP AUTH, MAPI over HTTP con credenciales básicas, Exchange ActiveSync con autenticación básica, y versiones antiguas del cliente de Office (Outlook 2013 y anteriores). La característica definitoria es que estos protocolos no tienen mecanismo para soportar autenticación multifactor — el intercambio de autenticación es puramente basado en credenciales, lo que significa que las políticas de MFA son efectivamente invisibles para ellos.
¿Qué sucede cuando bloqueo la autenticación heredada en Entra ID?
Cualquier intento de inicio de sesión que use un protocolo de autenticación heredada contra una aplicación en la nube cubierta por la política devuelve un error de acceso bloqueado. Los clientes de autenticación moderna — versiones actuales de Outlook, Outlook Mobile, Teams, acceso por navegador — no se ven afectados porque usan OAuth 2.0 y no coinciden con las condiciones de la política. Los atacantes que intentan relleno de credenciales vía IMAP o SMTP AUTH recibirán un error en lugar de un token. Los usuarios legítimos en clientes heredados perderán el acceso hasta que migren a un cliente de autenticación moderna.
¿Conditional Access requiere Entra ID P1 para bloquear la autenticación heredada?
Sí. Conditional Access es una función de Entra ID P1 y superior. P1 está incluida en las licencias M365 Business Premium, E3 y E5. Si tu tenant está en M365 Business Basic o Business Standard (que incluyen solo Entra ID Free), las políticas de Conditional Access no están disponibles. La alternativa es Security Defaults, que también bloquea la autenticación heredada pero no ofrece capacidad de exclusión.
¿Cómo encuentro qué usuarios están usando autenticación heredada en Entra ID?
Navega a Identity → Monitoring → Sign-in logs en el centro de administración de Entra. Filtra por Client app y selecciona las entradas categorizadas como “Other clients” — estas representan sesiones de autenticación heredada. El camino más rápido es el workbook integrado en Identity → Workbooks → Sign-ins using Legacy Authentication, que agrega estos datos en un reporte legible. Exporta a CSV antes de hacer cualquier cambio. Revisa la lista con cuidado; las cuentas de servicio y los service principals de aplicaciones aparecen aquí junto a las cuentas de usuario.
¿Puedo bloquear la autenticación heredada sin Conditional Access en Entra ID?
Sí, usando Security Defaults. Navega a Identity → Properties → Manage Security defaults y habilita la función. Security Defaults bloquea la autenticación heredada en todo el tenant como uno de varios controles de línea base que aplica. La limitación es que Security Defaults es binario — se aplica a todos los usuarios sin excepciones. Si alguna cuenta de servicio o aplicación en tu tenant requiere autenticación heredada, habilitarlo la romperá sin posibilidad de excluirla salvo deshabilitando Security Defaults por completo. Para tenants sin dependencias de servicios heredados y por debajo del umbral de licencia Business Premium, Security Defaults es una solución práctica y gratuita.
¿Cuál es la diferencia entre Security Defaults y Conditional Access para bloquear la autenticación heredada?
Ambos bloquean la autenticación heredada, pero difieren en la granularidad del control. Security Defaults es una línea base gestionada por Microsoft que aplica un conjunto fijo de políticas, incluyendo el bloqueo de autenticación heredada y requisitos de MFA. No requiere configuración, no requiere licencia adicional y no ofrece personalización — sin exclusiones, sin excepciones, sin despliegue por etapas. Conditional Access es un motor de políticas que configuras tú mismo. Permite excluir cuentas o service principals específicos, ejecutar en modo report-only antes de la aplicación, limitar políticas a aplicaciones específicas y combinar condiciones de formas que Security Defaults no puede. La regla práctica de decisión: Security Defaults para tenants pequeños con entornos limpios y licencias Basic/Standard; Conditional Access para cualquier cosa con dependencias de servicios, configuraciones híbridas, o una licencia Business Premium o superior.
¿Por qué falla el SMTP de mi impresora después de bloquear la autenticación heredada?
La mayoría de las impresoras multifunción configuradas para “Scan to Email” o “Send to Email” usan SMTP AUTH con usuario y contraseña, que es un protocolo de autenticación heredada. Una vez que la política de Conditional Access se aplica, esas conexiones SMTP AUTH son bloqueadas. El dispositivo no soporta OAuth, por lo que no puede adaptarse automáticamente. La solución es reconfigurar la impresora para usar el relay SMTP o el endpoint de direct send de Microsoft 365, ambos permiten retransmitir correo sin requerir que el dispositivo se autentique con credenciales de usuario. Los pasos de configuración específicos varían según el modelo de impresora y la configuración del tenant de M365 — verifica los ajustes correctos de relay en tu entorno.
¿Cómo excluyo una cuenta de servicio de una política de Conditional Access en Entra ID?
Al crear o editar la política, navega a la sección de asignación Users. Bajo Exclude, puedes agregar usuarios individuales, grupos o service principals. Para cuentas de servicio, agrega la cuenta de usuario específica o, si tienes múltiples cuentas de servicio, crea un grupo de seguridad dedicado (p. ej., CA-Exclusion-LegacyAuth-ServiceAccounts), agrega las cuentas a ese grupo y excluye el grupo de la política. Usar un grupo facilita la gestión continua — agregar una nueva cuenta de servicio a la exclusión es un cambio de membresía en el grupo, no una edición de la política. Cada cuenta excluida debe tener una razón documentada y un responsable encargado de migrarla a autenticación moderna. Trata las exclusiones como excepciones temporales, no como excepciones permanentes.
Conclusión
Bloquear la autenticación heredada es una de las acciones de seguridad de mayor impacto que puedes tomar en un tenant de M365. La superficie de ataque es real, está bien documentada y es explotada activamente. La solución es una única política de Conditional Access que toma menos de una hora desplegar correctamente cuando sigues el proceso del reporte previo.
Los pasos en orden: ejecuta el reporte de uso, crea una cuenta de acceso de emergencia, construye la política con las condiciones correctas de client app, ejecuta en report-only durante 24-48 horas, resuelve todo en tu lista de alcance de migración, y luego actívala. El rollback es un simple toggle si algo sale mal.
Si estás en Business Basic o Standard sin P1, habilita Security Defaults hoy — es mejor que nada y toma 30 segundos.
El siguiente paso lógico después de bloquear la autenticación heredada es requerir MFA para todos los usuarios en autenticación moderna mediante una política de Conditional Access separada. Eso está cubierto en la guía de aplicación de MFA en este sitio.