MFA obligatorio en Microsoft 365: guía completa para proteger usuarios, administradores y accesos críticos

Implantar MFA obligatorio en Microsoft 365 es una de las medidas más importantes para reducir el riesgo de compromiso de identidades, pero en 2026 ya no basta con activar Microsoft Authenticator para todos los usuarios y considerar terminado el proyecto.

Microsoft Entra ID dispone actualmente de diferentes mecanismos que intervienen en la autenticación: Security Defaults, Conditional Access, Authentication Methods Policy, authentication strengths, passkeys/FIDO2, Microsoft Authenticator, Temporary Access Pass, system-preferred authentication, Identity Protection y políticas específicas para administradores.

A esto hay que añadir un cambio importante en la propia plataforma: Microsoft está aplicando progresivamente MFA obligatorio en sus portales administrativos y herramientas de administración de Azure.

Esto puede generar confusión.

Que Microsoft exija MFA para entrar en Azure Portal o Microsoft 365 Admin Center no significa necesariamente que todos los usuarios de una organización estén obligados a utilizar MFA cuando acceden a Outlook, Teams, SharePoint, OneDrive o cualquier otra aplicación empresarial.

La organización sigue necesitando definir su propia estrategia de autenticación.

Y esa estrategia tampoco debería consistir únicamente en preguntar:

“¿Tiene MFA el usuario?”

En realidad deberíamos responder a cuestiones mucho más precisas:

¿qué usuarios están cubiertos por una política?, ¿qué métodos pueden utilizar?, ¿qué administradores disponen de autenticación resistente a phishing?, ¿qué ocurre si alguien pierde el móvil?, ¿qué cuentas de servicio siguen utilizando contraseña?, ¿qué aplicaciones heredadas pueden romperse y qué método utilizaríamos para recuperar el tenant durante una emergencia?

En Kloudeal planteamos los proyectos de MFA comenzando por identidad, aplicaciones y métodos existentes. Después definimos el modelo de acceso, preparamos recuperación y cuentas de emergencia, registramos a los usuarios y desplegamos las políticas de forma progresiva.

En esta guía explicamos cómo implementar MFA obligatorio en Microsoft 365 en 2026, cuándo utilizar Security Defaults o Conditional Access, cómo avanzar hacia passkeys y métodos resistentes a phishing, cómo preparar administradores y cuentas break-glass, cómo gestionar cuentas de servicio y cómo comprobar correctamente la cobertura mediante Microsoft Graph.

Índice

1. Qué es MFA en Microsoft 365
2. El MFA obligatorio de Microsoft en 2026
3. Por qué MFA obligatorio de Microsoft no significa MFA global
4. Cómo diseñar una arquitectura MFA moderna
5. Security Defaults vs Conditional Access vs MFA por usuario
6. Licencias
7. Assessment antes de activar MFA
8. Authentication Methods Policy
9. Configuración MFA/SSPR heredada
10. Métodos de autenticación
11. Microsoft Authenticator y number matching
12. System-preferred authentication
13. Passkeys y FIDO2
14. Passkeys sincronizadas y vinculadas a dispositivo
15. Passkeys de Microsoft Entra en Windows
16. Authentication Strengths
17. Opción 1: Security Defaults
18. Security Defaults y Device Code Flow
19. Opción 2: Conditional Access
20. Políticas Conditional Access recomendadas
21. Report-only
22. Administradores
23. Cuentas break-glass
24. Registration Campaign
25. Temporary Access Pass
26. Recuperación de usuarios
27. BYOD y dispositivos personales
28. Usuarios invitados y B2B
29. Cuentas de servicio
30. Workload identities
31. Autenticación heredada
32. SMTP y aplicaciones
33. Comprobar MFA con Microsoft Graph
34. Sign-in logs y Conditional Access
35. Métricas
36. Roadmap de 90 días
37. Errores frecuentes
38. Checklist
39. Preguntas frecuentes
40. Documentación oficial

Qué es MFA en Microsoft 365

Multi-Factor Authentication significa exigir más de una evidencia antes de aceptar una autenticación.

