Autenticación sin contraseña con Microsoft Intune

La autenticación sin contraseña reduce la suplantación de identidad (phishing) y el robo de credenciales mediante la sustitución de las contraseñas por métodos de inicio de sesión más seguros, como Windows Hello, claves de seguridad FIDO2, claves de paso, certificados, inicio de sesión telefónico de Microsoft Authenticator y pase de acceso temporal.

Microsoft Intune no emite credenciales sin contraseña. En su lugar, prepara dispositivos, aplicaciones y experiencias de usuario para que estos métodos sin contraseña funcionen de forma confiable a escala. Microsoft Entra ID es la entidad de identidad que comprueba las credenciales y aplica las directivas de autenticación y acceso condicional, mientras que Microsoft Intune configura las opciones del dispositivo, aplica el cumplimiento normativo y habilita las funcionalidades de la plataforma de las que dependen esos métodos. Juntos, Microsoft Entra ID y Microsoft Intune proporcionan la base de identidad y la preparación del dispositivo necesarias para adoptar la autenticación sin contraseña en diversas plataformas y factores de forma.

La experiencia sin contraseña varía según la plataforma. En Windows, suele abarcar tanto el inicio de sesión en el dispositivo como el acceso a aplicaciones a través de SSO. En macOS, se centra en la autenticación de la plataforma y el SSO en las aplicaciones, en lugar de la identidad profunda vinculada al dispositivo. En iOS/iPadOS y Android, se centra más a menudo en el inicio de sesión de aplicaciones, la autenticación asincrónica y el comportamiento de clave de paso que en el inicio de sesión del dispositivo. Tenga en cuenta estas distinciones al evaluar los requisitos de la plataforma y planear la implementación.

En este artículo se explica cómo Microsoft Intune admite una estrategia sin contraseña desde la perspectiva de un administrador. Para obtener más información sobre la implementación, siga los vínculos de implementación de cada método sin contraseña.

Cómo funciona la solución sin contraseña de Microsoft

La solución sin contraseña de Microsoft empareja Microsoft Entra ID para identidad e inicio de sesión único (SSO) con Microsoft Intune para la configuración de dispositivos y la aplicación de directivas. Esta combinación permite a los usuarios autenticarse mediante credenciales seguras, como datos biométricos, claves de seguridad FIDO2 o claves de paso, sin escribir contraseñas.

Microsoft Entra ID es el proveedor de identidades principal. Comprueba credenciales sin contraseña como PIN de Windows Hello, claves FIDO2 y claves de paso. Después de una autenticación correcta, Microsoft Entra ID emite un token de actualización principal (PRT) o equivalente, lo que permite un SSO fluido para Microsoft 365, Azure y otros recursos protegidos. Las directivas de acceso condicional evalúan el estado del dispositivo, la intensidad de la autenticación y las señales de riesgo antes de conceder acceso.

Microsoft Intune prepara los dispositivos para el inicio de sesión sin contraseña mediante la configuración de opciones, la aplicación del cumplimiento, la implementación de las aplicaciones necesarias y la compatibilidad con las experiencias de plataforma que hacen que sin contraseñas sea práctico a escala. Microsoft Intune proporciona a los administradores un plano de administración para Windows, macOS, iOS/iPadOS y Android.

Las funcionalidades de la plataforma en Windows, macOS, iOS y Android proporcionan la experiencia enlazada al dispositivo, incluidos los datos biométricos, el hardware seguro (TPM en Windows, Secure Enclave en macOS), la compatibilidad con claves de paso y el inicio de sesión único con broker.

Esta separación es importante. Microsoft Entra ID es la entidad de identidad. Microsoft Intune es la capa de administración que ayuda a los usuarios a adoptar y usar esos métodos correctamente.

Resistencia sin contraseña, MFA y suplantación de identidad

La autenticación sin contraseña no elimina los factores de seguridad. La mayoría de los métodos sin contraseña cumplen los requisitos de autenticación multifactor (MFA). Por ejemplo, Windows Hello usa una credencial vinculada al dispositivo (posesión) emparejada con un gesto biométrico (inherencia) o un PIN (conocimiento), lo que satisface MFA por diseño. Como resultado, las directivas de fortaleza de autenticación de acceso condicional clasifican muchos métodos sin contraseña como compatibles con MFA o incluso como MFA resistente a la suplantación de identidad (phishing).

