Los tres factores, y por qué la contraseña sola ya no alcanza
La autenticación se apoya en tres categorías: algo que sabes (contraseña, PIN), algo que tienes (teléfono, llave de seguridad, certificado) y algo que eres (biometría). MFA exige al menos dos de categorías distintas. Una contraseña más una pregunta secreta no es MFA: las dos son conocimiento, y las dos se roban igual.
El problema de la contraseña no es su longitud, es su reutilización. Basta con que un empleado use la misma clave del correo corporativo en un servicio externo que sufre una filtración para que esa combinación aparezca en listas públicas. A partir de ahí el ataque no requiere técnica: alguien prueba la credencial en el portal de correo y entra.
No todos los segundos factores protegen igual
Esta es la parte que suele decidirse por comodidad y conviene decidir por riesgo. Ordenados de menos a más resistentes:
- Código por SMS o llamada. Es mejor que nada y es el más fácil de vencer: el código se puede pedir por teléfono al usuario, interceptar o conseguir con un cambio fraudulento de línea. Úsalo sólo como último recurso.
- Código temporal de una app (TOTP). Los seis dígitos que rotan cada 30 segundos. Resiste el robo de línea, pero el usuario se los puede teclear a un sitio falso.
- Notificación push con coincidencia de número. El usuario escribe en la app el número que aparece en la pantalla. Es el mínimo recomendable para una plantilla general, porque corta el ataque de fatiga: ya no basta con bombardear a alguien con avisos hasta que apruebe por error.
- Llaves de seguridad FIDO2 y passkeys. Son resistentes al phishing: la credencial está ligada criptográficamente al dominio real, así que un sitio clonado no puede usarla aunque el usuario coopere. Es el factor indicado para administradores, dirección y finanzas.
- Certificado en el dispositivo o tarjeta inteligente. Equivalente en resistencia, con más trabajo de administración. Tiene sentido donde ya existe una infraestructura de certificados.
MFA sin acceso condicional deja huecos
Activar MFA y darlo por terminado es el error más común. El segundo factor sólo se pide donde hay una política que lo exija, y en un entorno real siempre quedan caminos que la esquivan.
- Autenticación heredada. Los protocolos antiguos de correo (POP, IMAP, SMTP AUTH) no saben pedir un segundo factor: el sistema acepta la contraseña y entra. Hay que bloquearlos explícitamente.
- Exclusiones que nadie revisa. La cuenta del escáner, la del ERP, la del consultor externo. Cada exclusión necesita dueño, justificación y fecha de revisión.
- Cuentas de servicio y de aplicación. No pueden usar MFA interactivo, así que se protegen de otra forma: identidades administradas, contraseñas largas y rotadas, permisos mínimos y restricción por ubicación o por dispositivo.
- Dispositivos no administrados. Un usuario con MFA correcto puede estar sincronizando archivos a una computadora personal sin cifrado ni antivirus. Eso se controla con políticas de acceso condicional que exijan dispositivo inscrito y en cumplimiento.
- Cuentas de emergencia. Hacen falta dos cuentas de acceso de último recurso, con credenciales largas guardadas en físico y con llaves FIDO2, excluidas de las políticas que podrían dejarte fuera de tu propio tenant. Y con alerta cada vez que se usen.
Lo que MFA no resuelve
MFA elimina la gran mayoría de los ataques de credenciales, pero no todos. Decir lo contrario genera una falsa tranquilidad que se paga caro.
El ataque vigente se llama adversary-in-the-middle: el usuario recibe un enlace, llega a una página que reproduce el portal de inicio de sesión, teclea su contraseña y su código correctamente, y el sitio intermedio captura la cookie de sesión ya autenticada. El atacante no necesita volver a pasar MFA porque reutiliza la sesión. Lo que lo detiene es un factor resistente al phishing, limitar la vida de las sesiones en los accesos sensibles, exigir dispositivo administrado y vigilar los inicios de sesión con riesgo detectado.
El otro hueco es el consentimiento fraudulento: el usuario autoriza una aplicación de terceros que pide permiso para leer su correo. El acceso resultante es legítimo a ojos del sistema y sobrevive al cambio de contraseña. Se mitiga restringiendo quién puede otorgar consentimiento y revisando periódicamente las aplicaciones autorizadas.
Cómo desplegarlo sin frenar la operación
- Inventariar cuentas: usuarios activos, administradores, buzones compartidos, cuentas de servicio y accesos de proveedores. Casi siempre aparecen cuentas de gente que ya no trabaja ahí.
- Medir primero. Revisar los registros de inicio de sesión para saber qué aplicaciones y protocolos se usan de verdad, antes de bloquear nada.
- Publicar las políticas en modo de sólo reporte para ver a quién afectarían, y después activarlas.
- Crear las cuentas de emergencia y probarlas antes de endurecer el acceso de administradores.
- Empezar por los administradores y la dirección, con llave de seguridad. Son pocas personas y son el objetivo preferente.
- Registrar a toda la plantilla con una ventana de inscripción acompañada: un mensaje claro, instrucciones con capturas y alguien de TI disponible esos días. El fracaso de un despliegue de MFA casi nunca es técnico, es de comunicación.
- Bloquear la autenticación heredada al final, cuando ya se sabe qué dependía de ella.
- Dejar monitoreo: alertas por nuevo método registrado, por intentos fallidos repetidos y por inicios de sesión imposibles.
Qué incluye Microsoft 365 para hacerlo
Si tu empresa ya usa Microsoft 365, buena parte de esto está pagado y sin configurar. El plan Business Premium incluye Entra ID Plan 1, que es lo que habilita el acceso condicional y las políticas por riesgo de dispositivo o de ubicación; Intune, para inscribir y exigir cumplimiento en equipos y teléfonos; Defender para Office 365, para el correo que trae los enlaces; y Defender para Empresas, para la detección en los equipos. Microsoft Authenticator con coincidencia de número y las llaves FIDO2 no cuestan licencia aparte.
La diferencia entre tener Business Premium y estar protegido es la configuración: políticas de acceso condicional escritas, excepciones documentadas, cuentas de emergencia probadas y alguien revisando las alertas. igeckoo es partner certificado de Microsoft y trabaja precisamente ese tramo, el que separa la licencia comprada del control funcionando.