Passkeys explicadas: el salto más allá de las contraseñas

Las contraseñas nos han fallado durante treinta años, y ninguna regla de complejidad lo ha cambiado. La gente las reutiliza, las páginas de phishing las roban, y cada semana se filtran bases de datos llenas de ellas. Las passkeys son la respuesta del sector, y en 2026 han pasado de ser una idea prometedora a un valor predeterminado que Apple, Google y Microsoft impulsan ahora en miles de millones de dispositivos. Esta guía explica qué es realmente una passkey, las concesiones que encontrarás y un plan práctico para añadirlas a tu producto.

Qué es realmente una passkey

Una passkey es una credencial de inicio de sesión basada en criptografía de clave pública en lugar de un secreto compartido. Cuando un usuario crea una, su dispositivo genera un par de claves. La clave privada permanece bloqueada en el dispositivo, protegida por la misma biometría o PIN que desbloquea el teléfono o el portátil. La clave pública va a tu servidor. No hay contraseña que escribir, ningún secreto guardado en tu base de datos, y nada que una página de inicio de sesión falsa pueda capturar.

La base técnica es el estándar WebAuthn del W3C combinado con los protocolos FIDO2. No necesitas memorizar las siglas, pero ayuda conocer los roles:

• El autenticador es el elemento que guarda la clave privada. Puede ser el teléfono, el portátil o una llave de seguridad de hardware como una YubiKey.
• La parte que confía (relying party) es tu aplicación, identificada por su dominio. Este vínculo con tu dominio exacto es lo que hace que las passkeys sean resistentes al phishing.
• La ceremonia es el intercambio en el que tu servidor envía un desafío, el dispositivo lo firma con la clave privada y tu servidor verifica la firma con la clave pública almacenada.

Como la credencial está vinculada criptográficamente a tu dominio, una passkey creada para yourbank.com simplemente no se ofrecerá en yourbank-login.co. El sitio imitador del atacante nunca ve nada que pueda reutilizar. Esa sola propiedad elimina la categoría más grande de robo de cuentas que vemos en la práctica.

Passkeys sincronizadas frente a passkeys ligadas al dispositivo

Existen dos variantes, y elegir entre ellas es una verdadera decisión de diseño.

Las passkeys sincronizadas se respaldan en un llavero en la nube, como iCloud Keychain, Google Password Manager, o un gestor de terceros como 1Password o Bitwarden. El usuario puede crear una passkey en su teléfono y usarla en su portátil momentos después. Es la opción más amigable para el consumidor y la que impulsa la adopción, porque perder un dispositivo no te deja fuera.

Las passkeys ligadas al dispositivo nunca abandonan el hardware en el que se crearon. Una llave de seguridad de hardware es el ejemplo clásico. Son más robustas para escenarios de alta garantía (piensa en consolas de administración, finanzas, salud) porque la clave privada físicamente no se puede copiar, pero exigen un plan de recuperación, ya que una llave perdida significa una credencial perdida.

La mayoría de los productos de consumo deberían liderar con passkeys sincronizadas y ofrecer las llaves ligadas al dispositivo como opción de refuerzo para las cuentas sensibles.

Por qué las passkeys superan a las contraseñas e incluso a la MFA clásica

Vale la pena ser específico sobre las ventajas, porque "más seguro" por sí solo no justifica el tiempo de ingeniería.

1. Resistencia al phishing por diseño. La credencial solo funciona en el dominio real. Esto cierra el ataque que derrota a los códigos SMS e incluso a la mayoría de las apps de autenticación.
2. Nada reutilizable que robar. Tu servidor almacena claves públicas. Una brecha en la base de datos filtra datos inútiles para un atacante, lo que cambia tu perfil de riesgo y tus obligaciones de divulgación.
3. Ningún secreto compartido en tránsito. No hay contraseña cruzando la red que interceptar, ni relleno de credenciales (credential stuffing), porque no existe ninguna lista de contraseñas que rellenar.
4. Inicio de sesión más rápido. Un escaneo facial o una huella dactilar superan a escribir una contraseña y luego copiar un código de una segunda app. Según nuestra experiencia, la conversión en el paso de inicio de sesión suele mejorar una vez que baja la fricción.
5. Menor carga de soporte. Los restablecimientos de contraseña son uno de los tickets más frecuentes de cualquier producto. Las passkeys eliminan discretamente una gran parte de ellos.

Las passkeys no sustituyen a un programa de seguridad completo. Encajan dentro de uno. Si estás pensando en la identidad de forma más amplia, se integran de manera natural en el modelo que describimos en la arquitectura de confianza cero explicada, donde una identidad fuerte es la base de cada decisión de acceso.

Las concesiones que nadie menciona en la presentación

Las passkeys son excelentes, pero implementarlas bien significa ser honesto sobre las asperezas.

• La recuperación de cuenta es ahora el problema difícil. Has trasladado el riesgo de "la contraseña es víctima de phishing" a "el usuario pierde el acceso a su autenticador." Tu flujo de recuperación se convierte en la parte más sensible del sistema en materia de seguridad, porque es el nuevo camino que un atacante buscará.
• La historia entre ecosistemas sigue siendo desigual. Mover una passkey sincronizada de una cuenta de Apple a una cuenta de Android aún no es fluido. Los usuarios que viven dentro de un solo ecosistema están bien. Los que combinan dispositivos a veces se confunden.
• La gestión de dispositivos empresariales añade restricciones. Los portátiles gestionados, las estaciones de trabajo compartidas y los navegadores bloqueados pueden complicar dónde se permite sincronizar las passkeys.
• No puedes eliminar las contraseñas el primer día. Durante una transición larga ejecutarás ambas, lo que significa dos rutas de código y dos conjuntos de casos límite que probar.
• El lenguaje de la experiencia de usuario es poco familiar. Muchos usuarios nunca han oído la palabra passkey. Un texto claro y buenas alternativas importan tanto como la criptografía.