No todas las opciones sin contraseña proporcionan el mismo nivel de protección. Comprender la diferencia entre los métodos resistentes y no resistentes a la suplantación de identidad te ayuda a seleccionar las fortalezas de autenticación adecuadas y a diseñar una estrategia de identidad segura.

  • Los métodos resistentes a la suplantación de identidad usan claves criptográficas asimétricas vinculadas al hardware que no se pueden interceptar ni reproducir, incluso si un usuario interactúa con un mensaje malintencionado o falsificado.
  • Los métodos no resistentes a la suplantación de identidad usan flujos sin contraseña, pero pueden verse comprometidos por ingeniería social, manipulación rápida o fatiga de MFA.

Cada método descrito más adelante en este artículo incluye su nivel de resistencia a la suplantación de identidad (phishing).

Más información

Ventajas de la autenticación sin contraseña con Microsoft Intune

Cuando utiliza Microsoft Intune, Microsoft Entra ID y las funcionalidades de la plataforma juntas, su organización obtiene:

  • Inicio de sesión único sin problemas: los usuarios inician sesión una vez en el dispositivo y obtienen acceso automático a las aplicaciones, los servicios en la nube y, en algunos casos, los recursos locales. Se eliminan las llamadas de restablecimiento de contraseña y las solicitudes repetidas de autenticación.
  • Comodidad del usuario en todos los dispositivos: los usuarios obtienen una experiencia nativa y coherente en todos los dispositivos. Windows Hello usa el inicio de sesión del sistema operativo, macOS integra Touch ID con Microsoft Entra ID y las plataformas móviles usan Microsoft Authenticator y las claves de paso de la plataforma. Los usuarios no tienen que hacer malabares con contraseñas separadas por dispositivo.
  • Postura de seguridad más sólida: los métodos resistentes a la suplantación de identidad evitan el robo de credenciales y los ataques de reproducción. La compuerta de cumplimiento de dispositivos garantiza que incluso las credenciales válidas solo funcionen desde dispositivos administrados en buen estado, en consonancia con los principios de Confianza cero.
  • Reducción de la carga de soporte técnico de TI: Menos restablecimientos de contraseñas, una incorporación más fluida con el pase de acceso temporal y opciones de recuperación de autoservicio reducen el volumen del servicio de asistencia.
  • Arquitectura preparada para el futuro: a medida que evolucionan los estándares, los nuevos métodos sin contraseña (incluidas las claves de paso sincronizadas y las credenciales respaldadas por hardware) pueden conectarse a la misma arquitectura de Microsoft Entra ID + Microsoft Intune sin necesidad de un rediseño importante.

Cómo impulsa Microsoft Intune la adopción sin contraseña

Microsoft Intune habilita y operacionaliza la autenticación sin contraseña al garantizar que los dispositivos y aplicaciones estén configurados correctamente para usar credenciales modernas y seguras. Mientras que Microsoft Entra ID rige la política de identidad y autenticación, Microsoft Intune prepara el entorno del dispositivo del que dependen los métodos sin contraseña.

Las contribuciones clave incluyen:

  • Preparación del dispositivo: inscripción, registro y configuración de dispositivos para que puedan participar en flujos de inicio de sesión sin contraseña.
  • Implementación de configuración: entregar las directivas necesarias para Windows Hello para empresas, autenticación basada en certificados, SSO de la plataforma de Apple y funcionalidades similares de la plataforma.
  • Cumplimiento y señales de acceso: proporcionar datos de cumplimiento y mantenimiento del dispositivo que el acceso condicional evalúa antes de conceder acceso.
  • Aprovisionamiento de aplicaciones y agentes: implementación de aplicaciones principales, como Microsoft Authenticator y Microsoft Intune Portal de empresa, que permiten la intermediación de identidades y escenarios de SSO sin contraseña.
  • Administración multiplataforma unificada: Proporciona una política y un marco de administración coherentes en Windows, macOS, iOS/iPadOS y Android para agilizar la implementación empresarial.

