Cómo usar Microsoft Intune para enviar certificados WiFi a dispositivos

Una referencia técnica completa para líderes de TI sobre la implementación de certificados WiFi 802.1X a través de Microsoft Intune. Cubre la arquitectura SCEP vs PKCS, los pasos de implementación, el mapeo de cumplimiento y los escenarios de implementación en el mundo real para entornos empresariales.

📖 7 GuidesSlugPage.minRead📝 1,541 GuidesSlugPage.words🔧 2 GuidesSlugPage.workedExamples❓ 3 GuidesSlugPage.practiceQuestions📚 8 GuidesSlugPage.keyDefinitions

GuidesSlugPage.podcastTitle

GuidesSlugPage.podcastTranscript

HOW TO USE MICROSOFT INTUNE TO PUSH WIFI CERTIFICATES TO DEVICES
A Purple Enterprise WiFi Intelligence Briefing

[INTRODUCTION & CONTEXT — approximately 1 minute]

Welcome back. I'm speaking today on behalf of Purple, the enterprise WiFi intelligence platform, and this episode is a focused briefing on one of the most practical — and honestly, most underrated — capabilities in the Microsoft Intune toolkit: automated certificate deployment for 802.1X WiFi authentication.

If you're managing WiFi across a hotel estate, a retail chain, a stadium, or a public-sector estate, you'll know the pain point I'm about to describe. You've got hundreds or thousands of managed devices. You want them to connect to your corporate WiFi automatically, securely, without users typing passwords, without IT touching every single device. And you want that connection to be cryptographically strong — not just a shared password that someone's already emailed to half the organisation.

That's exactly what Intune certificate deployment solves. And in the next nine minutes, I'm going to walk you through how it works, how to deploy it, and the pitfalls that catch most teams out on the first attempt.

[TECHNICAL DEEP-DIVE — approximately 5 minutes]

Let's start with the architecture. The foundation here is IEEE 802.1X — the port-based network access control standard that's been the backbone of enterprise WiFi security for over two decades. When a device connects to your WiFi, 802.1X requires it to authenticate before it gets any network access. The authentication conversation happens between three parties: the device — called the supplicant — your WiFi access point, which acts as the authenticator, and your RADIUS server, which is the authentication server that makes the final decision.

Now, 802.1X supports multiple authentication methods. The most secure is EAP-TLS — Extensible Authentication Protocol with Transport Layer Security. EAP-TLS uses mutual certificate authentication: the device presents a certificate to prove its identity, and the RADIUS server presents a certificate to prove its identity. No passwords involved. No credentials that can be phished. This is what we're aiming for.

The challenge has always been getting those certificates onto devices at scale. That's where Microsoft Intune comes in.

Intune supports two certificate deployment mechanisms: SCEP — Simple Certificate Enrollment Protocol — and PKCS, which stands for Public Key Cryptography Standards. Understanding the difference matters.

With SCEP, the private key is generated on the device itself. The device creates a Certificate Signing Request, sends it to your Certificate Authority via an intermediary server called NDES — the Network Device Enrollment Service — and the CA issues the certificate back. The private key never leaves the device. This is the more secure approach and is recommended for BYOD environments and high-security deployments.

With PKCS, the Certificate Authority generates the key pair, and the Intune Certificate Connector delivers the private key and certificate to the device. It's simpler to set up — no NDES server required — but the private key does transit through the connector, which is a consideration for your security posture.

For most enterprise deployments I'd recommend SCEP for BYOD and mixed-device environments, and PKCS where you have a homogeneous fleet of corporate-owned Windows devices and want to minimise infrastructure complexity.

Now, let's talk about the deployment sequence — because the order matters and getting it wrong is the most common cause of failed rollouts.

Step one: configure your Certificate Authority. You need a certificate template on your Active Directory Certificate Services instance — or if you're fully cloud-native, Microsoft's Intune Cloud PKI is now generally available and removes the on-premises CA requirement entirely. The template needs the correct key usage extensions: Client Authentication is mandatory. Set the minimum key size to 2048 bits, or 4096 if your organisation's security policy requires it.

Step two: deploy the trusted root certificate. Before any device can validate the RADIUS server's certificate, it needs to trust the CA that issued it. You create a Trusted Certificate configuration profile in Intune, upload the root CA certificate, and assign it to your device groups. This must land on devices before any WiFi profile or client certificate profile. If you get the sequencing wrong, devices will reject the RADIUS server and you'll spend an afternoon staring at Event ID 20271 in the Windows event log.

