Desafíos y soluciones en la implementación de claves de acceso empresariales

1. Introducción: realidad operativa de las claves de acceso empresariales para empleados#

Las claves de acceso han llegado al entorno laboral. La pregunta ya no es "¿funciona la tecnología?". La pregunta ahora es "¿cómo operamos esto a gran escala?". Los puntos de fricción se han trasladado a la capa operativa: el problema del "huevo y la gallina" en la inscripción inicial (inicialización), la diferencia entre claves de acceso vinculadas al dispositivo y sincronizadas, la interoperabilidad multiplataforma y los mecanismos de recuperación que no reviertan a la inseguridad de una contraseña.

Esta guía aborda los desafíos del mundo real al implementar claves de acceso en entornos de Microsoft Entra ID, cubriendo errores de configuración, flujos de trabajo operativos y estrategias de recuperación. Específicamente, vamos a abordar las siguientes preguntas:

1. ¿Cuál es la diferencia entre las claves de acceso vinculadas al dispositivo y las sincronizadas en Entra ID?
2. ¿Cómo inicializo claves de acceso para nuevos empleados sin contraseñas?
3. ¿Cómo se recuperan los usuarios cuando adquieren un teléfono nuevo y pierden el acceso a su autenticador?
4. ¿Qué errores de configuración causan fallos en la inscripción de claves de acceso?
5. ¿Cómo gestiono a los invitados B2B cuando exijo MFA resistente a phishing?
6. ¿Debería usar llaves de seguridad de hardware (YubiKeys) o claves de acceso móviles?
7. ¿Cómo gestiono los dispositivos macOS junto con Windows en una implementación de claves de acceso?
8. ¿Qué medidas preventivas evitan la sobrecarga del servicio de asistencia debido al reemplazo de teléfonos?

2. Comprensión de las claves de acceso en Microsoft Entra#

En Entra, "claves de acceso" = credenciales FIDO2/WebAuthn. En lugar de una contraseña, el usuario demuestra la posesión de una clave privada almacenada en un autenticador. Es resistente a phishing porque WebAuthn vincula la credencial al origen de inicio de sesión real (por lo que un sitio de phishing similar no puede reproducirla). Consulte la descripción general de Microsoft en la documentación de conceptos de claves de acceso (FIDO2).

Entra admite de forma efectiva dos "modos" de claves de acceso que se comportan de manera diferente.

2.1 Claves de acceso vinculadas al dispositivo en Entra#

Estas claves de acceso están vinculadas a un dispositivo físico (no sincronizables). La clave privada existe en un elemento de hardware específico (TPM en un portátil, Secure Element en una YubiKey). No es exportable.

En Entra, la historia vinculada al dispositivo se traduce comúnmente en:

• Claves de acceso de Microsoft Authenticator
• Windows Hello o Windows Hello for Business (WHfB) claves de acceso (no sincronizadas a partir de enero de 2026)
• Llaves de seguridad FIDO2 (llaves de hardware como YubiKeys)
• Tarjetas inteligentes (Smartcards)

La guía de configuración base de Microsoft para claves de acceso vinculadas al dispositivo se puede encontrar aquí: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-passkey-fido2

Casos de uso: Acceso de alto privilegio, cuentas "break-glass", entornos de estaciones de trabajo compartidas. Inconvenientes: Alta fricción. La pérdida del dispositivo significa la pérdida de la credencial. Alto costo operativo (por ejemplo, el envío de YubiKeys).

2.2 Claves de acceso sincronizadas en Entra#

Estas son claves de acceso almacenadas en el ecosistema de un proveedor y sincronizadas a través de los dispositivos del usuario (por ejemplo, Llavero de iCloud, Administrador de contraseñas de Google o proveedores de terceros). La clave privada se cifra y se almacena en la estructura de sincronización de un proveedor en la nube.

A partir de enero de 2026, en Entra, las claves de acceso sincronizadas se manejan a través de la función en vista previa: Claves de acceso sincronizadas (vista previa). Para habilitar y controlar las claves de acceso sincronizadas, Entra utiliza Perfiles de clave de acceso (vista previa).

Ajuste normativo: Validado recientemente por el Suplemento 1 de NIST SP 800-63B por cumplir los requisitos AAL2. Se trata de una victoria normativa masiva que valida que las claves de acceso sincronizadas son lo suficientemente "resistentes al phishing" para el uso general de la fuerza laboral.

Casos de uso: Trabajadores del conocimiento, usuarios de BYOD, comodidad para los ejecutivos. Inconvenientes: Garantía "más baja" que el hardware. Dependencia de la seguridad del flujo de recuperación de cuentas del proveedor de la nube.

A continuación, encontrará una descripción general de los proveedores de claves de acceso sincronizadas compatibles con Entra:

En la página de Información de seguridad de un usuario, las claves de acceso sincronizadas y las vinculadas al dispositivo se distinguen claramente. A continuación puede ver cómo aparecen una clave de acceso sincronizada (de 1Password) y una clave de acceso vinculada al dispositivo (YubiKey 5C NFC):

2.3 Alineación normativa: niveles AAL de NIST#

• AAL3 ha requerido históricamente autenticadores basados en hardware y vinculados al dispositivo (como YubiKeys o tarjetas inteligentes) que utilizan una clave privada no exportable.
• AAL2 ahora se puede lograr con claves de acceso sincronizadas según la guía de NIST.
• Matiz: Si bien las claves de acceso sincronizadas (como las de iCloud) son excelentes para los usuarios estándar, es posible que no cumplan estrictamente el requisito de "no exportabilidad" de AAL3 para los niveles de privilegio más altos. Por lo tanto, se requiere una estrategia segmentada: Llaves de hardware para los administradores (AAL3), Claves de acceso sincronizadas para los trabajadores (AAL2).

2.4 Requisitos de preparación del dispositivo#

Para garantizar que los dispositivos estén preparados para la autenticación sin contraseña resistente a phishing, deben ejecutar estas versiones mínimas:

