Passkey vs. Security Key: Diferencias y cómo elegir

Passkeys vs security keys: compara los tipos de credenciales FIDO2 según el nivel de garantía, atestación, recuperación y modelos de implementación empresarial. Descubre cuál se adapta a tu entorno.

¿Qué son las passkeys y las llaves de seguridad?

En 2021, Colonial Pipeline rastreó un incidente de ransomware hasta una contraseña de VPN comprometida, y la empresa pagó aproximadamente 4,4 millones de dólares en rescate, según un comunicado del DOJ. Esa es la realidad operativa del acceso inicial basado en credenciales: los atacantes no necesitan vulnerabilidades de día cero cuando pueden realizar phishing, reutilizar o ejecutar credential stuffing contra la autenticación basada en contraseñas.

Tanto las passkeys como las llaves de seguridad físicas existen para cerrar esa brecha. Utilizan la misma base criptográfica, pero la diferencia en cómo almacenan y gestionan las credenciales es relevante cuando se trata de proteger una empresa.

Una passkey es una credencial de autenticación FIDO que reemplaza las contraseñas por pares de claves criptográficas. Según la FIDO Alliance, las passkeys permiten a los usuarios iniciar sesión en aplicaciones y sitios web utilizando el mismo proceso que usan para desbloquear su dispositivo: biometría, un PIN o un patrón. Las passkeys se presentan en dos formas:

• Passkeys sincronizadas almacenan las credenciales en un gestor de credenciales respaldado en la nube y las sincronizan entre tus dispositivos.
• Passkeys vinculadas al dispositivo bloquean la clave privada a un solo dispositivo. Nunca sale de ese hardware.

En la práctica, el modelo de almacenamiento es lo que determina la mayoría de los compromisos empresariales.

Una llave de seguridad de hardware (también llamada autenticador itinerante) es un dispositivo de hardware externo que se comunica con navegadores y sistemas operativos mediante USB, NFC o Bluetooth utilizando el protocolo FIDO2 CTAP (Client-to-Authenticator Protocol). Piensa en YubiKeys, tarjetas inteligentes y tokens similares. Estas, por definición, están vinculadas al dispositivo: la clave privada se almacena en un módulo de seguridad de hardware y no puede exportarse ni copiarse.

Ambas tecnologías comparten la misma base criptográfica. Cada credencial es única, está vinculada a un dominio de servicio específico y se basa en criptografía de clave pública estándar. Los datos biométricos nunca salen de tu dispositivo. El servidor solo almacena la clave pública. Ese diseño compartido es lo que hace que ambas opciones sean relevantes para el mismo problema central de seguridad.

Relación de las passkeys y llaves de seguridad con la ciberseguridad

El DBIR de Verizon 2025 informa que el abuso de credenciales impulsa una parte importante del acceso inicial: 22% de las brechas involucran abuso de credenciales como método de acceso inicial, según el DBIR de Verizon. Esto coincide con lo que se observa en el campo: una vez que un atacante tiene credenciales válidas, estás luchando contra tus propios caminos de acceso.

Tanto las passkeys como las llaves de seguridad son resistentes al phishing por diseño. Como define la especificación WebAuthn, cada aserción de autenticación está limitada a un dominio web específico, por lo que un sitio de phishing de credenciales en un dominio diferente no puede obtener una aserción válida. Esto detiene el phishing de credenciales, el credential stuffing y los ataques adversario-en-el-medio a nivel de protocolo, razón por la cual las agencias y sectores regulados están impulsando la adopción de MFA resistente al phishing.

Por eso, la OMB M-22-09 ahora exige que las agencias federales utilicen solo autenticación resistente al phishing. La pregunta para tu organización no es si adoptar la autenticación FIDO2, sino qué modelo de implementación se ajusta a tu perfil de riesgo. La siguiente tabla muestra las diferencias clave lado a lado.

Comparativa rápida: Passkey vs. llave de seguridad