Step three: deploy the client certificate profile. This is either your SCEP profile — pointing at your NDES server URL — or your PKCS profile, pointing at your Certificate Authority. The Subject Alternative Name should include the User Principal Name for user certificates, or the AAD Device ID for device certificates. This distinction matters: user certificates authenticate the logged-in user, device certificates authenticate the machine itself, which means the device can connect to WiFi before a user logs in — useful for domain join scenarios and kiosk deployments.

Step four: create the WiFi configuration profile. In Intune, this is under Devices, Configuration Profiles, Templates, Wi-Fi. Set the WiFi type to Enterprise, enter your SSID, set EAP type to EAP-TLS, configure the server trust settings — this is where you reference the RADIUS server certificate name — and for client authentication, reference the certificate profile you created in step three.

Step five: assign everything to the right groups and validate. Assign your root certificate, client certificate, and WiFi profiles to the same device or user groups. Use Intune's built-in reporting to monitor profile deployment status. A successful deployment shows all three profiles as Succeeded in the device's configuration profile list.

One critical point on NPS configuration for Windows Server environments: from early 2024, Microsoft tightened certificate mapping requirements. If you're using device certificates with Azure AD-joined devices authenticating against on-premises NPS, you need to ensure the altSecurityIdentities attribute on the computer object in Active Directory is populated with the certificate's thumbprint. This doesn't happen automatically — you need a script or a workflow to handle it, typically triggered when the CA issues a new certificate.

[IMPLEMENTATION RECOMMENDATIONS & PITFALLS — approximately 2 minutes]

Let me give you the three pitfalls that I see most frequently in enterprise deployments.

Pitfall one: certificate chain gaps. The device needs to trust every certificate in the chain from the root CA down to the RADIUS server's certificate. If your RADIUS server certificate was issued by an intermediate CA, you need to deploy both the root and the intermediate to devices. I've seen deployments fail for weeks because someone deployed the root but not the intermediate.

Pitfall two: profile assignment timing. Intune profiles don't land on devices instantaneously. In a large estate, it can take 15 to 30 minutes for profiles to propagate after assignment. Don't test immediately after creating profiles. Use the Sync button in the Intune portal to force a check-in, then wait. Also, client certificate profiles must be deployed and confirmed before the WiFi profile is applied — if the WiFi profile references a certificate that doesn't exist yet, the profile will fail silently on some platforms.

Pitfall three: BYOD certificate revocation. When a device is unenrolled from Intune — because an employee leaves, or a device is lost — you need a process to revoke the certificate. If you're using SCEP with ADCS, configure the Certificate Revocation List distribution point correctly and ensure your RADIUS server is checking CRL or OCSP on every authentication. This is a compliance requirement under frameworks like PCI DSS, which mandates that access control mechanisms be revoked promptly when no longer needed.

On the topic of compliance: if you're operating in a PCI DSS scope — retail payment environments, for example — certificate-based 802.1X authentication is your strongest control for wireless network access. It satisfies PCI DSS Requirement 1.3 around network access controls and Requirement 8.6 around authentication factors. Document your certificate lifecycle management process as part of your compliance evidence.

For GDPR-regulated environments, particularly in hospitality and public-sector, the separation between your corporate 802.1X network and your guest WiFi network is critical. Your corporate Intune-managed network should be on a completely separate VLAN and SSID from any guest or visitor network. Purple's guest WiFi platform handles the visitor-facing side — captive portal, consent capture, analytics — while your Intune-managed corporate network handles staff and operational devices. These two networks should never share authentication infrastructure.

[RAPID-FIRE Q&A — approximately 1 minute]

Let me run through a few questions that come up regularly.

Can I use Intune Cloud PKI instead of on-premises ADCS? Yes. Microsoft's Intune Cloud PKI, released in 2024, provides a fully managed CA in Azure. It removes the NDES server requirement for SCEP and simplifies the connector setup significantly. For greenfield deployments or organisations without existing ADCS infrastructure, it's the recommended path.

Does this work for macOS and iOS devices? Yes. Intune supports certificate profiles for Windows, iOS, iPadOS, Android, and macOS. The profile types and configuration options vary slightly by platform, but the core architecture — trusted root, client certificate, WiFi profile — is consistent.

