Microsoft Security · Identidad y acceso

MFA resistente al phishing: preparar el despliegue sin bloquear usuarios

Un usuario puede tener MFA configurado y seguir siendo vulnerable a una página de inicio de sesión falsa. Por eso, desplegar MFA resistente al phishing exige mirar algo más que el número de métodos registrados. Hay que comprobar qué credencial utiliza cada persona, desde qué dispositivo trabaja y qué ocurrirá cuando pierda su método habitual.

Esta guía se centra en preparar y validar el despliegue en Microsoft Entra. El objetivo es que el cambio reduzca la exposición al robo de credenciales y tenga una operación sostenible. Las propuestas de pruebas, responsables y criterios de aceptación que encontrará a continuación son recomendaciones prácticas, no requisitos universales de Microsoft.

MFA resistente al phishing: qué cambia en la práctica

Una contraseña y un código introducidos en una web fraudulenta pueden terminar en manos de un atacante. La resistencia al phishing busca que la autenticación esté vinculada al servicio legítimo. Esto cambia el tipo de prueba que necesita hacer el equipo de TI: no basta con confirmar que aparece una solicitud adicional. Debe identificar el método aceptado por la política y comprobar que el inicio de sesión se completa en el contexto previsto.

Microsoft ofrece fortalezas de autenticación con requisitos distintos. La fortaleza MFA, la fortaleza MFA sin contraseña y la fortaleza MFA resistente al phishing no son equivalentes. Que un usuario apruebe una notificación en Microsoft Authenticator no significa, por sí solo, que haya utilizado un método resistente al phishing. Una passkey en esa misma aplicación es un método distinto de una notificación convencional.

Entre las opciones compatibles se encuentran passkeys FIDO2, Windows Hello for Business y autenticación basada en certificados configurada para multifactor. La elección depende del entorno. Una llave física puede resultar práctica para un administrador que cambia de equipo. Windows Hello for Business puede encajar en un puesto personal gestionado. Los certificados requieren una infraestructura y un ciclo de vida que la organización pueda mantener.

Las passkeys pueden estar vinculadas a un dispositivo o sincronizarse mediante un proveedor. No conviene aplicar el mismo criterio de custodia a todos los perfiles. Para cuentas privilegiadas, revise si necesita credenciales vinculadas a dispositivos y qué proveedores acepta. Compruebe las opciones vigentes de los perfiles de passkeys en su tenant. Esta función evoluciona y una receta basada en pantallas antiguas puede omitir controles relevantes.

Empiece por el acceso real, no por una compra de llaves

Construya un inventario por combinación de usuario, dispositivo y aplicación. Una persona puede trabajar desde un portátil gestionado, consultar Teams en el móvil y entrar ocasionalmente desde un escritorio virtual. El resultado correcto en el portátil no valida los otros dos casos. Incluya cuentas administrativas separadas, puestos compartidos, personal remoto, contratistas y equipos que no gestione la empresa.

Para cada combinación, anote el sistema operativo, navegador o cliente utilizado, método disponible, responsable del equipo y aplicación de negocio. No necesita una hoja enorme con todos los detalles técnicos. Necesita suficiente información para identificar qué casos están preparados, cuáles requieren una actuación y cuáles todavía carecen de evidencia. Separe las aplicaciones críticas de las que admiten una interrupción breve.

Compruebe las políticas de métodos de autenticación y los grupos incluidos o excluidos. Poder registrar una credencial y poder usarla son comprobaciones diferentes. Revise también las políticas de Acceso Condicional existentes. Si una persona pertenece a varios grupos, puede recibir requisitos acumulados que no se aprecian al mirar una única política. Documente las dependencias antes de introducir un nuevo requisito.

Licencias y permisos antes del piloto

Verifique el licenciamiento de Acceso Condicional y de las capacidades adicionales que vaya a utilizar. La presencia de un menú en el portal no demuestra que todo el colectivo esté correctamente cubierto. Asigne las tareas con el menor privilegio necesario y distinga quién puede configurar métodos, quién puede emitir credenciales de incorporación y quién puede cambiar políticas de acceso.

Prepare además una línea base: qué métodos se utilizan actualmente, en qué aplicaciones aparecen fallos y cuántas peticiones de soporte recibe el equipo. Esa referencia permitirá separar los incidentes nuevos de problemas previos. Si el acceso a una aplicación ya falla de forma intermitente, registrarlo antes evita atribuir todo al despliegue de MFA.