Los sistemas operativos más antiguos pueden requerir autenticadores externos (llaves de seguridad FIDO2) para admitir la autenticación sin contraseña resistente a phishing.

Más allá de los requisitos de versión mínima, la compatibilidad con las capacidades del lado del navegador también varía según la plataforma. Según el Análisis de capacidades del cliente WebAuthn de Corbado Passkey Benchmark 2026, el soporte en los navegadores para el primer trimestre de 2026 se sitúa en un 97–100 % para Conditional Get e Hybrid Transport, pero solo en un 83–92 % para Conditional Create en una combinación típica de navegadores de consumo, una limitación que afecta más a Windows porque Windows Hello no es una ruta de Conditional Create, y Edge en concreto informa de un soporte de Conditional Create muy bajo en el mismo conjunto de datos. El benchmark cubre implementaciones B2C orientadas al consumidor en lugar de entornos de fuerza laboral, pero se aplican los mismos límites subyacentes de capacidad del navegador/sistema operativo a los lanzamientos de Entra ID; las poblaciones de Edge con gran peso corporativo pueden situarse materialmente por debajo del rango combinado del 83–92 % de Conditional Create.

2.5 Recomendaciones de credenciales para usuarios (personas)#

Microsoft recomienda un enfoque basado en el perfil de usuario (persona) para la implementación de credenciales. Los diferentes roles tienen distintos requisitos de seguridad y niveles de fricción aceptables:

Credenciales portátiles (se pueden utilizar en varios dispositivos):

Credenciales locales (específicas del dispositivo):

El objetivo final: La mayoría de los usuarios deberían tener al menos una credencial portátil además de credenciales locales en cada dispositivo informático.

3. Experiencias de implementaciones de claves de acceso en vivo#

Al hablar con organizaciones que han implementado claves de acceso, se reconocen algunos puntos de fricción y patrones del mundo real.

3.1 Cambio operativo#

"Los desafíos no están en la pila tecnológica, sino en la capa operativa." Esto confirma que los obstáculos técnicos como los errores de "Clave de acceso no registrada" o la invisibilidad de las opciones de Windows Hello en dispositivos personales no son anomalías únicas, sino puntos de fricción sistémicos inherentes a la madurez actual del ecosistema. Para las operaciones empresariales, la clave es separar los fallos esperados y los inesperados en la supervisión. Agrupe los errores de WebAuthn explícitamente y realice un seguimiento de NotAllowedError, AbortError y los errores de clave de acceso de Credential Manager como señales distintas. Nuestro manual de análisis de autenticación proporciona un marco para clasificar estas señales, y la analítica de claves de acceso cubre los KPI específicos de claves de acceso, como las tasas de activación e inicio de sesión.

3.2 Inscripción: el momento decisivo#

La inscripción es la fase más difícil de la implementación, requiriendo una importante gestión del cambio.

• Complejidad de la preinscripción: La incorporación de nuevos empleados que no tienen credenciales previas es el principal cuello de botella. La dependencia de la inscripción mediada por el administrador crea una experiencia de usuario desarticulada.
• Fragmentación de la plataforma: "Frustración de los usuarios con los pasos" debido a iteraciones independientes de navegadores, sistemas operativos y administradores de contraseñas. Esto conduce a inconsistencias temporales en las que un flujo funciona en Chrome/Windows pero falla en Safari/macOS o falla en dispositivos personales no administrados pero funciona en dispositivos corporativos.

3.3 Brecha del modelo mental#

"Los usuarios no necesitan criptografía, necesitan un modelo mental". La confusión terminológica crea carga cognitiva:

• Clave de acceso
• Llave de seguridad
• Llave de hardware
• YubiKey
• sin contraseña (passwordless)
• Seguridad de Windows
• Windows Hello
• Windows Hello for Business (WHfB)
• Microsoft Authenticator
• Inicio de sesión por teléfono

Para los usuarios sin conocimientos técnicos o incluso para los más expertos, las diferencias entre estos términos no son obvias.

Recomendamos evitar la jerga como "resistente a phishing" o "par de claves" en las comunicaciones a los usuarios finales. En su lugar, céntrese en el concepto de "desbloqueo": "Usa tu cara para desbloquear los sistemas de la empresa", de forma análoga a desbloquear el teléfono.

3.4 Limitaciones de comunicación#

Una fuerte adopción al principio es fundamental para el éxito, pero la comunicación solo puede llegar hasta cierto punto. No puede enviar correos electrónicos de forma regular pidiendo a los usuarios que comprueben sus métodos de autenticación. En general, no se puede planificar bien el comportamiento del usuario. Esta realidad impulsa la necesidad de medidas técnicas proactivas en lugar de depender únicamente de la educación del usuario.

4. Análisis profundo de la configuración de Microsoft Entra ID#

La implementación de claves de acceso en un entorno empresarial requiere comprender y configurar políticas interdependientes. Las claves de acceso no son solo una función que se puede activar sin más, ya que tienen un impacto enorme en cada empleado en su trabajo diario.

4.1 Política de métodos de autenticación#

Los portales heredados de MFA y SSPR están obsoletos. Toda la configuración de FIDO2 debe producirse en el panel unificado de Política de métodos de autenticación (Authentication Methods Policy).

• Método de llave de seguridad FIDO2: Debe estar habilitado y segmentado. Recomendamos dirigirse a "Todos los usuarios" para la habilitación, pero controlar la aplicación a través del Acceso condicional.
• Restricciones de clave (AAGUIDs): Cada dispositivo FIDO2 (por ejemplo, YubiKey 5 NFC, Microsoft Authenticator en iOS, Administrador de contraseñas de Google) tiene un Identificador único de certificación de autenticador (AAGUID). Como práctica recomendada, en entornos de alta seguridad, utilice la opción "Aplicar restricciones de clave" para Permitir únicamente AAGUIDs específicos y aprobados. Esto evita que los usuarios registren llaves de seguridad baratas y no verificadas del "mercado gris".

4.2 Certificación: el punto de decisión crítico#

Una de las decisiones de configuración más significativas es "Aplicar certificación (Enforce Attestation)".