Normalmente hablamos de factores pertenecientes a categorías diferentes:

En Microsoft 365 la decisión de autenticación se realiza fundamentalmente mediante Microsoft Entra ID.

Eso significa que las mismas políticas pueden proteger:

Exchange Online, SharePoint, OneDrive, Teams, Azure, aplicaciones SaaS integradas con Entra y muchas aplicaciones empresariales.

MFA no significa necesariamente “introducir un código”

Una passkey o Windows Hello for Business pueden proporcionar autenticación multifactor sin que el usuario escriba una contraseña y posteriormente un código SMS.

De hecho, la evolución actual de Microsoft está orientada progresivamente hacia:

passwordless + phishing-resistant authentication.

Referencia oficial: Microsoft – Microsoft Entra multifactor authentication.

El MFA obligatorio de Microsoft en 2026

Microsoft está imponiendo MFA para determinadas experiencias administrativas independientemente de que una organización haya creado su propia política Conditional Access.

Fase 1

El despliegue comenzó en 2024 para operaciones realizadas desde:

Azure Portal, Microsoft Entra Admin Center y Microsoft Intune Admin Center.

Desde febrero de 2025 se amplió progresivamente al:

Microsoft 365 Admin Center.

Fase 2

Desde el 1 de octubre de 2025, Microsoft comenzó la segunda fase para determinadas operaciones de administración realizadas mediante:

Azure CLI, Azure PowerShell, Azure Mobile App, herramientas Infrastructure as Code, SDKs y endpoints REST del control plane.

No afecta de la misma forma a todas las operaciones

La documentación de Microsoft distingue en la segunda fase entre determinadas operaciones:

Create / Update / Delete

y operaciones de lectura.

También afecta a cuentas de emergencia

Las cuentas break-glass no quedan automáticamente exentas de este requisito de plataforma.

Deben disponer de un método capaz de satisfacer el MFA obligatorio.

Workload identities

Managed identities y service principals no están afectados de la misma forma por el requisito de MFA interactivo de Microsoft.

Esto refuerza una recomendación fundamental:

las automatizaciones no deberían utilizar cuentas de usuario.

Referencia oficial: Microsoft – Mandatory MFA for Azure and admin portals.

MFA obligatorio de Microsoft no significa que todos los usuarios tengan MFA para Microsoft 365

Esta distinción es crítica.

Ejemplo

Microsoft puede exigir MFA a un administrador cuando entra en:

admin.microsoft.com

pero eso no demuestra que un usuario estándar tenga MFA obligatorio cuando accede a:

Outlook, SharePoint o una aplicación SaaS.

Por eso sigue siendo necesaria una política propia

La organización debe decidir si utiliza:

Security Defaults

o

Conditional Access.

No deberíamos depender únicamente del enforcement de Microsoft

Su objetivo es proteger servicios administrativos específicos de Microsoft.

Nuestra estrategia debe proteger:

usuarios + aplicaciones + datos + sesiones + dispositivos.

Cómo diseñar una arquitectura MFA moderna

Podemos dividir el proyecto en cinco capas.

Coverage

Como mínimo:

usuarios, administradores, invitados relevantes y aplicaciones sensibles.

Methods

Definimos qué perfiles pueden utilizar:

passkeys, security keys, Authenticator, Windows Hello, CBA, OATH, SMS u otros métodos.

Enforcement

Utilizamos:

Security Defaults o Conditional Access.

Recovery

Necesitamos:

TAP, métodos alternativos y cuentas de emergencia.

Monitoring

Revisamos:

user registration details + sign-in logs + Conditional Access + audit logs.

Security Defaults vs Conditional Access vs MFA por usuario

Recomendación general

Para una organización pequeña que no dispone de Entra ID P1:

Security Defaults es mejor que no disponer de una estrategia MFA consistente.

Para una empresa que necesita definir excepciones, aplicaciones, dispositivos o authentication strengths:

Conditional Access.

Licencias necesarias

No diseñar basándonos solo en el nombre de la licencia

Antes de presupuestar una migración hacia métodos avanzados conviene comprobar:

