Una contraseña demuestra algo que el usuario conoce. La autenticación multifactor añade otra evidencia, como un código temporal, una notificación aprobada o una llave física. El objetivo es que una contraseña expuesta no baste para entrar, especialmente en cuentas que pueden cambiar datos o administrar servicios.
Activarla no consiste solo en marcar una opción. Hay que elegir el método, preparar la recuperación y evitar que una cuenta administrativa quede bloqueada cuando se pierde el único dispositivo autorizado.
Qué añade cada método
TOTP genera códigos temporales en una aplicación autenticadora. No depende de que llegue un mensaje, pero requiere conservar el secreto de configuración y proteger los códigos de recuperación. Las notificaciones push son cómodas, aunque una persona puede aprobar una petición inesperada si recibe muchas solicitudes.
Las llaves de seguridad basadas en estándares de autenticación resistente al phishing vinculan la comprobación al sitio legítimo. El coste y la gestión de dispositivos son mayores, pero resultan apropiadas para cuentas privilegiadas. Ningún método elimina la necesidad de proteger la sesión, el dispositivo y el proceso de recuperación.
Qué cuentas deben recibir prioridad
Empieza por correo, paneles de hosting, accesos de administración, repositorios y servicios que permiten restablecer otras cuentas. Una cuenta de correo comprometida puede servir para recuperar contraseñas aunque los demás servicios tengan segundo factor.
Las cuentas compartidas dificultan saber quién aprobó un acceso y complican la revocación. Es preferible asignar identidades individuales y mantener métodos de recuperación asociados a personas responsables, no a un buzón que nadie revisa.
Recuperación sin abrir una puerta
Genera códigos de recuperación y guárdalos en un lugar protegido y accesible para la persona autorizada. Define qué ocurre si se pierde el teléfono, cambia el empleado responsable o se rompe una llave. El soporte debe verificar identidad con un procedimiento independiente; enviar un código a la misma cuenta comprometida no es recuperación segura.
Prueba el proceso con una cuenta de ensayo y documenta quién puede restablecer el segundo factor. Desactivar MFA temporalmente puede ser necesario en una incidencia, pero debe quedar registrado, tener una duración limitada y revertirse después.
Phishing y fatiga de aprobaciones
El segundo factor reduce el valor de una contraseña robada, pero una persona puede entregar el código a un sitio falso o aprobar una notificación fraudulenta. Las llaves que verifican el origen del sitio ofrecen una resistencia distinta a los códigos copiados. La formación debe explicar cómo comprobar el contexto, no pedir que se apruebe cualquier aviso.
También conviene revisar sesiones abiertas, dispositivos autorizados y alertas de nuevos accesos. Si el atacante controla el correo de recuperación o una sesión ya iniciada, MFA no corrige por sí solo ese problema.
Cómo desplegarlo en administración
Inventa un calendario de migración realista: registra métodos alternativos, prueba una cuenta no privilegiada, después protege administradores y finalmente aplica la política al resto. Mantén un canal de soporte que pueda comprobar identidad sin convertir una excepción en acceso permanente.
Una contraseña larga y única, límites de intentos, actualización de dispositivos y registros de acceso complementan el segundo factor. La aplicación debe alertar sobre cambios de método y permitir revocar dispositivos que ya no se usan.
Qué cuentas deberían recibir prioridad
La primera decisión es proteger las cuentas que controlan recuperación, dinero, datos personales o infraestructura. Después revisa el método más resistente que la organización pueda mantener y prueba la recuperación antes de imponerlo. MFA añade una barrera importante, pero su eficacia depende del canal elegido y de todo lo que rodea al inicio de sesión.
Elegir el segundo factor según el riesgo
Para una cuenta con acceso a infraestructura, una llave física puede justificar su coste y su gestión adicional. Para usuarios numerosos, TOTP puede ser más sencillo de desplegar si se acompaña de códigos de recuperación protegidos y un soporte bien definido. Las notificaciones push reducen fricción, pero deben incluir contexto suficiente para reconocer una solicitud inesperada.
Evita que el proceso de recuperación sea más débil que el acceso normal. Un operador que restablece el factor después de una petición por correo no verificada puede anular la protección que se acaba de activar.
Cómo comprobar que la política sigue funcionando
Prueba el inicio de sesión desde un dispositivo nuevo, la revocación de un dispositivo perdido y la recuperación de una cuenta sin desactivar la política global. Revisa alertas de nuevos métodos, sesiones persistentes y cuentas que todavía no tienen el segundo factor.
La revisión debe incluir administradores, cuentas de soporte y buzones utilizados para recuperar accesos. Una política antigua puede cubrir a la mayoría de usuarios y dejar fuera precisamente la identidad con más privilegios.
Excepciones, cuentas de servicio y auditoría
Las cuentas que no pueden usar una aplicación autenticadora necesitan una alternativa documentada, no una exclusión indefinida. Las cuentas de servicio deberían usar credenciales rotables y permisos acotados; si no admiten MFA, compensa el riesgo con restricciones de red, secretos protegidos y revisión frecuente.
Audita quién tiene MFA activo, qué método utiliza y cuándo se modificó. Una cuenta puede aparecer protegida en el panel y conservar una sesión, token o método de recuperación que no se ha revisado.
Revisar el acceso después de una incidencia
Si una contraseña se ha expuesto, restablécela y revisa sesiones, dispositivos, códigos de recuperación y métodos alternativos. Activar un segundo factor después de un incidente sin revisar esas sesiones puede dejar acceso persistente. Documenta la fecha, la cuenta afectada y las comprobaciones realizadas.