What about personal devices in a BYOD programme? SCEP is your friend here. With Intune's device compliance policies, you can require that a device meets minimum security standards before a certificate is issued. If the device falls out of compliance — no screen lock, outdated OS — the certificate can be revoked and network access removed automatically.

Can Purple integrate with this architecture? Absolutely. Purple's platform sits on the guest network side, handling captive portal authentication, consent management, and analytics. The corporate 802.1X network and Purple's guest WiFi operate in parallel — same physical infrastructure, different SSIDs and VLANs — giving you complete separation between staff connectivity and visitor engagement.

[SUMMARY & NEXT STEPS — approximately 1 minute]

To wrap up: deploying WiFi certificates via Intune is a five-step process — CA configuration, trusted root deployment, client certificate profile, WiFi profile, and group assignment. Choose SCEP for BYOD and high-security environments; PKCS for simpler corporate-owned fleets. Get the sequencing right, handle the NPS certificate mapping requirement, and build a certificate revocation workflow from day one.

The business case is straightforward: you eliminate shared WiFi passwords, you get per-device and per-user authentication logs, you satisfy PCI DSS and ISO 27001 wireless security requirements, and you reduce the IT overhead of managing WiFi credentials across a large estate.

If you're planning a deployment and want to understand how Purple's guest WiFi and analytics platform fits alongside your corporate network architecture, visit purple.ai. We've got detailed guides on Azure Entra ID integration, 802.1X architecture, and guest network design for hospitality, retail, and public-sector environments.

Thanks for listening. Until next time.

GuidesSlugPage.keyTakeawaysTitle

✓EAP-TLS is the industry standard for secure enterprise WiFi, replacing vulnerable shared passwords with mutual certificate authentication.
✓Microsoft Intune automates the delivery of these certificates at scale, eliminating manual IT overhead.
✓SCEP is recommended for BYOD and high-security environments because the private key never leaves the device.
✓PKCS is suitable for corporate-owned, fully managed device fleets due to its simpler infrastructure requirements.
✓Profile sequencing is critical: always deploy the Trusted Root CA first, the Client Certificate second, and the WiFi profile last.
✓Corporate 802.1X networks must be logically separated from visitor networks (like those managed by Purple Guest WiFi) to maintain security boundaries.
✓For Windows NPS environments, ensure the Active Directory computer object's altSecurityIdentities attribute is mapped to the device certificate to prevent authentication failures.

Resumen Ejecutivo

Para líderes de TI empresariales que gestionan entornos a gran escala en Hospitalidad , Venta al por menor o recintos del sector público, el acceso inalámbrico seguro es un requisito operativo básico. Confiar en PSKs compartidas (Claves Precompartidas) o en la autenticación de nombre de usuario/contraseña (PEAP-MSCHAPv2) expone la red al robo de credenciales, phishing y fallos de cumplimiento. El estándar de la industria para una seguridad WiFi empresarial robusta es 802.1X con EAP-TLS (Protocolo de Autenticación Extensible con Seguridad de Capa de Transporte), que exige la autenticación mutua basada en certificados entre el dispositivo y la red.

Sin embargo, la principal barrera para la adopción de EAP-TLS ha sido históricamente la sobrecarga operativa de la gestión del ciclo de vida de los certificados. Microsoft Intune resuelve esto automatizando la entrega, renovación y revocación de certificados digitales a dispositivos gestionados a escala.

Esta referencia técnica detalla la arquitectura, las metodologías de implementación (SCEP vs PKCS) y los pasos de implementación necesarios para enviar certificados WiFi a través de Microsoft Intune. Proporciona orientación práctica para arquitectos de red e ingenieros de sistemas encargados de asegurar las comunicaciones corporativas mientras mantienen una estricta separación de las redes de visitantes, como las gestionadas por una plataforma de WiFi para Invitados .

Análisis Técnico Detallado: Arquitectura y Protocolos

Para implementar la autenticación basada en certificados de manera efectiva, los equipos de TI deben comprender la interacción entre la plataforma de Gestión de Dispositivos Móviles (MDM), la Infraestructura de Clave Pública (PKI) y la capa de control de acceso a la red.

El Marco de Autenticación 802.1X

