Configurar MFA y Acceso Condicional en Windows 11

Proteger el inicio de sesión en Windows 11 para empresas con MFA y Acceso Condicional se ha convertido en un requisito básico para cualquier organización que use Microsoft 365, Power Platform o servicios en la nube. Ya no basta con una contraseña complicada: los atacantes han aprendido a sortearlas, y el verdadero filtro de seguridad pasa por la autenticación multifactor y las directivas inteligentes de acceso.

Si trabajas con Microsoft Entra ID (el antiguo Azure AD), Intune y dispositivos Windows 11, seguro que ya te suena el concepto de Acceso Condicional, pero quizá no tengas claro cómo encaja todo: MFA, intensidad de autenticación, dispositivos compatibles, usuarios externos, Power Platform, etc. En esta guía vamos a juntar todas las piezas, explicando con detalle qué hace cada control, cómo se combinan y qué limitaciones reales tienes cuando lo aplicas a Windows 11, incluido el caso peculiar del inicio de sesión web.

Qué es el Acceso Condicional y cómo se relaciona con MFA en Windows 11

El Acceso Condicional de Microsoft Entra ID es básicamente un sistema de reglas “si pasa esto, haz aquello” que decide si un usuario puede acceder a un recurso: una aplicación en la nube, una acción concreta (por ejemplo, registrar información de seguridad) o un contexto de autenticación especial. Las directivas combinan señales como la identidad del usuario, el dispositivo, la red, el riesgo de inicio de sesión y el tipo de cliente para aplicar controles como MFA, exigencia de dispositivo compatible o bloqueo total.

Cada directiva se construye con dos grandes bloques: asignaciones (quién, qué y bajo qué condiciones) y controles de acceso (qué se exige o se bloquea). Varios controles pueden aplicarse a la vez y, si se dan las condiciones de más de una política, el usuario tendrá que cumplir todos los requisitos aplicables (por ejemplo, MFA + dispositivo compatible + aceptación de términos de uso).

En entornos con Windows 11 unido a Entra ID e Intune, el Acceso Condicional actúa justo en el momento en que se solicita un token para un recurso protegido. Esta puntualización es clave: el motor de Acceso Condicional no se dispara siempre que un usuario introduce credenciales, sino cuando una app (o el sistema) pide un token para un recurso concreto (Exchange, SharePoint, Power BI, etc.).

Por eso, aunque tu objetivo sea “que siempre se pida MFA al iniciar sesión en Windows 11”, en la práctica el reto técnico es dónde se evalúan esas políticas y qué aplicaciones o recursos desencadenan la evaluación del Acceso Condicional.

MFA e intensidad de autenticación: niveles y estrategias

En Microsoft Entra ID, la autenticación multifactor no es solo un interruptor de “sí/no”. Hay un concepto muy importante llamado intensidad de autenticación (authentication strength), que define cuán robusto tiene que ser el método para cumplir una directiva. Microsoft proporciona tres niveles integrados:

Seguridad de la autenticación multifactor (la menos restrictiva, pero la base recomendada en la mayoría de escenarios). Acepta los métodos estándar de MFA como SMS, llamada de voz, notificación push en Microsoft Authenticator, tokens OATH, etc. Es el punto de partida más habitual para exigir un segundo factor al acceder a recursos corporativos desde Windows 11.

Seguridad de MFA sin contraseña, que se orienta a métodos modernos como Windows Hello para empresas, claves FIDO2 o autenticación basada en certificados. Aquí ya no se depende de contraseña + código, sino de credenciales mucho más resistentes a ataques de phishing y robo de credenciales.

Intensidad de MFA resistente al phishing, el nivel más estricto, pensado para cuentas críticas (administradores, cuentas con alto privilegio, acceso a datos muy sensibles). Este nivel suele exigir combinación de métodos que no puedan ser fácilmente interceptados (por ejemplo, FIDO2 o Windows Hello para empresas).

