Los passkeys sustituyen la contraseña por una clave criptográfica que vive en el móvil o en el gestor de contraseñas del navegador, y ya la aceptan Chrome, Safari, Edge y Firefox desde hace varios años. Para una empresa que gestiona el acceso de clientes o empleados a su web —una tienda online, un SaaS, un panel de cliente— la pregunta ya no es si funcionan, sino cómo se integran sin dejar fuera a quien todavía no los tiene activados.
No: los passkeys resuelven el acceso del día a día, pero ninguna implementación seria retira la contraseña del todo. La propia documentación de la Web Authentication API recomienda mantenerla como alternativa para el dispositivo perdido, el navegador antiguo o la recuperación de cuenta, mientras las empresas migran el grueso de los accesos.
Cómo funcionan los passkeys en el navegador
Un passkey no es una contraseña más larga ni una app de autenticación: el navegador genera un par de claves ligado al dominio exacto de la web, guarda la privada cifrada en el dispositivo o en la nube del gestor de contraseñas, y solo envía la pública al servidor. Ese vínculo con el dominio es lo que impide que una web de phishing la reutilice, aunque copie el diseño del login al pixel.
Un passkey es una credencial de clave pública ligada a un dominio concreto: el servidor guarda la pública, el dispositivo guarda la privada, y sin esta última ninguna copia de la primera permite iniciar sesión.
Registro y verificación, los dos únicos endpoints
Del lado del servidor, implementar passkeys se reduce a dos rutas: una que registra la credencial cuando el usuario la activa por primera vez, y otra que la verifica en cada inicio de sesión. Librerías como SimpleWebAuthn en Node, o las que ya integran frameworks como Laravel a través de paquetes de WebAuthn, cubren la parte criptográfica que exige el estándar WebAuthn; conviene además revisar los riesgos habituales de la seguridad en APIs antes de exponer ambos endpoints. El trabajo real está en decidir qué pasa con quien entra desde un navegador que aún no soporta la función y en enlazar la credencial con la cuenta ya existente del cliente, no en crear una cuenta nueva.
Qué gana tu empresa con la verificación biométrica
El argumento de seguridad pesa tanto como el de conversión. Al no viajar ningún secreto compartido entre servidor y usuario, una filtración de la base de datos de credenciales no sirve para iniciar sesión en ningún sitio: solo hay claves públicas, y sin la privada del dispositivo son inútiles. Eso corta de raíz el reciclaje de contraseñas filtradas en otro servicio, la vía de entrada más común en los incidentes que llegan a soporte. Según el informe State of Passkeys 2026 de FIDO Alliance, elaborado por Sapio Research entre 11.000 consumidores y 1.400 responsables de decisión en diez países, ya hay 5.000 millones de passkeys en uso y el 68% de las organizaciones los tiene desplegados o en despliegue activo para el acceso de su plantilla. El 82% se plantea la autenticación sin contraseña como objetivo final, aunque solo el 28% la ha alcanzado por completo.
Por qué la contraseña sigue haciendo falta
La Web Authentication API es, según su propia documentación técnica, de disponibilidad amplia desde septiembre de 2021: no es una tecnología emergente, es la base sobre la que ya corren los passkeys en cualquier navegador actualizado. Pero disponibilidad amplia no es cobertura total, y una empresa no puede permitirse que un cliente con un navegador desactualizado, un móvil corporativo antiguo o una cuenta compartida entre varias personas se quede sin forma de entrar.
Qué pasa si se pierde el dispositivo
Apple, Google y Microsoft sincronizan los passkeys entre los dispositivos vinculados a la misma cuenta de iCloud, Google o Microsoft, así que perder el móvil no borra la credencial mientras el usuario conserve el acceso a esa cuenta. El problema aparece cuando pierde las dos cosas a la vez, o cuando la cuenta es compartida por varias personas del mismo departamento, algo habitual en pymes con un único usuario de gestión para varias herramientas. Ahí la recuperación necesita un segundo canal —contraseña, correo verificado o un código que entrega soporte— y ese canal hay que diseñarlo con el mismo cuidado que el propio passkey, porque es la puerta trasera que un atacante buscará primero.
¿Te ayudamos con esto?
Cuéntanos tu caso
Si esto te afecta, escríbenos en dos líneas y te respondemos por email con una valoración concreta.
Checklist técnico antes de activar passkeys
Antes de tocar el formulario de login conviene auditar qué flujos de acceso tiene realmente la web y cuál de ellos merece el cambio primero. No es lo mismo el acceso puntual a un blog que el login diario de un panel de cliente o el checkout de una tienda online. Repasar esto con una auditoría web ayuda a priorizar antes de escribir una línea de código.
- Qué formularios de login existen: cliente final, panel de administración, API de terceros.
- Si el CMS o el framework ya trae un paquete de WebAuthn mantenido o hay que integrarlo a mano mediante desarrollo de software a medida.
- Qué pasa con las sesiones abiertas de clientes que aún no han activado ningún passkey.
- Cómo queda registrado el cambio de método de acceso, de cara a una auditoría de seguridad informática posterior.
- Si hay app móvil nativa además de la web: ahí el calendario de trabajo se alarga una semana más.
Cuándo compensa activar la clave de acceso
Compensa primero donde el volumen de inicios de sesión es alto y el coste de un fallo también: el panel de cliente de un SaaS, el checkout con cuenta de una tienda online, el acceso de la plantilla a herramientas internas. En un ecommerce barcelonés con alta rotación de altas de cliente, cada fricción en el login se traduce en carritos abandonados; sustituir la contraseña por una verificación biométrica del propio móvil reduce esa fricción sin bajar la seguridad, más bien al contrario. Donde compensa menos es en una web informativa con un único acceso de administrador: ahí el cambio no toca la experiencia de ningún cliente y el esfuerzo de desarrollo rinde menos. La decisión, en todo caso, no es binaria: se puede empezar por un solo flujo, medir la adopción real entre los usuarios —el informe de FIDO Alliance sitúa el uso habitual en el 49% de quienes tienen un passkey activado, no en el 100%— y ampliar después. Ya vimos en un análisis anterior que este cambio de login sube la conversión hasta un 30%, así que el retorno no es solo de seguridad.
Preguntas frecuentes sobre passkeys
¿Un passkey sustituye a la autenticación en dos pasos?
No siempre. Un passkey ya combina algo que el usuario tiene (el dispositivo) con algo que es (huella o cara) o sabe (el PIN del móvil), así que cumple el mismo objetivo que el segundo factor. Muchas empresas lo tratan como sustituto completo del 2FA; otras lo mantienen como capa adicional en operaciones de alto riesgo, como un cambio de datos bancarios.
¿Qué pasa si un cliente cambia de móvil?
Si el nuevo dispositivo usa la misma cuenta de Apple, Google o Microsoft que el anterior, el passkey se sincroniza solo y el cliente no nota el cambio. Si estrena cuenta o cambia de ecosistema, tiene que volver a registrar la credencial desde la web, con el mismo flujo de alta que usó la primera vez.
¿Los passkeys funcionan en todos los navegadores?
En los actualizados sí: Chrome, Safari, Edge y Firefox lo soportan desde hace varias versiones y el estándar WebAuthn lleva disponible de forma amplia desde 2021. El riesgo no está en el navegador sino en versiones muy antiguas sin actualizar, sobre todo en parque de equipos corporativo, donde conviene comprobarlo antes de retirar la contraseña.
¿Cuánto tarda una empresa en implementarlo?
Depende de si el CMS o el framework ya trae un paquete de WebAuthn mantenido: si lo trae, es cuestión de días para el flujo web. Si hay que integrarlo desde cero y cubrir además una app móvil nativa, el desarrollo se mide en semanas, no en días, sobre todo por las pruebas en distintos dispositivos.