• Qué hace: Obliga al autenticador a demostrar criptográficamente su marca y modelo a Entra ID durante el registro.
• Conflicto: Las Claves de acceso sincronizadas (almacenadas en proveedores de software como Llavero de iCloud, Bitwarden o Administrador de contraseñas de Google) por lo general no admiten certificación porque están basadas en software y son agnósticas a la plataforma. No pueden firmar un desafío con un certificado de lote de hardware.
• Compromiso:
  • Establecido en SÍ (Yes): Necesario para una alta garantía (AAL3). Garantiza que la clave esté vinculada al hardware. Bloquea los proveedores de claves de acceso basadas en software.
  • Establecido en NO: Permite claves de acceso sincronizadas. Disminuye ligeramente la garantía (AAL2). Habilita los proveedores de claves de acceso basadas en software.

No puede aplicar una política global de "Sin certificación" si tiene administradores con altos privilegios que requieren llaves de hardware. Debe utilizar Perfiles de clave de acceso (Vista previa):

• Perfil A (Administradores): Aplicar certificación = Sí
• Perfil B (Personal general): Aplicar certificación = No

4.3 Explicación de los perfiles de clave de acceso#

Piense en los Perfiles de clave de acceso (Passkey Profiles) como el mecanismo para definir:

• "Estos usuarios pueden usar claves de acceso sincronizadas"
• "Estos usuarios deben usar solo las vinculadas al dispositivo"
• "Certificación requerida frente a no requerida" (y por lo tanto: claves de acceso sincronizadas permitidas frente a excluidas)
• "Restringir a ciertos tipos de autenticadores (restricciones AAGUID)"

A continuación, puede ver la página de configuración de Clave de acceso (FIDO2) en el centro de administración de Microsoft Entra donde se configuran los perfiles de clave de acceso:

Al editar un perfil de clave de acceso, puede configurar la aplicación de la certificación, los tipos de destino (vinculadas al dispositivo, sincronizadas o ambas) y restricciones específicas de AAGUID:

4.4 Acceso condicional y fortalezas de autenticación#

La aplicación se puede gestionar a través de políticas de Acceso condicional (CA) que utilizan Fortalezas de autenticación (Authentication Strengths).

• Fortaleza MFA resistente a phishing: Esta fortaleza incorporada requiere FIDO2, Windows Hello for Business (WHfB) o Autenticación basada en certificados (CBA).
• Trampa de bloqueo: Si crea una política de CA que requiere "MFA resistente a phishing" para "Todas las aplicaciones en la nube" y la aplica a "Todos los usuarios", bloqueará inmediatamente a todos los usuarios que aún no hayan registrado una clave de acceso. Ni siquiera podrán iniciar sesión para registrar una.
• Paradoja de "Registrar información de seguridad": Esta es una acción de usuario específica en CA. Si requiere MFA resistente a phishing para realizar la acción Registrar información de seguridad, crea una dependencia circular (el huevo y la gallina). Un usuario no puede registrar su primera clave de acceso porque necesita una clave de acceso para acceder a la página de registro.

Aquí tiene un resumen de qué métodos de autenticación satisfacen qué requisitos de fortaleza:

4.5 Autenticación preferida por el sistema#

La función "Autenticación multifactor preferida por el sistema" de Entra ID obliga al motor de inicio de sesión a solicitar al usuario el método registrado más seguro.

Si un usuario tiene registrado tanto SMS como una clave de acceso, el sistema utilizará por defecto la clave de acceso. Esto impulsa la adopción de claves de acceso de manera orgánica sin una aplicación estricta. Básicamente, "actualiza" la postura de seguridad del usuario automáticamente una vez que registra la credencial.

A continuación puede ver la experiencia de inicio de sesión con clave de acceso. Se solicita al usuario que use "Cara, huella dactilar, PIN o llave de seguridad" y puede seleccionar su clave de acceso de una extensión del navegador o del administrador de credenciales del sistema:

4.6 Consideraciones sobre macOS: Platform SSO#

Para las organizaciones con entornos mixtos de Windows/macOS, macOS Platform SSO proporciona el equivalente de Apple de Windows Hello for Business. En combinación con soluciones MDM, se puede lograr:

• Credenciales vinculadas al dispositivo vinculadas al Secure Enclave de la Mac
• Experiencia de SSO en aplicaciones nativas y aplicaciones web
• Autenticación resistente a phishing que cumple con los requisitos AAL2/AAL3

Nota: macOS Platform SSO requiere macOS 13+ y una configuración MDM adecuada. La configuración difiere significativamente de WHfB de Windows, por lo que debe planificar procesos de implementación separados.

5. Errores de configuración comunes: por qué "solo funciona con Microsoft Authenticator"#

Si su objetivo son las claves de acceso sincronizadas en dispositivos no administrados, estos son los bloqueadores más comunes:

5.1 Las claves de acceso sincronizadas no están habilitadas/seleccionadas#

No basta con habilitar simplemente "FIDO2" de forma general en Entra. Para las claves de acceso sincronizadas normalmente se necesita:

• La ruta de la función en vista previa descrita en Claves de acceso sincronizadas (vista previa)
• Una configuración de perfil usando Perfiles de clave de acceso

Si un grupo no está seleccionado en un perfil que permita claves de acceso sincronizadas, volverá al mundo "solo vinculadas al dispositivo".

5.2 Certificación aplicada (bloquea las claves de acceso sincronizadas)#

Esta es la causa de la mayoría de las preguntas en las organizaciones conscientes de la seguridad:

• Entra puede requerir certificación para algunos escenarios de claves de acceso (ayuda a validar el tipo/origen del autenticador)
• Las claves de acceso sincronizadas no admiten la certificación en Entra, por lo que si se aplica la certificación, el registro de las claves de acceso sincronizadas falla y se quedará solo con opciones vinculadas al dispositivo.

5.3 La lista de permisos de AAGUID bloquea a los proveedores#