Característica	Passkey (Sincronizada)	Llave de seguridad física
Almacenamiento de credenciales	Gestor de credenciales en la nube (Apple Keychain, Google Password Manager)	Módulo de seguridad de hardware en el token físico
Exportabilidad de la clave	Sincronizada entre dispositivos mediante la nube	No exportable; bloqueada al hardware
Nivel de garantía NIST	AAL2	AAL3
Resistencia al phishing	Sí (vinculación de dominio FIDO2)	Sí (vinculación de dominio FIDO2)
Atestación de dispositivo	No soportado (la sincronización en la nube rompe la cadena de confianza)	Soportado (certificado de fabricante embebido en hardware)
Modelo de recuperación	Recuperación de cuenta en la nube a través del proveedor	Llave de respaldo física o reinscripción mediada por administrador
Experiencia de usuario	Transparente, funciona entre dispositivos sincronizados	Requiere token físico en cada inicio de sesión
Costo de hardware	Ninguno (basado en software)	Compra de token por usuario y gestión del ciclo de vida
Compatibilidad multiplataforma	Dependiente del ecosistema del proveedor	Universal (USB, NFC, BLE en cualquier plataforma FIDO2)
Mejor uso	Fuerza laboral general, entornos BYOD	Administradores privilegiados, industrias reguladas, cumplimiento AAL3

La pila de protocolos, el modelo de almacenamiento y el soporte de atestación detrás de cada opción determinan tu nivel de garantía. Así es como se desglosan esos componentes.

Cómo funciona la autenticación FIDO2 internamente

Tanto las passkeys como las llaves de seguridad se basan en la misma pila de protocolos FIDO2, pero difieren en cómo almacenan, protegen y gestionan el material criptográfico subyacente. Comprender estos componentes te ayuda a asignar el tipo de credencial adecuado al nivel de riesgo correspondiente.

Pila de protocolos FIDO2

FIDO2 consta de dos componentes principales definidos por las especificaciones FIDO:

1. W3C Web Authentication (WebAuthn): La API del navegador que habilita la autenticación FIDO en sitios web y aplicaciones.
2. Client-to-Authenticator Protocol (CTAP): El protocolo que permite a los autenticadores externos comunicarse con navegadores y sistemas operativos compatibles con FIDO2.

Estas dos capas son las que proporcionan la vinculación de origen y la prueba criptográfica que hacen posible un inicio de sesión fuerte y resistente al phishing.

Arquitectura de almacenamiento de credenciales

El modelo de almacenamiento es la diferencia definitoria entre passkeys y llaves de seguridad. Cada enfoque maneja la clave privada de manera diferente:

• Llaves de seguridad de hardware almacenan las claves privadas en módulos de seguridad de hardware dedicados (HSM), a menudo utilizando un chip Trusted Platform Module (TPM). Según la documentación de Microsoft Entra, el material de la clave no es exportable. No se puede copiar, respaldar ni sincronizar.
• Passkeys sincronizadas utilizan un sistema operativo o una infraestructura de sincronización de terceros para replicar las claves criptográficas entre dispositivos. La guía de despliegue empresarial de FIDO Alliance señala que esto crea una dependencia de la infraestructura de sincronización del proveedor de passkeys y de sus controles de seguridad.

Esa distinción en el almacenamiento determina todas las decisiones posteriores sobre atestación, cumplimiento y recuperación.

Atestación

La atestación de dispositivo es una técnica incorporada en los protocolos FIDO y WebAuthn que permite al autenticador verificar criptográficamente la cadena de confianza desde el fabricante del dispositivo. Según el white paper de atestación de FIDO Alliance, esto requiere un certificado de fabricante embebido en el elemento seguro del autenticador.

Las passkeys sincronizadas no pueden proporcionar procedencia del dispositivo porque la sincronización en la nube rompe esta cadena criptográfica. Si aplicas atestación en tu plataforma de identidad, solo las credenciales vinculadas al dispositivo califican.

Alineación con el cumplimiento

NIST SP 800-63B-4 establece una distinción clara. AAL2 requiere autenticación resistente al phishing, y tanto las passkeys sincronizadas como las llaves de seguridad pueden calificar. AAL3 requiere una clave de autenticación no exportable, lo que descarta por completo las passkeys sincronizadas.

Estos componentes se corresponden directamente con lo que ocurre durante el inicio de sesión y donde los dos tipos de credenciales se comportan de manera diferente.

Registro, autenticación y puntos de divergencia

El flujo de autenticación para passkeys y llaves de seguridad sigue el mismo patrón FIDO2. La diferencia aparece en cómo cada una maneja el almacenamiento de credenciales, la portabilidad y la recuperación en segundo plano.

Registro (ambos métodos)

Durante la inscripción, el autenticador genera un par de claves pública/privada único vinculado al dominio del servicio. La clave privada permanece en el autenticador y el servidor solo almacena la clave pública.

Autenticación (ambos métodos)

1. El servidor envía un desafío criptográfico.
2. Realizas una verificación local: escaneo de huella digital, desbloqueo facial, PIN o pulsación de un botón físico.
3. El autenticador firma el desafío con la clave privada.
4. El servidor valida la firma utilizando la clave pública almacenada.

