Passkeys a escala empresarial: lecciones prácticas de implementaciones reales

En 2023, el informe de investigaciones de violaciones de datos de Verizon encontró que el 74 % de todas las violaciones involucró el elemento humano — phishing, robo de credenciales o uso indebido — con un costo medio de 4,45 millones de dólares por incidente. Las contraseñas son la causa raíz. A pesar de décadas de mandatos de MFA, los códigos SMS son intercambiados por SIM, las notificaciones push son bombardeadas por fatiga y las semillas TOTP son cosechadas mediante proxies intermediarios maliciosos como Evilginx2. Las passkeys — basadas en el estándar FIDO2 — son el primer tipo de credencial que es arquitectónicamente resistente al phishing. Pero los equipos de TI empresariales que se apresuran a pasar por alto las diapositivas brillantes de los proveedores descubren rápidamente que el despliegue en producción es una bestia completamente diferente.

Por qué las contraseñas — y la mayoría de MFA — siguen fallando

El problema no es el comportamiento del usuario; es el protocolo. Los secretos compartidos (contraseñas, OTP) deben transmitirse y verificarse en el lado del servidor, creando superficies de interceptación en cada salto. Las categorías de MFA resistentes al phishing en NIST SP 800-63B requieren autenticadores basados en posesión donde la clave privada nunca sale del dispositivo y el dominio de la parte confiable está vinculado criptográficamente al desafío. Solo las claves de seguridad de hardware (FIDO2/CTAP2) y las passkeys cumplen con este estándar. Sin embargo, las claves de hardware se estancaron a escala de consumidor debido al costo y la fricción de UX. Las passkeys resuelven el problema de distribución mediante la sincronización a través de almacenes de claves de la plataforma.

Qué son realmente las Passkeys (técnicamente)

Una passkey es una credencial FIDO2 almacenada como un par de claves asimétricas. La clave privada reside dentro de un enclave seguro o autenticador de plataforma — Apple Secure Enclave, Android Strongbox, Windows Hello TPM — y nunca se exporta. El registro genera un ID de credencial, una clave pública enviada al servidor de la parte confiable y, opcionalmente, una cadena de certificados de atestación. La autenticación produce una aserción firmada sobre un desafío del servidor concatenado con el origen (esquema + host + puerto), lo que hace que la firma sea inválida en cualquier otro dominio. Esta es la garantía antiphishing.

La especificación WebAuthn Nivel 3 añade tres tipos de credenciales relevantes para la empresa:

• Platform passkeys (sincronizadas): Almacenadas en iCloud Keychain, Google Password Manager o Windows Hello — sincronizadas entre dispositivos mediante bóvedas E2EE. Convenientes, pero el material de la clave privada sale del límite del dispositivo (cifrado).
• Platform passkeys (vinculadas al dispositivo): Vinculadas a un solo TPM o Secure Enclave del dispositivo. Alta garantía, sobrevive mal a un borrado del dispositivo — la credencial simplemente desaparece.
• Roaming authenticators (CTAP2): Claves físicas como la serie YubiKey 5 o FEITIAN BioPass. La mayor garantía, sin sincronización, y el cuello de botella para la distribución empresarial a gran escala.

CTAP2.1 añadió el protocolo PIN/UV Auth 2, gestión de credenciales (listar/eliminar credenciales en el dispositivo) y almacenamiento de blobs grandes. Los despliegues empresariales que apuntan a AAL3 (NIST) o Nivel de Garantía del Autenticador 3 normalmente exigen autenticadores vinculados al dispositivo o roaming authenticators.

Realidades del despliegue empresarial

Gestión de dispositivos y verificación de atestación

Las demostraciones de passkeys para consumidores omiten la atestación; los despliegues empresariales no pueden. La atestación permite a la parte confiable verificar el modelo y fabricante del autenticador antes de aceptar un registro. Microsoft Entra ID admite la aplicación de políticas de atestación — puedes restringir los registros de passkey a la serie YubiKey 5 o dispositivos Android específicos con claves respaldadas por hardware. Okta FastPass vincula de manera similar la atestación del dispositivo al estado de cumplimiento de MDM a través de su función Device Trust; un dispositivo macOS no inscrito en Jamf Pro fallará el registro. Duo Trusted Endpoints aplica puertas similares a través de su agente de endpoint.

El desafío: los certificados de atestación deben obtenerse del Servicio de Metadatos FIDO (MDS3), almacenarse en caché y revalidarse. Las entradas de MDS3 tienen revocación — un modelo de autenticador comprometido puede ser bloqueado en lista negra, y tu código debe manejar esto con elegancia sin bloquear a los usuarios existentes con credenciales ya registradas.

Sincronización entre plataformas y el problema de fragmentación del ecosistema