qué SKU tiene cada población y qué funcionalidad necesita realmente.

Assessment antes de activar MFA

Antes de introducir enforcement necesitamos identificar qué puede romperse.

Authentication Methods Policy: dónde se administran actualmente los métodos

La administración moderna de métodos se realiza desde:

Microsoft Entra Admin Center → Entra ID → Authentication methods → Policies.

Desde aquí podemos controlar

Passkey/FIDO2, Microsoft Authenticator, Temporary Access Pass, OATH y otros métodos compatibles.

También podemos definir scope

No todos los métodos necesitan estar disponibles para toda la empresa.

Enforcement y método son dos cosas diferentes

Authentication Methods Policy define:

qué credenciales pueden utilizar los usuarios.

Conditional Access define:

qué nivel de autenticación se exige para acceder.

Referencia oficial: Microsoft – Manage authentication methods.

Las políticas heredadas de MFA y SSPR ya no deberían ser el centro del diseño

Durante años Microsoft gestionó algunos métodos desde configuraciones separadas de:

MFA + Self-Service Password Reset.

Ese modelo ha sido sustituido por la Authentication Methods Policy.

Fecha importante

Desde el 30 de septiembre de 2025, los métodos ya no deben administrarse mediante las políticas heredadas de MFA y SSPR.

Microsoft proporciona migración

En:

Authentication methods → Policies → Manage migration

podemos revisar y consolidar la configuración.

Por qué merece la pena comprobarlo

En tenants antiguos podemos encontrar:

configuraciones históricas + per-user MFA + Authentication Methods Policy + Conditional Access.

Si nadie entiende qué controla cada capa, la operación se vuelve muy difícil.

Referencia oficial: Microsoft – Migrate authentication method policies.

No todos los métodos MFA ofrecen la misma protección

MFA no significa phishing-resistant MFA

Un atacante con una infraestructura AiTM puede intentar robar una sesión incluso aunque el usuario introduzca una contraseña y después un código.

Las credenciales FIDO2 están vinculadas criptográficamente al servicio legítimo, lo que cambia significativamente este riesgo.

Microsoft Authenticator y number matching

Microsoft Authenticator sigue siendo una opción práctica para muchos usuarios.

Number matching

Las notificaciones push de Authenticator utilizan actualmente number matching.

El usuario debe relacionar la solicitud con el inicio de sesión que está realizando.

Esto reduce MFA fatigue

El patrón antiguo:

“Approve / Deny” repetido hasta que el usuario acepta

resultaba más susceptible a ataques de fatiga.

Aun así no debemos enseñar a “aprobar MFA”

La formación correcta es:

si tú no estás intentando iniciar sesión, rechaza la solicitud y comunícalo.

Referencia oficial: Microsoft – Number matching.

System-preferred authentication: Microsoft presenta primero el método más fuerte

Tradicionalmente el usuario tenía un método MFA predeterminado.

Microsoft está evolucionando hacia system-preferred authentication.

Cómo funciona

Entra revisa los métodos registrados por el usuario y presenta primero el método que considera más fuerte.

Ejemplo

El usuario tiene:

SMS + Authenticator.

En lugar de priorizar SMS simplemente porque era el método que eligió hace años, el sistema puede presentar Authenticator.

Estado Microsoft-managed

Microsoft está desplegando gradualmente este comportamiento durante 2026.

La documentación actual indica que el comportamiento Microsoft-managed se está desplegando progresivamente hasta agosto de 2026.

Esto afecta al assessment

No debemos depender exclusivamente de:

“¿qué método ha seleccionado el usuario como predeterminado?”

También debemos analizar:

qué métodos están registrados y cuál puede utilizar realmente el sistema.

Referencia oficial: Microsoft – System-preferred authentication.

Passkeys/FIDO2: hacia una autenticación resistente a phishing

Las passkeys utilizan criptografía de clave pública.

La clave privada permanece asociada al autenticador y la aplicación almacena la correspondiente clave pública.

Ventaja fundamental

La credencial está asociada al origen legítimo.

Eso significa que una página de phishing que imita visualmente a Microsoft no puede simplemente capturar y reutilizar la credencial.