Ese flujo compartido es la razón por la que ambos enfoques bloquean los ataques de phishing a nivel de protocolo.

Portabilidad

Con una llave de seguridad física, llevas un token que autentica en dispositivos ilimitados. Conéctalo a cualquier navegador compatible con FIDO2 o tócala vía NFC, y accedes.

Con passkeys sincronizadas, tus credenciales se replican automáticamente entre dispositivos dentro del ecosistema de tu proveedor: Apple, Google o un gestor de terceros. Te autenticas en tu portátil y la misma passkey funciona en tu teléfono sin llevar nada adicional. Sin embargo, la portabilidad entre ecosistemas sigue siendo inconsistente. Un flujo que funciona en Chrome/Windows puede comportarse de manera diferente en Safari/macOS, y las diferencias de experiencia de usuario a nivel de navegador siguen siendo un punto de fricción para los despliegues empresariales.

Fronteras de seguridad

Para credenciales vinculadas al dispositivo, un atacante necesita tus credenciales, acceso físico al token de hardware y la capacidad de eludir la autenticación local.

Para credenciales sincronizadas, la frontera de seguridad se traslada a tu proveedor en la nube. Si un atacante compromete la cuenta en la nube mediante ingeniería social o manipulación de restablecimiento del proveedor, puede sincronizar credenciales a un dispositivo controlado por el atacante.

Ese cambio en la frontera es donde entra la planificación operativa. Ambos tipos de credenciales implican compromisos que debes considerar antes de la aplicación empresarial, y esos compromisos solo importan si las plataformas, navegadores y proveedores de identidad que utilizas realmente soportan el tipo de credencial que eliges.

Dónde se soportan actualmente las passkeys y llaves de seguridad

En 2025, la adopción de passkeys y llaves de seguridad ha alcanzado un punto de inflexión práctico en los ecosistemas de consumo y empresariales.

• Sistemas operativos y navegadores. Apple (iOS 16+, macOS Ventura+), Google (Android 9+) y Microsoft (Windows 10/11 vía Windows Hello) soportan de forma nativa la creación y autenticación con passkeys. Todos los navegadores principales, incluidos Chrome, Safari, Edge y Firefox, soportan WebAuthn. Según la FIDO Alliance, más del 95% de los dispositivos iOS y Android ya están preparados para passkeys, y más de mil millones de usuarios han activado al menos una passkey.
• Proveedores de identidad. Los IdP empresariales han añadido soporte FIDO2 de forma generalizada. Microsoft Entra ID soporta passkeys vinculadas al dispositivo en llaves de seguridad FIDO2 y en Microsoft Authenticator, con soporte para passkeys sincronizadas en vista previa. Okta soporta tanto passkeys como llaves de seguridad FIDO2 como autenticadores resistentes al phishing, con aplicación de atestación y controles de política basados en AAGUID. Cisco Duo, Ping Identity y otros IdP principales también soportan el registro FIDO2 para ambos tipos de credenciales. Esto significa que tu IdP probablemente no será el obstáculo.
• Llaves de seguridad de hardware funcionan universalmente en plataformas compatibles con FIDO2 mediante USB, NFC o Bluetooth. Fabricantes líderes como Yubico distribuyen llaves multiprotocolo (YubiKey 5 Series) que soportan FIDO2, PIV/Smart Card y OTP, cubriendo necesidades de autenticación modernas y heredadas en un solo token.
• Brechas de portabilidad multiplataforma. Las passkeys sincronizadas aún enfrentan fricción al moverse entre ecosistemas. Una passkey creada en Apple Keychain no se sincroniza de forma nativa con Google Password Manager o un dispositivo Windows. La FIDO Alliance está abordando esto con el Credential Exchange Protocol (CXP), una especificación preliminar desarrollada por Apple, Google, Microsoft, 1Password, Bitwarden y Dashlane para estandarizar transferencias seguras y cifradas de passkeys entre proveedores. Se espera que CXP alcance un borrador de revisión pública en 2026. Hasta entonces, gestores de contraseñas de terceros como 1Password y Bitwarden ofrecen la experiencia de passkey multiplataforma más consistente.

Para la planificación empresarial, la conclusión clave es que el soporte de plataforma ya no es la barrera de adopción. La fricción restante es la portabilidad entre ecosistemas para passkeys sincronizadas y la preparación organizacional en torno al registro, recuperación y aplicación de políticas. Estos desafíos operativos merecen un análisis más detallado.