Ninguno de estos puntos debería detenerte. Simplemente pertenecen a tu plan y no a una sorpresa posterior al lanzamiento.

Una lista de verificación práctica para el despliegue

Esta es la secuencia que seguimos cuando añadimos passkeys al producto de un cliente. Recórrela en orden en lugar de saltar a la parte emocionante.

1. Audita tu autenticación actual. Documenta cada ruta de inicio de sesión: web, móvil, API, administración y cualquier flujo heredado. No puedes añadir un método nuevo con limpieza hasta que conozcas cada puerta que ya existe.
2. Añade passkeys junto a las contraseñas, no en su lugar. Ofrece primero la creación de passkeys como una mejora en la página de seguridad de la cuenta. Deja que los usuarios dispuestos opten mientras todos los demás siguen trabajando.
3. Implementa WebAuthn con una biblioteca mantenida. No construyas la ceremonia a mano. Usa una biblioteca de servidor bien respaldada (por ejemplo SimpleWebAuthn en el ecosistema de Node) y un SDK de plataforma de confianza en móvil. Este es un ámbito donde reinventar la rueda invita a errores de seguridad sutiles.
4. Admite la interfaz condicional (autofill). Deja que el navegador muestre la passkey en el campo de nombre de usuario para que quienes regresan inicien sesión con un solo toque. Este único detalle impulsa la mayor parte de la ganancia de adopción.
5. Diseña la recuperación antes del lanzamiento. Decide tu ruta de respaldo: una segunda passkey, una verificación reforzada por correo o teléfono, códigos de recuperación, o un proceso asistido por soporte con comprobaciones de identidad. Escribe el modelo de amenaza de cada una.
6. Limita la tasa y registra las ceremonias. Trata el registro y la autenticación como eventos sensibles. Alerta sobre anomalías igual que lo harías con los restablecimientos de contraseña.
7. Invita a los usuarios existentes en el momento adecuado. Tras un inicio de sesión con contraseña exitoso, ofrece crear una passkey "para un inicio de sesión más rápido y seguro la próxima vez." Las indicaciones contextuales convierten mucho mejor que un banner que nadie lee.
8. Mide y luego ajusta. Haz seguimiento de la adopción de passkeys, la tasa de éxito de inicio de sesión y los tickets de soporte. Una vez que la adopción en una cuenta sea saludable, puedes plantearte hacer las contraseñas opcionales para esos usuarios.

Si estás construyendo el backend en torno a esto, el mismo cuidado se aplica a cómo expones los endpoints. Nuestras notas sobre el diseño de API que los desarrolladores adoran abordan la claridad y la disciplina de versionado que mantienen una superficie de autenticación mantenible a medida que crece.

Errores de implementación comunes

Unos pocos patrones causan la mayor parte de los problemas que vemos en las revisiones.

• Tratar la passkey como toda la historia de seguridad. Protege el inicio de sesión. No corrige una gestión de sesiones débil, la falta de límites de tasa o un flujo inseguro de correo de recuperación.
• Olvidar el ID de la parte que confía (relying party ID). Configurar mal el vínculo con el dominio es el error más frecuente, y o bien rompe el inicio de sesión o, peor aún, debilita la protección contra phishing por la que viniste.
• Ningún plan para dispositivos perdidos. Lanzar sin un flujo de recuperación garantiza una oleada de usuarios bloqueados la primera vez que alguien cambia de teléfono.
• Omitir el registro de auditoría. Si no puedes ver cuándo y dónde se registraron las passkeys, no podrás investigar una sospechosa más adelante.
• Suponer que todo usuario está listo. Mantén una alternativa clara y ayuda en lenguaje sencillo. La adopción es una curva, no un interruptor.

Cómo puede ayudar Innovation T

En Innovation T construimos y protegemos los sistemas que están detrás del cuadro de inicio de sesión. Cuando un cliente pide un inicio de sesión sin contraseña, no nos limitamos a conectar WebAuthn y marcharnos. Trazamos el mapa de la superficie de autenticación existente, diseñamos un flujo de recuperación que resiste ante un modelo de amenaza real, implementamos las ceremonias con bibliotecas mantenidas y sometemos el resultado a pruebas de estrés. Si ya usas contraseñas, planificamos una migración por etapas que añade passkeys sin romper a un solo usuario existente.

Las passkeys son un control dentro de un cuadro más amplio, por eso solemos combinar el trabajo con una revisión más extensa. Una auditoría de seguridad enfocada para tu sitio web te dice dónde encaja la autenticación entre tus riesgos reales, y dónde la próxima hora de ingeniería rinde más.

Si quieres una autenticación sin contraseña que tus usuarios realmente disfruten y tus auditores realmente aprueben, explora nuestros servicios de ingeniería de software y en la nube o ponte en contacto. Te ayudaremos a decidir qué construir, en qué orden y cómo lanzarlo de forma segura.