Puede utilizarse como MFA

Cuando una passkey se combina con el desbloqueo local mediante:

PIN o biometría

puede satisfacer los requisitos multifactor correspondientes.

Para quién

Especialmente interesante para:

administradores, dirección, finanzas, RR. HH., usuarios privilegiados y población con alto riesgo.

Referencia oficial: Microsoft – Passkeys FIDO2.

Passkeys sincronizadas frente a passkeys vinculadas al dispositivo

En 2026 es importante diferenciar distintos modelos.

Microsoft diferencia por perfil

La guía actual de Microsoft recomienda valorar:

device-bound credentials para administradores o usuarios especialmente privilegiados

y:

synced passkeys para muchos usuarios estándar

cuando el modelo de riesgo lo permita.

La recuperación cambia

Una synced passkey puede simplificar mucho el problema de perder un dispositivo.

Una security key física necesita un plan diferente:

segunda llave, TAP o procedimiento de recuperación controlado.

Microsoft Entra passkey en Windows

Microsoft dispone actualmente de Microsoft Entra passkeys on Windows.

En agosto de 2026 esta funcionalidad se encuentra documentada en public preview.

Qué permite

Crear una passkey vinculada al dispositivo dentro del contenedor local de Windows Hello.

Después el usuario puede autenticarse mediante:

biometría o PIN de Windows Hello.

Diferencia frente a synced passkey

La credencial permanece en el dispositivo y no se sincroniza.

No confundir con Windows Hello for Business

Son tecnologías relacionadas con FIDO/passwordless, pero tienen modelos de implementación y requisitos diferentes.

Referencia oficial: Microsoft – Microsoft Entra passkey on Windows.

Authentication Strengths: MFA no tiene por qué aceptar cualquier segundo factor

Conditional Access puede exigir simplemente:

Require multifactor authentication.

Pero también podemos utilizar:

Require authentication strength.

Esto permite definir qué nivel necesitamos

Built-in phishing-resistant MFA

Microsoft incluye una fortaleza predefinida para métodos resistentes a phishing.

Custom authentication strengths

También podemos construir perfiles específicos, por ejemplo limitando:

tipos concretos de FIDO2/passkey o certificados.

Referencia oficial: Microsoft – Authentication strengths.

Opción 1: Security Defaults

Security Defaults proporciona un baseline gratuito de identidad.

Actualmente incluye

Detalle importante

Security Defaults no significa necesariamente:

“cada usuario debe completar MFA en absolutamente cada inicio de sesión”.

Microsoft decide cuándo pedir autenticación adicional a usuarios finales en función de diferentes señales.

Administradores

Los roles administrativos cubiertos reciben requisitos más estrictos.

Cuándo encaja

Security Defaults puede resultar adecuado si:

no tenemos Entra P1/P2 + no necesitamos excepciones + no tenemos arquitectura compleja.

Cuándo no encaja

Si necesitamos:

grupos, aplicaciones, trusted locations, devices, authentication strengths, service-account exceptions o controles diferenciados.

En ese caso deberíamos evaluar Conditional Access.

Referencia oficial: Microsoft – Security Defaults.

Security Defaults y Device Code Flow: cambio importante desde julio de 2026

El Device Code Flow se utiliza en aplicaciones o dispositivos que tienen capacidad limitada para realizar el inicio de sesión directamente.

También puede abusarse para phishing

Un atacante puede intentar convencer a un usuario para introducir un código legítimo en una página de Microsoft y terminar autorizando una sesión controlada por el atacante.

Security Defaults lo bloquea

Cuando Security Defaults está habilitado, las solicitudes que utilizan Device Code Flow se bloquean.

Nuevos tenants

Desde el 1 de julio de 2026, los nuevos tenants Microsoft Entra incluyen este bloqueo como parte de Security Defaults.

Antes de activar

Debemos revisar si existen:

CLI antiguas, dispositivos, scripts o aplicaciones que dependen de Device Code.

Si necesitamos excepciones

Security Defaults no proporciona granularidad suficiente.