Desafíos y limitaciones a considerar

Ningún método de autenticación elimina todo el riesgo. Al desplegar passkeys frente a llaves de seguridad a gran escala, te enfrentarás a un pequeño conjunto de desafíos recurrentes:

• Los flujos de recuperación se convierten en un control de primera línea. Si los atacantes pueden influir en tu mesa de ayuda o en el proceso de restablecimiento del proveedor, pueden eludir tu flujo de inicio de sesión más fuerte.
• La pérdida de llaves se convierte en un problema de disponibilidad. Un token perdido puede bloquear a un usuario a menos que prepares respaldos y flujos de trabajo administrativos.
• Las diferencias de plataforma generan fricción. La fragmentación de navegadores y sistemas operativos puede provocar experiencias WebAuthn inconsistentes y una mayor carga de soporte.
• La gestión del ciclo de vida es real. La emisión, reemplazo y revocación añaden trabajo, especialmente al ampliar la cobertura de tokens más allá de los usuarios privilegiados.

Esto no es teórico. En 2023, MGM Resorts reveló un incidente cibernético impulsado por ingeniería social con un impacto negativo estimado de 100 millones de dólares, según un informe de MGM. Los factores de inicio de sesión fuertes ayudan, pero aún debes reforzar las operaciones de identidad, incluyendo la mesa de servicio y los procesos de respaldo. La buena noticia es que cada una de estas limitaciones se corresponde con una práctica de despliegue específica que puedes implementar antes de la aplicación.

Mejores prácticas para el despliegue de passkeys y llaves de seguridad

Ya sea que estés implementando passkeys, llaves de seguridad o ambas, estas prácticas te ayudarán a alinear el despliegue con el riesgo, la usabilidad y la realidad operativa:

1. Segmenta por riesgo y garantía. Emite una llave de seguridad de hardware para administradores privilegiados, ejecutivos y roles regulados donde AAL3 o la atestación de alta garantía sean relevantes. Utiliza passkeys sincronizadas para la fuerza laboral general donde AAL2 cumpla tus requisitos.
2. Haz que el registro y los respaldos sean rutinarios. Requiere la configuración de passkeys durante la incorporación de dispositivos y registra múltiples autenticadores por usuario para contar con un respaldo que no obligue a los usuarios a volver a factores fácilmente vulnerables al phishing.
3. Refuerza la recuperación de cuentas y los respaldos. Trata la recuperación de cuentas como un control: endurece la verificación de identidad para restablecimientos en la mesa de ayuda, restringe los métodos de respaldo y monitorea el uso anómalo de respaldos.
4. Despliega en fases y monitorea continuamente. Pilota primero con los grupos de mayor riesgo, expande por etapas y aplica una vez que el soporte al usuario y los flujos de restablecimiento sean sólidos. Mantén visibilidad continua para viajes inusuales, cambios de dispositivo riesgosos y reinscripciones sospechosas.

Si aplicas estas cuatro prácticas, reduces bloqueos y limitas las opciones del atacante sin ralentizar a los usuarios. A partir de ahí, puedes construir un modelo claro de segmentación para asignar el tipo de credencial adecuado en cada caso.

Cómo elegir entre una passkey y una llave de seguridad

Elegir entre una passkey y una llave de seguridad no debe ser una decisión excluyente. La mayoría de las empresas terminan con un modelo híbrido porque diferentes poblaciones requieren distintos niveles de garantía y rutas de recuperación.

Utiliza esta segmentación para tomar la decisión clara:

• Llave de seguridad de hardware: Utiliza cuando necesites AAL3, claves no exportables y fuerte atestación de dispositivo para acceso privilegiado.
• Passkey sincronizada: Utiliza cuando AAL2 sea suficiente y busques menor carga de TI para el acceso general de la fuerza laboral.
• Política híbrida: Usa llaves de seguridad para administradores y roles regulados, y passkeys sincronizadas para el resto de los usuarios.
• Diseño orientado a la recuperación: Trata los caminos de restablecimiento y respaldo como parte de tu conjunto de controles, no como una ocurrencia tardía, ya que pueden anular la MFA resistente al phishing.

Una vez que tengas esa segmentación, el siguiente paso es asegurarte de que aún puedas detectar y detener actividad liderada por identidad después del inicio de sesión.

Puntos clave

Las passkeys y las llaves de seguridad físicas ofrecen autenticación resistente al phishing mediante criptografía FIDO2, pero satisfacen necesidades empresariales diferentes. Las passkeys sincronizadas priorizan la experiencia del usuario y la escalabilidad para fuerzas laborales generales en AAL2. 