El estándar IEEE 802.1X define el control de acceso a la red basado en puertos. En un contexto inalámbrico, evita que un dispositivo transmita cualquier tráfico (que no sean tramas de autenticación EAP) hasta que su identidad sea verificada. La arquitectura consta de tres componentes:

Solicitante: El dispositivo cliente (laptop, smartphone, tablet) que solicita acceso a la red.
Autenticador: El punto de acceso inalámbrico o controlador de LAN inalámbrica que bloquea el tráfico hasta que la autenticación se realiza con éxito.
Servidor de Autenticación: El servidor RADIUS (Remote Authentication Dial-In User Service), como Microsoft Network Policy Server (NPS) o Cisco ISE, que valida las credenciales y autoriza el acceso.

EAP-TLS y Autenticación Mutua

EAP-TLS es el método EAP más seguro porque requiere autenticación mutua. El servidor RADIUS presenta su certificado al solicitante para demostrar que es la red corporativa legítima (previniendo ataques de gemelo malvado), y el solicitante presenta su certificado de cliente al servidor RADIUS para demostrar que es un dispositivo o usuario autorizado.

Mecanismos de Implementación de Certificados de Intune: SCEP vs PKCS

Microsoft Intune soporta dos protocolos principales para la implementación de certificados de cliente en dispositivos. Seleccionar el mecanismo apropiado es una decisión arquitectónica crítica.

Protocolo Simple de Inscripción de Certificados (SCEP)

Con SCEP, la clave privada se genera directamente en el dispositivo cliente. El dispositivo crea una Solicitud de Firma de Certificado (CSR) y la envía a través de Intune al servidor del Servicio de Inscripción de Dispositivos de Red (NDES), que actúa como proxy para la infraestructura de Servicios de Certificados de Active Directory (ADCS). La CA emite el certificado, que se devuelve al dispositivo.

Debido a que la clave privada nunca sale del dispositivo, SCEP se considera altamente seguro y es el enfoque recomendado para implementaciones BYOD (Trae Tu Propio Dispositivo) y arquitecturas de confianza cero.

Estándares de Criptografía de Clave Pública (PKCS)

Con PKCS, el Conector de Certificados de Intune solicita el certificado a la CA en nombre del dispositivo. La CA genera tanto el certificado público como la clave privada, que el conector luego entrega de forma segura al dispositivo a través de Intune.

Si bien PKCS simplifica los requisitos de infraestructura (no se necesita un servidor NDES), la clave privada se transmite a través de la red. Este modelo es generalmente aceptable para flotas de dispositivos propiedad de la empresa y totalmente gestionados donde la plataforma MDM ya es un componente de alta confianza.

Guía de Implementación: Despliegue Paso a Paso

La implementación de certificados WiFi a través de Intune requiere una secuencia precisa. La implementación de perfiles fuera de orden es la causa más común de fallos en la implementación.

Paso 1: Preparar la Infraestructura de Clave Pública (PKI)

Ya sea utilizando ADCS local o una solución nativa de la nube como Microsoft Cloud PKI, la Autoridad de Certificación debe configurarse con las plantillas apropiadas.

Uso de Clave: La plantilla debe incluir el OID Client Authentication (1.3.6.1.5.5.7.3.2).
Tamaño de Clave: Configure un tamaño de clave mínimo de 2048 bits (RSA) para alinearse con los estándares criptográficos modernos.
Nombre del Sujeto: Para certificados de usuario, el Nombre Alternativo del Sujeto (SAN) debe configurarse para usar el Nombre Principal de Usuario (UPN). Para certificados de dispositivo, use el ID de Dispositivo de Azure AD.

Paso 2: Implementar el Certificado Raíz de Confianza

Antes de que un dispositivo pueda autenticarse, debe confiar en la CA que emitió el certificado del servidor RADIUS.

Exporte el certificado de la CA Raíz (y cualquier certificado de CA intermedio) en .cer" formato.
En el centro de administración de Intune, navegue a Dispositivos > Perfiles de configuración > Crear perfil.
Seleccione la plataforma y elija el tipo de perfil Certificado de confianza.
Cargue el archivo .cer y asigne el perfil al dispositivo o grupos de usuarios de destino.

Nota: Este perfil debe aplicarse correctamente a los dispositivos antes de continuar con los siguientes pasos.