Apple, Google y Microsoft operan cada uno bóvedas de passkey separadas. Un empleado que registra una passkey en su iPhone (iCloud Keychain) no puede usarla en su portátil corporativo con Windows 11 a menos que use un flujo de autenticación entre dispositivos — un escaneo de código QR mediante el transporte híbrido de CTAP2, que depende de la proximidad de Bluetooth LE. Esto es compatible con Chrome 109+ y Safari 16+ en todas las plataformas, pero requiere que Bluetooth esté habilitado — algo que muchas políticas de refuerzo de endpoints empresariales deshabilitan.

Windows Hello for Business con Entra ID hybrid join funciona bien dentro del ecosistema de Microsoft. Pero un entorno mixto BYOD+corporativo con macOS, iOS, Android y Windows crea hasta cuatro bóvedas de credenciales separadas que deben gestionarse, monitorearse y tenerse en cuenta durante la baja. Ninguna de ellas se federan entre sí de forma nativa. La oferta de passkey empresarial de 1Password — disponible desde 1Password 8 — actúa como un gestor de passkey de terceros que puentea ecosistemas, pero introduce un nuevo límite de confianza y requiere la extensión del navegador 1Password para manejar las llamadas de WebAuthn a través de la API navigator.credentials.get().

Incorporación y baja de empleados

La incorporación es la mitad más fácil. La mayoría de los IdP ahora admiten el registro de passkey inicial: Okta y Entra ID pueden enviar un enlace de registro con límite de tiempo que permite a un nuevo empleado registrar una passkey inmediatamente después de verificar su identidad a través de un canal separado (OTP por correo electrónico o verificación de identidad por parte del gerente). La mitad difícil es la baja. Revocar una passkey requiere revocar la credencial en la parte confiable — que es una operación inmediata del lado del servidor — pero la credencial puede seguir existiendo en iCloud Keychain o Google Password Manager, capaz de intentar una autenticación que ahora será rechazada. Los empleados que se van en malos términos no pueden "llevarse sus passkeys" para autenticarse con éxito, pero los equipos de TI necesitan runbooks claros para no confundir la revocación de credenciales (hecha) con la eliminación de credenciales de la bóveda del dispositivo personal del usuario (no es tu jurisdicción).

Retrocesos condicionales de la interfaz de usuario

No todos los navegadores, dispositivos o versiones del sistema operativo admiten passkeys. Safari añadió soporte para passkey en iOS 16 / macOS Ventura 13. Chrome añadió una interfaz de usuario estable para passkey en la versión 108. Firefox añadió soporte para passkey en la versión 122 — notablemente tarde. Las passkeys de Windows Hello requieren al menos Windows 10 22H2 o Windows 11 21H2. Tu flujo de autenticación debe implementar Mediación Condicional — llamando a navigator.credentials.get() con mediation: "conditional" — para mostrar las passkeys al estilo de autocompletado sin bloquear a los usuarios en navegadores no compatibles para que recurran a contraseñas o TOTP. Eliminar el retroceso demasiado pronto bloqueará a los usuarios de dispositivos heredados y generará tickets de soporte inmediatos.

El panorama de los proveedores

Microsoft Entra ID es la historia de passkey empresarial más completa en la actualidad. El soporte para claves de seguridad FIDO2 (vinculadas al dispositivo) ha estado disponible de forma general desde 2021; las passkeys sincronizadas para Windows Hello se añadieron en 2024. El filtrado de atestación, la coincidencia de números para MFA push y las políticas de Acceso Condicional pueden restringir el registro de passkey solo a dispositivos compatibles. El punto débil: los escenarios de Hybrid Azure AD Join en entornos de Active Directory de Windows Server más antiguos tienen bordes ásperos, especialmente con aplicaciones locales que pasan a través de AD FS en lugar de Entra.

Okta admite FIDO2 WebAuthn como factor de autenticador dentro de Okta Verify FastPass. Sus integraciones de Device Trust (Jamf, Microsoft Intune, VMware Workspace ONE) permiten atestar que el dispositivo está inscrito en MDM antes de permitir la inscripción. El soporte de passkey de Okta como factor principal sin contraseña (reemplazando completamente las contraseñas, no solo como un paso adicional de MFA) alcanzó disponibilidad general a finales de 2024.

Duo Security (Cisco) añadió soporte para WebAuthn como factor de Duo, pero su historia de passkey para flujos completamente sin contraseña es menos madura que la de Entra u Okta. Duo sobresale en entornos heterogéneos donde no todas las aplicaciones admiten SAML/OIDC — sus complementos de Unix PAM y Windows Credential Provider permiten una garantía equivalente a passkey para flujos SSH y RDP.

1Password Business permite almacenar y usar passkeys dentro de la bóveda de 1Password, con políticas de uso compartido a nivel de equipo y registros de auditoría. Útil para cuentas de servicio compartidas, pero introduce riesgo de bloqueo del proveedor y requiere evaluar si tus requisitos de AAL permiten un gestor de passkey basado en software.

Modos de fallo comunes en producción