Las llaves de seguridad vinculadas al dispositivo proporcionan credenciales no exportables, soporte de atestación respaldado por hardware y alineación con AAL3 para usuarios privilegiados y entornos regulados. En la mayoría de las empresas, implementarás ambos en un modelo basado en riesgos y luego añadirás visibilidad de amenazas de identidad para detectar lo que los controles de autenticación por sí solos no pueden.

Preguntas frecuentes

¿Qué es una Passkey?

Una passkey es una credencial de autenticación FIDO2 que utiliza criptografía de clave pública en lugar de un secreto compartido como una contraseña. Cuando registras una passkey, tu dispositivo genera un par de claves único: la clave privada permanece en el dispositivo (o se sincroniza a través de un proveedor en la nube), y el servidor almacena solo la clave pública. 

Te autenticas mediante un escaneo biométrico, un PIN o el desbloqueo del dispositivo. Debido a que la credencial está vinculada a un dominio específico y nunca se transmite, detiene el phishing y el relleno de credenciales a nivel de protocolo.

¿Cuál es la diferencia entre AAL2 y AAL3?

AAL2 y AAL3 son niveles de garantía de autenticación de NIST que definen el grado de confianza que se puede tener en un inicio de sesión. AAL2 requiere autenticación resistente al phishing, pero puede permitir credenciales sincronizadas que se trasladan entre dispositivos bajo el control de un proveedor. 

AAL3 eleva el estándar al requerir una clave respaldada por hardware, no exportable, y requisitos de verificación más estrictos. En la práctica, esto hace que las claves de acceso sincronizadas sean adecuadas para AAL2, mientras que las llaves de seguridad u otros autenticadores vinculados al dispositivo se utilizan para AAL3.

¿Qué son los ataques de redacción de Passkey?

Los ataques de redacción de passkeys apuntan a la capa de la interfaz de usuario ocultando o suprimiendo los avisos de passkey, obligando a los usuarios a utilizar contraseñas, SMS u otros métodos alternativos más débiles. Los atacantes pueden lograr esto mediante proxys adversario-en-el-medio, páginas de inicio de sesión manipuladas o extensiones de navegador maliciosas que alteran lo que el usuario ve. 

Para reducir el riesgo, minimiza los métodos alternativos, aplica reglas de acceso condicional y restringe las políticas de extensiones. También debes alertar sobre aumentos repentinos en el uso de métodos alternativos, ya que suelen indicar coerción activa.

¿Cómo se implementan Passkeys y Security Keys en fases?

Una implementación por fases generalmente comienza con el trabajo de base: confirmar la compatibilidad con WebAuthn, definir las políticas de AAL2 frente a AAL3 y crear procedimientos sólidos de restablecimiento y reinscripción. Implementa security keys primero en roles privilegiados y de alto riesgo, luego despliega passkeys sincronizadas en oleadas al resto del personal. 

Haz cumplir las políticas solo FIDO una vez que la adopción y la preparación de soporte sean estables. Mantén los factores heredados solo el tiempo necesario para evitar bloqueos durante la transición y luego retíralos.

¿Son seguras las Passkeys sincronizadas en entornos BYOD?

Sí, pero necesitas controles. Almacena las passkeys corporativas dentro de contenedores gestionados o perfiles de trabajo para que las claves permanezcan en tu contexto gestionado, no en una bóveda personal en la nube. Restringe la creación de passkeys a navegadores y aplicaciones gestionados cuando sea posible y audita las credenciales corporativas registradas en cuentas personales. 

Tu modelo de recuperación de cuentas también es importante: si los restablecimientos recurren a pasos fácilmente vulnerables a la ingeniería social, las passkeys sincronizadas pierden gran parte de su garantía.

¿Por qué las empresas usan tanto Passkeys como Security Keys?

Utiliza ambos porque ningún autenticador individual equilibra la garantía, la usabilidad y las operaciones para cada rol. Proporciona llaves de seguridad a usuarios privilegiados, administradores y roles regulados que requieren claves no exportables y una fuerte prueba de procedencia del autenticador. 

Utiliza claves de acceso sincronizadas para la mayoría de la fuerza laboral donde AAL2 es suficiente y la facilidad de uso impulsa la adopción. Luego, aplica políticas consistentes de recuperación y reinscripción en ambos grupos para que los atacantes no puedan degradar a los usuarios a factores más débiles.