Autenticación resistente al phishing para empresas

MFA no significa automáticamente resistencia al phishing

La autenticación multifactor reduce riesgos, pero algunos códigos de un solo uso pueden ser capturados y retransmitidos por un sitio impostor. NIST define la resistencia al phishing por la capacidad del protocolo de impedir que un verificador falso obtenga credenciales o resultados válidos; la entrada manual de un código no cumple esa definición.

WebAuthn y FIDO2 permiten credenciales criptográficas vinculadas al dominio legítimo. En la experiencia de usuario suelen presentarse como passkeys o llaves de seguridad. La política concreta depende del servicio, del dispositivo, de cómo se sincroniza o protege la credencial y de los requisitos de recuperación. No todas las opciones ofrecen idéntico nivel de control empresarial.

Elige primero las cuentas y aplicaciones prioritarias

Empieza por administradores, acceso remoto, consolas cloud, correo corporativo y herramientas de desarrollo con capacidad de cambiar producción. Después amplía a otros colectivos según exposición, impacto y compatibilidad.

Para cada aplicación registra:

• proveedor de identidad y protocolo de inicio de sesión;
• sistemas operativos, navegadores y dispositivos admitidos;
• si acepta passkeys sincronizadas, llaves físicas o ambas;
• flujos de alta, cambio de dispositivo, pérdida y baja;
• cuentas de servicio y excepciones que aún no admiten el método.

Las cuentas de emergencia deben ser pocas, estar protegidas por un procedimiento independiente, monitorizadas y probadas. No las dejes como una contraseña compartida sin responsable ni controles.

Despliegue gradual con recuperación comprobada

1. Piloto: incorpora un grupo pequeño de TI y seguridad, incluyendo usuarios con dispositivos distintos. Comprueba alta, inicio de sesión, cambio de equipo y recuperación.
2. Administradores: exige el método aprobado en las aplicaciones críticas y elimina alternativas débiles solo después de probar la ruta de emergencia.
3. Expansión: comunica qué cambia, ofrece soporte de inscripción y mide quién no puede completar el flujo y por qué.
4. Aplicaciones heredadas: decide si se integran mediante el proveedor de identidad, se aíslan, se sustituyen o mantienen una excepción temporal con controles compensatorios.
5. Revisión periódica: audita credenciales registradas, cuentas inactivas, métodos alternativos, dispositivos perdidos y excepciones vencidas.

No conviertas un método de recuperación más débil en una puerta trasera permanente. La mesa de ayuda debe verificar identidad con un procedimiento definido, registrar la actuación y escalar casos de alto riesgo.

Indicadores útiles

Separa cobertura de eficacia operativa: porcentaje de cuentas objetivo que completaron el alta, accesos que siguen usando métodos heredados, incidencias de recuperación, excepciones abiertas y cuentas privilegiadas sin el método requerido. Una cifra global de “usuarios con MFA” no revela si el acceso privilegiado resiste el phishing.

NIST SP 800-63B-4 explica la vinculación al verificador y los límites de los códigos introducidos manualmente. La guía de CISA sobre MFA resistente al phishing puede servir como referencia para priorizar FIDO/WebAuthn, adaptando la implantación al entorno y a los requisitos actuales.

Relaciona esta estrategia con el playbook de acceso seguro para cuentas privilegiadas.

Referencias

• NIST SP 800-63B-4, autenticación y resistencia al phishing
• CISA: Implementing Phishing-Resistant MFA
• W3C Web Authentication (WebAuthn), Level 3