Passkeys: la próxima frontera de la autenticación sin contraseñas

Las passkeys están entre los cambios más importantes en la autenticación de consumo de los últimos años. Sustituyen el secreto memorizado por una credencial criptográfica en el dispositivo, ligada a cada sitio o aplicación.

Eso atenúa problemas enormes de las contraseñas—phishing, reutilización, bases robadas—que nacen del secreto compartido. Las passkeys son una primitiva criptográfica más sólida, pero no lo resuelven todo: la UX, la recuperación y los ecosistemas marcan si la gente las adopta de verdad.

Qué son las passkeys

Una passkey se basa en criptografía de clave pública, con WebAuthn y estándares FIDO. Tu dispositivo conserva una clave privada y el servicio solo almacena la clave pública correspondiente.

Al iniciar sesión, el dispositivo demuestra que posee la clave privada firmando un desafío, sin revelarla al sitio como haría una contraseña.

Passkeys sincronizadas y vinculadas al dispositivo

No todas las passkeys se comportan igual. Una passkey sincronizada se copia de forma segura y aparece a través de una plataforma o gestor, como Apple Passwords, Google Password Manager, Windows o un gestor compatible. Eso facilita el uso diario y el cambio de dispositivo.

Una passkey vinculada al dispositivo permanece en un autenticador concreto, por ejemplo una llave de seguridad hardware. Puede ser mejor para administradores y entornos empresariales, pero perdona menos si se pierde el dispositivo y no hay autenticador de respaldo.

La distinción importa para niveles de garantía. NIST SP 800-63B-4 trata los autenticadores sincronizables como útiles y resistentes al phishing en el contexto adecuado, pero AAL3 — el nivel de garantía de autenticación más alto de NIST, pensado para accesos muy sensibles donde hay que resistir con fuerza la suplantación del verificador y la compromisión del autenticador — exige una clave privada no exportable. Las passkeys sincronizadas no encajan en todos los casos de alta garantía.

Por qué son mejores que las contraseñas

• No hay una contraseña compartida que robar de una filtración de base de datos
• Fuerte resistencia al phishing típico que te hace escribir un secreto en una página falsa, porque la credencial queda ligada al origen real
• No hace falta memorizar ni escribir secretos largos en el día a día
• Menos presión para reutilizar la misma credencial en servicios distintos

Flujos típicos (qué ocurre de verdad)

• Registro: el sitio te pide crear una passkey (a veces tras verificar el correo, a veces en ajustes de seguridad). El móvil u ordenador pide Face ID, Touch ID, Windows Hello o un PIN del dispositivo—no para «mandar tu huella a la nube», sino para autorizar el autenticador local. Este genera un par de claves nuevo para ese sitio; solo la clave pública sube al servidor.
• Siguiente inicio de sesión: identificador de cuenta si hace falta, el servicio envía un desafío criptográfico, aceptas el mismo aviso local, el dispositivo firma y el servidor comprueba la firma. No escribes contraseña si el flujo no la exige como respaldo.
• Dispositivo o navegador nuevo: las passkeys sincronizadas pueden reaparecer al entrar en la bóveda de la plataforma (gestor de contraseñas de Apple o Google, o gestor compatible). Sin sincronización, a menudo hace falta otro dispositivo activo, códigos de respaldo o volver a contraseña + MFA hasta volver a registrar—ahí suele aparecer la primera fricción.
• Respaldo: muchos servicios conservan contraseña, enlace mágico o SMS. Ese solapamiento no significa que las passkeys «fallen»: refleja lo difícil que es la recuperación de cuenta sin abrir nuevas vías de fraude.

Ideas falsas habituales