El modelo adecuado sería normalmente:

Conditional Access con políticas controladas.

Opción 2: MFA obligatorio con Conditional Access

Conditional Access es el motor de políticas que permite combinar señales antes de conceder acceso.

Puede evaluar

usuario, grupo, rol, aplicación, ubicación, dispositivo, riesgo, plataforma, authentication strength y otras condiciones.

Una política base

Por ejemplo:

Después añadimos políticas específicas

No conviene crear una única “mega-policy” con todas las condiciones.

Resulta más sencillo mantener políticas con objetivos específicos.

Un baseline práctico de Conditional Access

Los números no son lo importante

Lo importante es que cada policy tenga:

una finalidad + un scope + una excepción + un owner.

Report-only antes de activar una política

Conditional Access permite ejecutar policies en Report-only.

Esto permite responder

¿qué habría ocurrido si la política hubiese estado activa?

Qué buscar

Revisar varios perfiles

web + desktop + móvil + admins + invitados + automatizaciones.

No dejar Report-only para siempre

Es una herramienta de validación, no un control de seguridad permanente.

Referencia oficial: Microsoft – Plan Conditional Access.

Administradores: MFA debería ser el mínimo, no el objetivo final

Las cuentas administrativas merecen protección diferenciada.

Microsoft recomienda phishing-resistant MFA

Para los principales roles administrativos, Microsoft recomienda avanzar hacia métodos resistentes a phishing.

Roles especialmente sensibles

Entre otros:

Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Authentication Administrator, Exchange Administrator, SharePoint Administrator y Security Administrator.

Separar identidad administrativa

Un administrador debería disponer idealmente de:

cuenta de productividad + cuenta administrativa separada.

Beneficio

La cuenta privilegiada no se utiliza para:

correo, navegación general o colaboración cotidiana.

Con PIM

Cuando existe Entra P2, podemos añadir:

roles eligible + activación temporal + MFA + approval + justification

según la sensibilidad del rol.

Referencia oficial: Microsoft – Require phishing-resistant MFA for administrators.

Cuentas break-glass en 2026: MFA sí, dependencia innecesaria no

La recomendación histórica de dejar una cuenta break-glass únicamente con contraseña ya no representa correctamente el escenario actual.

Microsoft recomienda al menos dos cuentas

Deben ser:

cloud-only + dominio .onmicrosoft.com + Global Administrator + uso exclusivamente de emergencia.

Deben satisfacer el MFA obligatorio

Microsoft recomienda utilizar métodos como:

FIDO2/passkey o certificate-based authentication.

Pero deben excluirse de Conditional Access que pueda bloquearlas

Esto no es contradictorio.

Una cosa es:

tener una credencial fuerte capaz de satisfacer MFA.

Otra diferente es:

hacer que su acceso dependa de una policy corporativa que podría ser precisamente la causa del bloqueo.

Ejemplo

No tiene mucho sentido que la única cuenta de emergencia requiera:

dispositivo Intune compliant + IP de oficina + Authenticator instalado en el mismo móvil del administrador.

Una caída de cualquiera de esas dependencias eliminaría su utilidad.

Buenas prácticas actuales

Referencia oficial: Microsoft – Emergency access accounts.

Registration Campaign: migrar usuarios hacia métodos mejores

No es necesario esperar a una gran migración para que los usuarios mejoren su método.

Microsoft Entra dispone de Registration Campaign.

En 2026 puede promover

Microsoft Authenticator

o

Passkey/FIDO2.

Solo un objetivo a la vez

Actualmente una campaña no puede pedir simultáneamente:

Authenticator + passkey.

Debemos seleccionar el objetivo de la campaña.

Podemos segmentar

Por ejemplo:

Microsoft-managed

Microsoft también administra valores recomendados para estas campañas y está evolucionando progresivamente la recomendación hacia passkeys en determinados tenants.

Referencia oficial: Microsoft – Registration Campaign.

Temporary Access Pass: el puente entre onboarding y autenticación fuerte

Temporary Access Pass es una credencial temporal emitida por un administrador.

Puede ser de