Además de estas opciones predefinidas, puedes crear intensidades personalizadas, componiendo tu propia mezcla de métodos aceptados, algo muy útil si quieres, por ejemplo, obligar a que tus administradores usen Windows Hello o FIDO2 para determinadas tareas en Windows 11 y prohibir que validen con SMS.

Crear una directiva base de MFA con Acceso Condicional

La forma más limpia de imponer MFA a nivel global (incluyendo accesos desde Windows 11 a servicios Microsoft 365, aplicaciones empresariales y Power Platform) es mediante una política de Acceso Condicional que tenga como destino a todos los usuarios y todos los recursos. El flujo típico para construir esta directiva sería:

Primero, accede al Centro de administración de Microsoft Entra con una cuenta que tenga al menos el rol de Administrador de Acceso Condicional. Desde ahí, entra en Entra ID > Acceso condicional > Directivas y crea una nueva política con un nombre claro y estandarizado.

En la sección de Usuarios o identidades de trabajo, selecciona “Todos los usuarios” en Incluir, pero excluye las cuentas de emergencia (break-glass) y las cuentas de sincronización (como las de Entra Connect) para no arriesgarte a bloquear el acceso administrativo o la sincronización de identidades. Si gestionas invitados con políticas específicas, puedes dejar fuera a los usuarios externos de esta directiva global.

En Recursos de destino (antes “Aplicaciones en la nube”), elige “Todos los recursos”. De esta forma, cualquier solicitud de token hacia servicios como Exchange Online, SharePoint, Teams, Power BI, aplicaciones de línea de negocio y hasta Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) se verá afectada por la directiva.

En los Controles de acceso, dentro de Conceder, marca “Conceder acceso” y activa “Requerir intensidad de autenticación”. Selecciona la intensidad de “autenticación multifactor” como mínimo. Al principio es muy recomendable habilitar la directiva en modo “Solo informe” para ver el impacto real antes de activarla de forma efectiva.

Una vez que hayas revisado los registros y validado que no vas a derribar medio entorno por error, puedes cambiar el estado a “Activado”. Desde ese momento, todas las solicitudes de acceso a recursos protegidos pasarán por esta capa de MFA, también desde equipos Windows 11 unidos al directorio, salvo las excepciones que hayas definido.

Controles de concesión avanzados: más allá de “requerir MFA”

Una vez cubierta la base de MFA, puedes empezar a jugar con el resto de controles de concesión que ofrece Acceso Condicional para dispositivos Windows 11 y otros sistemas. La lógica es parecida: eliges si bloqueas el acceso o lo concedes exigiendo una combinación de requisitos.

El control de “Bloquear acceso” es tan potente como peligroso. Si la asignación coincide (usuarios, recurso, condiciones), el acceso se deniega sin opción de MFA u otras mitigaciones. Es perfecto para eliminar protocolos heredados, bloquear países concretos o cortar el acceso a aplicaciones obsoletas, pero siempre conviene probar antes con modo “solo informe” y usar herramientas como What If.

Cuando optas por “Conceder acceso”, puedes combinar varios requisitos: exigir MFA, requerir un dispositivo compatible, forzar que el equipo esté unido a Entra híbrido, imponer el uso de una aplicación cliente aprobada, requerir directiva de protección de aplicaciones (App Protection Policy), exigir cambio de contraseña o mitigación de riesgo. Puedes decidir si el usuario debe cumplir todos los controles seleccionados (AND) o solo uno de ellos (OR).

El control de “Requerir que el dispositivo esté marcado como compatible” se apoya en Intune. El dispositivo debe estar registrado en Entra ID y cumplir las directivas de cumplimiento (antivirus, cifrado, versión de SO, etc.). Admite Windows 10/11, iOS, Android, macOS y Ubuntu Linux con Intune. Esta ruta es ideal para forzar que el acceso a datos sensibles se realice siempre desde equipos administrados.

Si estás en una organización híbrida, el control “Requerir dispositivo híbrido unido a Microsoft Entra” permite asegurarte de que solo equipos unidos al dominio y registrados en Entra ID (Windows anteriores a 10 y actuales) acceden a ciertos recursos. Este enfoque se usa mucho para limitar la administración a dispositivos corporativos.

