Come usare Microsoft Intune per distribuire certificati WiFi ai dispositivi

Un riferimento tecnico completo per i responsabili IT sulla distribuzione di certificati WiFi 802.1X tramite Microsoft Intune. Copre l'architettura SCEP vs PKCS, i passaggi di implementazione, la mappatura della conformità e gli scenari di distribuzione reali per ambienti aziendali.

📖 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.

Riepilogo Esecutivo

Per i responsabili IT aziendali che gestiscono ambienti su larga scala in Hospitality , Retail o sedi del settore pubblico, l'accesso wireless sicuro è un requisito operativo fondamentale. Affidarsi a PSK (Pre-Shared Keys) condivise o all'autenticazione tramite nome utente/password (PEAP-MSCHAPv2) espone la rete al furto di credenziali, al phishing e a violazioni della conformità. Lo standard di settore per una robusta sicurezza WiFi aziendale è 802.1X con EAP-TLS (Extensible Authentication Protocol with Transport Layer Security), che impone l'autenticazione reciproca basata su certificati tra il dispositivo e la rete.

Tuttavia, la barriera principale all'adozione di EAP-TLS è stata storicamente il sovraccarico operativo della gestione del ciclo di vita dei certificati. Microsoft Intune risolve questo problema automatizzando la consegna, il rinnovo e la revoca dei certificati digitali ai dispositivi gestiti su larga scala.

Questo riferimento tecnico descrive l'architettura, le metodologie di distribuzione (SCEP vs PKCS) e i passaggi di implementazione necessari per distribuire certificati WiFi tramite Microsoft Intune. Fornisce una guida pratica per architetti di rete e ingegneri di sistemi incaricati di proteggere le comunicazioni aziendali mantenendo una rigorosa separazione dalle reti per visitatori, come quelle gestite da una piattaforma Guest WiFi .

Approfondimento Tecnico: Architettura e Protocolli

Per implementare efficacemente l'autenticazione basata su certificati, i team IT devono comprendere l'interazione tra la piattaforma Mobile Device Management (MDM), l'infrastruttura a chiave pubblica (PKI) e il livello di controllo dell'accesso alla rete.

Il Framework di Autenticazione 802.1X

Lo standard IEEE 802.1X definisce il controllo dell'accesso alla rete basato su porta. In un contesto wireless, impedisce a un dispositivo di trasmettere qualsiasi traffico (diverso dai frame di autenticazione EAP) finché la sua identità non è verificata. L'architettura è composta da tre componenti:

Supplicant: Il dispositivo client (laptop, smartphone, tablet) che richiede l'accesso alla rete.
Authenticator: L'access point wireless o il controller LAN wireless che blocca il traffico fino al successo dell'autenticazione.
Authentication Server: Il server RADIUS (Remote Authentication Dial-In User Service), come Microsoft Network Policy Server (NPS) o Cisco ISE, che convalida le credenziali e autorizza l'accesso.

EAP-TLS e Autenticazione Reciproca

EAP-TLS è il metodo EAP più sicuro perché richiede l'autenticazione reciproca. Il server RADIUS presenta il suo certificato al supplicant per dimostrare che è la legittima rete aziendale (prevenendo attacchi evil-twin), e il supplicant presenta il suo certificato client al server RADIUS per dimostrare di essere un dispositivo o utente autorizzato.

Meccanismi di Distribuzione dei Certificati Intune: SCEP vs PKCS

Microsoft Intune supporta due protocolli primari per la distribuzione di certificati client ai dispositivi. La selezione del meccanismo appropriato è una decisione architettonica critica.

Simple Certificate Enrollment Protocol (SCEP)

Con SCEP, la chiave privata viene generata direttamente sul dispositivo client. Il dispositivo crea una Certificate Signing Request (CSR) e la invia tramite Intune al server Network Device Enrollment Service (NDES), che agisce come proxy per l'infrastruttura Active Directory Certificate Services (ADCS). La CA rilascia il certificato, che viene restituito al dispositivo.

Poiché la chiave privata non lascia mai il dispositivo, SCEP è considerato altamente sicuro ed è l'approccio raccomandato per le distribuzioni BYOD (Bring Your Own Device) e le architetture zero-trust.

