Introducción

Perder el teléfono no debería convertirse en perder una cuenta. Al sustituir contraseñas por passkeys conviene entender dos recorridos: el acceso habitual y la recuperación cuando falta el dispositivo o el gestor que conservaba las credenciales. El segundo no elimina el beneficio del primero.

El National Cyber Security Centre británico [2] recomienda usar passkeys donde estén disponibles por su resistencia al phishing, el engaño que imita un servicio para obtener acceso. La mejora tiene un mecanismo concreto y merece distinguirse de las condiciones de recuperación de cada proveedor.

Una prueba criptográfica vinculada al servicio

Una passkey utiliza una parte pública que conoce el servicio y una parte privada con la que se demuestra el acceso. La privada no se envía como una contraseña. El navegador y el componente que conserva y utiliza la credencial, llamado autenticador, aplican reglas que la vinculan al servicio correspondiente. Así lo describe WebAuthn [1].

Una página que copia la apariencia de otra no obtiene por ello su credencial. El servicio también debe validar el origen esperado de la operación. Esa combinación explica la resistencia al phishing en una implementación conforme, en lugar de atribuir la protección al mero aspecto de la pantalla.

El autenticador puede estar integrado en el teléfono o formar parte de una llave física. En una implementación compatible, desbloquearlo mediante PIN o biometría autoriza el uso de la credencial. El gesto de desbloqueo y la clave privada cumplen funciones distintas: uno permite utilizar la otra.

Dónde queda la passkey

Algunas credenciales permanecen ligadas a un autenticador. Otras se distribuyen entre dispositivos mediante un gestor o proveedor de sincronización. Este proveedor conserva y hace disponibles las credenciales según su propio sistema. Tener una passkey no permite deducir cuál de estas situaciones se aplica.

Apple describe [3] sincronización mediante el llavero de iCloud y un mecanismo propio de recuperación. Esa documentación ilustra una implementación concreta. No convierte sus procedimientos en instrucciones válidas para cualquier gestor ni demuestra una recuperación realizada en una cuenta del lector.

La diferencia tiene una consecuencia directa: perder un dispositivo y perder el acceso al gestor sincronizado son problemas distintos. El primer incidente puede quedar cubierto por otro dispositivo disponible. El segundo exige entender la recuperación del proveedor o disponer de otra vía admitida por el servicio.

Dos pantallas pueden compartir una dependencia

Imaginemos que una persona accede desde un portátil y un teléfono gracias al mismo gestor. Es un caso hipotético. Poder entrar desde ambos aporta comodidad y continuidad ante la pérdida de uno. Sin embargo, las dos pantallas no constituyen dos vías independientes frente a la pérdida de acceso al gestor común.

WebAuthn recomienda que los servicios permitan y fomenten registrar varias credenciales. Una credencial adicional puede ayudar frente a la pérdida del único autenticador, pero su independencia depende de dónde se conserva. Registrar otra en el mismo entorno no resuelve automáticamente todos los fallos de ese entorno.

Antes de retirar el equipo antiguo, resulta prudente conocer qué vía seguirá disponible y cómo se recupera el gestor. No hace falta borrar la única entrada que funciona para experimentar. Los pasos concretos deben proceder del servicio utilizado.

Adoptar la mejora y preparar la continuidad

La recuperación añade una dependencia que conviene comprender. La alternativa de mantener contraseñas por inercia conserva también riesgos conocidos de suplantación. Nuestro criterio es aprovechar la resistencia al phishing y acompañarla de una recuperación documentada y entendida, en vez de juzgar todo el sistema por la comodidad del primer acceso.

Cuando un servicio todavía no admite passkeys, el NCSC recomienda contraseñas fuertes y verificación en dos pasos. La transición no será idéntica en todas las cuentas. Una buena solución permite entrar de forma segura y conservar una salida practicable cuando falla el dispositivo habitual.

Metodología

Se consultaron apartados de WebAuthn y las guías del NCSC y Apple sobre uso, sincronización y recuperación. No se probó un proceso de recuperación ni se generalizan las condiciones de Apple a otros gestores.

Metodología general de la revista

Fuentes

Los supuestos y ejemplos se distinguen de los datos observados.

  1. [1] Web Authentication: An API for accessing Public Key Credentials - Level 3 — World Wide Web Consortium · fuente primaria · consultada el 22 de octubre de 2026

    Consulta parcial de WebAuthn: introducción, escenario 1.2.1, pérdida y movilidad de credenciales y validación del origen. No se leyó el estándar completo.

  2. [2] Passkeys: what you need to know | National Cyber Security Centre — National Cyber Security Centre · fuente primaria · consultada el 22 de octubre de 2026

    Guía pública sobre passkeys, uso y alternativas. No se consultó el informe técnico ni se emplean sus cifras de rapidez.

  3. [3] About the security of passkeys – Apple Support (UK) — Apple · fuente primaria · consultada el 22 de octubre de 2026

    Apartados de Apple sobre credenciales, sincronización y recuperación. Son documentación del proveedor, sin una prueba propia de recuperación.