Los métodos sin contraseña disponibles para los usuarios dependen tanto de la plataforma del dispositivo como de las opciones de autenticación habilitadas en Microsoft Entra ID. Microsoft Intune garantiza que cada dispositivo esté preparado, configurado y sea capaz de ofrecer una experiencia sin contraseña segura y confiable.

Windows Hello

Resistente a la suplantación de identidad

Windows Hello reemplaza las contraseñas con una clave asimétrica enlazada al dispositivo que se genera y se sella al TPM. El acceso a la clave se controla mediante un PIN o un gesto biométrico (reconocimiento facial o de huella digital), que combina la posesión y la inherencia en un único paso de inicio de sesión. Este método está respaldado por hardware y es resistente a la suplantación de identidad (phishing) para dispositivos Windows.

Rol de Intune
Microsoft Intune prepara los dispositivos Windows para Windows Hello mediante la entrega y aplicación de la configuración de directiva de Windows Hello para empresas.

Este método es más relevante cuando necesita:

  • Prepare los dispositivos Windows que dan prioridad a la nube para el inicio de sesión sin contraseña.
  • Entregar la configuración de directivas de Windows Hello para empresas durante la inscripción y la administración continua.
  • Alinee el inicio de sesión de Windows con el cumplimiento de dispositivos y la administración moderna.

Más información

Claves de seguridad FIDO2

Resistente a la suplantación de identidad

Las claves de seguridad FIDO2 son dispositivos físicos (USB, NFC o Bluetooth) que almacenan credenciales FIDO y proporcionan autenticación resistente a la suplantación de identidad sin depender de la plataforma del dispositivo. Dado que la credencial está vinculada a la clave de hardware y se comprueba a través de un desafío criptográfico, no se puede interceptar ni reproducir. Las claves FIDO2 son ideales para dispositivos compartidos, entornos de alta seguridad o como ruta de recuperación junto con credenciales basadas en plataforma.

Rol de Intune
Microsoft Intune puede ayudar a preparar los dispositivos para este método mediante la administración de plataformas compatibles y experiencias de inicio de sesión relacionadas.

Este método suele ser una buena opción cuando las organizaciones necesitan:

  • Una opción portátil sin contraseña para dispositivos compartidos o especializados.
  • Una opción sólida y resistente a la suplantación de identidad (phishing) que no está vinculada a una única plataforma ni a Microsoft Authenticator.
  • Una recuperación o una ruta alternativa junto con las credenciales basadas en la plataforma.

Para obtener instrucciones de implementación, consulte:

Llaves de acceso

Resistente a la suplantación de identidad

Las claves de paso son el paraguas basado en estándares para las credenciales FIDO que se pueden enlazar al dispositivo o sincronizar entre dispositivos. En Microsoft Entra ID, puede usar:

  • Claves de paso enlazadas al dispositivo almacenadas en hardware seguro (TPM o Secure Enclave) en un único dispositivo, por ejemplo, a través de Windows Hello o Microsoft Authenticator en iOS 17+ y Android 14+.
  • Claves de paso sincronizadas administradas por administradores de contraseñas de la plataforma (como iCloud Keychain o Google Password Manager) o proveedores externos compatibles, que permiten el uso entre dispositivos.
  • La clave de paso de Microsoft Entra en Windows es una clave de paso FIDO2 que usa Windows Hello para la verificación biométrica, pero no requiere la unión del dispositivo o el registro. Los usuarios pueden registrar varias claves de paso para varias cuentas de Microsoft Entra en el mismo dispositivo, lo que lo hace ideal para dispositivos compartidos, puntos de conexión no administrados y escenarios en los que no se aprovisiona Windows Hello para empresas.

Rol de Intune
Desde la perspectiva de Microsoft Intune, las claves de paso tienen que ver principalmente con la preparación de la plataforma y la aplicación: administrar los requisitos previos del dispositivo y la aplicación que hacen que la adopción de claves de paso sea viable en todas las plataformas.

