En passkeys la aplicación móvil permite sustituir la contraseña por una validación biométrica o un código del dispositivo, sin almacenar ningún secreto reutilizable en el servidor. Para un proyecto móvil, la ventaja es clara: menos fricción al iniciar sesión, menos restablecimientos y una mayor resistencia al phishing. La verdadera cuestión no es la tecnología, sino el despliegue progresivo para no bloquear a los usuarios existentes.
Passkeys en una aplicación móvil: lo que realmente cambia
Una passkey es una clave de acceso basada en criptografía asimétrica (un par de claves, una privada y otra pública). La clave privada permanece en el gestor de credenciales del usuario, por ejemplo iCloud Keychain, Google Password Manager o un gestor de terceros compatible. La clave pública, por su parte, se registra en su servidor.
En la práctica, el usuario ya no introduce su contraseña. Confirma su identidad con Face ID, Touch ID, la huella de Android, el código de bloqueo o un gestor de credenciales. Apple indica que las passkeys están vinculadas a la aplicación o al sitio para los que se han creado, lo que las hace resistentes al phishing. En iCloud Keychain, están cifradas de extremo a extremo.
Este cambio tiene un impacto directo en su presupuesto de support. Los tickets de “contraseña olvidada”, los bloqueos tras varios intentos, las cuentas comprometidas por la reutilización de contraseñas: todo ello disminuye mecánicamente cuando la adopción se gestiona bien. Según la FIDO Alliance, alrededor de 5 mil millones de passkeys estaban en uso activo en el mundo en mayo de 2026, con un 75 % de las personas encuestadas que ya habían activado al menos una passkey.
Pero cuidado con el efecto escaparate. Añadir un botón “Iniciar sesión con una passkey” no basta. Hay que prever las cuentas antiguas, los dispositivos perdidos, los usuarios que cambian de teléfono, los recorridos web y móvil, así como los casos en los que una passkey no está disponible.
Por qué eliminar las contraseñas no es solo una cuestión de seguridad
Para un directivo, la seguridad importa, por supuesto. Pero el interés de las passkeys en una aplicación móvil también se mide en conversión y retención. Cada pantalla de inicio de sesión es un lugar en el que el usuario puede abandonar.
En una aplicación de e-commerce, banca, salud, SaaS o marketplace, un inicio de sesión rápido puede ahorrar unos segundos en cada sesión. Parece algo modesto. A la escala de miles de usuarios activos, a veces es la diferencia entre una experiencia fluida y un carrito abandonado.
La FIDO Alliance señalaba en 2026, por parte de las empresas que habían empezado un despliegue, una mayor confianza en la seguridad, tiempos de inicio de sesión más cortos y una carga de support reducida. Los obstáculos citados siguen siendo muy concretos: compatibilidad con los sistemas historicos y validación presupuestaria. Ahí es exactamente donde la definición del producto importa.
La trampa clásica consiste en tratar la passkey como una funcionalidad aislada. En realidad, afecta a la autenticación, el back-office, el support al cliente, los correos electrónicos transaccionales, las políticas del RGPD y, a veces, incluso los recorridos comerciales. Si su aplicación comparte cuentas con un sitio web o un CRM, la decisión debe tomarse desde la arquitectura.
Para contar con una base sólida, la reflexión debe integrarse en el proyecto móvil global, al mismo nivel que la performance, la accesibilidad o la seguridad de la aplicación. Esto es especialmente cierto en los proyectos iOS/Android, donde las restricciones nativas deben anticiparse desde el diseño de la aplicación móvil.
La experiencia de usuario adecuada: proponer, explicar, tranquilizar
Las passkeys son sencillas cuando ya se entienden. Lo son mucho menos para un usuario que descubre el término en el momento de crear su cuenta. Las directrices de diseño publicadas por la FIDO Alliance en 2024 insisten precisamente en la coherencia de los textos, el momento adecuado para proponerlas y la claridad de las pantallas.
En la práctica, el mejor momento no siempre es el registro. En algunos servicios, es mejor esperar a que el usuario haya completado una primera acción de valor: compra, reserva, solicitud de presupuesto, configuración de un espacio. Entonces comprende alors por qué proteger y acelerar sus próximos inicios de sesión.
Una buena experiencia debe evitar tres errores frecuentes:
- presentar la passkey como una obligación inmediata, alors que una parte del público no está preparada;
- utilizar un vocabulario demasiado técnico, como “clave criptográfica”, sin un beneficio comprensible;
- eliminar demasiado rápido las opciones de respaldo, especialmente para las cuentas antiguas o profesionales.
Google recomienda, en Android, notificar al usuario después de la creación de una passkey y explicarle que puede gestionarla desde su proveedor de credenciales o desde los ajustes de la aplicación. Este detalle es menos trivial de lo que parece. Reduce las inquietudes del tipo “¿dónde se almacena mi acceso?” y limita las solicitudes al support.
Por parte de la agencia, el reflejo es prototipar las pantallas de autenticación antes de iniciar el desarrollo. Una prueba de usuario de 5 a 8 personas suele bastar para detectar las formulations que bloquean. Sinceramente, en esta fase, una hora dedicada a los microtextos ahorra más que un día de correction después de la puesta en producción.
iOS, Android, servidor: los componentes técnicos que hay que prever
En iOS, las passkeys se basan en los mecanismos de Apple en torno a AuthenticationServices y pueden sincronizarse a través de iCloud Keychain o de proveedores externos compatibles. En Android, Google recomienda la API Jetpack Credential Manager para gestionar el intercambio de credenciales en las aplicaciones. En 2026, Credential Manager cubre las passkeys, las contraseñas, el inicio de sesión federado (Google, Apple, etc.), las credenciales digitales, la restauración de credenciales, la compatibilidad con WebView y el autofill (relleno automático).
Lors de la creación de una passkey Android, la clave privada se almacena en un proveedor de credenciales como Google Password Manager, mientras que la clave pública se almacena en el servidor de la aplicación. Por lo tanto, el servidor debe ser capaz de registrar, verificar y revocar estas claves. No se trata solo de un cambio de interfaz.
Un punto técnico merece su atención si planifica una Desarrollo de Android en 2026: Google cita dependencias recientes como androidx.credentials:credentials:1.7.0-alpha02 y androidx.credentials:credentials-play-services-auth:1.7.0-alpha02, al tiempo que señala que las versiones anteriores a la 1.2 pueden provocar una excepción de Android 14. En otras palabras, una aplicación antigua puede requerir una fase de actualización incluso antes de añadir las passkeys.
La portabilidad también avanza. Las notas de Google Play services v26.21 de junio de 2026 indican que los teléfonos Android pueden importer y exporter contraseñas y passkeys entre Google Password Manager y gestores de terceros a través del estándar Credential Exchange. Dashlane también anunció su despliegue en Android en torno a este estándar en febrero de 2026. Para sus usuarios, es una buena noticia: cambiar de herramienta no debería significar perder el acceso.
| Opción de autenticación móvil | Seguridad | Experiencia del usuario | Coste de implantación en Francia | Plazo típico |
|---|---|---|---|---|
| Contraseña + correo electrónico de recuperación | Baja a media, sensible al phishing | Conocida pero frustrante | Incluido o de 1 000 a 3 000 € según lo existente | Algunos días |
| Contraseña + doble autenticación | Buena si está bien configurada | Más larga, sobre todo por SMS | 3 000 à 8 000 € hors costes SMS | 1 a 3 semanas |
| Passkeys con incorporación progresiva | Muy buena, resistente al phishing | Fluida tras la pedagogía inicial | 8 000 à 25 000 € según app, servidor y UX | De 3 a 8 semanas |
| Rediseño completo de la identidad del cliente | Muy buena si se revisa la arquitectura | Homogénea web, móvil, support | 25 000 à 80 000 € y más | 2 a 5 meses |
Estos importes son ordres de magnitud observados en el mercado francés, no una tarifa universal. Una app reciente y bien documentada cuesta menos de evolucionar que una base híbrida antigua con un servidor de autenticación frágil. Con este presupuesto, a veces es mejor asegurar primero el sistema de cuentas antes de añadir una capa visible del lado del usuario.
Desplegar sin perder a sus usuarios existentes
El mal enfoque consiste en eliminar las contraseñas de un día para otro. Aunque el objetivo sea “sin contraseña”, el camino debe seguir siendo reversible durante un tiempo. El UK National Cyber Security Centre recordaba en 2026 que los usuarios deben seguir utilizando contraseñas forts y la verificación en dos pasos lorsque las passkeys no estén disponibles.
Un despliegue prudente empieza por las cuentas nuevas, luego propone la creación de una passkey a los usuarios conectados, y solo después lors de los siguientes inicios de sesión. Las cuentas sensibles pueden ser prioritarias: administradores, vendedores, clientes profesionales, usuarios que almacenan datos personales o financieros. El RGPD ya exige proteger adecuadamente los datos personales; una autenticación más robusta ayuda, pero no sustituye la minimización de datos ni la trazabilidad de los accesos.
En los proyectos que llevamos a cabo, a menudo vemos una confusión entre “supresión de la contraseña” y “supresión de cualquier alternativa”. Es peligroso. Un usuario puede perder su teléfono, cambiar de ecosistema, compartir un dispositivo familiar, usar una flota profesional bloqueada o conectarse desde una WebView integrada.
La estrategia de respaldo debe decidirse antes de la puesta en producción. Puede combinar inicio de sesión por email mágico (enlace temporario), contraseña mantenida durante un tiempo, doble autenticación para las operaciones sensibles o un procedimiento de support reforzado. Los gestores de credenciales que pueden guardar y sincronizar passkeys reducen el riesgo de pérdida de acceso, como recuerda el NCSC, pero no lo eliminan.
Si su aplicación ya se basa en “Iniciar sesión con Apple”, Google Sign-In o un SSO profesional (autenticación centralizada), no lo sustituya todo sin analizarlo. Para ciertos públicos B2B, el SSO sigue siendo más adecuado que las passkeys individuales, especialmente con Microsoft Entra ID u Okta. La solución evidente no siempre es la correcta.
Seguridad, conformidad y costes ocultos que anticipar
Las passkeys reducen fortemente el riesgo de phishing, porque el identificador criptográfico está vinculado al servicio legítimo. Un sitio falso no puede simplemente recuperar una contraseña y reutilizarla en otro lugar. Es un avance importante para las aplicaciones expuestas al fraude, a las cuentas comprometidas o a los ataques de credential stuffing (intentos masivos con credenciales robadas).
El asunto no termina ahí. Hay que registrar las creaciones y eliminaciones de passkeys, prever la revocación en caso de sospecha, documentar los recorridos de recuperación y formar al support. Un agente de support que “restablece el acceso” con demasiada facilidad puede arruinar una buena arquitectura.
Los costes ocultos suelen venir de lo existente: API de autenticación antigua, base de usuarios mal normalizada, ausencia de entorno de pruebas, aplicación Android no actualizada o webview que no respeta los comportamientos modernos de Credential Manager. También puede ser necesaria una revisión de seguridad móvil si la app maneja datos sensibles; las vulnerabilidades de la aplicación siguen siendo un tema por derecho propio, como muestran regularmente los incidentes de seguridad en infraestructuras expuestas.
Para una aplicación de gran consumo, prevea también un presupuesto de producto: wording, pantallas de ayuda, correos electrónicos, analytics, support de nivel 1. Para una aplicación de negocio, añada la gestión del cambio y la compatibilidad de las flotas. Las notas de Google Play services v26.19 de mayo de 2026 incluso amplían Credential Manager a los dispositivos Automotive, con contraseñas y passkeys guardadas y la posibilidad de utilizar un teléfono para la autenticación mediante passkey. Este tipo de evolución muestra que la identidad móvil va más allá del solo smartphone.
Si su roadmap incluye una revisión más amplia, la cuestión de las passkeys puede estar vinculada a la arquitectura web y móvil, al alojamiento, al cifrado e incluso a la estrategia de certificados. Para las organizaciones que ya anticipan las próximas evoluciones de seguridad, el tema se une de forma natural a las reflexiones sobre la criptografía poscuántica y la vida útil de las protecciones actuales.
Cuándo las passkeys realmente merecen la inversión
Las passkeys para aplicación móvil se justifican fortemente en cuanto una cuenta tiene valor: datos personales, historico de compra, documentos, medios de pago, espacio profesional, funcionalidades de pago. También son pertinentes cuando sus estadísticas muestran muchos fallos de inicio de sesión o restablecimientos de contraseña.
Por el contrario, para una aplicación de eventos con una vida útil muy corta, un prototipo o un servicio sin cuenta sensible, la inversión puede ser prematura. Un enlace mágico por correo electrónico o un inicio de sesión social puede bastar temporariamente. Sinceramente, esta tecnología solo se justifica si mejora un recorrido real, no para marcar la casilla de innovación.
La buena decisión consiste en medir tres cifras antes de decidir: tasa de fallo de inicio de sesión, volumen de tickets relacionados con los accesos y proporción de usuarios que vuelven varias veces al mes. Si estos indicadores son altos, las passkeys pueden amortizar parte de su coste gracias a la reducción del support y a la mejoración de la conversión. Si no dispone de estos datos, empiece por instrumentarlos.
La implementación debe seguir siendo coherente con su ecosistema. Una aplicación iOS muy utilizada, un sitio WordPress del cliente, un back-office Laravel o Node.js, una infraestructura OVH o Cloudflare: cada pieza influye en la elección. Las passkeys no son un módulo mágico que se añade al final, sino una evolución de la identidad digital del servicio.
Definir este tipo de proyecto de antemano evita la mayoría de las malas sorpresas: elección del recorrido, compatibilidad iOS/Android, estrategia de respaldo, impactos en el servidor, support y presupuesto. A menudo es ahí donde una mirada externa ahorra tiempo, sobre todo cuando la aplicación ya existe y las cuentas de usuario no pueden ponerse en riesgo.
Preguntas frecuentes sobre las passkeys en una aplicación móvil
¿Se pueden sustituir totalmente las contraseñas por passkeys?
Sí, pero rara vez desde el primer despliegue. Es preferible ofrecer las passkeys de forma progresiva, con un método de recuperación fiable para los usuarios que pierden un dispositivo o no tienen todavía un gestor compatible.
¿Funcionan las passkeys en iPhone y Android?
Sí. Apple las admite a través de su ecosistema passkeys, en particular iCloud Keychain, y Android recomienda Credential Manager para las aplicaciones móviles. Los detalles de implementación cambian según la versión de la app y los proveedores de credenciales.
¿Cuánto cuesta añadir passkeys a una aplicación móvil?
En Francia, una incorporación progresiva suele costar a menudo entre 8 000 y 25 000 € según el estado de la aplicación, del servidor y de los recorridos UX. Una revisión completa de la identidad del cliente puede superar los 25 000 €.
¿Qué ocurre si el usuario pierde su teléfono?
Las passkeys pueden ser guardadas y sincronizadas por gestores de credenciales, lo que reduce el riesgo de perder el acceso. Aun así, es necesario prever un procedimiento de recuperación controlado para evitar bloqueos y suplantaciones.