Entra le permite restringir los autenticadores permitidos (a menudo a través de listas de permitidos/bloqueados de AAGUID). Si incluye en la lista de permitidos únicamente a Microsoft Authenticator (o a un conjunto reducido de autenticadores), es posible que los proveedores de sincronización de terceros queden bloqueados de forma implícita. La parte confusa es que la autenticación local (por ejemplo, Touch ID, Face ID, escaneo biométrico de Windows) funciona, pero la página de inicio de sesión de Entra muestra entonces un error.

5.4 El Acceso condicional fuerza ciertos tipos de claves de acceso#

Incluso si las claves de acceso están habilitadas, el Acceso condicional puede obligar de forma efectiva a los usuarios a usar un subconjunto de métodos (por ejemplo, "Solo Authenticator" o una configuración de fortaleza que no permita el perfil de clave de acceso previsto). En la práctica, esto crea la "dependencia de Authenticator" incluso cuando el plan son claves de acceso sincronizadas.

5.5 Invitados B2B vs cuentas de miembros#

Si los socios externos son usuarios invitados B2B en un inquilino de recursos, existen limitaciones conocidas sobre dónde y cómo pueden registrar métodos de autenticación. Este es con frecuencia el problema oculto del "por qué no funciona" cuando la intención es que "los socios usen claves de acceso en nuestro inquilino".

6. Desafíos operativos y soluciones#

6.1 Paradoja de inicialización#

El problema más extendido ("La inscripción es la parte más difícil") es el problema de la inicialización (bootstrapping): ¿Cómo se emite de forma segura una credencial de alta garantía a un usuario que actualmente no tiene credenciales (o solo credenciales de baja garantía)?

6.1.1 Pase de acceso temporal (TAP)#

El Pase de acceso temporal (TAP) es un enfoque arquitectónico para la incorporación sin contraseña.

• Qué es: Un código de acceso con límite de tiempo (por ejemplo, 1 hora) y alta entropía que Entra ID trata como un método de "autenticación fuerte". Omite la necesidad de una contraseña o de un MFA existente.
• Flujo de trabajo:
  1. Verificación de identidad: Se verifica la identidad del nuevo empleado (por ejemplo, mediante un proceso de Recursos Humanos o verificación del gerente).
  2. Emisión: Un administrador (o un flujo lógico automatizado de Logic App) genera un TAP para el usuario.
  3. Inicio de sesión "mágico": El usuario accede a aka.ms/mysecurityinfo. Introduce su nombre de usuario y el TAP.
  4. Registro: Debido a que el TAP satisface el requisito de "Autenticación fuerte", se permite al usuario acceder a la pantalla de Información de seguridad. Hace clic en "Agregar método" y registra su clave de acceso.
  5. Estado estable: El TAP caduca. El usuario ahora tiene una credencial resistente a phishing. Nunca llegó a teclear una contraseña.

6.1.2 Automatización a través de Graph API#

Para las organizaciones grandes, la emisión manual de TAP no es escalable. La mejor práctica es automatizar mediante Microsoft Graph API.

• Escenario: Un nuevo empleado es procesado en el sistema de Recursos Humanos (Workday/SuccessFactors).
• Desencadenante (Trigger): El evento de aprovisionamiento desencadena una Azure Logic App.
• Acción: La Logic App llama al método POST de Graph API /users/{id}/authentication/temporaryAccessPassMethods.
• Entrega: El TAP se entrega de forma segura al responsable de contratación del usuario o a su correo electrónico personal (cifrado) para el acceso el primer día.

6.1.3 Microsoft Entra Verified ID para una incorporación de alta garantía#

Para la incorporación remota o para escenarios que requieren una alta garantía de identidad, Entra Verified ID de Microsoft con Face Check (Comprobación facial) proporciona una vía de inscripción sin contraseña en primera instancia:

1. Prueba de identidad: El nuevo usuario verifica la identidad a través de un socio de IDV (escaneo de una identificación del gobierno).
2. Coincidencia biométrica: Face Check compara una selfi en directo con la foto del documento de identidad mediante Azure AI Vision. Solo se comparte una puntuación de confianza de coincidencia (no hay datos biométricos sin procesar).
3. Credencial verificada emitida: El usuario recibe una credencial de Identificación Verificada.
4. Emisión de TAP: Una vez realizada la verificación con éxito, el sistema emite un Pase de acceso temporal.
5. Inicialización de la clave de acceso: El usuario registra su primera clave de acceso utilizando el TAP.

El flujo de Face Check guía a los usuarios a través de tres pasos: Verificar (compartir credenciales), Confirmar (realizar escaneo facial) y Revisar (ver el resultado de la coincidencia):

Este flujo permite tener cuentas verdaderamente sin contraseña desde el primer día. Nunca se llega a crear una contraseña.

6.2 Problema del reemplazo del teléfono (el desafío de escala oculto)#

Esta suele ser la mayor fuente de llamadas al servicio de asistencia en las implementaciones de claves de acceso. Las organizaciones con grandes poblaciones de BYOD (por ejemplo, más de 10 000 dispositivos) pueden recibir un gran número de llamadas de soporte solo por usuarios que compran teléfonos nuevos y no conocen el proceso para volver a registrar los métodos de autenticación.

Cuando se introducen las claves de acceso en la mezcla, esto se vuelve aún más crítico porque:

• Los usuarios instalan aplicaciones (como Outlook) en su teléfono nuevo
• Estas aplicaciones solicitan autenticación
• El aviso de MFA aparece en el teléfono antiguo (que puede que ya hayan cambiado o borrado)
• El usuario queda bloqueado y llama al servicio de asistencia

6.2.1 Matriz de escenarios para el reemplazo de teléfonos#

El objetivo es trasladar la mayor cantidad posible de casos a las dos primeras filas, minimizando la intervención del servicio de asistencia.

6.2.2 Truco de inscripción en Intune#

Una idea inteligente: Requerir una clave de acceso para la inscripción en Intune obliga a los usuarios a completar la configuración de Microsoft Authenticator en su teléfono nuevo inmediatamente, antes de que puedan acceder a las aplicaciones corporativas.