Esta dependencia es especialmente importante en:

  • Windows, donde el inicio de sesión de plataforma y Windows Hello pueden intersecarse con una planeación sin contraseña más amplia. La clave de paso de Microsoft Entra en Windows amplía la cobertura de clave de paso a los dispositivos que no están inscritos o unidos, complementando Windows Hello para empresas en dispositivos administrados.
  • iOS/iPadOS y Android, donde las claves de paso pueden depender del estado del dispositivo móvil y del comportamiento del agente de aplicaciones.
  • macOS, donde la integración de la identidad de la plataforma y la experiencia de inicio de sesión del usuario dan forma a la adopción.

Para obtener instrucciones de implementación, consulte:

Inicio de sesión por teléfono de Microsoft Authenticator

No es resistente a la suplantación de identidad

El inicio de sesión en el teléfono de Microsoft Authenticator reemplaza las contraseñas por la aprobación basada en la inserción y la coincidencia de números en el dispositivo móvil de confianza del usuario. Es cómodo y ampliamente compatible, pero se basa en notificaciones push en lugar de credenciales enlazadas al hardware, lo que significa que no evita por completo los ataques de phishing, como la manipulación de mensajes de MFA.

Nota:

Microsoft Authenticator también puede almacenar claves de paso enlazadas a dispositivos (iOS 17+, Android 14+), que son resistentes a la suplantación de identidad (phishing). En esta sección se trata específicamente el flujo de inicio de sesión por teléfono basado en la inserción.

Rol de Intune
Microsoft Intune admite este flujo mediante la implementación y administración de los requisitos previos de dispositivos y aplicaciones móviles.

En muchos entornos, esta compatibilidad incluye:

  • Implementación de Microsoft Authenticator en dispositivos móviles administrados.
  • Compatibilidad con la experiencia de inicio de sesión asincrónica en todas las aplicaciones de Microsoft.
  • Tener en cuenta las consideraciones de la política de protección de aplicaciones en las plataformas móviles cuando forman parte del diseño de acceso móvil más amplio.

Para obtener instrucciones de implementación, consulte:

Pase de acceso temporal

No es un método permanente , sino que se usa para la incorporación y la recuperación

El Pase de acceso temporal (TAP) es una credencial por tiempo limitado que emite un administrador para ayudar a los usuarios a arrancar o recuperar el acceso antes de completar su configuración sin contraseña a largo plazo. TAP no es un método permanente sin contraseña y no es resistente a la suplantación de identidad (phishing), pero con frecuencia es una parte fundamental de una implementación correcta porque resuelve el problema del primer inicio de sesión sin emitir una contraseña.

Rol de Intune
Desde la perspectiva de Microsoft Intune, el Pase de acceso temporal es importante cuando desea:

  • Simplifique la incorporación a métodos sin contraseña.
  • Reducir la dependencia de contraseñas temporales durante la implementación.
  • Conecte los escenarios de incorporación a la configuración de dispositivos Windows administrados.

Incorporación desde cero desde el día con TAP

Un desafío común en las implementaciones sin contraseña es el problema del huevo y la gallina : un nuevo usuario necesita iniciar sesión para registrar su credencial sin contraseña, pero no desea emitir una contraseña para ese primer inicio de sesión. TAP resuelve este problema al proporcionar una credencial de corta duración para la configuración inicial del dispositivo y el registro de credenciales.

Un flujo de incorporación típico tiene este aspecto:

  1. El Administración emite una TAP: el administrador de TI o el flujo de trabajo automatizado genera una TAP por tiempo limitado para el nuevo usuario en el Centro de administración de Microsoft Entra o a través de Microsoft Graph API.
  2. El usuario configura su dispositivo: el usuario introduce el TAP durante la OOBE de Windows Autopilot, el asistente de configuración de macOS o la inscripción a dispositivos móviles. En Windows 11, el inicio de sesión web habilita la entrada de TAP directamente en la pantalla de bloqueo.
  3. El usuario registra un método sin contraseña: después de iniciar sesión con la pulsación, se le pide al usuario que registre Windows Hello, una clave de seguridad FIDO2, una clave de paso en Microsoft Authenticator u otro método sin contraseña. Esta es la credencial permanente que reemplaza al TAP.
  4. TAP expira : el TAP es de un solo uso o de tiempo limitado (configurable), por lo que no se puede reutilizar después de que el usuario registre su método sin contraseña.

Este flujo elimina la necesidad de emitir y revocar una contraseña temporal, y proporciona a Microsoft Intune una ruta de incorporación administrada desde el primer inicio de sesión.