Registro e incorporación: la parte que suele faltar

Enviar un correo diciendo «registre su llave» no garantiza una incorporación segura. Defina cómo se verificará la identidad de la persona, dónde recibirá instrucciones y qué acompañamiento tendrá. La comunicación debe identificar el servicio, el motivo del cambio y el canal conocido de ayuda. Evite enseñar al usuario a aceptar enlaces inesperados o a entregar códigos a quien le llame.

Temporary Access Pass, o TAP, puede facilitar el registro y la recuperación de métodos sin contraseña. Es una credencial temporal que requiere una política habilitada y un procedimiento de entrega seguro. No la trate como una contraseña de cortesía que soporte puede emitir sin comprobar al solicitante. Registre quién la autorizó y confirme después que el usuario incorporó el método previsto.

Ensaye el registro completo con personas ajenas al equipo de seguridad. Compruebe qué ven cuando una llave no está conectada, cuando el navegador ofrece varias credenciales y cuando utilizan una cuenta administrativa diferente de su cuenta habitual. Una instrucción técnicamente correcta puede resultar confusa si la pantalla muestra nombres o elecciones que el procedimiento no explica.

El cierre de la incorporación debe incluir un inicio de sesión nuevo. Que el registro termine correctamente no prueba el acceso desde Outlook, Teams, el portal administrativo o una aplicación interna. Confirme el resultado en los registros, evitando que una sesión previa o un token ya emitido escondan un problema que aparecerá al renovar la autenticación.

Diseñe un piloto que pueda fallar de forma controlada

Elija un grupo pequeño pero representativo. Incluya al menos una persona con movilidad, alguien con una aplicación crítica, un administrador y un caso con dispositivo compartido o virtual si existe en la empresa. El tamaño importa menos que la cobertura. Un piloto formado únicamente por técnicos con equipos nuevos produce una confianza que puede no trasladarse al resto de la plantilla.

Antes de activar la exigencia, revise la política en report-only y utilice las herramientas de evaluación disponibles. Estos resultados ayudan a detectar alcance y requisitos, pero no sustituyen una prueba real del método. Si necesita interpretar esa fase, consulte nuestra guía de validación de Acceso Condicional en report-only. Ambos contenidos se publican dentro de la misma serie de seguridad.

Al pasar el piloto a aplicación efectiva, pruebe un inicio de sesión nuevo desde cada combinación prevista. Anote usuario de prueba, hora, aplicación, dispositivo, método y política aplicada. No guarde secretos en la evidencia. La pregunta útil es si el requisito nuevo se ha satisfecho y si la persona ha podido completar su tarea, no únicamente si aparece un resultado satisfactorio en una pantalla.

Pruebas positivas y negativas

Una prueba positiva demuestra que un método permitido funciona. Una prueba negativa comprueba que un método insuficiente no satisface la fortaleza exigida. Utilice cuentas y recursos preparados para ese ensayo. No haga pruebas improvisadas que puedan dejar a un administrador sin acceso. El resultado esperado de cada caso debe estar escrito antes de ejecutar la prueba.

Incluya cambio de navegador, cierre de sesión, equipo de sustitución y pérdida del método principal. En escritorios virtuales o conexiones remotas, valide el flujo específico y los requisitos de redirección o autenticación entre dispositivos. No suponga que una llave conectada físicamente al portátil puede utilizarse de la misma forma dentro de cualquier sesión remota.

Para invitados, compruebe el tenant de origen, el modelo de colaboración y las políticas entre organizaciones. La experiencia del empleado interno no demuestra la del usuario externo. Si una aplicación depende de colaboradores, convierta ese caso en una condición de aceptación propia. La solución puede requerir coordinación con otra organización y no una excepción permanente en su tenant.

La recuperación también forma parte de la seguridad

La pérdida de una llave o un teléfono no debería forzar a soporte a eliminar el requisito de seguridad para toda la persona. Prepare un método de respaldo que satisfaga la política cuando sea posible y un proceso de recuperación de identidad. Ensaye quién autoriza el restablecimiento, cómo se entrega una credencial temporal y qué método perdido debe retirarse.