un único uso o múltiples usos durante un periodo limitado

según policy.

Casos de uso

Configuración

Desde:

Entra ID → Authentication methods → Policies → Temporary Access Pass.

Actualmente podemos definir

duración mínima, máxima, duración predeterminada, longitud y si puede reutilizarse.

TAP no es una contraseña temporal permanente

Debe existir un procedimiento de:

identificación del usuario → emisión → entrega segura → registro → cierre.

Referencia oficial: Microsoft – Temporary Access Pass.

El proyecto MFA necesita un procedimiento de recuperación

La pregunta no es si algún usuario perderá su móvil.

La pregunta es cuándo.

Escenarios

móvil perdido, teléfono sustituido, security key rota, empleado remoto, Authenticator eliminado o cambio de dispositivo.

Proceso

No desactivar MFA para recuperar un usuario

Una mala práctica frecuente es:

“le quitamos MFA diez minutos”.

TAP proporciona un mecanismo mucho más controlado.

MFA en BYOD: autenticación no equivale a protección del dato

MFA demuestra con mayor confianza quién está intentando acceder.

No responde necesariamente:

¿qué puede hacer ese dispositivo con los datos después?

Podemos combinar

No exigir compliant device indiscriminadamente

Una policy de:

All users + All apps + Require compliant device

sin revisar BYOD puede bloquear inmediatamente:

móviles personales, equipos externos e incluso determinadas integraciones.

Usuarios invitados y MFA

Los invitados B2B también deben formar parte del diseño.

Una opción

Podemos exigir MFA en nuestro tenant.

Otra

En determinados escenarios podemos confiar en la MFA realizada en el tenant de origen mediante:

cross-tenant access settings.

Authentication strengths

También pueden utilizarse con usuarios externos, pero debemos comprobar qué método puede reconocerse desde el tenant de origen.

Evitar duplicar prompts innecesariamente

Un buen diseño B2B permite mantener seguridad sin obligar al invitado a registrar credenciales adicionales innecesarias cuando podemos confiar adecuadamente en su organización.

Cuentas de servicio: el problema no se resuelve excluyéndolas de MFA para siempre

Una cuenta de servicio basada en:

usuario + contraseña almacenada

es deuda técnica de identidad.

Ejemplos

scripts PowerShell, integraciones, ERP, backups, SMTP, tareas programadas y herramientas antiguas.

La solución no debería ser

“serviceaccount@empresa.com queda fuera de MFA indefinidamente”.

Objetivo

Migrar hacia:

managed identity, service principal, certificate authentication, workload identity o mecanismo moderno específico de la aplicación.

Si temporalmente necesitamos una excepción

Workload identities: identidad para máquinas, no usuarios fingiendo ser máquinas

Microsoft diferencia claramente:

user identities

y

workload identities.

Ejemplos de workload identity

managed identities y service principals.

Ventaja

No necesitan responder interactivamente a un prompt de Authenticator.

Conditional Access para workload identities

Microsoft dispone además de capacidades específicas de Conditional Access para determinadas workload identities.

No reutilizar policies de usuario

El modelo de riesgo es diferente.

Bloquear autenticación heredada

Los protocolos que no admiten autenticación moderna no pueden completar MFA de la misma forma que OAuth moderno.

Ejemplos históricos

clientes antiguos, POP/IMAP con Basic Authentication, ActiveSync heredado y aplicaciones que utilizan credenciales directamente.

Security Defaults ya bloquea legacy authentication

Con Conditional Access conviene disponer de una policy específica.

Antes de bloquear

Revisar sign-in logs utilizando:

Client app / legacy authentication

para localizar dependencias.

No confundir protocolo con autenticación

IMAP o POP pueden existir en escenarios modernos con OAuth.

El problema de seguridad histórico es principalmente:

Basic Authentication.

SMTP, dispositivos y aplicaciones

MFA suele descubrir dependencias de correo que nadie había documentado.

Ejemplos

impresoras, escáneres, ERP, CRM, monitorización, aplicaciones internas y formularios.

Antes del enforcement

Documentar para cada emisor:

Una cuenta de usuario con contraseña no debe ser la solución universal

La alternativa exacta depende del caso de uso.

Cómo comprobar correctamente qué usuarios están preparados para MFA

No debemos analizar cobertura únicamente mediante el estado:

Disabled / Enabled / Enforced

de la antigua página de per-user MFA.

De hecho

Cuando utilizamos:

Security Defaults o Conditional Access,

es normal que el estado per-user aparezca como:

Disabled.

Eso no significa que no haya MFA

El enforcement proviene de otra capa.

Authentication Methods Activity

Microsoft Graph dispone del recurso:

/reports/authenticationMethods/userRegistrationDetails

Propiedades especialmente útiles

PowerShell recomendado para inventario

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "AuditLog.Read.All"

$MfaStatus = Get-MgReportAuthenticationMethodUserRegistrationDetail -All

$MfaStatus |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  IsAdmin,
                  IsMfaRegistered,
                  IsMfaCapable,
                  IsPasswordlessCapable,
                  MethodsRegistered,
                  IsSystemPreferredAuthenticationMethodEnabled |
    Export-Csv "C:\Temp\MFA-Registration-Details.csv" `
        -NoTypeInformation `
        -Encoding UTF8

Usuarios que no están MFA capable

$MfaStatus |
    Where-Object {
        $_.IsMfaCapable -eq $false -and
        $_.UserType -eq "member"
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  IsAdmin,
                  MethodsRegistered

Administradores sin capacidad MFA

$MfaStatus |
    Where-Object {
        $_.IsAdmin -eq $true -and
        $_.IsMfaCapable -eq $false
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  MethodsRegistered

Usuarios sin passwordless

$MfaStatus |
    Where-Object {
        $_.IsPasswordlessCapable -eq $false
    } |
    Select-Object UserDisplayName,
                  UserPrincipalName,
                  MethodsRegistered

Por qué esto es mejor que Get-MgUserAuthenticationMethod

Enumerar objetos de autenticación puede servir para operaciones detalladas sobre un usuario.

Pero para un assessment global necesitamos responder directamente:

¿está registrado?, ¿es MFA capable?, ¿es passwordless capable?

El informe de registro ya ofrece estas propiedades.

Referencia oficial: Microsoft Graph – User registration details.

Sign-in logs: comprobar enforcement real

Un usuario puede tener Authenticator registrado y no estar correctamente protegido por la policy que esperábamos.

Por eso registration y enforcement deben revisarse por separado.

En cada sign-in podemos analizar

Authentication Details, Conditional Access, client, application, IP, device, location y risk cuando existe licencia.

Preguntas

No esperar siempre un prompt

El hecho de no ver una pantalla MFA en cada inicio no significa necesariamente que MFA se esté omitiendo.

Puede existir:

SSO, token válido, authentication strength ya satisfecha o una credencial passwordless multifactor.

Métricas útiles después del despliegue

Roadmap de implantación en 90 días

Días 1–15: descubrir

Días 16–30: preparar seguridad y recuperación

Días 31–45: piloto

Días 46–60: enforcement

Días 61–75: ampliar passwordless

Días 76–90: gobernar y medir

Errores frecuentes al implementar MFA en Microsoft 365

Checklist antes de activar MFA obligatorio

Preguntas frecuentes sobre MFA obligatorio en Microsoft 365

Conclusión: MFA obligatorio ya no consiste simplemente en instalar Microsoft Authenticator

Implementar MFA obligatorio en Microsoft 365 continúa siendo una de las mejoras más importantes que puede realizar una organización sobre su seguridad de identidad.

Pero el modelo ha evolucionado.

Microsoft ya exige MFA en diferentes portales y herramientas administrativas, y esta obligación seguirá formando parte del propio funcionamiento de la plataforma.

Sin embargo, eso no elimina la necesidad de diseñar nuestra propia estrategia.

Security Defaults proporciona una buena protección básica cuando no existe Entra ID Premium y no necesitamos excepciones complejas.

Conditional Access proporciona el control necesario cuando queremos diferenciar usuarios, aplicaciones, dispositivos, riesgos y fortalezas de autenticación.

La siguiente decisión es qué credenciales queremos permitir.

Microsoft Authenticator continúa siendo práctico para muchos usuarios, pero el objetivo para cuentas con privilegios debería avanzar hacia phishing-resistant MFA.

Passkeys/FIDO2, Windows Hello for Business y certificate-based authentication proporcionan opciones mucho más resistentes a los ataques modernos de phishing que SMS u OTP tradicionales.

La evolución de Microsoft durante 2026 refuerza este camino.

System-preferred authentication permite priorizar automáticamente métodos más fuertes y Registration Campaign puede utilizarse para migrar progresivamente usuarios desde métodos más débiles hacia Authenticator o passkeys.

Temporary Access Pass completa esa arquitectura proporcionando una vía controlada de bootstrap y recuperación.

También ha cambiado la forma correcta de diseñar cuentas de emergencia.

Las cuentas break-glass siguen siendo necesarias y Microsoft continúa recomendando disponer de al menos dos, pero deben estar preparadas para satisfacer los requisitos obligatorios de MFA. Al mismo tiempo, deben permanecer fuera de políticas Conditional Access que podrían bloquearlas durante el incidente que precisamente deberían ayudarnos a resolver.

Las automatizaciones requieren otro enfoque.

Una cuenta de usuario con contraseña excluida indefinidamente de MFA no debería considerarse una solución estable. El objetivo debe ser migrar hacia workload identities, managed identities, service principals o autenticación mediante certificados cuando corresponda.

Finalmente, necesitamos medir.

No podemos evaluar el proyecto preguntando simplemente si un usuario aparece como “Enabled” en la antigua página de MFA.

Authentication Methods Activity y Microsoft Graph nos permiten saber qué usuarios son MFA capable, MFA registered y passwordless capable, mientras los Sign-in Logs nos permiten validar si las políticas se están aplicando realmente.

La pregunta correcta deja de ser:

“¿Tenemos MFA activado?”

y pasa a ser:

“¿Todos los usuarios que deberían estar protegidos tienen una credencial adecuada, existe una policy que realmente la exige, podemos recuperar el acceso si esa credencial falla y hemos eliminado las excepciones que permiten saltarse el modelo?”

Cuando podemos responder afirmativamente a esas cuatro cuestiones, tenemos una estrategia MFA y no simplemente una configuración.

Documentación oficial recomendada

MFA y enforcement obligatorio

• Microsoft – Microsoft Entra multifactor authentication
• Microsoft – Mandatory MFA for Azure and admin portals
• Microsoft – Verify mandatory MFA setup

Security Defaults

• Microsoft – Security Defaults

Conditional Access

• Microsoft – Conditional Access overview
• Microsoft – Plan Conditional Access
• Microsoft – Require MFA for all users
• Microsoft – Require MFA for administrators
• Microsoft – Phishing-resistant MFA for administrators

Authentication Methods

• Microsoft – Manage authentication methods
• Microsoft – Migrate authentication method policies
• Microsoft – System-preferred authentication
• Microsoft – Authenticator number matching

Passkeys y FIDO2

• Microsoft – Passkeys FIDO2
• Microsoft – Enable passkeys
• Microsoft – Passkeys in Authenticator
• Microsoft – Synced passkeys
• Microsoft – Passkey FAQ
• Microsoft – Entra passkey on Windows

Authentication Strengths

• Microsoft – Authentication Strengths
• Microsoft – How Authentication Strengths work
• Microsoft – Custom Authentication Strengths

Registration y Temporary Access Pass

• Microsoft – Registration Campaign
• Microsoft – Temporary Access Pass
• Microsoft – Deploy phishing-resistant passwordless authentication

Emergency access

• Microsoft – Emergency access accounts
• Microsoft – Resilient access control strategy

Microsoft Graph y reporting

• Microsoft Graph – userRegistrationDetails
• Microsoft Graph – List userRegistrationDetails
• Microsoft Graph PowerShell – Get-MgReportAuthenticationMethodUserRegistrationDetail

BYOD e Intune

• Microsoft – App Protection Policies