Para obtener instrucciones de implementación, consulte:

Autenticación basada en certificados (CBA)

Resistente a la suplantación de identidad

La autenticación basada en certificados (CBA) usa certificados digitales y criptografía asimétrica para verificar la identidad, lo que la hace resistente a la suplantación de identidad y evita la reproducción de credenciales. Se adopta ampliamente en sectores regulados y entornos gubernamentales, a menudo a través de tarjetas inteligentes como PIV y CAC. A diferencia de otros métodos sin contraseña en los que Microsoft Intune prepara principalmente el entorno del dispositivo, CBA es un área en la que Microsoft Intune desempeña un papel directo en la distribución de las credenciales.

Rol de Intune
Microsoft Intune admite dos modelos de infraestructura para la entrega de certificados:

  • PKI local: las organizaciones con una entidad de certificación (CA) existente pueden usar el Conector de certificados para Microsoft Intune para conectar su PKI local con Microsoft Intune. El conector permite a Microsoft Intune implementar perfiles de certificado SCEP y PKCS en dispositivos administrados mediante la infraestructura de CA existente. Este modelo se adapta a las organizaciones que ya operan una CA empresarial o necesitan integrarse con inversiones PKI establecidas.
  • Microsoft Cloud PKI: para las organizaciones que desean simplificar o eliminar la infraestructura de certificados local, Microsoft Cloud PKI proporciona una entidad de certificación basada en la nube como parte del conjunto de aplicaciones de Microsoft Intune Suite. La PKI en la nube emite y administra certificados sin necesidad de servidores locales, conectores o módulos de seguridad de hardware.

Independientemente del modelo de infraestructura, Microsoft Intune entrega certificados a dispositivos mediante perfiles de certificado:

  • Los perfiles de certificado raíz de confianza distribuyen el certificado raíz de la CA para que los dispositivos puedan establecer la cadena de confianza.
  • Los perfiles de certificado SCEP solicitan e implementan certificados desde una CA habilitada para SCEP.
  • Los perfiles de certificado PKCS solicitan e implementan certificados mediante el estándar PKCS #12.
  • Los perfiles de certificado PFX importados implementan certificados generados previamente que se importan en Microsoft Intune.

Estos perfiles funcionan en Windows, macOS, iOS/iPadOS y Android, lo que convierte a Microsoft Intune en el mecanismo de entrega que conecta la infraestructura de PKI (ya sea local o basada en la nube) al método de identidad definido en Microsoft Entra ID.

Para obtener instrucciones de implementación, consulte:

Requisitos previos

Antes de planear una implementación sin contraseñas, compruebe que el entorno cumple los requisitos de licencia y plataforma para los métodos que quiere usar. Algunas características sin contraseña requieren niveles de licencia específicos de Microsoft Entra ID o Microsoft Intune, y cada método tiene requisitos mínimos de versión del sistema operativo.

Requisitos de licencias

En función de los métodos sin contraseña que elija, es posible que su organización necesite licencias de Microsoft Entra ID P1 o Microsoft Entra ID P2 para los usuarios, así como licencias específicas de Microsoft Intune para la administración de dispositivos y la entrega de certificados. En la tabla siguiente se resumen los requisitos de licencia para las funciones comunes sin contraseña:

Funcionalidad Requisito de licencia
Windows Hello Microsoft Entra ID P1 (para aplicación de acceso condicional)
Claves de seguridad FIDO2 Microsoft Entra ID P1
Claves de paso (vinculadas al dispositivo y sincronizadas) Microsoft Entra ID P1
Inicio de sesión por teléfono de Microsoft Authenticator Microsoft Entra ID P1
Pase de acceso temporal Microsoft Entra ID P1
Autenticación basada en certificados (CBA) Microsoft Entra ID P1 (P2 para acceso condicional basado en riesgos)
Directivas de intensidad de autenticación Microsoft Entra ID P1
Acceso condicional basado en riesgos Microsoft Entra ID P2
Microsoft Cloud PKI Licencia de Microsoft Intune Suite o PKI en la nube independiente
Cumplimiento de dispositivos y perfiles de configuración Plan 1 de Microsoft Intune

