La autenticación multifactor, o MFA, añade comprobaciones al inicio de sesión. Sin embargo, la empresa necesita saber qué método utiliza y en qué aplicaciones se exige realmente. Que una cuenta tenga un segundo factor registrado no demuestra que todos sus accesos estén protegidos de la misma manera.
Para empresas de Venezuela y Latinoamérica, proponemos evaluar la MFA resistente al phishing como un cambio operativo: personas, dispositivos, aplicaciones y soporte deben funcionar juntos. El primer paso es elegir un servicio importante y comprobar el recorrido completo de acceso.
1. Comprende qué aporta la resistencia al phishing
FIDO Alliance explica que las passkeys utilizan criptografía de clave pública y credenciales vinculadas al servicio correspondiente. Por diseño, una passkey solo se presenta al sitio donde se registró, por lo que el usuario no puede escribirla accidentalmente en una página falsa. [1]
Esta protección permite plantear un objetivo concreto: reducir la exposición de la autenticación a sitios que imitan el acceso legítimo. Pide al proveedor identificar el mecanismo utilizado, su compatibilidad y las condiciones necesarias para que funcione.
Evita evaluar una solución únicamente por la etiqueta “sin contraseña”. Microsoft distingue entre MFA, MFA sin contraseña y MFA resistente al phishing dentro de sus controles de intensidad de autenticación. Son categorías diferentes. [2]
2. Selecciona usuarios y aplicaciones para el piloto
Microsoft recomienda planificar el despliegue según perfiles de usuarios y comprobar la preparación de sus dispositivos. También contempla empezar por un grupo antes de extender la adopción. [3]
Como aplicación práctica, selecciona un grupo pequeño que represente el trabajo real: administración, personal remoto y usuarios con funciones sensibles. Registra sus aplicaciones, navegadores, sistemas operativos y formas habituales de conexión.
Incluye situaciones que suelen quedar fuera de una demostración: un equipo de reemplazo, una aplicación de escritorio y el acceso desde otra sede. Acuerda con el responsable del negocio qué operaciones deben continuar durante las pruebas. Si aparece una incompatibilidad, documenta su alcance y asigna un responsable antes de ampliar el piloto.
3. Comprueba que el método se exige al acceder
Registrar una passkey y exigirla para un recurso son decisiones distintas. Microsoft Entra permite especificar las combinaciones de autenticación admitidas mediante Acceso Condicional. Su documentación aclara que una persona puede introducir una contraseña inicialmente y aun así necesitar un método resistente al phishing antes de continuar. [2]
Por eso, pide comprobar el resultado sobre la aplicación protegida. Utiliza cuentas de prueba autorizadas para verificar qué sucede cuando el usuario intenta acceder con un método diferente o desde un dispositivo no contemplado.
Registra el método utilizado, la política aplicada y el resultado. La evidencia debe demostrar que el recurso requiere la protección acordada, además de mostrar que el usuario pudo registrar su credencial. Confirma también los requisitos de licencia y configuración de la plataforma elegida.
4. Prepara la pérdida del dispositivo antes de que ocurra
Microsoft recomienda registrar al menos dos métodos de autenticación para disponer de una alternativa ante situaciones como pérdida o robo. [3] La organización debe decidir cuáles son apropiados para cada perfil y cómo conservar la protección exigida al recurso.
Como procedimiento interno, define quién recibe la solicitud, cómo verifica la identidad y quién autoriza el registro de una credencial de reemplazo. Evita que una llamada urgente se convierta automáticamente en permiso para retirar controles.
Prueba el proceso con una cuenta ficticia: pérdida del autenticador principal, uso de la alternativa y retirada de la credencial anterior. Documenta qué ocurre si tampoco está disponible el método de respaldo. El soporte necesita instrucciones verificables, responsables y una vía de escalamiento.
5. Mantén visibilidad después del inicio de sesión
La protección del acceso debe acompañarse de seguimiento de la actividad. Proofpoint describe el robo de tokens de sesión y la fatiga de MFA entre las vías utilizadas contra cuentas, y señala cambios de métodos de autenticación, reglas de correo y conexiones de aplicaciones como elementos relevantes para investigar una toma de cuenta. [4]
Como propuesta operativa, acuerda con el SOC qué registros están disponibles y qué situaciones requieren revisión: alta inesperada de un autenticador, cambios de recuperación o actividad posterior incompatible con el trabajo habitual.
Comprueba la recepción de esos eventos mediante pruebas autorizadas. Una señal aislada necesita contexto; registra quién investiga y cómo comunica sus conclusiones. Mantén también las medidas de protección de los dispositivos y la gestión de incidentes.
6. Amplía el despliegue con criterios de aceptación
Utiliza ITSM para coordinar el cambio y conservar una ficha con aplicaciones cubiertas, usuarios incluidos, pruebas realizadas y excepciones abiertas. Cada excepción debe tener motivo, responsable, controles acordados y fecha de revisión.
Antes de incorporar otro grupo, revisa accesos exitosos, fallos de compatibilidad y solicitudes de recuperación. Explica a los usuarios qué pantallas deberían ver y cómo reportar una solicitud de autenticación inesperada.
Comienza por un alcance que puedas comprobar y mantener. La decisión de ampliar debe apoyarse en evidencia de protección y continuidad operativa.
Si tu empresa quiere revisar la seguridad de sus accesos y organizar un despliegue con controles verificables, contacta a INSTALINE para conversar sobre sus necesidades.
Referencias oficiales
Consultadas el 2 de noviembre de 2026.
