He gestionado suficientes despliegues de MFA como para conocer el patrón. Pasamos un año promoviendo notificaciones push y códigos TOTP, declaramos la victoria, y dieciocho meses después el informe de incidentes dice que un agente del servicio de asistencia aprobó un restablecimiento para alguien con un acento convincente y un perfil de LinkedIn. El control no falló porque las personas sean estúpidas. Falló porque el control sigue dependiendo de un secreto que un ser humano puede ser persuadido de revelar.

Ese es el argumento completo a favor de las passkeys, y creo que vale la pena ser directo al respecto: las contraseñas más un código no son resistentes al phishing, y los atacantes lo descubrieron mucho antes de que la mayoría de nuestras hojas de ruta lo hicieran. Hablemos entonces de qué cambia realmente, qué no cambia, y cómo conseguir que las personas que firman los cheques y las que hacen clic en los botones estén de tu lado.

Qué control falló, exactamente

Una contraseña, un código SMS, un código TOTP y una notificación push comparten una propiedad: la prueba de identidad es un valor que puede ser retransmitido. Un proxy de adversario en el medio (Evilginx y sus variantes) se sitúa entre el usuario y la página de inicio de sesión real, reenvía todo en tiempo real y se marcha con una sesión. CISA lo dijo claramente en su ficha informativa de 2022 sobre la implementación de MFA resistente al phishing: los códigos basados en aplicaciones y las notificaciones push son mejor que nada, pero solo los métodos FIDO/WebAuthn y los basados en PKI se consideran resistentes al phishing. NIST SP 800-63B dice lo mismo con un lenguaje más formal, y reserva sus niveles de garantía más altos para los autenticadores que verifican el origen.

Las passkeys son el empaquetado amigable para el consumidor de ese modelo. La credencial es un par de claves pública y privada. La clave privada nunca abandona el autenticador (un teléfono, un portátil, una llave de seguridad). Durante el inicio de sesión, el navegador vincula la firma al identificador de la parte confiante, que es tu dominio. Si el usuario está en evil.example en lugar de login.yourcompany.com, el autenticador no tiene ninguna clave coincidente y simplemente no firmará. No hay ningún código que escribir en el cuadro equivocado. El propio artículo de Cloudflare sobre la campaña de phishing de 2022 que afectó a Twilio y otros es la mejor evidencia de campo que conozco: el mismo señuelo, los mismos atacantes, y los usuarios con llave de hardware no fueron comprometidos porque la verificación de origen hizo su trabajo.

Así que cuando alguien me pregunta por qué volvemos a hacer esto después de que "ya implementamos MFA", mi respuesta es que sí implementamos MFA, solo que la versión en la que el atacante puede participar.

Preparando la infraestructura

Antes de tocar a los usuarios, haz un inventario de las partes confiantes. Cada lugar donde un usuario escribe una contraseña hoy está detrás de tu IdP o no lo está. Los que están detrás del IdP reciben passkeys el día que habilitas WebAuthn como método de autenticación. Los que no lo están son tu proyecto real. La buena noticia es que esta lista suele ser más corta y más reveladora de lo que esperas, lo cual resulta motivador a su manera.

Luego toma tres decisiones de arquitectura y anótalas:

• Sincronizadas o vinculadas al dispositivo. Apple, Google y Microsoft sincronizan passkeys a través de sus cuentas en la nube. El suplemento de 2024 de NIST al 800-63B acepta autenticadores sincronizables en AAL2, así que esto no es herejía, pero significa que la passkey es tan robusta como la recuperación de la cuenta de iCloud o Google del usuario. Para administradores y roles privilegiados, exige credenciales vinculadas al dispositivo en llaves de hardware y aplícalo mediante atestación donde tu IdP lo admita.
• Recuperación. Aquí es donde todo programa sin contraseñas reintroduce silenciosamente una contraseña. Decide ahora qué sucede cuando el teléfono cae al agua. Lo ideal es que la respuesta sea "una segunda passkey registrada" y, en su defecto, un flujo de verificación de identidad, no una charla amigable con el servicio de asistencia.
• Alternativa y puesta en desuso. Mantén push o TOTP como alternativa solo durante un periodo fijo, registra cada uso de la misma, y revisa ese registro semanalmente. Si un usuario tiene una passkey y aún recibe una notificación push, algo está mal y probablemente sea un atacante.

En el lado de la ingeniería, activa la interfaz condicional (el autocompletado del navegador para passkeys) para que el formulario de inicio de sesión no necesite un botón separado que nadie pulsa, y prueba el inicio de sesión entre dispositivos mediante el flujo de código QR, porque muchos de tus usuarios de escritorio se autenticarán con el teléfono que llevan en el bolsillo.

Cómo convencer a los usuarios

Aquí está la prueba definitiva: si tu despliegue necesita un vídeo de formación, ya has perdido. Las passkeys son el primer control de seguridad en mi carrera que es genuinamente más fácil que lo que reemplaza. Face ID, hecho. Sin código, sin aplicación que abrir, sin "¿recibiste el mensaje?". Empieza por ahí, y registra la passkey en un momento en que el usuario ya esté autenticado y algo aburrido, como justo después de un inicio de sesión exitoso. No fuerces el registro un lunes por la mañana antes del café; compites con su bandeja de entrada, y la bandeja de entrada ganará.

Mide y publica dos cifras: el tiempo medio de inicio de sesión y los tickets del servicio de asistencia por bloqueos. Cuando ambos desciendan, y lo harán, cuéntaselo a la gente. Los usuarios toleran el teatro de la seguridad; les gustan activamente las cosas que les devuelven treinta segundos al día.

Cómo convencer a los directivos

Los directivos no compran criptografía de clave pública. Compran tres cosas: menor probabilidad de brecha, menor coste del servicio de asistencia y no aparecer como protagonistas de un titular. El DBIR de Verizon ha situado las credenciales robadas en lo más alto de los vectores de acceso inicial año tras año, así que el relato de riesgo se escribe solo. Microsoft ha argumentado durante años que MFA bloquea la gran mayoría de los intentos de compromiso de cuentas, y ahora los atacantes han pasado a la parte que MFA no cubre. Presenta las passkeys como el cierre de esa brecha, no como otra novedad reluciente del equipo de seguridad.

Luego haz un piloto con los propios directivos. Dale una passkey al director financiero antes de dársela a ingeniería. Es el capital político más barato que jamás ganarás, y si el director financiero puede iniciar sesión con el pulgar, nadie en la empresa podrá alegar que es demasiado difícil.

Las passkeys no arreglarán tu proceso de incorporación, cambio y baja de empleados, ni tus cuentas de servicio obsoletas ni tu política de restablecimiento en el servicio de asistencia. Corrigen un fallo específico y bien comprendido: el secreto retransmitible. Eso es algo poco común en esta industria, un control que es a la vez más robusto y más agradable. Aprovecha la oportunidad.