Las contraseñas combinan dos defectos difíciles de reconciliar: las fáciles de recordar se adivinan o reutilizan; las robustas generan fricción, recuperación y costos de soporte. Las passkeys cambian el problema porque el usuario ya no entrega un secreto al sitio.
WebAuthn Level 3 fue publicado por W3C como Candidate Recommendation Snapshot en mayo de 2026. La especificación define credenciales de clave pública vinculadas a una parte confiante —el dominio de la aplicación— y reconoce las credenciales descubribles del lado cliente como passkeys. NIST, por su parte, integró autenticadores sincronizables en la revisión 4 de sus guías de identidad digital, finalizada en 2025. La tecnología ya es una opción arquitectónica seria, no un experimento de navegador.
Cómo funciona una passkey sin magia
En el registro, el servidor genera un desafío aleatorio y solicita al navegador crear una credencial. El autenticador —teléfono, computadora o llave de seguridad— crea un par criptográfico. La aplicación recibe la clave pública, un identificador y metadatos permitidos; la clave privada no se entrega al servidor.
En el inicio de sesión, el servidor envía un nuevo desafío. El autenticador pide presencia o verificación del usuario —por ejemplo biometría o PIN local— y firma el desafío. El servidor verifica la firma, el origen, el dominio y contadores o señales aplicables.
1. Dominio
La credencial queda ligada al Relying Party ID.
2. Dispositivo
El autenticador conserva y usa la clave privada.
3. Servidor
Valida el desafío con la clave pública registrada.
El servidor no almacena una contraseña que pueda reutilizarse. Además, la firma incorpora el contexto del sitio. Una credencial creada para empresa.com no funciona en empresa-segura.com, aunque la interfaz falsa sea idéntica.
Passkey sincronizada o ligada al dispositivo
No todas las passkeys tienen el mismo modelo de recuperación y custodia:
- Sincronizadas: el ecosistema del usuario puede hacerlas disponibles en otros dispositivos autorizados. Mejoran continuidad y adopción, con dependencia del mecanismo de protección de esa cuenta.
- Ligadas al dispositivo: la clave no se sincroniza. Son útiles cuando el control físico y la evidencia del autenticador pesan más que la conveniencia.
- Llaves de seguridad: autenticadores externos que pueden servir a personal privilegiado, recuperación robusta o entornos regulados.
La decisión debe responder al riesgo. Una tienda de consumo puede priorizar passkeys sincronizadas para reducir abandono. Una consola administrativa puede exigir credenciales ligadas a dispositivos gestionados o llaves físicas, con enrolamiento supervisado.
La seguridad del login depende de todo el recorrido
Registro
No permitas añadir una passkey solo porque existe una sesión antigua. Reautentica, notifica al usuario, muestra el dispositivo registrado y registra evidencia. En cuentas de alto riesgo, exige un factor fuerte existente o revisión adicional.
Recuperación
Si “olvidé mi acceso” acepta datos públicos y envía un enlace débil, el atacante simplemente evita WebAuthn. Diseña varios caminos según riesgo: passkey de respaldo, dispositivo conocido, llave de recuperación, validación asistida o periodo de espera con alertas.
Gestión de credenciales
El usuario necesita ver passkeys registradas, nombres comprensibles, última utilización y opción de revocación. Mantén más de una credencial cuando el caso lo justifique y envía alertas ante altas o bajas.
Sesión
Una autenticación fuerte no compensa cookies inseguras. Protege sesión, rotación, cierre, dispositivos y operaciones sensibles. Para cambios críticos, solicita una nueva verificación de usuario en lugar de confiar indefinidamente en una sesión antigua.
Error común
Agregar passkeys al inicio de sesión y conservar recuperación por SMS como puerta universal. La resistencia al phishing debe cubrir también registro, recuperación y cambios de cuenta.
Una experiencia que los usuarios entiendan
“Crear credencial WebAuthn” es lenguaje de implementación, no de producto. La interfaz debe explicar el beneficio y anticipar lo que ocurrirá:
- Usa “Acceder con passkey” y una explicación breve: rostro, huella o PIN del dispositivo.
- No afirmes que la biometría se envía al servidor; la verificación ocurre en el autenticador.
- Ofrece passkey cuando existe intención y confianza: después de un login exitoso, una compra o una sesión frecuente.
- Integra autocompletado condicional cuando esté disponible para que passkeys y usuarios aparezcan en el flujo conocido.
- Da instrucciones para cambio de teléfono, pérdida y dispositivos compartidos.
- Mide registro iniciado, completado, uso recurrente, fallos y recuperación.
Arquitectura de servidor: validaciones que no son opcionales
Una biblioteca madura reduce errores, pero la aplicación conserva responsabilidades. Debe generar desafíos criptográficamente aleatorios, de un solo uso y con caducidad; verificar origin, RP ID, tipo de ceremonia y firma; asociar correctamente el userHandle; proteger contra repetición; y aplicar política de verificación del usuario.
Evita registrar datos biométricos o suponer qué gesto usó el usuario. El servidor recibe evidencia criptográfica y banderas, no la huella. Trata la atestación como una decisión de riesgo específica: solicitar información de procedencia innecesaria puede afectar privacidad y compatibilidad.
Plan de despliegue en cuatro etapas
- Instrumentar: mide fallos, restablecimientos, abandono y costo de soporte del login actual.
- Ofrecer: permite añadir passkeys de forma voluntaria después de autenticación exitosa y registra más de una.
- Preferir: presenta passkeys primero en dispositivos compatibles, manteniendo un camino alternativo vigilado.
- Exigir donde importa: elimina factores susceptibles al phishing para administradores, finanzas y operaciones sensibles, con recuperación equivalente.
Durante la transición, registra qué método se usó y evita degradación silenciosa. Si una cuenta configurada para passkey entra con un método más débil, el evento debe generar evaluación o notificación.
Checklist de implementación
- HTTPS, dominio y RP ID definidos para web y subdominios.
- Desafíos únicos, breves y consumidos una sola vez.
- Validación completa del lado servidor con biblioteca mantenida.
- Registro protegido por reautenticación y notificación.
- Más de una credencial y nombres comprensibles.
- Recuperación diseñada al mismo nivel de riesgo.
- Pruebas entre navegadores, sistemas y dispositivos reales.
- Telemetría sin almacenar datos innecesarios del autenticador.
Conclusión
Las passkeys mejoran seguridad y experiencia porque eliminan el secreto compartido y vinculan la autenticación al sitio correcto. Pero el resultado no depende de una llamada a la API: depende de que la aplicación trate identidad como un ciclo completo. Una migración gradual, observable y con recuperación robusta puede reducir fricción sin abrir una puerta lateral más débil.
Fuentes y lectura adicional
- W3C — Web Authentication Level 3, Candidate Recommendation Snapshot.
- NIST SP 800-63 Rev. 4 — Digital Identity Guidelines.
- NIST SP 800-63B-4 — Autenticadores y resistencia al phishing.
- FIDO Alliance — Recursos de despliegue empresarial de passkeys.
- FIDO Alliance — Ruta de passkeys para prevenir phishing.
Última revisión editorial y técnica: 31 de julio de 2026. La política de autenticación debe ajustarse al riesgo y obligaciones de cada servicio.