• Hoy en día: La inscripción en Intune requiere un aumento de nivel (step-up) de MFA. Esto significa que si quiere iniciar sesión en un teléfono nuevo, instala Outlook allí. Sin embargo, el mensaje de MFA va al teléfono antiguo.
• Con requisito de clave de acceso: Los usuarios deben configurar primero las claves de acceso de Microsoft Authenticator en el nuevo teléfono para completar la inscripción. Esto sucede rápidamente (el día del cambio de teléfono) en lugar de meses después cuando el teléfono antiguo ya no está.

Esto no soluciona la recuperación, pero cambia los tiempos. Los usuarios registran su nuevo dispositivo mientras aún tienen acceso al antiguo.

6.3 Las llaves de seguridad de hardware vienen con problemas logísticos#

Las llaves de hardware (YubiKeys, etc.) se posicionan a veces como la solución universal. En teoría lo son, sin embargo, el mundo real muestra más desafíos:

• Pesadilla logística: Las organizaciones que antes implementaban tokens físicos (como RSA SecurID) a menudo pasaban años intentando eliminarlos. Reemplazar un programa de tokens físicos por otro no es atractivo.
• Envío directo (drop-shipping): Yubico puede enviar las llaves directamente a los usuarios y estas no necesitan reemplazar las baterías cada pocos años (a diferencia de SecurID). Pero si alguien olvida su llave, no puede iniciar sesión (en escritorios compartidos).
• Carga de TI local: Los supervisores locales no deben convertirse en soporte de TI de facto para las llaves olvidadas.
• Costo: Las llaves de hardware añaden un costo por usuario que escala con el número de empleados.

Cuándo tienen sentido las llaves de hardware:

• Administradores de Nivel 0: Administradores de dominio, cuentas "break-glass"
• Estaciones de trabajo compartidas: Entornos de quioscos, fábricas, tabletas de campo
• Contratistas sin BYOD: Usuarios externos que no utilizarán dispositivos personales

6.4 Desafíos con dispositivos no administrados#

Muchos usuarios se quejan de que no pueden ver las opciones de uso de la clave de acceso en un dispositivo personal. Este es el clásico punto de fricción de los "dispositivos no administrados".

6.4.1 Análisis del error "Clave de acceso no registrada"#

Es posible que los usuarios no puedan agregar claves de acceso en un dispositivo personal, mientras que funciona en un dispositivo corporativo. Probablemente esto se deba a que las Políticas de cumplimiento de Intune (Intune Compliance Policies) interactúan con el flujo de registro.

• Mecanismo: Windows Hello for Business (WHfB) es una credencial de plataforma. Está vinculada al TPM del dispositivo específico (clave de acceso vinculada al dispositivo).
• Restricción: Para registrar WHfB, por lo general el dispositivo debe estar unido (joined) (Entra Joined o Hybrid Joined) al inquilino. A un dispositivo personal que simplemente está "Registrado" (Workplace Joined) se le pueden aplicar restricciones de política a través de Intune que bloquean el aprovisionamiento de contenedores WHfB si el dispositivo no está completamente administrado o no cumple los requisitos. Consulte Requisitos de inicio de sesión de llave de seguridad FIDO2.
• Opción "Clave de acceso": En un dispositivo personal, el usuario debería intentar registrar una Llave de seguridad FIDO2 (roaming) o una Clave de acceso entre dispositivos (Cross-Device Passkey) (en su teléfono), no Windows Hello for Business (a menos que se admita por completo la inscripción de BYOD).
• Problema de visibilidad en Entra ID: Si no aparece "Windows Hello" como opción, el dispositivo no ha completado la inscripción de MDM necesaria.

6.4.2 Fallos de Autenticación entre dispositivos (CDA)#

En los dispositivos no administrados, los usuarios a menudo prueban el flujo de Autenticación entre dispositivos (CDA) (escaneando un código QR en el PC con su teléfono).

• Dependencia de Bluetooth: El flujo CDA requiere que el Bluetooth esté habilitado tanto en el PC como en el teléfono. No necesitan emparejarse, pero deben realizar un protocolo de enlace Bluetooth de baja energía (BLE) para comprobar la proximidad. Revise las claves de acceso vinculadas al dispositivo en Microsoft Authenticator para obtener más detalles.
• Bloqueo por política corporativa: Si el Bluetooth está deshabilitado en los portátiles corporativos a través de BIOS o GPO por "seguridad", ya ha roto el mecanismo principal para las claves de acceso en itinerancia (roaming).
• Bloqueo de Websocket: El flujo CDA utiliza una conexión websocket a cable.ua5v.com o cable.auth.com. Los cortafuegos corporativos agresivos o las configuraciones de Zscaler suelen bloquear estos dominios, lo que hace que el escaneo del código QR se bloquee o falle silenciosamente. Consulte la documentación de claves de acceso de Microsoft Authenticator.

6.5 B2B e identidades externas#

Otro punto de dolor para las empresas es lidiar con consultores externos (invitados B2B).

• Problema: Un consultor intenta acceder a un sitio de SharePoint. El inquilino aplica una política de Acceso condicional que requiere "MFA resistente a phishing".
• Fallo: El consultor intenta registrar una llave FIDO2 en el inquilino de recursos. Esto falla. Entra ID no admite que los usuarios invitados registren llaves FIDO2 en el inquilino de recursos.
• Solución: Configuración de acceso entre inquilinos
  • Lógica: En lugar de forzar al invitado a registrar una credencial en su inquilino, debe confiar en la credencial que utiliza en su inquilino (el del invitado).
  • Configuración: Vaya a Identidades externas > Configuración de acceso entre inquilinos (Cross-tenant access settings). Seleccione la organización asociada. En Confianza entrante (Inbound Trust), marque "Confiar en la autenticación multifactor de los inquilinos de Microsoft Entra".
  • Resultado: Cuando el consultor inicia sesión usando una YubiKey en su inquilino de origen, su inquilino recibe una reclamación que dice "MFA satisfecha + Resistente a phishing". Se concede el acceso sin que el usuario tenga que registrar nada. Esto externaliza la gestión del ciclo de vida de las credenciales al socio, reduciendo su responsabilidad y la carga del servicio de asistencia.