También puedes exigir aplicaciones cliente aprobadas (la clásica lista de apps de Office, Outlook, OneDrive, Teams, Power BI, etc.) o una directiva de protección de aplicaciones de Intune, lo que garantiza que los datos se abren solo en apps protegidas por MAM, principalmente en iOS y Android (y en vista preliminar para Edge en Windows).

Finalmente, los controles de “Requerir cambio de contraseña” y “Requerir mitigación de riesgos” se integran con Microsoft Entra ID Protection: se usan cuando el usuario está marcado como de alto riesgo. En estos escenarios, se fuerza un flujo de reseteo seguro o de corrección de riesgo, siempre precedido por MFA, para cortar compromisos de cuenta sin intervención constante del administrador.

Acceso Condicional: asignaciones, condiciones y orden de evaluación

Para que una política se aplique, debes definir al menos un conjunto mínimo de asignaciones: usuarios o grupos, recursos de destino y un control de concesión o bloqueo. A partir de ahí, puedes refinar con condiciones adicionales.

En la parte de Usuarios y grupos decides a quién afecta la política: todos los usuarios, grupos concretos, roles de directorio (por ejemplo, global admins) o identidades de carga de trabajo (service principals). La evaluación se realiza cuando se emite un token nuevo, de modo que si un usuario entra en un grupo después de tener un token válido, la política no le afectará hasta que renueve credenciales.

En Recursos de destino puedes marcar aplicaciones en la nube de Microsoft (Office 365, Azure Service Management API, portales de administración, etc.), apps publicadas vía Application Proxy, acciones de usuario como registrar información de seguridad o registrar/unir dispositivos, e incluso contextos de autenticación específicos que luego se usan desde SharePoint, PIM u otras aplicaciones.

Las condiciones de red te permiten usar ubicaciones con nombre basadas en rangos de IP o ubicaciones geográficas. Un patrón típico consiste en no pedir MFA cuando el usuario está en la red corporativa de confianza y exigirla cuando se conecta desde Internet público.

Además, tienes condiciones adicionales como plataformas de dispositivo (Windows, iOS, Android, macOS, Linux), tipo de aplicación cliente (navegador, app móvil/escritorio, protocolos heredados), filtros de dispositivo (en función de atributos del objeto de dispositivo) y riesgo de inicio de sesión (si tienes Entra ID Protection).

Cuando varias políticas se aplican al mismo usuario y recurso, se combinan de forma acumulativa. Así, si una directiva exige MFA y otra exige dispositivo compatible, el usuario debe cumplir ambas. El orden de validación suele seguir la lógica MFA – estado de dispositivo – términos de uso, y verás esta secuencia reflejada en los registros de inicio de sesión.

Limitaciones del MFA con el inicio de sesión web en Windows 11

En entornos donde se ha activado el inicio de sesión web en Windows 11 (para autenticación directa en la pantalla de bloqueo), muchos administradores se han encontrado con una sorpresa: las directivas de Acceso Condicional que requieren MFA no se evalúan como esperan. El usuario ve el formulario de usuario y contraseña de Entra, pero después no aparece el desafío de MFA.

Esto no suele ocurrir con inicios de sesión en navegador, apps móviles u Office en Windows 11, donde las mismas políticas de Acceso Condicional se aplican sin problema. Si en lugar de Acceso Condicional activas MFA por usuario (el modelo clásico), entonces sí se fuerza MFA en el inicio de sesión web, lo que hace pensar que el problema está en cómo ese flujo interactúa con el motor de políticas de Acceso Condicional.

El soporte de Microsoft ha aclarado que, técnicamente, hoy no es posible aplicar un desafío de MFA mediante Acceso Condicional al flujo de inicio de sesión web. El motivo es la propia arquitectura: Acceso Condicional se ejecuta cuando se solicita un token para un recurso protegido concreto, y el inicio de sesión web no desencadena esa evaluación del modo en que lo hacen otras aplicaciones.