Más información

Requisitos de la plataforma

Los métodos sin contraseña descritos en este artículo se basan en capacidades específicas de la plataforma que solo están disponibles en determinadas versiones del sistema operativo. En la tabla siguiente se resumen los requisitos de la plataforma para cada método:

Método Windows macOS iOS/iPadOS Android
Windows Hello Todos los clientes de Windows compatibles — — —
Claves de seguridad FIDO2 Todos los clientes de Windows compatibles — — —
Llaves de acceso Windows 11 Todas las versiones compatibles Todas las versiones compatibles Android 14+
Claves de paso enlazadas al dispositivo en Microsoft Authenticator — — Todas las versiones compatibles Android 14+
SSO de plataforma (Secure Enclave) — Todas las versiones compatibles — —
Inicio de sesión web (PULSE en la pantalla de bloqueo) Windows 11 — — —
Inicio de sesión por teléfono de Microsoft Authenticator — — Todas las versiones compatibles Android 11+

Nota:

Compatible se refiere a las versiones del sistema operativo que Microsoft Intune admite actualmente para la funcionalidad completa, la implementación de directivas y la administración.
Los requisitos de versión de la plataforma pueden cambiar con cada ciclo de lanzamiento. Compruebe siempre los requisitos actuales en la documentación del producto para el método específico que va a implementar.

Más información

Consideraciones de la plataforma

Sin contraseña no es una característica. Es un conjunto de experiencias específicas de la plataforma que dependen de Microsoft Entra ID para la identidad y de Microsoft Intune para la administración de dispositivos.

Windows

Windows es el ejemplo más completo de cómo la inscripción de dispositivos, el inicio de sesión en la nube, la postura de seguridad y la experiencia de usuario sin contraseña funcionan juntos.

Microsoft Intune suele admitir escenarios sin contraseña de Windows al:

  • Preparación de dispositivos unidos a Microsoft Entra en primer lugar.
  • Entrega de la configuración de Windows Hello para empresas.
  • Compatibilidad con experiencias de claves de seguridad FIDO2.
  • Alinear la preparación del dispositivo con el cumplimiento normativo y la administración moderna.
  • Compatibilidad con experiencias de incorporación que pueden conectarse a Windows Autopilot.

Cuando un usuario inicia sesión con Windows Hello o una clave FIDO2, Windows obtiene un token de actualización principal de Microsoft Entra ID. PRT permite un SSO fluido para las aplicaciones de Microsoft 365, las aplicaciones SaaS y, cuando se configura Cloud Kerberos Trust, los recursos locales como recursos compartidos de archivos, todo ello sin solicitudes de inicio de sesión adicionales.

Más información

Consideraciones híbridas y heredadas

Las experiencias sin contraseña descritas en este artículo asumen una dirección primero en la nube con dispositivos unidos a Microsoft Entra. Las organizaciones con dispositivos híbridos unidos a Microsoft Entra deben tener en cuenta estas diferencias:

  • El inicio de sesión web (que se usa para pulsar en la pantalla de bloqueo de Windows) solo se admite en dispositivos unidos a Microsoft Entra, no en dispositivos unidos a Microsoft Entra híbrido.
  • Windows Hello para empresas funciona tanto en dispositivos unidos a Microsoft Entra como en dispositivos unidos a Microsoft Entra híbrido, pero las implementaciones híbridas pueden requerir infraestructura adicional en función del modelo de confianza.
  • El acceso a recursos locales desde dispositivos unidos a Microsoft Entra requiere la confianza Kerberos en la nube o la confianza basada en certificados. La confianza Kerberos en la nube es el modelo recomendado porque no requiere la implementación de certificados para la autenticación Kerberos. Para obtener más información, consulte [Implementación de confianza Kerberos en la nube](/windows/security/identity-protection/> hello-for-business/deploy/hybrid-cloud-kerberos-trust).
  • Las aplicaciones heredadas que requieren autenticación Kerberos de Active Directory pueden seguir funcionando con métodos sin contraseña, pero las aplicaciones que requieren enlaces NTLM o LDAP directo pueden necesitar una planificación adicional.