7. Estrategias de recuperación#

A menudo, las decisiones de recuperación todavía van por detrás de la implementación real. Existen múltiples opciones de recuperación dependiendo de las necesidades de su organización.

7.1 Recuperación de cuenta de autoservicio (SSAR) con Verified ID#

El nuevo flujo de Recuperación de cuenta de autoservicio (SSAR) de Microsoft Entra ID (en vista previa) permite la recuperación con alta garantía sin la intervención del servicio de asistencia.

1. Desencadenante: El usuario no puede iniciar sesión. Selecciona "Recuperar mi cuenta".
2. Verificación de identidad: Se redirige al usuario a un proveedor externo de verificación de identidad (IDV) (por ejemplo, Onfido, IDemia).
3. Comprobación del documento: El usuario escanea su licencia de conducir física, identificación nacional o pasaporte utilizando la cámara de su móvil.
4. Comprobación de vida (Liveness Check): El usuario realiza una comprobación facial (Face Check) mediante selfi. Esto se compara con el documento de identidad (y posiblemente con la foto almacenada en Entra ID). La comparación utiliza las API de Azure AI Vision Face y solo se comparte una puntuación de confianza. No se envían datos biométricos sin procesar a la aplicación.
5. Restauración: Al tener éxito, el sistema emite automáticamente un Pase de acceso temporal (TAP) al usuario.
6. Reinscripción: El usuario utiliza el TAP para registrar una nueva clave de acceso inmediatamente.

Recomendación: Esta vía de recuperación automatizada y respaldada por biometría es superior a "Llamar al servicio de asistencia", el cual es vulnerable a la ingeniería social (ataques de voz Deepfake).

7.2 Recuperación asistida por el administrador con My Staff#

Si desea reducir la carga de Service Desk pero no puede habilitar el autoservicio completo, Microsoft Entra incluye una función nativa de administración delegada llamada My Staff.

• Cómo funciona: Delegue permisos limitados a "Gerentes de equipo" (a través de Unidades Administrativas en Entra).
• Flujo: Si un usuario pierde el acceso, puede ponerse en contacto con un administrador local delegado, que puede utilizar el portal My Staff para realizar tareas de recuperación compatibles, como restablecer una contraseña o actualizar un número de teléfono.
• Por qué ayuda: Aleja del servicio de asistencia centralizado el trabajo común de recuperación de cuentas y acelera el soporte.

7.3 Quiosco de recuperación de autoservicio (intranet)#

Puesto que a menudo los usuarios conservan un portátil de confianza y protegido por WHfB, puede crear una sencilla página en la intranet de tipo "break glass" (romper el cristal).

• Construcción: Una aplicación web interna sencilla que requiere el inicio de sesión WHfB (autenticación fuerte).
• Acción: Una vez autenticado, el usuario hace clic en "Tengo un teléfono nuevo". La aplicación usa la Microsoft Graph API (servicio en segundo plano) para generar un Pase de acceso temporal (TAP) de corta duración y lo muestra en la pantalla.
• Resultado: El usuario escribe ese TAP en su nuevo teléfono para inicializar la aplicación Microsoft Authenticator. Cero intervención del servicio de asistencia.

Esta es la palanca clave para reducir los restablecimientos de "borrar métodos de autenticación" sin debilitar la política. Si dispone de un mecanismo sólido de portátil como inicializador, su carga de comunicaciones se reduce significativamente porque los usuarios pueden recuperarse sin conocer la secuencia perfecta.

8. Recomendaciones para implementaciones empresariales de claves de acceso#

Estructure su implementación en torno a las Fases de madurez. Reconozca la fricción ("La tecnología está lista, las operaciones son difíciles") y aplique estas mitigaciones.

8.1 Acciones inmediatas (Fase de "Arreglo")#

1. Audite Bluetooth y Firewalls: Asegúrese de que los portátiles corporativos permiten Bluetooth (para las comprobaciones de proximidad) y de que los dominios de transmisión de FIDO/WebAuthn están en la lista blanca (\*.cable.auth.com) para solucionar los fallos entre dispositivos.
2. Habilite la confianza entre inquilinos: Deje de intentar registrar claves de acceso de invitados. Configure la confianza entrante para MFA (Inbound Trust for MFA) en los socios clave para resolver los problemas de acceso B2B de forma inmediata.
3. Implemente TAP para la incorporación: Ordene el uso de pases de acceso temporal para la incorporación de todos los nuevos usuarios, a fin de resolver el problema del registro ("el huevo y la gallina").

8.2 Decisiones estratégicas (Fase de "Arquitectura")#

1. Adopte un modelo de "Garantía híbrida":
   • Nivel 0 (Administradores): Aplique Certificación y Restricciones de clave. Solo se permiten YubiKeys/Hardware (AAL3).
   • Nivel 1 (Trabajadores): Deshabilite la aplicación de la certificación mediante Perfiles de clave de acceso. Permita las claves de acceso sincronizadas para reducir la fricción y el costo (AAL2).
2. Planifique para macOS: Implemente Platform SSO con su MDM como una vía paralela a WHfB de Windows.

8.3 Preparación para el futuro (Fase de "Optimización")#

1. Planifique para SSAR: Inicie un programa piloto para la Recuperación de cuenta de autoservicio con Verified ID para eliminar el servicio de asistencia como vector de ingeniería social.
2. Autenticación preferida por el sistema: Habilite esta política para "actualizar" automáticamente a los usuarios a claves de acceso en cuanto registren una, impulsando la adopción sin un mandato estricto.
3. Implemente opciones de recuperación: Implemente el TAP asistido por el administrador a través de My Staff y/o un Quiosco de recuperación de autoservicio.
4. Requisito de clave de acceso en Intune: Considere la posibilidad de exigir la clave de acceso para la inscripción en Intune para forzar el registro temprano en los nuevos dispositivos.

8.4 Matriz de resolución de problemas#

