MFA resistente al phishing: cómo desplegar passkeys en una empresa
Por Carlos Isidoro De Ayala Diaz ·
MFA resistente al phishing para empresas: cómo valorar passkeys, WebAuthn, recuperación, dispositivos y un despliegue gradual sin bloquear accesos críticos.
Distingue resistencia al phishing de tener dos pasos
Activar un segundo factor reduce riesgos, pero no convierte automáticamente el acceso en resistente al phishing. Una contraseña de un solo uso recibida por SMS, correo o una aplicación puede introducirse en una página falsa y ser reutilizada de inmediato por quien controla esa página. Una aprobación enviada al móvil también puede aceptarse por cansancio o confusión si el usuario recibe solicitudes repetidas. El proyecto debe identificar qué mecanismo protege cada aplicación y qué ataques pretende dificultar, en lugar de contabilizar factores sin revisar cómo se verifican.
NIST define la resistencia al phishing mediante autenticadores que impiden revelar secretos o resultados válidos a un verificador impostor. WebAuthn consigue esta vinculación con el nombre del servicio: la credencial creada para un dominio no produce una autenticación válida para otro. Las passkeys se apoyan en ese modelo y pueden sustituir la contraseña o formar parte de una autenticación multifactor, según cómo se proteja la clave y qué comprobación local exija el dispositivo. El término describe una propiedad técnica; no garantiza por sí solo que todo el proceso de acceso sea seguro.
El inventario inicial separa empleados, administradores, proveedores, cuentas de servicio y accesos de emergencia. Para cada colectivo se anotan aplicaciones, proveedor de identidad, método actual, posibilidad de usar WebAuthn y consecuencias de perder el autenticador. También se localizan protocolos y clientes antiguos que no admiten autenticación moderna. Si una cuenta conserva un camino alternativo basado en contraseña y código, un atacante elegirá ese camino. La mejora real depende de proteger o retirar las rutas de recuperación y compatibilidad que debilitan el control principal.
Decide qué tipo de passkey encaja con cada nivel de riesgo
No todas las passkeys se administran del mismo modo. Una credencial vinculada a un dispositivo o una llave física facilita limitar dónde reside la clave y puede ser adecuada para administración, infraestructura o funciones con impacto elevado. Una passkey sincronizada entre dispositivos mejora la recuperación y reduce fricción para muchos usuarios, pero introduce dependencias en la cuenta y en el mecanismo de sincronización del proveedor. FIDO recomienda evaluar ambos modelos según usuarios, dispositivos, recuperación, cumplimiento y capacidad operativa; no existe una única elección correcta para toda la organización.
La decisión necesita una política de dispositivos. En equipos corporativos se puede exigir bloqueo local, cifrado, actualización y gestión antes de registrar una credencial. En dispositivos personales hay que aclarar si se permiten passkeys sincronizadas, cómo se retira el acceso al finalizar la relación y qué información puede ver la empresa. Las llaves físicas requieren inventario, entrega segura, unidades de reserva y un procedimiento para pérdida o rotura. La biometría, cuando se usa, desbloquea normalmente la credencial en el dispositivo; el servidor no recibe una copia del rostro o la huella como contraseña.
Las cuentas técnicas merecen un tratamiento separado. Un proceso automático no puede confirmar una presencia humana ni depender de una passkey sincronizada en el teléfono de una persona. Esas identidades necesitan credenciales propias, permisos mínimos, rotación y almacenamiento controlado. Las cuentas compartidas deben sustituirse por identidades nominativas siempre que la plataforma lo permita. Para administradores conviene registrar más de un autenticador autorizado y mantener un acceso de emergencia muy restringido, vigilado y probado, de forma que una avería no obligue a reactivar contraseñas débiles para toda la empresa.
Diseña alta, recuperación y baja antes del despliegue
El alta debe demostrar quién registra la primera credencial. Si basta con conocer una contraseña ya comprometida, el atacante puede adelantarse al usuario y apropiarse del nuevo mecanismo. La empresa decide cuándo exige una comprobación adicional, si el registro solo se permite desde un equipo gestionado y quién puede autorizar excepciones. Después se muestra al usuario qué credenciales tiene, cuándo se añadieron y cómo revocarlas. Los registros de auditoría deben identificar altas, eliminaciones, cambios de recuperación y usos anómalos sin almacenar claves privadas ni datos biométricos.
La recuperación suele ser el punto más delicado. Un proceso basado en preguntas previsibles, correo accesible con la misma contraseña o una llamada sin verificación puede anular la protección de WebAuthn. NIST exige que la recuperación conserve un nivel de confianza adecuado y que se notifiquen los cambios relevantes. En la práctica se definen evidencias aceptables, separación de funciones, tiempos de espera para operaciones sensibles y comunicación al titular. El soporte necesita un guion que permita ayudar sin pedir códigos, contraseñas ni aprobaciones que un atacante pueda reutilizar.
La baja cubre despidos, fin de contratos, pérdida de dispositivos, cambio de funciones y compromiso. Deshabilitar la cuenta en el directorio debe impedir el acceso a las aplicaciones federadas, pero se comprueba cuáles mantienen sesiones o credenciales locales. También se revocan llaves, passkeys registradas, tokens de recuperación y sesiones persistentes. Para dispositivos perdidos se combina la revocación del acceso con las capacidades de gestión disponibles; borrar el equipo a distancia no sustituye la retirada de credenciales. Cada escenario se ensaya con cuentas de prueba antes de depender de él durante una incidencia.
Pilota con cuentas críticas y conserva una salida controlada
Un despliegue gradual empieza con aplicaciones compatibles y un grupo que represente los casos reales: varios sistemas operativos, trabajo remoto, personas con más de un dispositivo y usuarios que requieren accesibilidad. Se mide si completan el registro, cuánto soporte necesitan y qué fallos aparecen al cambiar de equipo. Después se incorporan administradores y procesos críticos con controles más estrictos. El piloto no termina al lograr un inicio de sesión correcto; debe probar recuperación, sustitución, baja, acceso de emergencia y bloqueo de los métodos antiguos.
Las aplicaciones heredadas se tratan como excepciones con propietario y fecha de revisión. Mientras no admitan WebAuthn, pueden protegerse mediante acceso condicionado, segmentación, reducción de privilegios o un intermediario compatible. CISA señala FIDO/WebAuthn como opción ampliamente disponible resistente al phishing y propone la coincidencia de números como mejora provisional cuando todavía se usan notificaciones. Una medida intermedia tiene sentido si queda documentada y no se presenta como estado final. Mantener indefinidamente todos los métodos por comodidad conserva la ruta que el atacante tratará de explotar.
La aceptación final compara el estado real con la política: porcentaje de cuentas cubiertas, métodos alternativos, excepciones, recuperación probada, eventos visibles y responsables. También se documenta cómo detener la obligatoriedad para un grupo sin borrar credenciales válidas ni abrir el acceso general. Élite Solutions Tech puede revisar desde Murcia la configuración, el hardening del proveedor de identidad y el plan de adopción para empresas con sedes locales o nacionales. La propuesta concreta plataformas, usuarios, pruebas y ejecución; una passkey no sustituye la gestión de permisos, dispositivos, sesiones ni respuesta ante incidentes.