En passkeys los sitios web no deben sustituir todos sus contraseñas de la noche a la mañana en 2026. El enfoque adecuado consiste más bien en proponerlas como método de inicio de sesión principal, manteniendo temporariamente las contraseñas y la autenticación en dos factores para los usuarios que no estén preparados. Beneficio esperado: menos phishing, menos supporte relacionado con contraseñas olvidadas, pero un proyecto que debe definirse seriamente por el lado de experiencia del usuario y seguridad.
Passkeys para sitios web: lo que realmente cambia para su proyecto
Una passkey es una clave de acceso sin contraseña, basada en FIDO2 y WebAuthn, el estándar web utilizado por los navegadores modernos. En la práctica, su sitio almacena una clave pública, mientras que la clave privada permanece con el usuario, en su dispositivo o en su gestor de passkeys como iCloud Keychain, Google Password Manager, Windows Hello, 1Password o Dashlane.
La diferencia con una contraseña es simple: no se introduce nada secreto en un formulario. El usuario valida su acceso con su huella, su rostro, el código de su dispositivo o una llave de seguridad. Después, el sitio verifica una firma criptográfica, es decir, una prueba matemática de que se ha utilizado la clave privada correcta.
Para un directivo, el interés no es teorrico. Las passkeys reducen fortemente el riesgo de phishing, porque el identificador criptográfico está vinculado al dominio del sitio, por ejemplo votresite.fr. Si un pirata crea una página de inicio de sesión falsa en otro dominio, la passkey no funciona como en el sitio real.
En mayo de 2026, la FIDO Alliance estimaba en 5 mil millones el número de passkeys en uso activo en el mundo. Es masivo, pero no es una adopción universal. La misma comunicación hablaba de una etapa, no de una línea de meta. En otras palabras: el tema está maduro, no es mágico.
Por qué las passkeys reducen los riesgos sin resolverlo todo
El principal beneficio de las passkeys para sitios web reside en su resistencia al phishing. El NIST, en SP 800-63B-4 publicado en 2025, recuerda que las contraseñas no son resistentes al phishing, mortras que los autenticadores FIDO/WebAuthn forman parte de los métodos de MFA resistentes. MFA significa autenticación multifactor: varias pruebas para iniciar sesión.
Esta seguridad proviene del propio funcionamiento de WebAuthn. En cada inicio de sesión, el servidor genera un desafío temporario, llamado challenge. El navegador transmite este desafío al autenticador del usuario, que lo firma con la clave privada. Después, el servidor verifica la origen del sitio, el RP ID (la identidad del servicio), los indicadores de verificación del usuario y la firma.
Dicho de otro modo, no es solo un botón más moderno. Es una arquitectura de inicio de sesión diferente. Limita las contraseñas reutilizadas, las bases de datos de contraseñas robadas, los ataques de phishing y parte de las llamadas al supporte.
Pero no elimina todos los riesgos. Una mala implementación puede crear cuentas bloqueadas, recorridos incomprensibles o fallos en torno a la recuperación de cuenta. En los proyectos que llevamos a cabo, vemos a menudo que la recuperación de acceso está menos pensada que el registro. Sin embargo, es ahí donde los usuarios entran en pánico, sobre todo en B2B.
Sustituir las contraseñas: sí, pero rara vez en una sola etapa
Google recomienda encore, en sus guías para desarrolladores de 2025, mantener los mecanismos existentes como las contraseñas y el 2FA durante la transición. La razón es pragmática: no todos los usuarios entienden las passkeys, no todos los entornos las autorizan encore, y algunos dispositivos profesionales siguen bloqueados por el departamento de TI.
Para un sitio de comercio electrónico, una extranet de clientes o una plataforma SaaS, la estrategia más segura es progresiva. Primero añade las passkeys como opción después de un inicio de sesión clásico. Luego fomenta su creación. Solo después las destaca como método predeterminado para los usuarios compatibles.
La trampa frecuente consiste en creer que “sin contraseña” significa “sin fricción”. En realidad, el primer registro de una passkey debe ir acompañado: mensaje claro, dispositivo utilizado, método de respaldo, explicación breve. Una etiqueta confusa como “crear una clave de acceso” puede hacer caer la adopción si su audiencia no es tecnófila.
Caso típico en el que la solución evidente es mala: imponer las passkeys a todos los clientes de un portal B2B desde el primer inicio de sesión. Si sus usuarios se conectan desde puestos compartidos, entornos Citrix, navegadores antiguos o smartphones no gestionados, corre el riesgo de trasladar el problema al supporte. Con ese presupuesto, más vale una migración guiada que un cambio brusco.
Presupuesto, plazos y arbitrajes para una pyme francesa
El coste depende menos de la propia passkey que de su sistema de autenticación actual. Un sitio WordPress sencillo con cuentas de cliente, una aplicación Laravel, un back-office Symfony o una plataforma React/Node.js no tienen el mismo nivel de deuda técnica. El término designa aquí el coste acumulado por las decisiones pasadas.
Para dar un orden de magnitud honesto en el mercado francés, la incorporación de passkeys en un sitio existente suele empezar en torno a 4 000 a 8 000 euros sin IVA si la autenticación es limpia y está bien documentada. Para una aplicación empresarial con roles, SSO, móvil, auditoría de seguridad y escenarios de recuperación, se ven más bien presupuestos de 12 000 a 30 000 euros sin IVA según los proveedores.
Los plazos siguen la misma lógica. Una prueba de concepto puede hacerse en una o dos semanas. Una puesta en producción seria lleva más bien de cuatro a ocho semanas, porque hay que probar los navegadores, los dispositivos, los emails de recuperación, los casos de pérdida del teléfono, las cuentas ya existentes y los registros de seguridad.
| Proyecto | Plazo realista | Presupuesto orientativo Francia | Puntos a tener en cuenta |
|---|---|---|---|
| Incorporación de passkeys en un área de cliente sencilla | 2 à 4 semanas | 4 000 a 8 000 € sin IVA | Compatibilidad del navegador y mensajes para el usuario |
| Plateforma SaaS con roles y 2FA | 4 a 8 semanas | 10 000 a 20 000 € sin IVA | Migración de las cuentas existentes y supporte |
| Aplicación web + móvil iOS/Android | 6 a 12 semanas | 15 000 a 35 000 € sin IVA | Coherencia entre WebAuthn, Android, iOS y recuperación |
| Rediseño completo de la autenticación | 8 a 16 semanas | 25 000 € sin IVA y más | Arquitectura, RGPD, auditoría, SSO, supervisión |
Estas cantidades no sustituyen a un presupuesto, pero evitan un malentendido: las passkeys no son solo un plugin que activar. Afectan al inicio de sesión y, por tanto, a la facturación, a los datos personales y a la confianza. Para un sitio de bajo riesgo, la inversión puede esperar. Para un área de cliente que maneja facturas, datos de RR. HH. o información médica, el criterio cambia rápidamente.
Qué hay que comprobar antes de poner en marcha el proyecto
Antes de pedir un presupuesto, cartografíe los usos reales. ¿Quién se conecta? ¿Desde qué dispositivos? ¿Con qué frecuencia? ¿Con qué permisos? Un administrador que modifica coordenadas bancarias no tiene el mismo nivel de riesgo que un lector ocasional de contenido premium.
Su alojamiento y sus capas de seguridad también cuentan. Un sitio detrás de Cloudflare, con TLS correctamente configurado, registros de acceso y protección antibot, parte de una base mejor que una aplicación antigua expuesta directamente. Las cuestiones de certificados y cifrado se unen, además, a temas más amplios como la migración de los certificados SSL frente a la criptografía poscuántica.
Estos son los criterios que hay que dejar por escrito antes de desarrollar:
- Definir las cuentas afectadas con prioridad: administradores, clientes, socios, colaboradores.
- Prever un método de recuperación sólido en caso de pérdida del dispositivo o de salida de un empleado.
- Conservar temporariamente las contraseñas o la 2FA para los casos no compatibles.
- Probar Chrome, Safari, Edge, Firefox, iOS, Android, Windows Hello y macOS según su audiencia.
- Documentar los tratamientos de datos personales en el marco del RGPD, en particular los registros de conexión.
- Formar al supporte al cliente con guiones sencillos, porque las primeras preguntas serán muy concretas.
Los iframes merecen una mención. En 2026, web.dev recuerda que los navegadores desactivan WebAuthn por defecto en los iframes cross-origin, es decir, integrados desde otro dominio, debido a riesgos como el clickjacking o los iframes ocultos. Si su proceso de pago, de SSO o de registro se basa en integraciones externas, este detalle puede bloquear el proyecto.
Impacto en la experiencia de usuario y la conversión
Una passkey bien integrada acelera el inicio de sesión. En móvil, el usuario valida con Face ID, Touch ID, Android Biometrics o el código del dispositivo. Ya no tiene que volver a encontrar una contraseña, esperar un correo electrónico o copiar un código SMS.
Aun así, la conversión depende del momento en que proponga la passkey. Pedirla demasiado pronto puede inquietar. Proponerla justo después de un inicio de sesión correcto, con una frase corta del tipo “Conéctese más rápido la próxima vez”, suele funcionar mejor. Sinceramente, esta tecnología solo se justifica si el proceso es más sencillo que el anterior.
La otra decisión se refiere a la identidad de marca y a las interfaces nativas. Las ventanas de creación de passkey están controladas por el navegador o el sistema operativo. No controla todo el diseño. Para un proyecto móvil, también hay que alinear esta experiencia con las convenciones de iOS y Android; algunas elecciones de interfaz coinciden con las reflexiones realizadas sobre la adopción de los nuevos códigos visuales de iOS en la web.
Desde el lado de la agencia, el reflejo es prototipar el recorrido antes de codificar toda la arquitectura. Tres pantallas probadas con algunos usuarios reales evitan a veces dos semanas de desarrollo mal orientado. Simple. Pero rara vez se hace lo bastante pronto.
¿Hay que elegir una solución existente o desarrollar WebAuthn por cuenta propia?
Existen dos vías. Puede utilizar un proveedor de identidad como Auth0, Okta, Microsoft Entra ID, Firebase Authentication o Amazon Cognito cuorndo se adore a su arquitectura. También puede integrar WebAuthn directamente en su backend, con bibliotecas mantenidas para Node.js, PHP, Python, Java o Go.
La solución externa reduce el riesgo técnico y acelera el lanzamiento. A cambio, añade un coste recurrente, una dependencia del proveedor y, a veces, una rigidez en la experiencia. El desarrollo interno da más control, pero exige una verdadera competencia en seguridad: challenge del servidor, verificación de origen, almacenamiento de las claves públicas, contadores, revocación, auditoría.
Para una pyme, la decisión rara vez se toma por la belleza técnica. Se toma por el riesgo de negocio. Si la autenticación no es su diferenciación, un proveedor reconocido puede ser una opción racional. Si su plataforma gestiona reglas complejas, unas aplicaciones móviles y un SI interno, una integración dominada pasa a ser más defendible.
Esta elección suele formar parte de una reflexión más amplia sobre la arquitectura del sitio, los frameworks y la explotación. Las decisiones técnicas en torno a JavaScript, por ejemplo, también pueden influir en el mantenimiento, como muestra la elección entre Bun, Deno y Node.js para un proyecto web en 2026. Y si parte de una renovación completa, la definición del proyecto con una agencia local para la creación de sitios web ayuda a conectar seguridad, presupuesto y objetivos comerciales.
Las passkeys de Apple han contribuido mucho a popularizar el tema entre el gran público; para un recordatorio historico útil, la evolución de la función Passkey de Apple muestra bien cómo el acceso sin contraseña ha pasado de ser una promesa a un uso habitual.
Definir este tipo de proyecto de antemano evita la mayoría de las malas sorpresas: elección de migración, mensajes para los usuarios, seguridad de recuperación, compatibilidad con lo existente. A menudo es ahí donde una mirada externa ahorra tiempo, sobre todo cuando el inicio de sesión condiciona directamente la facturación o el acceso a datos sensibles.
Preguntas frecuentes sobre las passkeys para sitios web
¿Las passkeys sustituyen totalmente a las contraseñas en 2026?
No está #trp-gettext para la majoridad de los sitios. Las passkeys pueden convertirse en el método principal, pero se sigue recomendando mantener un modo de inicio de sesión de respaldo durante la transición.
¿Puede un sitio WordPress utilizar passkeys?
Sí, siempre que se utilice una extensión fiable o un desarrollo adaptado al sistema de cuentas. Para un sitio escaparate sin espacio para miembros, el interés es limitado; para un espacio de cliente o de administrador, la mejora de seguridad puede ser real.
¿Las passkeys son compatibles con todos los navegadores?
Los principales navegadores modernos los admiten, en particular Chrome, Safari, Edge y Firefox según las plataformas. Aun así, hay que comprobar su audiencia real, especialmente en un entorno profesional restringido.
¿Qué pasa si un usuario pierde su teléfono?
Puede recuperar sus passkeys a través de su cuenta Apple, Google, Microsoft o su gestor, según la configuración. Su sitio también debe prever un procedimiento de recuperación seguro; de lo contrario, el support se convertirá en el punto débil.
¿Las passkeys bastan para cumplir con el RGPD?
No. Mejoran la seguridad del acceso, pero el RGPD también abarca la minimización de los datos, los plazos de conservación, los derechos de las personas y la documentación de los tratamientos.