9. Supervisión de la implementación con el libro de trabajo Passwordless resistente a phishing#

Microsoft ha publicado un Libro de trabajo Passwordless resistente a phishing (Phishing-Resistant Passwordless Workbook) que las organizaciones con registros en Azure Monitor pueden utilizar para realizar un seguimiento del progreso del lanzamiento. Acceda a él a través del centro de administración de Entra en Supervisión > Libros de trabajo:

El libro de trabajo tiene dos secciones principales:

9.1 Fase de preparación de la inscripción#

Utilice esta pestaña para analizar los registros de inicio de sesión y determinar qué usuarios están listos para el registro frente a qué usuarios pueden estar bloqueados. Puede filtrar por plataforma del sistema operativo (Windows, macOS, iOS, Android) y tipo de credencial (Clave de acceso en aplicación Authenticator, Llave de seguridad FIDO2, Autenticación basada en certificados):

El libro de trabajo muestra:

• Pares de usuario/dispositivo listos para inscripción: usuarios que pueden registrar el tipo de credencial seleccionado
• Pares de usuario/dispositivo no listos: usuarios que pueden tener problemas de registro (por ejemplo, versiones obsoletas del sistema operativo)

Puede exportar listas de usuarios que necesiten acciones de reparación (por ejemplo, actualizaciones del sistema operativo, reemplazos de dispositivos o alternativas de credenciales).

9.2 Fase de preparación para la aplicación#

Una vez que los usuarios estén listos para la autenticación de solo resistencia a phishing, utilice la pestaña Preparación para la aplicación (Enforcement Readiness). En primer lugar, cree una política de Acceso condicional de Solo informe (Report-Only) que requiera MFA resistente a phishing. Esto llena los registros de inicio de sesión con datos sobre si el acceso habría sido bloqueado si la aplicación estuviera activa.

El panel de control muestra:

• Total de usuarios en el alcance
• Éxito solo de informe - usuarios que aprobarían la aplicación
• Política no satisfecha - usuarios que serían bloqueados (¡investigue estos!)
• Desgloses de Estado del dispositivo, Plataforma del dispositivo y Aplicación del cliente

Utilice la pestaña Análisis de datos adicional (Further Data Analysis) para investigar por qué se bloquearía a determinados usuarios. Estos datos le ayudan a dirigirse a los usuarios para su reparación antes de habilitar la aplicación.

9.3 Lanzamiento por oleadas con supervisión de la mesa de ayuda#

Microsoft recomienda ejecutar implementaciones por oleadas con rangos de fechas flexibles. Supervise el volumen de tickets en la mesa de ayuda como señal:

• Aumento del volumen de tickets: Disminuya la velocidad de las implementaciones, las comunicaciones y las acciones de aplicación
• El volumen de tickets disminuye: Vuelva a acelerar las actividades

Cree grupos de seguridad de Microsoft Entra ID para cada ola y agregue grupos a sus políticas de forma incremental. Esto evita abrumar a los equipos de soporte.

10. Lista de comprobación para la prueba piloto de claves de acceso sincronizadas#

Si el objetivo son las claves de acceso sincronizadas sin la dependencia de Microsoft Authenticator, siga esta postura piloto:

1. Habilite las claves de acceso sincronizadas (vista previa) Siga Claves de acceso sincronizadas (vista previa).

2. Utilice Perfiles de clave de acceso (vista previa) y seleccione el grupo piloto Cree/asigne un perfil que permita claves de acceso sincronizadas como se describe en Perfiles de clave de acceso.

3. No aplique la certificación (al menos para el grupo piloto) La aplicación de la certificación excluye las claves de acceso sincronizadas según la documentación de conceptos de claves de acceso (FIDO2).

4. Evite inicialmente las listas de permisos estrictas de AAGUID Comience de forma permisiva para confirmar el flujo, luego restrinja una vez que sepa qué proveedores desea permitir. Consulte Habilitar claves de acceso (FIDO2).

5. Confirme que el Acceso condicional no fuerza a Microsoft Authenticator Asegúrese de que el CA y las fortalezas de autenticación siguen permitiendo el perfil de clave de acceso previsto (de lo contrario, parece una dependencia de Microsoft Authenticator).

6. Valide el modelo de identidad (miembro vs invitado) Si los usuarios son invitados, confirme la compatibilidad esperada en su modelo de inquilino antes de pasar tiempo ajustando perfiles.

11. Conclusión#

La implementación de claves de acceso empresariales es compleja a nivel operativo, pero el camino a seguir está bien definido. Aquí están las respuestas clave, alineadas con las preguntas operativas principales planteadas anteriormente:

1. Claves de acceso vinculadas al dispositivo vs sincronizadas: Las credenciales vinculadas al dispositivo (por ejemplo, Microsoft Authenticator, Windows Hello, YubiKeys, tarjetas inteligentes) están estrictamente unidas a un solo dispositivo y satisfacen el AAL3. Las claves de acceso sincronizadas (por ejemplo, Llavero de iCloud, Administrador de contraseñas de Google) funcionan en todos los dispositivos y cumplen el AAL2. La mayoría de las organizaciones necesitan ambos tipos: autenticadores de hardware para administradores (AAL3) y claves de acceso sincronizadas para el resto del personal (AAL2).

2. Inicialización de nuevos empleados: Utilice el Pase de acceso temporal (TAP) para resolver el problema de "el huevo y la gallina" en la incorporación. Para implementaciones a gran escala, automatice esto a través de la Graph API. Para casos de uso de alta garantía, complemente la incorporación con Entra Verified ID y Face Check.

3. Recuperación tras reemplazo de teléfono: Ofrezca múltiples métodos de recuperación: Quiosco de recuperación de autoservicio (use un portátil como dispositivo de inicialización), TAP asistido por el administrador a través de My Staff y SSAR (Recuperación de cuenta de autoservicio) con Verified ID para los casos más extremos.

4. Errores de configuración: Los errores más frecuentes incluyen aplicar la certificación a nivel global, no habilitar las funciones de vista previa para las claves de acceso sincronizadas, listas de permisos de AAGUID demasiado estrictas y políticas de Acceso condicional (CA) que crean dependencias circulares.