Una recuperación correctamente diseñada deja trazabilidad y una situación final comprobada. El ticket no debería cerrarse al emitir el TAP. Debe confirmar el nuevo registro, el acceso al recurso y la retirada del método que ya no debe utilizarse. Si hay sospecha de robo o uso indebido, añada la investigación de sesiones y actividad correspondiente, con el equipo responsable.

Las cuentas de emergencia necesitan un tratamiento específico: credenciales custodiadas, autenticación resistente al phishing, alertas y pruebas periódicas. No son cuentas sin protección. Revise la guía de Microsoft y mantenga su disponibilidad independiente de las políticas restrictivas que podrían impedir el acceso durante una emergencia. Una cuenta que nadie ha probado es una intención, no una capacidad de recuperación.

Soporte y comunicación que permiten ampliar

Prepare una guía corta para el usuario y otra para soporte. La primera debe explicar lo que cambia en su jornada y qué hacer si falta el método. La segunda necesita preguntas de diagnóstico: cuenta utilizada, dispositivo, aplicación, momento del fallo y mensaje recibido. Pedir una captura puede ayudar, siempre que no contenga códigos, credenciales o información que no deba circular.

Reserve atención durante la primera ventana de cada oleada. La formación no sustituye a una persona que pueda resolver un registro incompleto o un problema de compatibilidad. Defina un canal conocido y evite que el cambio coincida con viajes, cierres contables o sustituciones masivas de equipos. La fecha debe elegirse por preparación operativa, además de por urgencia de seguridad.

Comunique también qué no debe hacer el usuario: compartir la llave, aprobar una petición que no ha iniciado o entregar un código a una llamada inesperada. No convierta el aviso en una lista de amenazas. Un ejemplo breve y una vía clara de ayuda suelen aportar más que una comunicación larga que nadie conserva para cuando ocurre el problema.

Qué evidencia permite dar por buena una oleada

Defina criterios antes de ampliar. Como mínimo, los casos críticos deben tener un resultado esperado, el acceso debe estar confirmado con el método previsto y la recuperación debe haberse ensayado. El responsable de la aplicación debe validar que el trabajo se completa. Seguridad debe revisar las excepciones y soporte debe reconocer los fallos más habituales.

• Inventario de combinaciones probadas y casos todavía pendientes.
• Registros que identifican el método y la política aplicada.
• Prueba de respaldo o recuperación con resultado documentado.
• Excepciones con propietario y fecha de revisión.
• Responsable de decidir la siguiente oleada y condiciones para detenerla.

No establezca un porcentaje de éxito que oculte un único fallo crítico. Si noventa personas pueden trabajar y el administrador de recuperación no puede entrar, la oleada no está preparada. Revise la relevancia de cada escenario junto con las cifras. Los datos agregados sirven para detectar patrones, pero la decisión depende también del impacto de los casos que faltan.

Ejemplo práctico de decisión

Imagine una empresa con portátiles gestionados y comerciales que acceden desde el móvil. El piloto confirma los portátiles, pero detecta que parte de los móviles no dispone del método permitido. Una decisión razonable sería ampliar únicamente a las combinaciones ya validadas, acompañar el registro móvil y mantener una lista visible de pendientes. No se trata de dar el proyecto por terminado mientras existe una excepción desconocida.

Tras cada oleada, compare incidencias con la línea base y revise las políticas efectivamente aplicadas. Si una exclusión deja fuera a más personas de las previstas, detenga la ampliación y corrija el alcance. El cierre debe incluir un procedimiento de altas, bajas y cambios de dispositivo. De otro modo, la cobertura empieza a degradarse en cuanto llegan nuevos empleados.

Quién mantiene el control después de la implantación

Asigne un responsable de revisar la cobertura cuando cambian los grupos, se incorporan aplicaciones o se renuevan dispositivos. El mantenimiento debe comprobar métodos realmente utilizados y excepciones todavía abiertas. Incluya esa revisión en la administración habitual, con una evidencia breve de las decisiones tomadas. Un despliegue puede estar bien ejecutado y perder eficacia meses después si las altas se resuelven con otro procedimiento o una exclusión temporal se mantiene sin que nadie la supervise.

Documentación oficial para contrastar la configuración

• Fortalezas de autenticación
• Planificación del despliegue resistente al phishing
• Temporary Access Pass
• Passkeys sincronizadas
• Cuentas de acceso de emergencia