Si su entorno es híbrido, planifique la implementación sin contraseña empezando por los dispositivos unidos a Microsoft Entra y expandiéndola a dispositivos unidos a Microsoft Entra híbridos a medida que su infraestructura lo admita.

Más información

macOS

En macOS, la planificación sin contraseña depende de cómo se integre Microsoft Entra ID con la experiencia de inicio de sesión único e inicio de sesión de la plataforma. Microsoft Intune ofrece la configuración de dispositivo necesaria para las integraciones de identidad centradas en Apple.

Con el complemento Microsoft Enterprise SSO y el marco de SSO de plataforma de Apple, Microsoft Intune puede implementar una configuración que permita a los usuarios iniciar sesión en el Mac con sus credenciales de Microsoft Entra ID. Cuando se configura con el método de clave de enclave seguro, ofrece una experiencia de inicio de sesión respaldada por hardware y resistente a la suplantación de identidad, similar a Windows Hello.

Esta información es importante a la hora de planificar:

  • SSO de plataforma y experiencias de inicio de sesión relacionadas.
  • Inicio de sesión único entre el dispositivo y las aplicaciones de Microsoft.
  • Un modelo de administración coherente junto con dispositivos Windows y móviles.

Más información

iOS y iPadOS

En iOS y iPadOS, la planeación sin contraseña se centra más en el inicio de sesión de aplicaciones, la autenticación asincrónica y el comportamiento de clave de paso que en el inicio de sesión del dispositivo. Microsoft Intune implementa y administra las aplicaciones y la configuración que hacen que esas experiencias sean coherentes para los usuarios.

La extensión Microsoft SSO en iOS puede interceptar solicitudes de autenticación en aplicaciones de Microsoft y de terceros, lo que permite un inicio de sesión sin problemas después de la configuración inicial del dispositivo. Microsoft Authenticator actúa como agente de autenticación y también puede almacenar claves de paso enlazadas al dispositivo en iOS 17+ para una autenticación resistente a la suplantación de identidad (phishing).

Más información

Android

En Android, Microsoft Intune establece el contexto administrado del que dependen los flujos de autenticación sin contraseña y con broker. Este contexto es especialmente relevante cuando Microsoft Authenticator o las experiencias de aplicaciones relacionadas forman parte del diseño de acceso móvil.

El Portal de empresa y Microsoft Authenticator pueden actuar como agentes de autenticación en Android. Después de que un usuario inicia sesión a través del agente, Microsoft Entra ID emite un token de actualización principal que habilita el SSO en todas las aplicaciones compatibles con agentes del perfil de trabajo. En Android 14+, Microsoft Authenticator también puede almacenar claves de paso enlazadas al dispositivo para una autenticación resistente a la suplantación de identidad (phishing).

Más información

Dependencias para la autenticación sin contraseña

Arquitectura de Confianza cero

La autenticación sin contraseña es una parte de una estrategia más amplia de identidad y acceso a dispositivos. Para un administrador de Microsoft Intune, la planeación suele implicar estas capas:

  • Identidad: métodos de autenticación resistentes a la suplantación de identidad (phishing) en Microsoft Entra ID.
  • Confianza de dispositivos: inscripción, cumplimiento y configuración de Microsoft Intune.
  • Directiva de acceso: acceso condicional y planificación de exclusión relacionada.
  • Protección de datos: funcionalidades de Microsoft Purview que ayudan a proteger el contenido después de conceder el acceso.
  • Investigación y respuesta: Microsoft Defender señala y flujos de trabajo cuando el riesgo o el peligro necesitan seguimiento.

Más información

Acceso condicional

El acceso condicional evalúa señales como el estado del dispositivo y la intensidad de la autenticación antes de conceder acceso. Cuando se combina con métodos sin contraseña, el acceso condicional puede aplicar directivas de seguridad de autenticación que requieren una MFA resistente a la suplantación de identidad (phishing), lo que exige de forma eficaz sin contraseña al bloquear métodos más débiles como contraseñas o códigos SMS.

Al implementar el acceso condicional sin contraseña, tenga en cuenta también la planificación del acceso de emergencia para evitar escenarios de bloqueo accidental.

Más información

Recuperación y acceso de emergencia