5. Invitados B2B: Evite registrar claves de acceso directamente para invitados B2B en su inquilino. En su lugar, habilite la Confianza de acceso entre inquilinos para validar las credenciales del inquilino de origen del invitado.

6. Llaves de hardware vs claves de acceso móviles: Las llaves de seguridad de hardware son necesarias para ciertas funciones de alta seguridad (administradores, estaciones de trabajo compartidas), pero presentan obstáculos logísticos a gran escala. Las claves de acceso móviles suelen ser más prácticas para los trabajadores.

7. macOS junto a Windows: Use Platform SSO con JAMF/MDM para habilitar el soporte de claves de acceso en macOS de forma paralela a las implementaciones de Windows. Planifique flujos de trabajo específicos para cada plataforma.

8. Medidas proactivas: Utilice Intune para identificar dispositivos inactivos e incentivar a los usuarios para que pongan remedio antes de que se produzca un bloqueo. Considere la posibilidad de convertir el registro de claves de acceso en un requisito previo para la inscripción en Intune para fomentar una adopción temprana. Desarrolle un flujo de trabajo de recuperación de autoservicio utilizando portátiles como dispositivos de inicialización.

La tecnología está lista. El principal desafío es la ejecución operativa. La planificación de la recuperación debe ser una parte integral desde el primer día, no una idea de último momento. Una vez que la infraestructura sea sólida, concéntrese en optimizar la adopción del inicio de sesión con clave de acceso para asegurar que las claves de acceso se conviertan en el principal método de autenticación en toda su fuerza laboral.

Acerca de Corbado

Corbado es la Passkey Intelligence Platform para equipos de CIAM que gestionan autenticación de consumidores a gran escala. Te ayudamos a ver lo que los logs de tu IDP y las herramientas de analytics genéricas no muestran: qué dispositivos, versiones de SO, navegadores y gestores de credenciales soportan passkeys, por qué los registros no se convierten en inicios de sesión, dónde falla el flujo de WebAuthn y cuándo una actualización de SO o navegador rompe el login en silencio — todo sin reemplazar Okta, Auth0, Ping, Cognito o tu IDP propio. Dos productos: Corbado Observe aporta observabilidad para passkeys y cualquier otro método de login. Corbado Connect añade passkeys gestionados con analytics integrado (junto a tu IDP). VicRoads ejecuta passkeys para más de 5M de usuarios con Corbado (+80 % de activación de passkey). Habla con un experto en Passkeys →

Preguntas frecuentes#

¿Por qué habilitar MFA resistente a phishing en el Acceso condicional bloquea a todos mis usuarios?#

Crear una política de Acceso condicional que requiera MFA resistente a phishing para todas las aplicaciones en la nube bloquea inmediatamente a cualquier usuario que aún no haya registrado una clave de acceso, incluyendo el bloqueo del acceso a la propia página de registro de Información de seguridad. Esta dependencia circular, llamada la paradoja de 'Registrar información de seguridad', significa que debe emitir un Pase de acceso temporal (Temporary Access Pass) a los usuarios afectados antes de habilitar la aplicación de la política para que puedan completar el registro inicial.

¿Cómo gestiono los usuarios invitados B2B cuando mi inquilino requiere MFA resistente a phishing?#

Entra ID no admite que los usuarios invitados registren llaves FIDO2 en un inquilino de recursos, por lo que intentar aplicar el registro de claves de acceso para invitados fallará. La solución correcta es configurar los Ajustes de acceso entre inquilinos en Identidades externas para confiar en las reclamaciones de MFA del inquilino de origen del invitado, lo que significa que una YubiKey utilizada en su propia organización satisface su requisito de MFA resistente a phishing sin ningún registro en su inquilino.

¿Qué causa que la autenticación entre dispositivos mediante código QR falle silenciosamente al iniciar sesión con una clave de acceso?#

La autenticación entre dispositivos requiere que el Bluetooth esté habilitado tanto en el PC como en el teléfono para completar un protocolo de enlace de proximidad BLE, por lo que cualquier política corporativa que deshabilite el Bluetooth romperá el flujo por completo. El flujo también utiliza una conexión WebSocket a cable.auth.com, que los firewalls o las configuraciones de Zscaler bloquean con frecuencia, lo que hace que el escaneo del código QR se bloquee o falle sin un mensaje de error claro.

¿Cómo monitorizo qué empleados están listos para la aplicación de MFA resistente a phishing antes de activarla?#

El libro de trabajo Passwordless resistente a phishing (Phishing-Resistant Passwordless Workbook) de Microsoft, accesible a través del centro de administración de Entra en Supervisión > Libros de trabajo, proporciona una vista de Preparación de la inscripción que muestra qué pares de usuario/dispositivo pueden registrarse por plataforma y tipo de credencial. Para la preparación de la aplicación, cree una política de Acceso condicional de solo informe que requiera MFA resistente a phishing para que los registros de inicio de sesión revelen qué usuarios estarían bloqueados antes de activar la aplicación en vivo.

¿Cuál es la mejor estrategia de recuperación para los empleados que adquieren un teléfono nuevo y pierden el acceso a su clave de acceso?#

El enfoque recomendado es en capas: un Quiosco de recuperación de autoservicio que utiliza un portátil protegido por WHfB genera un Pase de acceso temporal a través de la Graph API y cubre la mayoría de los casos sin la intervención del servicio de asistencia. Para los usuarios que no tienen un portátil, el TAP asistido por el administrador a través del portal My Staff delega la recuperación a los gerentes directos, y la Recuperación de cuenta de autoservicio con la comprobación facial biométrica de Entra Verified ID maneja los casos extremos que requieren una reverificación completa de la identidad.

Lecturas adicionales#

Para obtener información detallada sobre las implementaciones empresariales de claves de acceso/FIDO2, siga a expertos como Merill Fernando y Jan Bakker, quienes publican regularmente guías prácticas sobre la autenticación de Microsoft Entra.