Autenticazione WiFi con Azure AD ed Entra ID: Guida all'Integrazione e alla Configurazione
Questa guida tecnica di riferimento fornisce ai responsabili IT, agli architetti di rete e ai direttori delle operazioni delle sedi una roadmap pratica per l'integrazione di Microsoft Entra ID (Azure AD) con le reti WiFi aziendali utilizzando RADIUS e 802.1X. Copre la decisione architetturale tra Windows NPS on-premise e RADIUS cloud-native, l'implementazione dell'autenticazione EAP-TLS basata su certificati tramite Microsoft Intune e le migliori pratiche operative per proteggere l'accesso wireless in ambienti hospitality, retail e del settore pubblico. Per le organizzazioni che hanno già investito nell'ecosistema Microsoft 365 ed Entra ID, questa guida colma il divario tra la gestione delle identità in cloud e la sicurezza della rete fisica.
Riepilogo Esecutivo
Per le imprese moderne fortemente investite nell'ecosistema Microsoft, collegare l'infrastruttura di identità cloud con le reti wireless fisiche è un imperativo di sicurezza critico. Storicamente, l'autenticazione WiFi si basava su Active Directory Domain Services (AD DS) on-premise e Windows Network Policy Server (NPS). Tuttavia, man mano che le organizzazioni migrano verso Microsoft Entra ID (precedentemente Azure AD) e adottano modelli di sicurezza zero-trust, l'approccio tradizionale di autenticazione basato su credenziali — PEAP-MSCHAPv2 — non è più sufficiente o sicuro.
Questa guida fornisce ai responsabili IT, agli architetti di rete e ai direttori delle operazioni delle sedi una roadmap pratica per l'implementazione dell'autenticazione WiFi con Azure AD. Esploriamo le differenze architetturali tra il mantenimento di un'impronta NPS on-premise e la migrazione a una soluzione RADIUS cloud-native. Fondamentalmente, dettagliamo come sfruttare Microsoft Intune per l'autenticazione basata su certificati (EAP-TLS), che elimina le vulnerabilità legate alle password e offre un'esperienza fluida e senza attriti per gli utenti finali. Che tu stia gestendo un hotel da 500 camere, una catena di negozi o una grande installazione nel settore pubblico, questa guida ti aiuterà a proteggere il tuo perimetro wireless utilizzando i tuoi investimenti esistenti nelle identità Microsoft. Per una discussione più ampia sui modelli di implementazione, consulta la nostra Guida decisionale per i team IT: Cloud RADIUS vs RADIUS On-Premise .
Approfondimento Tecnico: Architettura e Standard
La base del WiFi aziendale sicuro è lo standard IEEE 802.1X, che fornisce il controllo dell'accesso alla rete basato sulle porte. In un ambiente incentrato su Microsoft, l'integrazione di 802.1X con Entra ID richiede un'attenta pianificazione architetturale su tre livelli: l'infrastruttura wireless, il server di autenticazione e la directory delle identità.
Il Ruolo di RADIUS e 802.1X
Quando un dispositivo client (il supplicant) tenta di connettersi a una rete WPA2/WPA3-Enterprise, l'Access Point Wireless (l'authenticator) blocca tutto il traffico eccetto i pacchetti EAP (Extensible Authentication Protocol). L'access point inoltra questi pacchetti a un server RADIUS. Il server RADIUS convalida l'identità dell'utente o del dispositivo rispetto a un servizio di directory e restituisce un messaggio di Access-Accept o Access-Reject. Questo modello a tre parti — supplicant, authenticator, server di autenticazione — è la pietra angolare della sicurezza wireless aziendale ed è descritto in dettaglio nella nostra Definizione di Access Point Wireless: La tua Guida Definitiva 2026 .
Approcci Architetturali per Ambienti Microsoft
Esistono due architetture principali per l'integrazione dell'identità Microsoft con l'autenticazione WiFi, ciascuna con distinti compromessi:
| Dimensione | Ibrido On-Premise (NPS) | Cloud-Native (Cloud RADIUS) |
|---|---|---|
| Infrastruttura | Richiesto Windows Server VM o bare metal | Nessun server on-premise |
| Fonte di Identità | AD DS via LDAP/Kerberos | Entra ID direttamente via API |
| Autorità di Certificazione | ADCS on-premise + Intune Connector | Intune Cloud PKI o PKI del fornitore |
| Scalabilità | HA/bilanciamento del carico manuale | Scalabilità automatica del provider |
| Ideale per | AD Ibrido, dispositivi legacy | Organizzazioni cloud-first gestite da Intune |
| Complessità Operativa | Maggiore inizialmente e continuativa | Minore sovraccarico operativo |
Ibrido On-Premise (Windows NPS + AD DS + Azure AD Connect): Questo è l'approccio tradizionale. Windows NPS funge da server RADIUS, autenticando le richieste rispetto a un Active Directory on-premise. Per collegarlo al cloud, Azure AD Connect sincronizza le identità on-premise con Entra ID. Sebbene robusto, ciò richiede il mantenimento dell'infrastruttura server on-premise, la gestione dell'alta disponibilità e l'implementazione di una PKI complessa (ADCS) se si implementa EAP-TLS.
Cloud-Native (Cloud RADIUS + Entra ID + Intune): Questo approccio moderno elimina la necessità di server NPS on-premise. Un fornitore Cloud RADIUS di terze parti si integra direttamente con Entra ID tramite Microsoft Graph API. L'autenticazione avviene interamente nel cloud. Questa architettura si allinea con una strategia cloud-first, riducendo significativamente il sovraccarico operativo e allineandosi ai principi di accesso alla rete zero-trust.
EAP-TLS vs. PEAP-MSCHAPv2: La Scelta Critica
La scelta del metodo EAP è la singola decisione di sicurezza più importante in questa implementazione. PEAP-MSCHAPv2 si basa sull'inserimento delle credenziali di dominio da parte degli utenti. Questo è vulnerabile al furto di credenziali, agli attacchi man-in-the-middle e crea una scarsa esperienza utente quando le password scadono. La ricerca ha costantemente dimostrato che PEAP-MSCHAPv2 può essere compromesso tramite attacchi con access point contraffatti.
EAP-TLS (Transport Layer Security) è il gold standard del settore per il WiFi sicuro. Utilizza certificati digitali installati sul dispositivo client per l'autenticazione reciproca — sia il client che il server provano la propria identità. Non ci sono password da digitare e la connessione è crittograficamente forte. In un ambiente Microsoft, i certificati vengono solitamente distribuiti utilizzando Microsoft Intune tramite SCEP (Simple Certificate Enrollment Protocol) o PKCS. Questo è il percorso raccomandato per tutte le nuove implementazioni ed è essenziale per la conformità con PCI DSS (Requisito 8) e gli obblighi di protezione dei dati GDPR.
Guida all'Implementazione: Distribuzione Passo dopo Passo
L'implementazione dell'autenticazione WiFi con Entra ID utilizzando EAP-TLS e Intune richiede il coordinamento di diversi componenti tra identità, gestione dei dispositivi e infrastruttura di rete. Per una distribuzione cloud-native si raccomanda il seguente approccio in cinque fasi.
Fase 1: Preparare l'Infrastruttura di Gestione delle Identità e dei Dispositivi
Inizia verificando che il tuo tenant Entra ID abbia la licenza appropriata. Microsoft 365 E3/E5 o Enterprise Mobility + Security (EMS) E3/E5 include le funzionalità di gestione dei dispositivi Intune e di Accesso Condizionale richieste per questa implementazione. Senza Intune, la distribuzione automatizzata dei certificati non è possibile.
Successivamente, stabilisci la tua Public Key Infrastructure (PKI). Hai tre opzioni: una PKI cloud-native fornita dal tuo fornitore Cloud RADIUS, la Cloud PKI di Microsoft (disponibile con la licenza Intune Suite) o un'implementazione ADCS on-premise esistente collegata a Intune tramite il Microsoft Intune Certificate Connector. Per le nuove implementazioni, si raccomanda vivamente una PKI cloud-native per evitare dipendenze on-premise.
Fase 2: Configurare Intune per la Distribuzione dei Certificati
Nel centro di amministrazione di Microsoft Intune, crea un profilo di configurazione Trusted Certificate. Carica il certificato della Root CA della tua PKI e distribuiscilo ai gruppi di dispositivi di destinazione. Questo passaggio è critico: assicura che i dispositivi client si fidino del certificato presentato dal server RADIUS durante l'handshake TLS, prevenendo attacchi man-in-the-middle.
Successivamente, crea un profilo SCEP Certificate (o PKCS si la tua PKI lo richiede). Configura il formato del Subject Name — per l'autenticazione basata sull'utente, usa CN={{UserPrincipalName}}; per l'autenticazione basata sul dispositivo, usa CN={{DeviceName}} o il numero di serie del dispositivo. Imposta il Subject Alternative Name (SAN) per includere lo User Principal Name o l'ID del dispositivo. Assegna entrambi i profili ai gruppi di dispositivi o utenti Entra ID appropriati.
Fase 3: Configurare l'Integrazione Cloud RADIUS
Concedi al tuo fornitore Cloud RADIUS le autorizzazioni Microsoft Graph API necessarie nel tuo tenant Entra ID. Come minimo, il fornitore richiede User.Read.All e GroupMember.Read.All per convalidare le appartenenze ai gruppi durante l'autenticazione. Alcuni fornitori richiedono anche Device.Read.All per le policy basate sui dispositivi.
All'interno del portale di gestione Cloud RADIUS, definisci le tue policy di autenticazione. Una policy ben strutturata per un ambiente aziendale potrebbe essere: "Consenti l'accesso se il certificato è emesso da [Trusted CA] E l'utente è membro del gruppo Entra ID [Corporate-WiFi-Users] E il dispositivo è contrassegnato come Conforme in Intune." Questa policy stratificata applica simultaneamente sia l'identità che lo stato di salute del dispositivo.
Fase 4: Configurare l'Infrastruttura Wireless
Nel controller LAN wireless o nel dashboard di gestione cloud (come Cisco Meraki, Aruba Central o Juniper Mist), aggiungi gli indirizzi IP del server Cloud RADIUS e i segreti condivisi come server di autenticazione RADIUS. Configura server primari e secondari per la ridondanza. Imposta il timeout RADIUS a un minimo di 5 secondi per accogliere la latenza di andata e ritorno del cloud.
Crea un nuovo SSID configurato per WPA2-Enterprise o WPA3-Enterprise. Assegna i server RADIUS a questo SSID. Per le implementazioni nel settore Hospitality , assicurati che questo SSID aziendale sia su una VLAN separata da qualsiasi rete ospite. Per gli ambienti Retail , considera di distribuire l'SSID aziendale solo nelle aree del retro, mantenendo separata la rete dell'area vendita.
Fase 5: Distribuire il Profilo WiFi tramite Intune
Crea un profilo di configurazione WiFi in Intune. Imposta l'SSID in modo che corrisponda esattamente a quello configurato sull'infrastruttura wireless. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza. Nelle impostazioni EAP, seleziona EAP-TLS come metodo di autenticazione. Collega il profilo del certificato SCEP come certificato client e specifica il profilo Trusted Root CA distribuito nella Fase 2.
Assegna questo profilo WiFi agli stessi gruppi di dispositivi che hanno ricevuto i profili dei certificati. I dispositivi riceveranno silenziosamente il certificato e la configurazione WiFi durante la successiva sincronizzazione con Intune e si connetteranno automaticamente quando si trovano nel raggio d'azione dell'SSID — senza alcuna interazione da parte dell'utente.
Migliori Pratiche per Ambienti Aziendali
Le seguenti raccomandazioni rappresentano il consenso del settore per implementazioni Microsoft 802.1X sicure e scalabili in sedi aziendali.
Imponi EAP-TLS in tutte le nuove implementazioni. Non distribuire nuove reti utilizzando PEAP-MSCHAPv2. I rischi di sicurezza del WiFi basato su credenziali sono ben documentati e incompatibili con una postura di sicurezza zero-trust. EAP-TLS è essenziale per la conformità con PCI DSS, GDPR e ISO 27001.
Automatizza il ciclo di vita dei certificati. Assicurati che quando un utente viene disabilitato in Entra ID o un dispositivo viene ritirato in Intune, il certificato corrispondente venga revocato automaticamente o la policy RADIUS blocchi immediatamente l'accesso. Questo è particolarmente importante in ambienti ad alto turnover come Hospitality e Retail , dove i cambi di personale sono frequenti.
Implementa l'Accesso Condizionale di Entra ID. Sfrutta le policy di Accesso Condizionale per imporre la conformità del dispositivo come condizione per l'accesso alla rete. Richiedere che i dispositivi siano contrassegnati come 'Conformi' in Intune prima di potersi autenticare su RADIUS garantisce che solo i dispositivi aggiornati e conformi alle policy accedano alla rete aziendale.
Segmenta rigorosamente le reti aziendali e quelle ospiti. 802.1X è progettato per i dispositivi aziendali gestiti. Per visitatori, appaltatori e BYOD, implementa una soluzione dedicata di WiFi per Ospiti con un Captive Portal. Questa può integrarsi con Entra ID B2B per l'accesso degli appaltatori, o utilizzare login social e verifica SMS per l'accesso del pubblico generico. Non consentire mai a dispositivi non gestiti di accedere all'SSID 802.1X aziendale.
Pianifica per i dispositivi legacy e IoT. Stampanti, sensori IoT e dispositivi legacy che non possono supportare i certificati richiedono una strategia separata. Usa il MAC Authentication Bypass (MAB) per i dispositivi noti, o un SSID WPA2-Personal dedicato con una PSK complessa e ruotata, isolato su una VLAN dedicata. La piattaforma Sensors di Purple, ad esempio, può operare su una VLAN IoT dedicata separata dall'infrastruttura di autenticazione aziendale.
Monitora gli eventi di autenticazione. Integra i log RADIUS con il tuo SIEM o usa la piattaforma WiFi Analytics per monitorare i fallimenti di autenticazione, gli avvisi di scadenza dei certificati e i modelli di accesso insoliti. Il monitoraggio proattivo previene le interruzioni prima che impattino sulle operazioni.
Risoluzione dei Problemi e Mitigazione dei Rischi
Anche le implementazioni ben pianificate incontrano problemi. Di seguito sono riportate le modalità di guasto più comuni e le relative risoluzioni.
Errori di Distribuzione dei Certificati. Il problema più comune in un'implementazione EAP-TLS è che i dispositivi non ricevono i certificati da Intune. Ciò è solitamente causato da un Intune Certificate Connector configurato in modo errato (se si utilizza ADCS on-premise), un URL SCEP errato o dispositivi che non si sincronizzano con Intune. Verifica sempre lo stato del Certificate Connector nel centro di amministrazione di Intune e controlla i log di sincronizzazione del dispositivo. Assicurati che l'account di servizio SCEP abbia le autorizzazioni necessarie sulla CA.
Problemi di Timeout RADIUS. Se l'access point non riesce a raggiungere il server RADIUS entro il timeout configurato, i client non riusciranno a connettersi. Assicurati che le regole del firewall consentano le porte UDP 1812 (autenticazione) e 1813 (accounting) in uscita verso gli intervalli IP del fornitore Cloud RADIUS. Se utilizzi NPS on-premise, distribuisci almeno due server NPS e configura i tuoi access point per il failover tra di essi.
Errori di Fiducia del Certificato. Se i client ricevono un errore di "certificato del server non attendibile", il profilo Trusted Root CA non è stato distribuito correttamente al dispositivo. Verifica l'assegnazione del profilo in Intune e controlla l'archivio certificati del dispositivo. Questo è un problema comune con i dispositivi appena registrati che non hanno ancora completato la loro prima sincronizzazione con Intune.
Estensione NPS per Azure MFA. Sebbene sia tecnicamente possibile utilizzare l'Estensione NPS per imporre l'Autenticazione a Più Fattori per il WiFi, è fortemente sconsigliato per l'accesso primario. L'esperienza utente di ricevere una richiesta MFA ogni volta che un dispositivo si sposta tra gli access point è gravemente dirompente. Affidati invece alla forte autenticazione fornita dal certificato del dispositivo e applica l'MFA a livello di applicazione.
Conflitti di Criteri di Gruppo. In ambienti ibridi, gli Oggetti Criteri di Gruppo (GPO) che configurano il client wireless Windows potrebbero entrare in conflitto con i profili WiFi di Intune. Assicurati che i profili Intune abbiano la precedenza rivedendo le impostazioni di registrazione MDM e, dove necessario, bloccando la configurazione wireless basata su GPO per i dispositivi gestiti da Intune.
ROI e Impatto Aziendale
La migrazione a un'architettura RADIUS cloud-native integrata con Entra ID offre un valore misurabile e quantificabile su diverse dimensioni.
Riduzione dei Ticket all'Helpdesk. I problemi WiFi legati alle password — blocchi, password scadute, supplicant configurati in modo errato — sono una fonte significativa di ticket di supporto IT negli ambienti basati su credenziali. EAP-TLS li elimina completamente. Le organizzazioni in genere segnalano una riduzione del 30-50% del volume di helpdesk relativo al WiFi dopo la migrazione all'autenticazione basata su certificati.
Risparmio sui Costi dell'Infrastruttura. La dismissione dei server NPS on-premise riduce i costi di calcolo, le tariffe di licenza del sistema operativo e il sovraccarico operativo per l'applicazione di patch e il mantenimento di cluster ad alta disponibilità. Per un'organizzazione di medie dimensioni che gestisce due server NPS, ciò può rappresentare un risparmio di £15.000–£30.000 all'anno in costi infrastrutturali e operativi.
Miglioramento della Postura di Sicurezza e Conformità. Allontanarsi dall'autenticazione basata su credenziali mitiga il rischio di furto di credenziali e movimento laterale, proteggendo i dati aziendali sensibili. Per le organizzazioni soggette a PCI DSS, questo affronta direttamente i requisiti di controllo dell'accesso alla rete. Per le organizzazioni del settore Healthcare che gestiscono dati dei pazienti, supporta la conformità DSPT. Per gli operatori del settore Transport , si allinea ai requisiti della Direttiva NIS2 per la sicurezza della rete.
Migliore Esperienza Utente. Una connessione WiFi fluida e automatica — senza richieste di password, senza blocchi e senza configurazione manuale — migliora la produttività e riduce gli attriti per il personale. Questo è particolarmente impattante in ambienti ad alta mobilità come centri di distribuzione, reparti ospedalieri e aree vendita al dettaglio.
Trattando la tua rete WiFi come un'estensione della tua strategia di identità cloud, garantisci un accesso sicuro e senza attriti che scala con la tua organizzazione. Per ulteriori indicazioni sugli aspetti di integrazione SD-WAN delle moderne reti aziendali, consulta I principali vantaggi della SD-WAN per le aziende moderne . Per considerazioni sull'implementazione specifiche per l'hospitality, fai riferimento a Soluzioni WiFi moderne per l'hospitality che i tuoi ospiti meritano .
Termini chiave e definizioni
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.
Casi di studio
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.
Analisi degli scenari
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?
💡 Suggerimento:Consider what NPS requires to function and whether those dependencies will exist post-migration. Also consider the security implications of the current EAP method.
Mostra l'approccio consigliato
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?
💡 Suggerimento:Consider the difference between user-based and device-based certificate profiles in Intune, and how RADIUS policies can be scoped to device identity.
Mostra l'approccio consigliato
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?
💡 Suggerimento:Remember the architectural principle separating managed device authentication from unmanaged device access. Consider how Entra ID B2B could be leveraged.
Mostra l'approccio consigliato
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?
💡 Suggerimento:Consider the options available for devices that cannot support EAP-TLS, and the importance of network segmentation.
Mostra l'approccio consigliato
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.
Punti chiave
- ✓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.