• «El sitio recibe mi huella.» No: la biometría se queda en el dispositivo; el sitio recibe una prueba criptográfica.
• «Las passkeys acaban con el phishing.» Quitan el ataque clásico de «escribes la contraseña en una copia falsa» en flujos solo passkey, pero no todo el engaño ni un móvil ya comprometido.
• «Una passkey es solo MFA.» Una passkey puede cumplir el objetivo de la MFA — prueba ligada a un dispositivo y verificación local del usuario — pero no es lo mismo que contraseña más código de seis cifras. La respuesta criptográfica queda ligada al sitio real.
• «Una passkey abre todo.» Cada proveedor recibe sus propias claves ligadas a su origen; banco y correo no comparten una mega-passkey.
• «Es solo de Apple.» Apple impulsó la UX, pero Google, Microsoft y gestores implementan las mismas normas—la interoperabilidad existe, pero es irregular.
• «Puedo copiar mi passkey a un Excel.» Las passkeys no son secretos legibles para pegar; es deliberado, y choca con décadas de hábito con contraseñas.

La portabilidad está mejorando

Una crítica legítima de los primeros despliegues era el bloqueo de proveedor: si tus passkeys viven dentro de una bóveda de plataforma, ¿cómo las mueves a otra? La FIDO Alliance trabaja en el Credential Exchange Protocol y el Credential Exchange Format para hacer la transferencia más segura e interoperable.

Es un avance importante, pero conviene ser preciso: la portabilidad mejora, no está resuelta igual en todas partes. En 2026 todavía conviene comprobar dónde se guardan tus passkeys, si tu gestor las soporta y qué exportación o recuperación existe antes de depender de un solo proveedor.

Por qué la adopción va más lenta que el bombo

El soporte en estándares y sistemas llegó antes que la comprensión general. Durante décadas la contraseña «era» la cuenta; confiar en claves invisibles, sincronización en la nube o avisos del fabricante suena abstracto cuando algo falla.

En empresas, implementar WebAuthn bien (formatos de attestación, claves residentes, recuperación, guiones de soporte) cuesta más que otro formulario de contraseña. Los equipos pequeños lo posponen; muchas corporaciones siguen exigiendo MFA «clásica» por cumplimiento.

• UX fragmentada: textos y pasos cambian entre Android, iOS, Windows y navegadores—el soporte lo nota.
• Miedo a perder el teléfono: sin copias de seguridad claras, «perdí el móvil» asusta más que «olvidé la contraseña», aunque haya caminos.
• Confianza en la plataforma: a algunas personas no les gusta que las claves pasen por Apple, Google o un gestor—aunque el diseño criptográfico no debería exponer claves privadas.
• Despliegues a medias: passkey en la app pero no en la web (o al revés), y la gente vuelve a la contraseña pensando que «no funciona».

Dónde siguen teniendo límites

• No todos los servicios las admiten, sobre todo herramientas de nicho, software autoalojado y algunos accesos VPN corporativos.
• Pérdida del dispositivo y herencia digital son historias más delicadas que un simple restablecimiento de contraseña.
• Los escenarios entre dispositivos siguen dependiendo de sincronización, llaves físicas o volver a registrar.
• Durante años seguirás usando contraseñas fuertes en muchas cuentas.

Qué significa esto hoy para los usuarios

Usa passkeys cuando un servicio las ofrezca—especialmente en cuentas importantes—porque reducen mucho el robo de contraseña por phishing. Combínalas con un gestor y opciones de recuperación que conozcas.

Cuenta con un mundo mixto durante años: passkeys en algunos accesos, contraseñas generadas en otros, y a veces frustración cuando la implementación está a medias. Esa irregularidad explica la brecha entre el entusiasmo de seguridad y la acogida más tibia del público general.

Lista práctica de configuración

• Crea passkeys primero para correo, gestor de contraseñas, banca, almacenamiento cloud, cuentas de desarrollo y redes sociales que suelen ser objetivo.
• Mantén al menos dos vías de recuperación: otro dispositivo de confianza, una llave hardware, códigos de respaldo o un flujo de recuperación documentado.
• No elimines la contraseña hasta que el servicio admita claramente inicio de sesión solo con passkey y entiendas la recuperación.
• Para cuentas de trabajo, pregunta si la política necesita passkeys sincronizadas, llaves vinculadas al dispositivo o ambas.