Una preocupación común al quitar contraseñas es lo que sucede cuando un usuario pierde su único dispositivo sin contraseña: un teléfono, una clave FIDO2 o un portátil con Windows Hello. Sin un plan de recuperación, los administradores pueden enfrentarse a escalaciones de soporte técnico y los usuarios pueden quedar excluidos de los recursos críticos.

Planifique estos escenarios como parte de su implementación sin contraseña:

  • Cuentas de acceso de emergencia: mantenga al menos dos cuentas anticipo que estén excluidas de las directivas de acceso condicional y de la aplicación sin contraseña. Estas cuentas proporcionan una ruta de acceso de reserva si una configuración errónea o una interrupción bloquea el resto del acceso. Almacene credenciales de forma segura y supervise la actividad de inicio de sesión en estas cuentas.
  • Recuperación con pase de acceso temporal: cuando un usuario pierde su dispositivo sin contraseña, un administrador puede emitir una nueva TAP para que el usuario pueda iniciar sesión y registrar una credencial de reemplazo. Este enfoque evita restablecer la contraseña del usuario y mantiene el flujo de recuperación dentro del modelo sin contraseña.
  • Varios métodos registrados: anime a los usuarios a registrar más de un método sin contraseña siempre que sea posible. Por ejemplo, un usuario que usa Hello for Business en su portátil también puede registrar una clave de paso en Microsoft Authenticator en su teléfono. Si un dispositivo se pierde, el otro método sigue funcionando.
  • Administración de credenciales de autoservicio: los usuarios pueden administrar sus métodos de autenticación en Mi información de seguridad. Cuando se combina con la recuperación basada en TAP, este enfoque reduce la dependencia del departamento de soporte técnico para restablecer las credenciales.
  • Recuperación total de pérdidas con Id. verificada: para escenarios en los que un usuario pierde todas las credenciales y dispositivos registrados, la recuperación de la cuenta de Microsoft Entra mediante el Id. verificado proporciona una ruta de recuperación verificada por identidad que no depende de contraseñas o credenciales emitidas por el departamento de soporte técnico.

Planear la recuperación antes de aplicar la aplicación sin contraseña es esencial. Un lanzamiento que bloquea las contraseñas sin una ruta de recuperación crea el tipo de escenarios de bloqueo que erosionan la confianza del administrador y del usuario en la transición.

Más información

Cumplimiento y preparación del dispositivo

La ausencia de contraseña suele depender de que el dispositivo se encuentre en el estado correcto para que los usuarios puedan confiar en la experiencia. La preparación normalmente incluye:

Verificación y operaciones en curso

Para validar una implementación sin contraseña, los puntos de control comunes incluyen:

Adopción y comunicación del usuario

La preparación técnica es solo una parte de un lanzamiento sin contraseñas. Los usuarios acostumbrados a las contraseñas pueden experimentar confusión o resistencia cuando cambian los flujos de inicio de sesión. Planear la comunicación y el soporte técnico de los usuarios puede marcar la diferencia entre una transición sin problemas y una escalación generalizada del departamento de soporte técnico.

Tenga en cuenta estas prácticas:

  • Comunique el cambio con antelación: informe a los usuarios de que su experiencia de inicio de sesión está cambiando, por qué está cambiando y qué esperar. Céntrese en las ventajas: menos contraseñas que recordar, inicio de sesión más rápido y mayor seguridad.
  • Proporcione instrucciones específicas de la plataforma: la experiencia sin contraseña es diferente en Windows (biometría de Hola o PIN), macOS (Touch ID con SSO de plataforma), iOS (autenticador o claves de paso) y Android (agente de autenticación). Adapta la comunicación a las plataformas que tienen tus usuarios.
  • Identificar grupos piloto: comience con un grupo de usuarios que puedan probar la experiencia y proporcionar comentarios antes de aplicar la aplicación de la contraseña en toda la organización. El personal de TI, los primeros usuarios y los equipos conscientes de la seguridad suelen ser buenos candidatos.
  • Prepare al personal del departamento de soporte técnico: asegúrese de que su equipo de soporte técnico sepa cómo emitir un pase de acceso temporal para la recuperación, cómo guiar a los usuarios a través del registro de credenciales y dónde comprobar los registros de inicio de sesión cuando surjan problemas.

Más información

  • Last updated on