Paso 3: Implementar el perfil de certificado de cliente

Cree un perfil de certificado SCEP o PKCS para entregar el certificado de identidad al solicitante.

Navegue a Dispositivos > Perfiles de configuración > Crear perfil.
Seleccione la plataforma y elija Certificado SCEP o Certificado PKCS.
Configure el formato del Nombre del Sujeto y SAN de acuerdo con sus requisitos de identidad (Usuario vs. Dispositivo).
Especifique el Proveedor de Almacenamiento de Claves (KSP) — típicamente el Módulo de Plataforma Confiable (TPM) para seguridad respaldada por hardware.
Asigne el perfil a los mismos grupos objetivo del Paso 2.

Paso 4: Configurar el perfil de WiFi

El componente final vincula los certificados a la configuración de la red inalámbrica.

Navegue a Dispositivos > Perfiles de configuración > Crear perfil.
Seleccione la plataforma y elija el tipo de perfil de Wi-Fi.
Establezca el tipo de Wi-Fi en Empresarial e ingrese el SSID exacto.
Establezca el tipo de EAP en EAP-TLS.
En Confianza del servidor, especifique el nombre exacto del certificado del servidor RADIUS y seleccione el perfil de certificado de raíz de confianza implementado en el Paso 2.
En Autenticación de cliente, seleccione el perfil de certificado SCEP o PKCS implementado en el Paso 3.
Asigne el perfil a los grupos de destino.

Mejores prácticas y recomendaciones estratégicas

Certificados de dispositivo vs. de usuario

Los arquitectos de red deben decidir si emitir certificados al dispositivo (autenticación de máquina) o al usuario (autenticación de usuario).

Certificados de dispositivo: Permiten que la máquina se conecte a la red WiFi antes de que un usuario inicie sesión. Esto es crítico para el aprovisionamiento inicial del dispositivo, el procesamiento de políticas de grupo y los restablecimientos de contraseña en la pantalla de inicio de sesión. Recomendado para dispositivos propiedad de la empresa.
Certificados de usuario: Vinculan el acceso a la red con la identidad del individuo. Esto proporciona auditorías granulares y control de acceso basado en roles. Recomendado para escenarios BYOD.

Segmentación de red y acceso de invitados

Un principio de seguridad fundamental es la estricta separación lógica de la red corporativa 802.1X de las redes de acceso para visitantes o públicas. La infraestructura gestionada por Intune debe dedicarse exclusivamente a dispositivos corporativos y personal autenticado.

Para el acceso de visitantes, las organizaciones deben implementar un SSID Guest WiFi dedicado respaldado por un Captive Portal. Esto asegura que los dispositivos no gestionados estén aislados, al mismo tiempo que permite a la empresa capturar análisis de visitantes a través de una plataforma de WiFi Analytics . Para obtener más información sobre cómo proteger la infraestructura DNS en ambos segmentos, revise nuestra guía sobre cómo Proteger su red con DNS y seguridad robustos .

Abordar el requisito de mapeo de certificados de NPS

Para las organizaciones que utilizan Microsoft Network Policy Server (NPS) con dispositivos unidos a Azure AD, Microsoft introdujo un cambio de configuración crítico. NPS ahora requiere un mapeo de certificados fuerte.

Al usar certificados de dispositivo, el objeto de equipo en el Active Directory local debe tener su atributo altSecurityIdentities poblado con los detalles del certificado (típicamente el X509IssuerSerialNumber). Los equipos de TI deben implementar un script programado o un flujo de trabajo impulsado por eventos para actualizar este atributo cuando Intune emite un nuevo certificado, de lo contrario, la autenticación fallará.

Solución de problemas y mitigación de riesgos

Cuando una implementación 802.1X falla, el problema casi siempre reside en la cadena de certificados o en la secuencia del perfil de Intune.

Modos de falla comunes