Por tanto, si tu requisito es que el inicio de sesión en la pantalla de bloqueo de Windows 11 siempre pida MFA, la única vía fiable a día de hoy es usar MFA por usuario, lo que fuerza el segundo factor en cada autenticación independientemente del recurso al que se vaya a acceder después. No es tan flexible ni tan granular como Acceso Condicional, pero resuelve esta limitación concreta.

Acceso Condicional para aplicaciones, Power Platform y APIs

El ámbito de Acceso Condicional va mucho más allá de Windows 11 y Microsoft 365. Power Platform (Power Apps, Power Automate, Power BI, Copilot Studio, etc.) se apoya completamente en Entra ID para autenticación y autorización, por lo que las mismas directivas de acceso se aplican al uso de aplicaciones, flujos y conectores.

Al nivel de inquilino, Entra ID garantiza que el usuario tiene una cuenta activa, ha pasado las políticas de acceso (MFA, ubicación, dispositivo, riesgo) y dispone de licencia. Pero para Power Platform esto es solo la primera capa: luego entran en juego roles de servicio (Administrador de Power Platform, Administrador de Dynamics 365), grupos de seguridad que controlan el acceso a entornos, y por encima de todo el modelo de seguridad de Dataverse (RBAC, permisos por tabla, fila y columna).

Si quieres proteger seriamente tus soluciones de negocio, tienes que combinar Acceso Condicional con un diseño de roles de seguridad ajustado. Por ejemplo, los desarrolladores suelen necesitar acceso de creador en entornos de desarrollo, pero no permisos de administración en producción. Las directivas de Acceso Condicional te sirven para exigir MFA, restringir ubicaciones o imponer dispositivos compatibles, pero el “qué pueden hacer” se define con roles y permisos de Dataverse.

Otro punto relevante es la evaluación continua de acceso (Continuous Access Evaluation). En lugar de esperar a que caduquen los tokens (típicamente, hasta una hora), ciertos servicios como Dataverse pueden revocar accesos casi en tiempo real cuando detectan cambios críticos: revocación de permisos, cambios de ubicación, modificaciones de directivas, etc. Este enfoque reduce la ventana de exposición si se revoca el acceso de un usuario o se detecta un evento de riesgo.

Acceso Condicional para usuarios externos y colaboración B2B

Muchas organizaciones comparten recursos con usuarios externos: socios, proveedores, clientes, consultores… En estos casos entra en juego Microsoft Entra External ID, la colaboración B2B y la conexión directa B2B. Los usuarios externos pueden autenticarse en su propio inquilino o en proveedores de identidad sociales (Google, Facebook, SAML, etc.), pero el inquilino de recursos decide qué políticas de Acceso Condicional se aplican.

Para escenarios entre inquilinos de Entra, puedes configurar la confianza de entrada de MFA y del dispositivo. Esto permite que, si el usuario ya ha completado MFA o se ha validado que su dispositivo es compatible o unido a Entra híbrido en su organización de origen, tu inquilino acepte esa señal y no vuelva a pedir otro desafío. Si no configuras esa confianza, el comportamiento varía: los invitados B2B tendrán que hacer MFA en tu inquilino; los usuarios de conexión directa B2B pueden quedar bloqueados si se requiere MFA o cumplimiento de dispositivo que no se pueda evaluar.

En el caso de usuarios que no son de Entra (identidades sociales, cuentas Microsoft personales o autenticación mediante OTP por correo), el inquilino de recursos siempre es responsable de la MFA. Es decir, si tu política exige MFA, se hará en tu directorio, no puedes delegarlo en otro proveedor externo.

También puedes definir directivas específicas según el tipo de usuario externo: invitados B2B (UserType=Guest), miembros B2B (que se tratan casi como internos), usuarios de conexión directa B2B (sin objeto de usuario en tu directorio), usuarios invitados locales antiguos, proveedores de servicios, etc. Este nivel de granularidad te permite, por ejemplo, exigir MFA resistente al phishing solo a conexiones externas de alto riesgo.

Protección del directorio, riesgos y ámbitos de bajo privilegio