• La política de atestación rompe el despliegue: Habilitar la atestación estricta antes de auditar los modelos de autenticador de tu flota de dispositivos bloqueará a los empleados con dispositivos Android antiguos o hardware no certificado por FIDO2. Comienza con atestación: "indirect" y endurece más tarde.
• Bluetooth deshabilitado por política elimina la autenticación entre dispositivos: Identifica los flujos de autenticación entre dispositivos basados en código QR que dependen de BLE y crea excepciones o dirige a los usuarios a claves de hardware roaming en su lugar.
• iCloud Keychain se sincroniza con dispositivos personales: Las Mac inscritas corporativamente comparten iCloud Keychain con los iPhones personales de los empleados si se usa el mismo Apple ID. Los perfiles de MDM no pueden aislar esto sin un Apple ID administrado — planifica tu inscripción en Apple Business Manager en consecuencia.
• La falta de coincidencia de RP ID rompe aplicaciones de terceros: Las aplicaciones registradas con un ID de parte confiable de app.company.com rechazarán las passkeys registradas contra company.com y viceversa. Audita todas tus configuraciones de RP ID antes del despliegue.
• Sin ruta de recuperación de cuenta: Un dispositivo perdido con una passkey vinculada al dispositivo y sin autenticador de respaldo significa una reprobación de identidad asistida por el servicio de ayuda desde cero. Define el SLA de recuperación antes de la puesta en marcha.

Marco de implementación paso a paso

El siguiente marco asume Entra ID u Okta como IdP, una flota mixta de Windows/macOS/iOS/Android y el objetivo de eliminar las contraseñas como factor principal en 18 meses.

1. Mes 1-2 — Auditoría: Inventaría los modelos de autenticador en tu flota a través de MDM. Verifica las versiones del navegador. Mapea el método de autenticación de cada aplicación (SAML, OIDC, NTLM heredado). Identifica los requisitos de AAL por nivel de aplicación.
2. Mes 2-3 — Diseño de políticas: Define qué segmentos de usuarios obtienen passkeys sincronizadas vs. vinculadas al dispositivo. Redacta la política de atestación (comienza con indirect). Define los runbooks de recuperación de cuenta. Confirma que las políticas de Acceso Condicional / MFA Adaptativo no bloqueen la inscripción.
3. Mes 3-5 — Piloto: Despliega al personal de TI y a los primeros usuarios. Habilita las passkeys como un factor adicional opcional junto con las contraseñas. Mide las tasas de éxito de registro, los intentos de autenticación entre dispositivos y las tasas de retroceso en los registros de tu IdP.
4. Mes 5-10 — Inscripción amplia: Envía campañas de inscripción con enlaces de inscripción de autoservicio. Apunta al 80% de la fuerza laboral inscrita. Mantén las contraseñas activas como respaldo. Monitorea el volumen de tickets del servicio de ayuda: los tickets de recuperación de cuenta y passkey perdida son tu señal.
5. Mes 10-18 — Eliminación de contraseñas: Para los usuarios inscritos, aplica políticas de Acceso Condicional que requieran passkey (FIDO2) como método de autenticación. Deshabilita la autenticación con contraseña para los niveles de aplicación cubiertos. Mantén un proceso de recuperación de emergencia con tokens de hardware para cuentas administrativas.

Lo que aún falta en el ecosistema

Las passkeys no están terminadas. Todavía hay varias brechas a mediados de 2025:

• Sin estándar nativo de itinerancia de passkey empresarial: No existe un estándar de FIDO Alliance para migrar passkeys entre plataformas (por ejemplo, de iCloud Keychain a Google Password Manager). El bloqueo del proveedor es real.
• Soporte limitado para SSH/RDP/VPN: WebAuthn es una API del navegador. Existen agentes SSH que admiten claves de hardware FIDO2 (mediante ssh-keygen -t ecdsa-sk), pero las passkeys sincronizadas no pueden usarse en flujos SSH nativos sin una capa puente.
• El manejo de la revocación de atestación es inmaduro: La mayoría de las implementaciones de IdP no manejan adecuadamente los eventos de revocación de MDS3 para credenciales registradas existentes. Necesitas lógica personalizada o un compromiso del proveedor.
• Retraso de Firefox: El soporte de passkey de Firefox (v122+) todavía tiene bordes ásperos en la UX para la mediación condicional y los flujos entre dispositivos, y su cuota de mercado en entornos empresariales — particularmente servicios gubernamentales y financieros — no es trivial.

La adopción empresarial de passkey ha superado la etapa de los primeros usuarios — Microsoft, Google y Okta están lanzando funciones GA. Los equipos que tienen éxito son aquellos que lo tratan como una migración de infraestructura, no como una actualización de aplicación: auditar primero, pilotear sin descanso, y mantener los retrocesos activos más tiempo del que parece cómodo. La resistencia al phishing al final vale el costo operativo.