Falla silenciosa del perfil de WiFi: Si el perfil de WiFi de Intune se aplica a un dispositivo antes de que el certificado de cliente se haya aprovisionado correctamente, el perfil de WiFi a menudo no se instalará o fallará silenciosamente. Siempre verifique la presencia del certificado en el almacén personal del dispositivo (certmgr.msc en Windows) antes de solucionar problemas de configuración de WiFi.
Errores de validación de confianza del servidor: Si el dispositivo rechaza el servidor RADIUS, verifique que el nombre del servidor especificado en el perfil de WiFi de Intune coincida exactamente con el Nombre del Sujeto o SAN en el certificado del servidor RADIUS. Además, asegúrese de que toda la cadena de certificados (Raíz e Intermedio) esté presente en el almacén de Autoridades de Certificación Raíz Confiables del dispositivo.
Indisponibilidad de la Lista de Revocación de Certificados (CRL): Si el servidor RADIUS no puede alcanzar el punto de distribución de CRL de la CA para verificar el estado del certificado de cliente, la autenticación será denegada. Asegúrese de que la URL de CRL esté altamente disponible y sea accesible desde el servidor RADIUS.

ROI e impacto empresarial

La transición a la autenticación WiFi basada en certificados a través de Intune ofrece importantes retornos operativos y de seguridad.

Mitigación de riesgos: Elimina el riesgo de recolección de credenciales, ataques pass-the-hash y acceso no autorizado a la red a través de PSK compartidas.
Eficiencia operativa: Reduce los tickets de la mesa de ayuda de TI relacionados con las expiraciones de contraseñas y los problemas de conectividad WiFi. La gestión automatizada del ciclo de vida significa que los certificados se renuevan de forma transparente sin la intervención del usuario.
Habilitación del cumplimiento: Satisface estrictos requisitos reglamentarios. Para entornos minoristas, aborda directamente los requisitos de PCI DSS para una sólida encriptación y autenticación inalámbrica. Para el sector público y la atención médica, se alinea con los principios de acceso a la red de confianza cero (ZTNA).

Al aprovechar Microsoft Intune para la implementación de certificados, los equipos de TI pueden lograr una experiencia inalámbrica fluida y altamente segura que opera silenciosamente en segundo plano, permitiendo que la empresa se centre en las operaciones principales.

GuidesSlugPage.keyDefinitionsTitle

802.1X

An IEEE standard for port-based network access control that prevents unauthorized devices from accessing a LAN or WLAN until they successfully authenticate.

The foundational security protocol that replaces shared WiFi passwords with enterprise-grade authentication in corporate environments.

EAP-TLS

Extensible Authentication Protocol with Transport Layer Security. An authentication framework that requires both the client and the server to prove their identities using digital certificates.

The specific protocol configured in the Intune WiFi profile to enforce mutual certificate authentication, eliminating the risk of credential theft.

SCEP

Simple Certificate Enrollment Protocol. A mechanism where the client device generates its own private key and requests a certificate from the CA via an intermediary server.

The preferred deployment method for BYOD environments because the private key is never transmitted across the network.

PKCS

Public Key Cryptography Standards. In the context of Intune, a deployment method where the CA generates the private key and the Intune Connector securely delivers it to the device.

A simpler deployment architecture often used for corporate-owned device fleets, as it removes the need for an NDES server.

NDES

Network Device Enrollment Service. A Microsoft server role that acts as a proxy, allowing devices running without domain credentials to obtain certificates from an Active Directory Certificate Authority.

A mandatory infrastructure component when deploying certificates via SCEP in an on-premises ADCS environment.

RADIUS

Remote Authentication Dial-In User Service. A networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management.

The server (like Microsoft NPS or Cisco ISE) that receives the authentication request from the WiFi access point and validates the device's certificate.

Supplicant

The software client on the end-user device (laptop, smartphone) that initiates the 802.1X authentication process.

The Intune WiFi profile configures the native OS supplicant (e.g., Windows WLAN AutoConfig) to use the correct certificates and EAP methods.

Certificate Revocation List (CRL)

A digitally signed list published by the Certificate Authority containing the serial numbers of certificates that have been revoked and should no longer be trusted.

Crucial for security compliance; the RADIUS server must check the CRL to ensure a connecting device hasn't been reported lost or stolen.

GuidesSlugPage.workedExamplesTitle

A 400-location retail chain is deploying corporate-owned tablets for inventory management. The devices are fully managed via Intune and joined to Azure AD. They need immediate network access upon boot to sync inventory databases, before any specific user logs in. The network infrastructure uses Cisco ISE as the RADIUS server. What is the optimal certificate deployment strategy?

The IT team should implement PKCS device certificates.

