Las passkeys resisten el phishing de credenciales, pero necesitan recuperación, reglas para cajas compartidas y alternativas bien controladas.
Autor
Anichur Rahaman
La nómina vence al mediodía. A las 8:50, la responsable financiera descubre que falta su único dispositivo registrado. Soporte tiene una llamada convincente, un plazo y ningún procedimiento acordado. Es una situación ficticia, no algo que ocurra necesariamente en toda empresa.
Una passkey puede eliminar la contraseña reutilizable al entrar. No decide si quien llama es realmente la responsable ni autoriza una nómina de emergencia. Eso corresponde a recuperación y permisos del negocio.
No preguntes solo «¿pueden registrar passkeys?». Pregunta «¿recuperará acceso la persona correcta tras una pérdida, sin dárselo a un impostor?». Diseña ese día antes de exigir el método.
FIDO explica el acceso con clave pública: el servicio verifica una prueba de la clave privada en lugar de pedir una contraseña reutilizable. El desbloqueo local puede usar biometría o PIN.
La resistencia al phishing vincula la autenticación a la parte prevista. Una web parecida no recoge una passkey escrita para retransmitirla como contraseña o código. WebAuthn usa alcance RP-ID y validación de origen, no una única URL exacta de página.
Resistente al phishing no significa invulnerable. Malware, sesiones robadas, recuperación débil, equipos compartidos abiertos o permisos excesivos siguen causando daño. Guardar claves públicas no vuelve inocuos el resto de datos y sesiones de una base filtrada.
Tocar una llave para demostrar presencia no equivale a verificar al usuario con PIN o biometría. Exige la fuerza necesaria para la acción, con verificación cuando proceda. Entrar tampoco concede todos los permisos: nómina, exportaciones y cambios bancarios conservan controles propios.
La passkey sincronizada facilita cambiar de dispositivo; una ligada al dispositivo puede satisfacer mantener la clave en hardware específico. La etiqueta no prueba la garantía completa del acceso. La tabla ayuda a comprar y definir política, no certifica cumplimiento.
NIST exige proteger las claves exportadas en autenticadores sincronizables. Una clave privada sincronizada puede copiarse protegida; afirmar que nunca sale del primer dispositivo es incorrecto.
NIST SP800-63B-4 permite autenticadores sincronizados que cumplan requisitos en AAL2, no AAL3. Cada nivel exige todos sus controles, no solo comprar una llave.
Para cuentas de mayor impacto, considera respaldo físico aprobado guardado aparte y recuperación probada. Dos dispositivos dependientes de la misma cuenta de sincronización no son dos recuperaciones independientes. Protege también la recuperación del proveedor.
La FAQ actual de Microsoft Entra señala límites para ver o controlar dispositivos con copias sincronizadas. Comprueba el proveedor real; no supongas una lista exhaustiva por dispositivo.
| Elección | Propiedad útil | Qué comprobar |
|---|---|---|
| Passkey sincronizada | Puede estar en dispositivos del proveedor aprobado | Recuperación, compartir, visibilidad y política |
| Credencial ligada al dispositivo | No se sincroniza dentro de ese modelo | Hardware, verificación, compatibilidad y respaldo |
| Respaldo/recuperación | Devuelve acceso legítimo tras la pérdida | Dependencias independientes, verificación y privilegios |
Empieza por una credencial alternativa registrada y aceptada por la política. Pruébala antes y guárdala separada. Si queda un método aprobado, úsalo y sigue la sustitución documentada; no entregues una credencial a una llamada sin autenticar.
Si no queda ninguno, aplica recuperación definida según riesgo. NIST distingue métodos y notificación. Una voz conocida, un mensaje del jefe o una videollamada no bastan por sí solos frente a la suplantación.
Si admite códigos de recuperación guardados, protégelos sin conexión y separados del equipo principal. Prueba su uso permitido y sustitución; un código usado no es acceso permanente.
Dale a soporte verificación documentada con información y canales preestablecidos, escalado y permisos de restablecimiento limitados. Protege el alta de la sustitución, notifica por canales existentes y revisa el evento. Añade aprobaciones o restricciones temporales según política; la urgencia no autoriza atajos.
Gestionar el equipo perdido, revocar la credencial y cerrar sesiones son tareas distintas. Quitar un equipo de la nube no elimina automáticamente sesiones de negocio. Revocar en la aplicación una credencial sincronizada puede inutilizar todas sus copias; borrar un dispositivo no invalida necesariamente los demás. Coordina con identidad y prueba cada control.
Ante sospecha de compromiso, contiene acceso según el procedimiento sin esperar reemplazo. Si no verificas identidad, mantén restricción y escala. La continuidad puede usar otro aprobador ya autorizado con separación de funciones; no suplantar al usuario bloqueado.
Usa cuentas individuales y termina la sesión anterior al relevo. No guardes una credencial personal sincronizada en un perfil compartido accesible por compañeros. Revisa perfiles de sistema, modo kiosco, bloqueo, periféricos y política de teléfonos/Bluetooth.
Una llave aprobada o acceso entre dispositivos compatible puede ayudar; prueba terminal y navegador reales. Un PIN corto de cajero dentro de una sesión POS no es automáticamente passkey WebAuthn ni MFA resistente al phishing. Evalúalo por su finalidad y permisos limitados.
Contratistas necesitan cuenta propia limitada, caducidad y revocación de accesos/sesiones al salir. También al cambiar de puesto. Recuperar la llave física no basta si siguen activos cuenta, proveedor de sincronización o sesión.
Inventaría navegadores, equipos, proveedores, recuperación y accesibilidad. Lista vías que evitan el requisito: contraseña, email, TOTP, SMS, soporte, cliente antiguo y sesión persistente. Exige la fuerza adecuada en rutas protegidas, no solo un recordatorio de registro.
Empieza con grupo compatible y responsables. Prioriza alto impacto, con respaldo de administradores probado antes de exigirlo. Prueba registro, acceso, pérdida de equipo/respaldo, dominio incorrecto, alternativa débil, suplantación al recuperar, respuesta a sesión robada, relevo y baja de contratista en entornos autorizados.
TOTP y recuperación por email/SMS pueden formar parte de transición; no son alternativas igual de resistentes. Si una ruta sensible acepta el método débil con iguales privilegios, sigue expuesta a él. Define límites, vigilancia y retirada, sin prometer mejora total por registrarse.
Para clientes, ofrece adopción clara y accesible con recuperación utilizable. Evita exigir un alta sin probar en medio del checkout. Los requisitos pueden variar; demuestra el recorrido completo en lugar de imponer una norma idéntica a toda cuenta.
En un piloto didáctico de 40 empleados, 32 registrados son el 80%. Si 18 de los mismos 40 aún entran en la aplicación protegida solo con contraseña, esa exposición es un 45% aparte. Los grupos pueden coincidir. Ninguna cifra prueba ausencia de alternativas débiles en los demás.
Mide uso exitoso del método requerido, errores por equipo/navegador, recuperación y abuso sospechado, bloqueos, permisos alternativos y soporte. Indica cohorte y periodo. Las cifras de grandes servicios de consumo no prometen tu velocidad ni tus ahorros.
En la mañana de nómina, interesa demostrar que el respaldo funciona, la suplantación falla, se contienen sesiones y credenciales y el caso legítimo pendiente tiene responsable. Hazlo antes de declarar listo el despliegue. La passkey es una parte fuerte; recuperación y permisos deben acompañarla.
Revisado el 5 de noviembre de 2026. Anichur Rahaman es el creador de StoreConsole. Empresa y cifras son ilustrativas; verifica tu aplicación y proveedor.
Sobre el autor
Anichur Rahaman
Seguir Leyendo
