El MFA reduce el riesgo de que una contraseña robada baste para entrar en una cuenta, pero puede plantear un problema operativo cuando se pierde un móvil, se sustituye un dispositivo o deja la empresa quien administraba un servicio. Si nadie puede recuperar el acceso a WordPress, al hosting o al DNS, una incidencia técnica sencilla puede convertirse en una interrupción difícil de gestionar.
El problema no se resuelve compartiendo códigos, dejando un correo personal como recuperación o creando excepciones permanentes. La alternativa es un plan de recuperación MFA limitado a las cuentas críticas, con responsables internos, una validación proporcionada al impacto y una revisión defensiva tras cada recuperación. El objetivo es restablecer acceso autorizado sin convertir el proceso en una puerta trasera.
La recuperación MFA también es una acción sensible
Una cuenta puede estar bien protegida en el inicio de sesión y, aun así, quedar expuesta si resulta demasiado fácil cambiar su teléfono, registrar una nueva passkey o modificar el correo de recuperación. OWASP recomienda que el restablecimiento de MFA permita recuperar el acceso legítimo sin facilitar el secuestro de la cuenta. También aconseja solicitar una nueva autenticación con un factor ya registrado antes de cambiar los factores MFA, en lugar de confiar solo en una sesión que podría haber sido comprometida. [3]
Conviene tratar la pérdida del segundo factor como un proceso de continuidad y de seguridad, no como una solicitud informal por chat. La persona que pide el cambio debe identificarse mediante un canal definido, y la decisión debe quedar registrada. Cuando la cuenta permite publicar contenidos, modificar DNS, restaurar copias o consultar datos de clientes, una segunda aprobación interna puede ser una medida razonable.
- Exige una petición por el canal interno acordado.
- Comprueba la identidad y el motivo antes de cambiar o eliminar un factor.
- Registra quién autorizó la acción, cuándo se hizo y qué debe revisarse después.
Delimita las cuentas incluidas en el plan
No hace falta empezar por todas las cuentas de la empresa. Prioriza las que pueden afectar a la disponibilidad, la configuración o la información de la web: administración del CMS, hosting, DNS, correo corporativo, CDN o WAF, plataforma de comercio electrónico y proveedor de identidad. ENISA recomienda decidir qué activos y roles requieren MFA según su criticidad, definir métodos de respaldo seguros y supervisar los registros de autenticación. [4]
Clasifica cada cuenta por su capacidad de causar impacto, no por el cargo de quien la usa. Una misma persona puede tener acceso a varios proveedores, pero cada servicio tendrá sus propios mecanismos de soporte, evidencias y plazos. Por ejemplo, una cuenta que modifica registros DNS necesita una ruta de recuperación distinta de la cuenta editorial que publica una entrada en el blog.
- Servicio y URL oficial de acceso.
- Propietario interno y segundo responsable autorizado.
- Nivel de privilegio y acciones que permite realizar la cuenta.
Crea una ficha de recuperación por proveedor
Para cada plataforma crítica, prepara una ficha breve y accesible solo para quienes deban usarla. Debe indicar quién puede abrir una petición al proveedor, qué comprobaciones internas se realizan, cuál es el canal oficial de soporte y qué cambios requieren doble revisión. Evita incluir contraseñas, códigos temporales, semillas de autenticadores u otros secretos en documentos compartidos.
NIST contempla mecanismos como códigos de recuperación, contactos de recuperación y la repetición de la verificación de identidad. También indica que los eventos de recuperación deben generar notificaciones para ayudar a detectar usos fraudulentos. Si un proveedor ofrece códigos de recuperación, custódialos según una política interna y revisa su vigencia cada vez que cambien los responsables autorizados. [1]
- Vía oficial de recuperación y datos de contacto del proveedor.
- Evidencias o aprobaciones internas necesarias antes de iniciar el trámite.
- Pasos obligatorios posteriores: revisión de factores, sesiones y contactos de recuperación.
Responde de forma distinta según el incidente
Ante la pérdida o sustitución de un dispositivo, el objetivo es dar de alta un nuevo factor sin precipitarse a eliminar el anterior si todavía puede verificarse su situación. Un ejemplo hipotético: la responsable de contenidos cambia de teléfono y conserva acceso a la cuenta corporativa. Un segundo responsable valida la solicitud, se registra el nuevo factor mediante el proceso oficial y se confirma después que los factores antiguos no necesarios han sido retirados.
Una baja de personal o una sospecha de compromiso requiere más cautela. En el primer caso, hay que retirar el acceso y los métodos de recuperación vinculados a esa persona según el alcance autorizado. En el segundo, recuperar la contraseña no basta: OWASP aconseja revisar métodos MFA, direcciones de recuperación, sesiones activas y cambios recientes, e invalidar sesiones o enlaces de recuperación que ya no deban seguir vigentes. [5]
- Pérdida de dispositivo: valida la solicitud y registra el nuevo factor.
- Salida de personal: retira permisos, factores y contactos asociados.
- Sospecha de compromiso: revisa sesiones, cambios recientes y datos de recuperación antes de cerrar el caso.
Prueba el proceso y mejora lo que falle
Un procedimiento que nunca se ha probado puede depender, sin que nadie lo sepa, de una persona concreta o de información obsoleta. Realiza pruebas controladas, con autorización previa y sobre cuentas o entornos previstos para ello. La prueba no busca forzar accesos: verifica que el equipo localiza la ficha, identifica al responsable, usa el canal oficial del proveedor y documenta el resultado.
Revisa el plan tras cambios de proveedor, personal, dominios, roles o métodos de autenticación. Para cuentas de mayor valor o privilegio, CISA recomienda priorizar MFA resistente al phishing y empezar por los servicios compatibles y por grupos como administradores de sistemas o equipos de soporte. Los códigos OTP introducidos manualmente pueden seguir teniendo utilidad operativa, pero NIST no los considera resistentes al phishing porque pueden ser reenviados desde un sitio impostor. [2] [1]
- Programa una revisión periódica y otra tras cambios relevantes.
- Anota fecha de prueba, incidencias detectadas y responsable de corregirlas.
- Actualiza la ficha solo después de comprobar que la nueva ruta funciona.
Preguntas frecuentes
¿Debemos guardar códigos de recuperación MFA en un documento compartido?
No es recomendable guardar códigos, contraseñas o secretos MFA en documentos compartidos de uso general. Si el proveedor ofrece códigos de recuperación, la empresa puede definir una custodia restringida, controles de acceso y revisiones cuando cambien los responsables. La ficha operativa debe indicar dónde está el mecanismo aprobado, no exponer el,
¿Dos responsables deben compartir la misma cuenta administradora?
No. Es preferible que cada responsable tenga una identidad propia y permisos acordes con su función. Así se puede retirar acceso individual, revisar actividad y mantener una ruta de recuperación sin compartir contraseñas ni factores MFA. Cuando el proveedor lo permita, asigna roles diferenciados en lugar de usar una única cuenta común.
¿Cada cuánto conviene revisar el plan de recuperación MFA?
Revísalo de forma periódica y siempre que haya cambios relevantes: salida o incorporación de personal, sustitución de dispositivos, cambio de proveedor, alta de un dominio o modificación de privilegios. Una prueba controlada permite detectar contactos obsoletos, instrucciones incompletas o dependencias de una sola persona antes de que ocurra una de