Public Key Cryptography Standards (PKCS)

Con PKCS, l'Intune Certificate Connector richiede il certificato alla CA per conto del dispositivo. La CA genera sia il certificato pubblico che la chiave privata, che il connettore poi consegna in modo sicuro al dispositivo tramite Intune.

Sebbene PKCS semplifichi i requisiti dell'infrastruttura (non è necessario un server NDES), la chiave privata viene trasmessa attraverso la rete. Questo modello è generalmente accettabile per flotte di dispositivi di proprietà aziendale e completamente gestiti, dove la piattaforma MDM è già un componente altamente affidabile.

Guida all'Implementazione: Distribuzione Passo Dopo Passo

La distribuzione di certificati WiFi tramite Intune richiede una sequenza precisa. La distribuzione di profili in ordine errato è la causa più comune di fallimento dell'implementazione.

Passo 1: Preparare l'Infrastruttura a Chiave Pubblica (PKI)

Sia che si utilizzi ADCS on-premises o una soluzione cloud-native come Microsoft Cloud PKI, la Certificate Authority deve essere configurata con i modelli appropriati.

Key Usage: Il modello deve includere l'OID Client Authentication (1.3.6.1.5.5.7.3.2).
Key Size: Configurare una dimensione minima della chiave di 2048 bit (RSA) per allinearsi agli standard crittografici moderni.
Subject Name: Per i certificati utente, il Subject Alternative Name (SAN) deve essere configurato per utilizzare il User Principal Name (UPN). Per i certificati dispositivo, utilizzare l'Azure AD Device ID.

Passo 2: Distribuire il Certificato Root Attendibile

Prima che un dispositivo possa autenticarsi, deve fidarsi della CA che ha emesso il certificato del server RADIUS.

Esportare il certificato Root CA (e qualsiasi certificato CA intermedio) in .cer" format.
Nel centro di amministrazione Intune, navigare su Dispositivi > Profili di configurazione > Crea profilo.
Selezionare la piattaforma e scegliere il tipo di profilo Certificato attendibile.
Caricare il file .cer e assegnare il profilo al dispositivo di destinazione o ai gruppi di utenti.

Nota: Questo profilo deve essere applicato con successo ai dispositivi prima di procedere con i passaggi successivi.

Passaggio 3: Distribuire il profilo del certificato client

Creare un profilo di certificato SCEP o PKCS per consegnare il certificato di identità al supplicante.

Navigare su Dispositivi > Profili di configurazione > Crea profilo.
Selezionare la piattaforma e scegliere Certificato SCEP o Certificato PKCS.
Configurare il formato del Nome del Soggetto e il SAN in base ai requisiti di identità (Utente vs. Dispositivo).
Specificare il Key Storage Provider (KSP) — tipicamente il Trusted Platform Module (TPM) per la sicurezza basata su hardware.
Assegnare il profilo agli stessi gruppi di destinazione del Passaggio 2.

Passaggio 4: Configurare il profilo WiFi

Il componente finale lega i certificati alle impostazioni della rete wireless.

Navigare su Dispositivi > Profili di configurazione > Crea profilo.
Selezionare la piattaforma e scegliere il tipo di profilo Wi-Fi.
Impostare il tipo di Wi-Fi su Enterprise e inserire l'SSID esatto.
Impostare il tipo EAP su EAP-TLS.
Sotto Attendibilità server, specificare il nome esatto del certificato del server RADIUS e selezionare il profilo del certificato Trusted Root distribuito nel Passaggio 2.
Sotto Autenticazione client, selezionare il profilo del certificato SCEP o PKCS distribuito nel Passaggio 3.
Assegnare il profilo ai gruppi di destinazione.

Best Practice e Raccomandazioni Strategiche

Certificati del dispositivo vs. dell'utente

Gli architetti di rete devono decidere se rilasciare i certificati al dispositivo (autenticazione macchina) o all'utente (autenticazione utente).

Certificati del dispositivo: Consentono alla macchina di connettersi alla rete WiFi prima che un utente effettui l'accesso. Questo è fondamentale per il provisioning iniziale del dispositivo, l'elaborazione delle Group Policy e il ripristino delle password nella schermata di accesso. Raccomandato per i dispositivi di proprietà aziendale.
Certificati dell'utente: Collegano l'accesso alla rete all'identità dell'individuo. Questo fornisce un auditing granulare e un controllo degli accessi basato sui ruoli. Raccomandato per scenari BYOD.

