Autenticación WiFi de Azure AD y Entra ID: Guía de integración y configuración
Esta guía de referencia técnica proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de recintos una hoja de ruta práctica para integrar Microsoft Entra ID (Azure AD) con redes WiFi empresariales mediante RADIUS y 802.1X. Cubre la decisión arquitectónica entre Windows NPS on-premise y RADIUS nativo de la nube, el despliegue de autenticación EAP-TLS basada en certificados a través de Microsoft Intune y las mejores prácticas operativas para asegurar el acceso inalámbrico en entornos de hospitalidad, retail y sector público. Para las organizaciones que ya han invertido en el ecosistema de Microsoft 365 y Entra ID, esta guía cierra la brecha entre la gestión de identidades en la nube y la seguridad de la red física.
Resumen ejecutivo
Para las empresas modernas con una fuerte inversión en el ecosistema de Microsoft, vincular la infraestructura de identidad en la nube con las redes inalámbricas físicas es un imperativo de seguridad crítico. Históricamente, la autenticación WiFi dependía de Active Directory Domain Services (AD DS) on-premise y Windows Network Policy Server (NPS). Sin embargo, a medida que las organizaciones migran a Microsoft Entra ID (anteriormente Azure AD) y adoptan modelos de seguridad zero-trust, el enfoque tradicional de autenticación basado en credenciales — PEAP-MSCHAPv2 — ya no es suficiente ni seguro.
Esta guía proporciona a los gerentes de TI, arquitectos de red y directores de operaciones de recintos una hoja de ruta práctica para implementar la autenticación WiFi de Azure AD. Exploramos las diferencias arquitectónicas entre mantener una infraestructura NPS on-premise y migrar a una solución RADIUS nativa de la nube. De manera crucial, detallamos cómo aprovechar Microsoft Intune para la autenticación basada en certificados (EAP-TLS), lo que elimina las vulnerabilidades relacionadas con las contraseñas y proporciona una experiencia fluida y sin fricciones para los usuarios finales. Ya sea que gestione un hotel de 500 habitaciones, una cadena de retail o un gran despliegue en el sector público, esta guía le ayudará a asegurar su entorno inalámbrico utilizando sus inversiones actuales en identidad de Microsoft. Para una discusión más amplia sobre los modelos de despliegue, consulte nuestra Guía de decisión para equipos de TI: Cloud RADIUS vs. RADIUS On-Premise .
Inmersión técnica profunda: Arquitectura y estándares
La base de una red WiFi empresarial segura es el estándar IEEE 802.1X, que proporciona control de acceso a la red basado en puertos. En un entorno centrado en Microsoft, la integración de 802.1X con Entra ID requiere una planificación arquitectónica cuidadosa en tres capas: la infraestructura inalámbrica, el servidor de autenticación y el directorio de identidades.
El papel de RADIUS y 802.1X
Cuando un dispositivo cliente (el suplicante) intenta conectarse a una red WPA2/WPA3-Enterprise, el punto de acceso inalámbrico (el autenticador) bloquea todo el tráfico excepto los paquetes EAP (Protocolo de Autenticación Extensible). El punto de acceso reenvía estos paquetes a un servidor RADIUS. El servidor RADIUS valida la identidad del usuario o dispositivo contra un servicio de directorio y devuelve un mensaje de Access-Accept o Access-Reject. Este modelo de tres partes — suplicante, autenticador, servidor de autenticación — es la piedra angular de la seguridad inalámbrica empresarial y se describe en detalle en nuestra Definición de puntos de acceso inalámbricos: Su guía definitiva para 2026 .
Enfoques arquitectónicos para entornos Microsoft
Existen dos arquitecturas principales para integrar la identidad de Microsoft con la autenticación WiFi, cada una con distintas compensaciones:
| Dimensión | Híbrido On-Premise (NPS) | Nativo de la nube (Cloud RADIUS) |
|---|---|---|
| Infraestructura | Se requiere VM de Windows Server o bare metal | Sin servidores on-premise |
| Fuente de identidad | AD DS vía LDAP/Kerberos | Entra ID directamente vía API |
| Autoridad de certificación | ADCS on-premise + Conector de Intune | PKI en la nube de Intune o PKI del proveedor |
| Escalabilidad | HA/balanceo de carga manual | Escalado automático por el proveedor |
| Ideal para | AD híbrido, dispositivos heredados | Organizaciones cloud-first gestionadas por Intune |
| Complejidad operativa | Mayor inicial y continua | Menor carga operativa |
Híbrido On-Premise (Windows NPS + AD DS + Azure AD Connect): Este es el enfoque tradicional. Windows NPS actúa como el servidor RADIUS, autenticando las solicitudes contra un Active Directory on-premise. Para vincular esto a la nube, Azure AD Connect sincroniza las identidades on-premise con Entra ID. Aunque es robusto, esto requiere mantener la infraestructura de servidores on-premise, gestionar la alta disponibilidad y desplegar una PKI compleja (ADCS) si se implementa EAP-TLS.
Nativo de la nube (Cloud RADIUS + Entra ID + Intune): Este enfoque moderno elimina la necesidad de servidores NPS on-premise. Un proveedor de Cloud RADIUS de terceros se integra directamente con Entra ID a través de la API de Microsoft Graph. La autenticación ocurre completamente en la nube. Esta arquitectura se alinea con una estrategia cloud-first, reduciendo significativamente la carga operativa y alineándose con los principios de acceso a la red zero-trust.
EAP-TLS vs. PEAP-MSCHAPv2: La elección crítica
La elección del método EAP es la decisión de seguridad más trascental en este despliegue. PEAP-MSCHAPv2 depende de que los usuarios ingresen sus credenciales de dominio. Esto es vulnerable al robo de credenciales, ataques de intermediario (man-in-the-middle) y crea una mala experiencia de usuario cuando las contraseñas caducan. La investigación ha demostrado consistentemente que PEAP-MSCHAPv2 puede verse comprometido a través de ataques de puntos de acceso no autorizados.
EAP-TLS (Transport Layer Security) es el estándar de oro de la industria para WiFi seguro. Utiliza certificados digitales instalados en el dispositivo cliente para la autenticación mutua: tanto el cliente como el servidor demuestran su identidad. No hay contraseñas que escribir y la conexión es criptográficamente sólida. En un entorno Microsoft, los certificados se despliegan típicamente usando Microsoft Intune a través de SCEP (Simple Certificate Enrollment Protocol) o PKCS. Este es el camino recomendado para todos los nuevos despliegues y es esencial para el cumplimiento de PCI DSS (Requisito 8) y las obligaciones de protección de datos de GDPR.
Guía de implementación: Despliegue paso a paso
La implementación de la autenticación Entra ID WiFi mediante EAP-TLS e Intune requiere la coordinación de varios componentes en la infraestructura de identidad, gestión de dispositivos y red. Se recomienda el siguiente enfoque de cinco fases para un despliegue nativo de la nube.
Fase 1: Preparar la infraestructura de gestión de identidades y dispositivos
Comience verificando que su tenant de Entra ID tenga las licencias adecuadas. Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5 incluyen las capacidades de gestión de dispositivos de Intune y el Acceso condicional necesarios para este despliegue. Sin Intune, el despliegue automatizado de certificados no es posible.
A continuación, establezca su infraestructura de clave pública (PKI). Tiene tres opciones: una PKI nativa de la nube proporcionada por su proveedor de Cloud RADIUS, la propia Cloud PKI de Microsoft (disponible con la licencia de Intune Suite) o un despliegue de ADCS local existente conectado a Intune a través del Microsoft Intune Certificate Connector. Para nuevos despliegues, se recomienda encarecidamente una PKI nativa de la nube para evitar dependencias locales.
Fase 2: Configurar Intune para el despliegue de certificados
En el centro de administración de Microsoft Intune, cree un perfil de configuración de Certificado de confianza. Cargue el certificado de la CA raíz de su PKI y despliéguelo en sus grupos de dispositivos de destino. Este paso es crítico: garantiza que los dispositivos cliente confíen en el certificado presentado por el servidor RADIUS durante el handshake de TLS, evitando ataques de intermediario (man-in-the-middle).
A continuación, cree un perfil de Certificado SCEP (o PKCS si su PKI lo requiere). Configure el formato del Nombre del sujeto: para la autenticación basada en el usuario, use CN={{UserPrincipalName}}; para la autenticación basada en el dispositivo, use CN={{DeviceName}} o el número de serie del dispositivo. Configure el Nombre alternativo del sujeto (SAN) para incluir el Nombre principal del usuario o el ID del dispositivo. Asigne ambos perfiles a los grupos de usuarios o dispositivos de Entra ID correspondientes.
Fase 3: Configurar la integración de Cloud RADIUS
Otorgue a su proveedor de Cloud RADIUS los permisos necesarios de la Microsoft Graph API en su tenant de Entra ID. Como mínimo, el proveedor requiere User.Read.All y GroupMember.Read.All para validar las membresías de grupo durante la autenticación. Algunos proveedores también requieren Device.Read.All para políticas basadas en dispositivos.
Dentro del portal de gestión de Cloud RADIUS, defina sus políticas de autenticación. Una política bien estructurada para un entorno corporativo podría decir: "Permitir el acceso si el certificado es emitido por [CA de confianza] Y el usuario es miembro del grupo de Entra ID [Corporate-WiFi-Users] Y el dispositivo está marcado como 'Compliant' en Intune." Esta política por capas aplica simultáneamente tanto la identidad como el estado de salud del dispositivo.
Fase 4: Configurar la infraestructura inalámbrica
En su controlador de LAN inalámbrica o panel de gestión en la nube (como Cisco Meraki, Aruba Central o Juniper Mist), agregue las direcciones IP del servidor Cloud RADIUS y los secretos compartidos como servidores de autenticación RADIUS. Configure servidores primarios y secundarios para redundancia. Establezca el tiempo de espera (timeout) de RADIUS en un mínimo de 5 segundos para dar cabida a la latencia de ida y vuelta de la nube.
Cree un nuevo SSID configurado para WPA2-Enterprise o WPA3-Enterprise. Asigne los servidores RADIUS a este SSID. Para despliegues en Hospitalidad , asegúrese de que este SSID corporativo esté en una VLAN separada de cualquier red de invitados. Para entornos de Retail , considere desplegar el SSID corporativo solo en áreas operativas (back-of-house), manteniendo separada la red del piso de ventas.
Fase 5: Desplegar el perfil de WiFi a través de Intune
Cree un perfil de configuración de WiFi en Intune. Configure el SSID para que coincida exactamente con lo que configuró en la infraestructura inalámbrica. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad. En la configuración de EAP, seleccione EAP-TLS como método de autenticación. Vincule el perfil de certificado SCEP como el certificado de cliente y especifique el perfil de CA raíz de confianza que desplegó en la Fase 2.
Asigne este perfil de WiFi a los mismos grupos de dispositivos que recibieron los perfiles de certificado. Los dispositivos recibirán de forma silenciosa el certificado y la configuración de WiFi durante su próxima sincronización con Intune, y se conectarán automáticamente cuando estén dentro del alcance del SSID, sin necesidad de interacción del usuario.
Mejores prácticas para entornos empresariales
Las siguientes recomendaciones representan el consenso de la industria para despliegues de Microsoft 802.1X seguros y escalables en entornos empresariales.
Exija EAP-TLS en todos los nuevos despliegues. No despliegue nuevas redes utilizando PEAP-MSCHAPv2. Los riesgos de seguridad del WiFi basado en credenciales están bien documentados y son incompatibles con una postura de seguridad de confianza cero (zero-trust). EAP-TLS es esencial para el cumplimiento de PCI DSS, GDPR e ISO 27001.
Automatice el ciclo de vida de los certificados. Asegúrese de que cuando se deshabilite a un usuario en Entra ID o se retire un dispositivo en Intune, el certificado correspondiente se revoque automáticamente o la política de RADIUS bloquee el acceso de inmediato. Esto es particularmente importante en entornos de alta rotación como Hospitalidad y Retail , donde los cambios de personal son frecuentes.
Implemente el Acceso condicional de Entra ID. Aproveche las políticas de Acceso condicional para exigir el cumplimiento de los dispositivos como condición para el acceso a la red. Requerir que los dispositivos estén marcados como 'Compliant' en Intune antes de que puedan autenticarse en RADIUS garantiza que solo los dispositivos con parches al día y que cumplen con las políticas accedan a la red corporativa.
Segmente rigurosamente las redes corporativas y de invitados. 802.1X está diseñado para dispositivos corporativos gestionados. Para visitantes, contratistas y BYOD, implemente una solución de Guest WiFi dedicada con un captive portal. Esto puede integrarse con Entra ID B2B para el acceso de contratistas, o utilizar inicios de sesión de redes sociales y verificación por SMS para el acceso del público en general. Nunca permita dispositivos no gestionados en el SSID 802.1X corporativo.
Planifique para dispositivos heredados e IoTdispositivos.** Las impresoras, los sensores de IoT y los dispositivos heredados que no admiten certificados requieren una estrategia independiente. Utilice MAC Authentication Bypass (MAB) para dispositivos conocidos, o un SSID WPA2-Personal dedicado con una PSK compleja y rotativa, aislada en una VLAN dedicada. La plataforma Sensors de Purple, por ejemplo, puede operar en una VLAN de IoT dedicada, independiente de la infraestructura de autenticación corporativa.
Monitoree los eventos de autenticación. Integre los registros de RADIUS con su SIEM o utilice la plataforma WiFi Analytics para monitorear fallas de autenticación, advertencias de vencimiento de certificados y patrones de acceso inusuales. El monitoreo proactivo evita interrupciones antes de que afecten las operaciones.
Resolución de problemas y mitigación de riesgos
Incluso las implementaciones bien planificadas encuentran problemas. A continuación, se presentan los modos de falla más comunes y sus soluciones.
Fallas en el despliegue de certificados. El problema más común en un despliegue de EAP-TLS es que los dispositivos no reciben los certificados de Intune. Esto suele deberse a un Intune Certificate Connector mal configurado (si se utiliza ADCS on-premise), una URL de SCEP incorrecta o dispositivos que no se sincronizan con Intune. Verifique siempre el estado del Certificate Connector en el centro de administración de Intune y revise los registros de sincronización de los dispositivos. Asegúrese de que la cuenta de servicio de SCEP tenga los permisos necesarios en la CA.
Problemas de tiempo de espera de RADIUS. Si el punto de acceso no puede comunicarse con el servidor RADIUS dentro del tiempo de espera configurado, los clientes no podrán conectarse. Asegúrese de que las reglas de su firewall permitan los puertos UDP 1812 (autenticación) y 1813 (contabilidad) de salida hacia los rangos de IP del proveedor de Cloud RADIUS. Si utiliza NPS on-premise, despliegue al menos dos servidores NPS y configure sus puntos de acceso para la conmutación por error (failover) entre ellos.
Fallas de confianza en el certificado. Si los clientes reciben un error de "certificado de servidor no confiable", el perfil de la CA raíz de confianza no se ha desplegado correctamente en el dispositivo. Verifique la asignación del perfil en Intune y revise el almacén de certificados del dispositivo. Este es un problema común con dispositivos recién inscritos que aún no han completado su primera sincronización con Intune.
Extensión NPS para Azure MFA. Aunque técnicamente es posible utilizar la extensión NPS para aplicar la autenticación multifactor en WiFi, se desaconseja firmemente para el acceso principal. La experiencia del usuario al recibir una solicitud de MFA cada vez que un dispositivo se desplaza entre puntos de acceso es sumamente disruptiva. Confíe en la autenticación sólida proporcionada por el certificado del dispositivo y, en su lugar, aplique MFA en la capa de aplicación.
Conflictos de directivas de grupo. En entornos híbridos, los objetos de directiva de grupo (GPO) que configuran el cliente inalámbrico de Windows pueden entrar en conflicto con los perfiles de WiFi de Intune. Asegúrese de que los perfiles de Intune tengan prioridad revisando la configuración de inscripción de MDM y, cuando sea necesario, bloqueando la configuración inalámbrica basada en GPO para los dispositivos gestionados por Intune.
ROI e impacto empresarial
La migración a una arquitectura RADIUS nativa de la nube integrada con Entra ID ofrece un valor medible y cuantificable en varias dimensiones.
Reducción de tickets de soporte. Los problemas de WiFi relacionados con contraseñas (bloqueos, contraseñas vencidas, suplicantes mal configurados) son una fuente importante de tickets de soporte de TI en entornos basados en credenciales. EAP-TLS los elimina por completo. Las organizaciones suelen informar una reducción del 30 al 50% en el volumen de tickets de soporte relacionados con WiFi tras la migración a la autenticación basada en certificados.
Ahorro en costos de infraestructura. El desmantelamiento de los servidores NPS on-premise reduce los costos de cómputo, las tarifas de licencia del SO y la carga operativa de parchar y mantener clústeres de alta disponibilidad. Para una organización mediana que opera dos servidores NPS, esto puede representar ahorros de entre £15,000 y £30,000 al año en costos operativos y de infraestructura.
Mejora de la postura de seguridad y cumplimiento. Abandonar la autenticación basada en credenciales mitiga el riesgo de robo de credenciales y movimiento lateral, protegiendo los datos corporativos confidenciales. Para las organizaciones sujetas a PCI DSS, esto aborda directamente los requisitos de control de acceso a la red. Para las organizaciones de Salud que manejan datos de pacientes, respalda el cumplimiento de DSPT. Para los operadores de Transporte , se alinea con los requisitos de la Directiva NIS2 para la seguridad de la red.
Mejora de la experiencia del usuario. La conexión WiFi automática y fluida, sin solicitudes de contraseña, bloqueos ni configuración manual, mejora la productividad y reduce la fricción para el personal. Esto es particularmente impactante en entornos de alta movilidad, como centros de distribución, salas de hospitales y pisos de venta minorista.
Al tratar su red WiFi como una extensión de su estrategia de identidad en la nube, garantiza un acceso seguro y sin fricciones que escala con su organización. Para obtener más orientación sobre los aspectos de integración de SD-WAN en las redes empresariales modernas, consulte Los beneficios principales de SD-WAN para las empresas modernas . Para consideraciones de despliegue específicas para el sector de la hospitalidad, consulte Soluciones modernas de WiFi para hospitalidad que sus huéspedes merecen .
Términos clave y definiciones
802.1X
An IEEE standard for port-based Network Access Control (PNAC). It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN, preventing unauthorised access before authentication is complete.
The foundational protocol that prevents unauthorised devices from accessing the enterprise network. All WPA2/WPA3-Enterprise deployments rely on 802.1X.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users who connect and use a network service. Defined in RFC 2865.
The server component that validates credentials or certificates against the directory (Entra ID or AD DS) and instructs the access point to grant or deny access.
Supplicant
The client device (laptop, smartphone, IoT device) attempting to connect to the network. In Windows, the built-in wireless client acts as the supplicant.
In Intune deployments, the supplicant must be configured with the correct WiFi profile and client certificate to communicate successfully with the RADIUS server.
Authenticator
The network device — typically a Wireless Access Point or managed switch — that facilitates the authentication process between the supplicant and the RADIUS server. It enforces access control based on the RADIUS response.
The access point must be configured with the RADIUS server IP address and shared secret. It acts as a relay, forwarding EAP packets between the client and the RADIUS server.
EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)
An EAP method that relies on digital certificates for mutual authentication between the client and the RADIUS server. It is defined in RFC 5216 and is considered one of the most secure EAP standards available.
The recommended authentication method for all new Microsoft 802.1X deployments. It eliminates passwords entirely and is required for compliance with PCI DSS and zero-trust network access frameworks.
NPS (Network Policy Server)
Microsoft's implementation of a RADIUS server and proxy, available as a role in Windows Server. NPS can authenticate users and devices against Active Directory Domain Services.
The traditional on-premise solution for enterprise WiFi authentication in Microsoft environments. Many organisations are now migrating from NPS to Cloud RADIUS solutions as they move to Entra ID.
SCEP (Simple Certificate Enrollment Protocol)
A protocol used for issuing digital certificates to network devices in a scalable, automated manner. Defined in RFC 8894.
The primary method Microsoft Intune uses to silently deploy client certificates to managed devices for EAP-TLS WiFi authentication. Requires a SCEP-compatible Certificate Authority.
Microsoft Entra ID
Microsoft's cloud-based identity and access management service, formerly known as Azure Active Directory. It provides user authentication, group management, Conditional Access, and integration with thousands of applications.
The central identity provider in modern Microsoft environments. Cloud RADIUS solutions integrate with Entra ID via Microsoft Graph API to validate user and device identities during WiFi authentication.
Conditional Access
An Entra ID feature that enforces access policies based on signals such as user identity, device compliance status, location, and risk level. Policies can require devices to be Intune-compliant before granting access.
Used in advanced RADIUS deployments to ensure that only compliant, managed devices can authenticate to the corporate WiFi network, even if they present a valid certificate.
PEAP-MSCHAPv2
Protected EAP with Microsoft Challenge Handshake Authentication Protocol version 2. A credential-based EAP method that uses a username and password for authentication, tunnelled within a TLS session.
The legacy authentication method used in many existing NPS deployments. It is vulnerable to credential theft and man-in-the-middle attacks and should be migrated to EAP-TLS in all new deployments.
Casos de éxito
A 200-location retail chain needs to secure their back-office WiFi for store manager laptops. They currently use a shared WPA2-Personal password (PSK) across all stores, which is rarely rotated. They use Entra ID and Intune for device management. How should they modernise their wireless security?
The retail chain should migrate to WPA3-Enterprise using EAP-TLS across all 200 locations. The recommended architecture is a Cloud RADIUS solution integrated directly with their Entra ID tenant, eliminating the need for on-premise NPS servers at each site. Using Intune, they deploy a SCEP certificate profile to issue unique device certificates to the store manager laptops. A Trusted Root CA profile is deployed first to ensure devices trust the RADIUS server. A WiFi configuration profile is then deployed via Intune, silently connecting devices to the new SSID using the issued certificate. The old PSK SSID is decommissioned once all devices have migrated. For the store's customer-facing WiFi, a separate captive portal solution handles guest access without impacting the corporate authentication infrastructure.
A large conference centre uses on-premise Windows NPS for staff WiFi authentication. They are experiencing frequent connectivity failures during large events because the NPS server becomes overwhelmed with concurrent authentication requests from 500+ staff devices. They are also migrating their identity infrastructure to Entra ID. What is the recommended architecture going forward?
The conference centre should migrate from the on-premise NPS server to a Cloud RADIUS provider that integrates directly with Entra ID. Staff devices should be transitioned to certificate-based authentication (EAP-TLS) managed via Intune, resolving both the scalability issue and the Entra ID migration requirement simultaneously. For the high volume of event attendees, a separate, segmented network using a captive portal solution handles guest onboarding without impacting the corporate RADIUS infrastructure. The two networks should be on separate VLANs with appropriate firewall rules between them. The on-premise NPS server can be decommissioned once all staff devices have successfully migrated.
Análisis de escenarios
Q1. Your organisation is completing a full migration from on-premise Active Directory to Entra ID only — no on-premise domain controllers will remain. You currently use Windows NPS for WiFi authentication using PEAP-MSCHAPv2. What is the most secure and operationally efficient approach for the new cloud-only environment, and what specific steps are required?
💡 Sugerencia:Consider what NPS requires to function and whether those dependencies will exist post-migration. Also consider the security implications of the current EAP method.
Mostrar enfoque recomendado
The most secure and efficient approach is to implement a Cloud RADIUS solution integrated directly with Entra ID, and transition to EAP-TLS certificate-based authentication managed via Microsoft Intune. NPS cannot authenticate against Entra ID directly — it requires on-premise AD DS — so it cannot survive the migration without Azure AD Connect maintaining a hybrid identity. The steps are: (1) Select a Cloud RADIUS provider and grant it Microsoft Graph API permissions in Entra ID. (2) Establish a cloud-native PKI or use Microsoft Cloud PKI. (3) Deploy Trusted Root CA and SCEP certificate profiles via Intune. (4) Deploy a WiFi configuration profile via Intune configured for EAP-TLS. (5) Configure the SSID on the wireless infrastructure to use the Cloud RADIUS servers. (6) Decommission NPS once all devices have migrated.
Q2. A hospital IT team wants to implement 802.1X for their medical carts (Windows laptops) using Entra ID. They want to ensure that if a cart is stolen, it cannot connect to the network even if the associated user account is still active. How should the certificate profile and RADIUS policy be configured to achieve this?
💡 Sugerencia:Consider the difference between user-based and device-based certificate profiles in Intune, and how RADIUS policies can be scoped to device identity.
Mostrar enfoque recomendado
The IT team should configure Intune to deploy device certificates (not user certificates) to the medical carts. In the SCEP profile, the Subject Name should reference the device identity (e.g., CN={{DeviceName}} or the device serial number) rather than the user UPN. The RADIUS policy should be configured to authenticate the device certificate and validate the device against Entra ID device objects. If a cart is stolen, the IT team can remotely wipe the device via Intune (which removes the certificate from the device's certificate store) or revoke the specific device certificate in the PKI. Either action immediately blocks network access without affecting any user accounts. This approach is superior to user-based certificates for shared devices like medical carts.
Q3. You have successfully deployed EAP-TLS via Intune for all 800 corporate laptops across a university campus. However, the IT department frequently brings in external contractors who need internet access for project work. These contractors use their own personal or company-issued laptops that are not enrolled in your Intune tenant. How should you provide access for these contractors without compromising the security of the corporate 802.1X network?
💡 Sugerencia:Remember the architectural principle separating managed device authentication from unmanaged device access. Consider how Entra ID B2B could be leveraged.
Mostrar enfoque recomendado
Do not attempt to provision 802.1X access for unmanaged contractor devices. Instead, deploy a separate Guest SSID backed by a Captive Portal solution. For contractors who have their own corporate Entra ID tenants, configure the captive portal to support Entra ID B2B collaboration, allowing them to authenticate with their own corporate credentials via the portal. For contractors without a compatible identity provider, use a sponsored access workflow where a university staff member approves the access request. The contractor network should be on a separate VLAN with internet-only access and no route to internal university resources. This maintains the integrity of the 802.1X corporate network while providing a secure, auditable access path for external parties.
Q4. During a post-deployment review, your security team flags that several devices on the corporate WiFi are still using PEAP-MSCHAPv2 despite the EAP-TLS rollout. Investigation reveals these are IoT devices — smart displays, environmental sensors, and a fleet of network printers — that do not support certificate-based authentication. How should these devices be handled?
💡 Sugerencia:Consider the options available for devices that cannot support EAP-TLS, and the importance of network segmentation.
Mostrar enfoque recomendado
IoT devices and legacy hardware that cannot support EAP-TLS should not be placed on the corporate 802.1X SSID. The recommended approach is to create a dedicated IoT SSID on a separate VLAN with strict firewall rules limiting communication to only the services those devices require (e.g., print servers, management platforms). For authentication, use MAC Authentication Bypass (MAB) for devices with known, fixed MAC addresses, or a WPA2-Personal SSID with a complex, regularly rotated PSK. The IoT VLAN should have no access to corporate file shares, Active Directory, or sensitive internal resources. Purple's Sensors platform, for example, is designed to operate on a dedicated IoT network segment, separate from corporate infrastructure.
Conclusiones clave
- ✓Traditional on-premise Windows NPS servers are being replaced by Cloud RADIUS solutions that integrate directly with Entra ID, eliminating on-premise infrastructure dependencies.
- ✓Credential-based authentication (PEAP-MSCHAPv2) is a significant security risk and should be migrated to EAP-TLS certificate-based authentication in all new and existing deployments.
- ✓EAP-TLS is the gold standard for secure, passwordless WiFi — certificates are deployed silently via Microsoft Intune using SCEP or PKCS profiles.
- ✓Microsoft Intune is the cornerstone of a modern Microsoft WiFi authentication stack, managing the full certificate lifecycle from issuance to revocation.
- ✓802.1X is designed exclusively for Intune-managed corporate devices; unmanaged guests and contractors must use a separate Captive Portal solution.
- ✓Entra ID Conditional Access can enforce device compliance as a prerequisite for WiFi authentication, ensuring only patched and policy-compliant devices connect.
- ✓RADIUS ports 1812 (authentication) and 1813 (accounting) must be open outbound from the wireless infrastructure to the RADIUS server — this is the most common cause of deployment failures.