Un detalle delicado a menudo pasado por alto es que muchas aplicaciones piden ámbitos de bajo privilegio relacionados con el directorio como User.Read, People.Read, GroupMember.Read.All, etc. Tradicionalmente, cuando creabas políticas “Todos los recursos” con alguna exclusión, estos ámbitos quedaban fuera para no romper aplicaciones que solo leían el perfil básico del usuario o su pertenencia a grupos.

Microsoft ha cambiado este comportamiento y ahora estos ámbitos se evalúan como acceso al recurso Windows Azure Active Directory (00000002-0000-0000-c000-000000000000). Esto significa que, si tienes una política que apunta a “Todos los recursos” con exclusiones o una directiva específica sobre Windows Azure AD, las solicitudes de tokens que solo pidan estos scopes pueden disparar Acceso Condicional y forzar MFA o cumplimiento de dispositivo.

En la práctica, los usuarios pueden empezar a ver desafíos de MFA al iniciar sesión en herramientas como Visual Studio Code, Azure CLI u otras apps que únicamente solicitan openid, profile, User.Read o scopes similares. Si la intención de tu organización es también blindar este tipo de acceso a información de directorio, es una medida coherente; si no, tendrás que ajustar las directivas o crear políticas específicas para Windows Azure Active Directory.

Para identificar qué aplicaciones se verán afectadas, puedes usar scripts de PowerShell y los informes de uso y actividad de Microsoft Entra. Estos te permiten listar los service principals y los ámbitos delegados que utilizan, así como los recuentos de inicio de sesión recientes, para detectar apps que solo piden esos scopes de bajo privilegio y evaluar si necesitas excepciones.

Buenas prácticas de seguridad y gobierno de identidades

Configurar MFA y Acceso Condicional en Windows 11 y en el resto de tu entorno es solo la mitad de la historia. El otro 50 % está en el modelo de gobierno de identidades: quién tiene permisos, durante cuánto tiempo y con qué privilegios.

Entre las recomendaciones más importantes está minimizar el número de cuentas de alto impacto, separar roles en lugar de elevar privilegios sobre cuentas de usuario normales, y usar modelos Just-In-Time (JIT) con herramientas como Microsoft Entra Privileged Identity Management (PIM) para conceder permisos elevados solo cuando se necesitan.

También conviene evitar accesos administrativos permanentes, mantener cuentas de emergencia documentadas y vigiladas, reforzar la autenticación de administradores con métodos sin contraseña o MFA robusto, y aplicar directivas de Acceso Condicional más estrictas sobre estos roles (por ejemplo, exigir dispositivo compatible y MFA resistente al phishing para cualquier operación administrativa desde Windows 11).

En cuanto al ciclo de vida de las identidades, es fundamental tener un proceso claro para deshabilitar o eliminar cuentas cuando un usuario cambia de puesto, sale de la organización o cuando una carga de trabajo deja de utilizar una identidad de servicio. Revisiones periódicas de acceso, especialmente sobre roles con privilegios elevados o sobre usuarios externos, ayudan a evitar la acumulación de permisos innecesarios.

Para Power Platform en concreto, es muy recomendable dirigir a los creadores a sus propios entornos de desarrollo, restringir el uso compartido masivo (por ejemplo, evitar la opción “Todos” a la ligera), controlar el acceso a entornos mediante grupos de Entra ID, usar Dataverse como repositorio principal con RBAC granular y aplicar directivas de datos que limiten los conectores que se pueden usar en entornos predeterminados o de desarrollo.

Cuando todo esto se combina —MFA sólido, directivas de Acceso Condicional bien pensadas, protección de dispositivos Windows 11 mediante Intune, gobierno de identidades robusto y un modelo de permisos de mínimo privilegio— se construye un perímetro moderno basado en identidad que va mucho más allá de la simple contraseña y del firewall clásico de red. La experiencia del usuario mejora (con menos contraseñas que recordar y más inicio de sesión único) y, al mismo tiempo, el riesgo de compromiso se reduce drásticamente, incluso frente a ataques avanzados de phishing y robo de tokens.