Segmentazione della rete e accesso ospiti

Un principio di sicurezza fondamentale è la rigorosa separazione logica della rete aziendale 802.1X dalle reti di accesso per visitatori o pubbliche. L'infrastruttura gestita da Intune dovrebbe essere dedicata esclusivamente ai dispositivi aziendali e al personale autenticato.

Per l'accesso dei visitatori, le organizzazioni dovrebbero implementare un SSID Guest WiFi dedicato supportato da un captive portal. Ciò garantisce che i dispositivi non gestiti siano isolati, pur consentendo all'azienda di acquisire analisi sui visitatori tramite una piattaforma WiFi Analytics . Per saperne di più sulla protezione dell'infrastruttura DNS in entrambi i segmenti, consultare la nostra guida su come Proteggere la rete con DNS e sicurezza robusti .

Gestione del requisito di mappatura dei certificati NPS

Per le organizzazioni che utilizzano Microsoft Network Policy Server (NPS) con dispositivi uniti ad Azure AD, Microsoft ha introdotto una modifica critica alla configurazione. NPS ora richiede una mappatura forte dei certificati.

Quando si utilizzano i certificati del dispositivo, l'oggetto computer nell'Active Directory locale deve avere il suo attributo altSecurityIdentities popolato con i dettagli del certificato (tipicamente l'X509IssuerSerialNumber). I team IT devono implementare uno script pianificato o un flusso di lavoro basato su eventi per aggiornare questo attributo quando Intune rilascia un nuovo certificato, altrimenti l'autenticazione fallirà.

Risoluzione dei problemi e mitigazione dei rischi

Quando una distribuzione 802.1X fallisce, il problema risiede quasi sempre nella catena di certificati o nella sequenza dei profili Intune.

Modalità di errore comuni

Errore silenzioso del profilo WiFi: Se il profilo WiFi di Intune viene applicato a un dispositivo prima che il certificato client sia stato correttamente provisionato, il profilo WiFi spesso non si installerà o fallirà silenziosamente. Verificare sempre la presenza del certificato nello store Personale del dispositivo (certmgr.msc su Windows) prima di risolvere i problemi di configurazione WiFi.
Errori di convalida dell'attendibilità del server: Se il dispositivo rifiuta il server RADIUS, verificare che il nome del server specificato nel profilo WiFi di Intune corrisponda esattamente al Nome del Soggetto o al SAN sul certificato del server RADIUS. Inoltre, assicurarsi che l'intera catena di certificati (Root e Intermedio) sia presente nello store Trusted Root Certification Authorities del dispositivo.
Indisponibilità della Certificate Revocation List (CRL): Se il server RADIUS non riesce a raggiungere il punto di distribuzione CRL della CA per verificare lo stato del certificato client, l'autenticazione verrà negata. Assicurarsi che l'URL CRL sia altamente disponibile e accessibile dal server RADIUS.

ROI e impatto aziendale

La transizione all'autenticazione WiFi basata su certificati tramite Intune offre significativi ritorni operativi e di sicurezza.

Mitigazione del rischio: Elimina il rischio di credential harvesting, attacchi pass-the-hash e accesso non autorizzato alla rete tramite PSK condivise.
Efficienza operativa: Riduce i ticket dell'helpdesk IT relativi alla scadenza delle password e ai problemi di connettività WiFi. La gestione automatizzata del ciclo di vita significa che i certificati vengono rinnovati in modo trasparente senza l'intervento dell'utente.
Abilitazione alla conformità: Soddisfa rigorosi requisiti normativi. Per gli ambienti retail, affronta direttamente i requisiti PCI DSS per una crittografia e autenticazione wireless robuste. Per il settore pubblico e sanitario, si allinea ai principi di accesso alla rete zero-trust (ZTNA).

Sfruttando Microsoft Intune per la distribuzione dei certificati, i team IT possono ottenere un'esperienza wireless fluida e altamente sicura che opera silenziosamente in background, consentendo all'azienda di concentrarsi sulle operazioni principali.

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.