Configure a device certificate template on the CA.
Deploy the Root CA certificate to the tablets via Intune.
Create a PKCS certificate profile in Intune, setting the Subject Name format to the Azure AD Device ID ({{AAD_Device_ID}}).
Create an Enterprise WiFi profile specifying EAP-TLS, referencing the ISE server's certificate name and the deployed PKCS profile.
Assign all profiles to the device group containing the tablets.

GuidesSlugPage.examinerCommentary PKCS is appropriate here because the devices are corporate-owned and fully managed, reducing the risk associated with private key transit. Device certificates are mandatory because the tablets require network access prior to user login. By targeting the Azure AD Device ID, Cisco ISE can authenticate the specific hardware asset and assign it to the correct restricted inventory VLAN.

A large teaching hospital allows medical staff to use their personal smartphones (BYOD) to access clinical scheduling applications. The devices are enrolled in Intune via a Work Profile. Security policy mandates that no corporate credentials be stored on personal devices, and network access must be revoked immediately if a device is compromised. How should the WiFi authentication be designed?

The hospital must implement SCEP user certificates combined with Intune Compliance Policies.

Deploy an NDES server to proxy requests to the CA.
Create a SCEP user certificate profile in Intune, with the SAN configured to the User Principal Name ({{UserPrincipalName}}).
Create an Intune Compliance Policy requiring a minimum OS version, an active screen lock, and no jailbreak/root access.
Configure the CA to publish a highly available Certificate Revocation List (CRL).
Configure the RADIUS server to strictly enforce CRL checking on every authentication attempt.

GuidesSlugPage.examinerCommentary SCEP is the only acceptable choice for BYOD because the private key is generated on the personal device and cannot be intercepted. User certificates are required to tie network activity to the specific clinician for HIPAA/GDPR auditing. The critical component is the integration with Intune Compliance Policies; if a device becomes non-compliant, Intune can trigger certificate revocation, and the RADIUS server's CRL check will immediately block network access.

GuidesSlugPage.practiceQuestionsTitle

Q1. Your organisation is migrating from PEAP-MSCHAPv2 (username/password) to EAP-TLS for the corporate WiFi. During the pilot phase, several Windows 11 laptops receive the Intune configuration profiles successfully but fail to connect to the network. Reviewing the Windows Event Logs shows Event ID 20271 indicating the RADIUS server certificate was rejected. What is the most likely cause?

GuidesSlugPage.hintPrefixConsider the chain of trust required for mutual authentication.

GuidesSlugPage.viewModelAnswer

The devices lack the Trusted Root CA certificate that issued the RADIUS server's certificate. In EAP-TLS, the device must validate the RADIUS server's identity. The IT team must ensure the 'Trusted certificate' profile containing the Root CA (and any Intermediate CAs) is deployed to the devices via Intune and successfully installed before the WiFi profile attempts to connect.

Q2. A public sector venue is deploying 802.1X for staff devices using Intune and PKCS certificates. They also operate a separate visitor network managed by a Guest WiFi platform. An auditor notes that if a staff laptop is stolen, the certificate remains valid for 12 months. How should the network architect address this risk?

GuidesSlugPage.hintPrefixHow does the authentication server know a certificate is no longer valid before it expires?

GuidesSlugPage.viewModelAnswer

The architect must implement a robust Certificate Revocation workflow. First, ensure the CA publishes a Certificate Revocation List (CRL) to a highly available distribution point. Second, configure the RADIUS server (e.g., NPS) to mandate CRL checking during every authentication attempt. Finally, establish an Intune operational procedure to explicitly revoke the certificate of any device marked as lost or stolen, which updates the CRL and blocks network access.

Q3. You are designing the Intune deployment for a fleet of shared kiosk devices in a retail environment. These devices reboot daily and must immediately connect to the corporate network to download updates before any user interacts with them. Should you deploy User certificates or Device certificates, and what Subject Alternative Name (SAN) format should be used?

GuidesSlugPage.hintPrefixConsider the state of the device immediately after a reboot.

GuidesSlugPage.viewModelAnswer

You must deploy Device certificates. Because the kiosks need network access before a user logs in, a User certificate would be unavailable at boot time. The Subject Alternative Name (SAN) in the Intune certificate profile should be configured to use the Azure AD Device ID ({{AAD_Device_ID}}) or the device's fully qualified domain name, allowing the RADIUS server to authenticate the specific hardware asset.