How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Questa guida spiega come configurare SCEP (Simple Certificate Enrollment Protocol) per l'assegnazione automatizzata dei certificati WiFi aziendali, coprendo l'intera architettura da PKI e NDES fino alla distribuzione dei profili MDM e alla convalida RADIUS. Si rivolge a responsabili IT, architetti di rete e CTO di hotel, catene retail, stadi, centri congressi e organizzazioni del settore pubblico che desiderano superare le chiavi precondivise e implementare un'autenticazione 802.1X EAP-TLS scalabile e basata sull'identità. La piattaforma cloud overlay indipendente dall'hardware di Purple si integra direttamente con questa architettura, fornendo il livello WiFi per ospiti e BYOD che si affianca alla rete del personale autenticata tramite certificato.

📖 10 minuti di lettura📝 2,282 parole🔧 2 esempi pratici❓ 3 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network. Whether that is a university campus, a multi-site hotel group, or a large public sector estate, the challenges are identical.

We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them.

This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map.

Let us get into it.

First principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalised by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine.

In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS, Extensible Authentication Protocol with Transport Layer Security, which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks, where an attacker spins up a rogue access point to harvest credentials.

Here is how the full chain works. A managed device, a student laptop, a staff phone, a hotel point-of-sale terminal, needs to join the corporate wireless network. Your MDM platform, which might be Microsoft Intune or Jamf, pushes a SCEP payload to that device. The payload contains two things: the SCEP URL, which points to your NDES server or cloud SCEP gateway, and a challenge password or shared secret.

The device generates its own public and private key pair locally. This is critical. The private key never leaves the device. It is generated on-device, stored in the secure enclave or TPM, and is never transmitted across the network. The device then creates a Certificate Signing Request, a CSR, and sends it to the SCEP gateway. The gateway validates the challenge, forwards the CSR to your Certificate Authority, and the CA signs it and returns the public certificate to the device.

From that point on, when the device connects to your WiFi SSID, it presents that certificate to the RADIUS server. The RADIUS server validates the certificate against your CA trust chain, checks the Certificate Revocation List to confirm the cert has not been revoked, and if everything checks out, sends an accept message to the access point. The device is on the network. The whole process is invisible to the user.

Now, let us talk about where SCEP sits relative to the alternative, which is PKCS. PKCS, Public Key Cryptography Standards, is the other certificate delivery method supported by platforms like Intune. With PKCS, the CA generates both the public and private key centrally, and the certificate connector pushes the key pair down to the device. That means the private key travels over the network, which introduces a theoretical attack surface. PKCS is fine for use cases like S/MIME email encryption where key escrow is actually desirable. For WiFi authentication, SCEP is the right choice. The private key stays on the device, full stop.

Now, the hardware layer. SCEP and EAP-TLS are vendor-neutral standards, which means they work across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Your RADIUS configuration, whether that is Windows NPS, FreeRADIUS, or a cloud RADIUS service, is where you define the certificate validation policy and, critically, where you configure dynamic VLAN assignment.

Dynamic VLANs are how you segment the network by identity. A student device gets VLAN 20 for internet access only. A faculty device gets VLAN 10 for access to internal research systems. A facilities management device gets VLAN 30 for access to building management systems. All of this is driven by the certificate attributes and the RADIUS policy, with no manual intervention per device.

For identity provider integration, SCEP certificate attributes, specifically the Subject Alternative Name, can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. That ties the certificate to a specific identity, which means when you disable an account in Entra ID and the MDM unenrols the device, the certificate is revoked and WiFi access is cut automatically. That is the revocation story that pre-shared keys simply cannot tell.

Right, let us talk about the deployment sequence, because this is where most teams trip up.

The sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Intune and Jamf both enforce profile dependencies. If your WiFi profile references a SCEP certificate that has not yet been deployed to the device, the WiFi profile will fail with a cryptic error that looks like a misconfiguration but is actually just a timing issue.

The second pitfall is group targeting. All three profiles, Trusted Root, SCEP, and WiFi, must be deployed to the exact same Azure AD or Jamf group. If the SCEP profile targets a user group and the WiFi profile targets a device group, Intune cannot resolve the dependency and the WiFi profile will show as Not Applicable. This catches teams out constantly.

Third: NDES server accessibility. Your NDES server needs to be reachable from the internet so that devices can enrol before they arrive on-site. The right way to do this is via Azure AD Application Proxy, not by punching a hole in your firewall. App Proxy gives you secure remote access without inbound ports and lets you apply Conditional Access policies to the enrolment flow.

Fourth: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point is unavailable, because a server is down, or the URL has changed, authentication fails for every device on the network simultaneously. That is a campus-wide outage. Make your CRL endpoints highly available, and test revocation before you go live.

For large networks, anything above 500 devices, consider a cloud SCEP gateway rather than on-premises NDES. Cloud gateways eliminate the NDES single point of failure, scale horizontally, and typically integrate directly with cloud RADIUS services, removing another infrastructure dependency.

Let us tackle a few rapid-fire questions we often hear from CTOs.

Can SCEP handle BYOD devices that are not MDM-enrolled? Not directly. SCEP requires MDM enrolment to push the certificate payload. For unmanaged BYOD, you need a different approach, either a self-service onboarding portal, or a separate SSID using a captive portal with identity verification. Purple handles that guest and BYOD layer cleanly, sitting alongside your certificate-authenticated staff network.

What about iOS and Android? Both platforms support SCEP natively. iOS has supported SCEP since iOS 4. Android Enterprise supports SCEP through Intune and other MDMs. The configuration is slightly different per platform but the underlying protocol is identical.

Does EAP-TLS work with WPA3? Yes. WPA3-Enterprise mandates 192-bit security mode for sensitive environments, and EAP-TLS is fully compatible. In fact, WPA3-Enterprise with EAP-TLS is the combination recommended by the Wi-Fi Alliance for government and financial networks.

To bring this together. SCEP certificate WiFi authentication is the right architecture for any network with more than 50 managed devices. It eliminates shared credentials, gives you per-device identity, enables dynamic VLAN segmentation, and integrates directly with your identity provider for automated revocation. The deployment sequence, Trusted Root, then SCEP profile, then WiFi profile, is fixed. Group targeting must be consistent. CRL availability is not optional.

For higher education specifically, the combination of SCEP for staff and faculty devices, alongside a separate guest WiFi layer for students on personal devices, gives you both security and a great user experience without compromise.

If you want to go deeper, Purple's guide on enterprise WiFi authentication covers the cloud-native path. And if you are thinking about what happens when an employee leaves, our guide on revoking WiFi access walks through the full revocation workflow.

Thanks for listening. I am from the Purple technical team, and we will see you in the next briefing.

Punti chiave

✓SCEP (RFC 8894) automates certificate enrollment for managed devices - the private key is generated on-device and never transmitted, making it the correct choice for WiFi authentication over PKCS.
✓The deployment sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Violating this order causes profile dependency failures.
✓All three MDM profiles (Trusted Root, SCEP, WiFi) must target the exact same directory group. Cross-group targeting is the most common cause of deployment failures.
✓NDES should be published via Azure AD Application Proxy, not exposed directly to the internet. For networks above 500 devices, a cloud SCEP gateway eliminates the NDES single point of failure.
✓CRL Distribution Point availability is a network-critical dependency. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication simultaneously.
✓EAP-TLS with SCEP-provisioned certificates satisfies PCI DSS 4.0 Requirement 8.6 for wireless networks in cardholder data environments and is required for WPA3-Enterprise 192-bit (Suite B).
✓SCEP covers managed devices only. Unmanaged BYOD and guest devices require a separate SSID with captive portal and identity verification - Purple's platform handles this layer alongside your certificate-authenticated staff network.

Sintesi esecutiva

Per le grandi strutture aziendali - che si tratti di un hotel da 200 camere, di una catena retail con 50 punti vendita o di un grande centro congressi - affidarsi a chiavi precondivise per il WiFi del personale rappresenta un rischio per la sicurezza e un collo di bottiglia operativo. Una sola password trapelata espone l'intera rete. L'autenticazione basata su certificati tramite IEEE 802.1X ed EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina completamente questo rischio. Ogni dispositivo dimostra la propria identità crittograficamente prima che l'access point conceda l'accesso alla rete.

La sfida è la distribuzione. Distribuire manualmente certificati client univoci a migliaia di dispositivi Windows, iOS e Android non è fattibile. SCEP (Simple Certificate Enrollment Protocol), formalizzato come RFC 8894 dall'IETF nel 2020, risolve questo problema. Automatizza il processo di richiesta, emissione e installazione dei certificati digitali sui dispositivi gestiti tramite la piattaforma MDM, senza alcuna interazione da parte dell'utente.

Questa guida copre l'intera architettura: cosa fa SCEP, come si integra con Microsoft Intune, Jamf e altre piattaforme MDM, l'esatta sequenza di distribuzione che la maggior parte dei team sbaglia e le insidie operative che causano interruzioni. Esaminiamo anche due scenari di implementazione reali nei settori hospitality e retail, e spieghiamo come la piattaforma Guest WiFi di Purple si inserisce a fianco della rete del personale autenticata tramite certificato.

Ascolta il podcast di approfondimento correlato:

Approfondimento tecnico: SCEP, PKI e 802.1X

Cosa fa effettivamente SCEP

SCEP non sostituisce la Public Key Infrastructure (PKI). È il livello di registrazione automatizzata che si sovrappone ad essa. La PKI - tipicamente una gerarchia a due livelli con una CA radice offline e una CA emittente online - rimane l'ancora di fiducia. SCEP automatizza la fase in cui un dispositivo richiede un certificato a tale CA, eliminando la necessità di generare manualmente CSR e installare certificati.

Nel contesto dell'autenticazione WiFi, il protocollo di destinazione è EAP-TLS. Questo è il metodo di autenticazione 802.1X che richiede sia al dispositivo client che al server RADIUS di presentare certificati X.509 validi. Nessuna delle due parti si fida dell'altra senza una prova crittografica. Questo modello di autenticazione reciproca elimina il furto di credenziali e protegge dagli attacchi "evil twin", in cui un utente malintenzionato attiva un access point fittizio per carpire nomi utente e password.

Per un'analisi dettagliata dell'handshake EAP-TLS, consulta la nostra guida su Autenticazione dei certificati WiFi: accesso sicuro alla rete .

Il flusso di registrazione SCEP, passo dopo passo

L'intera catena di registrazione funziona come segue. La piattaforma MDM - Microsoft Intune, Jamf o un altro MDM - invia un payload SCEP a un dispositivo gestito. Tale payload contiene due elementi: l'URL SCEP che punta al server NDES (Network Device Enrollment Service) o al gateway SCEP cloud, e una password di verifica (challenge password) o segreto condiviso.

Il dispositivo genera localmente la propria coppia di chiavi pubblica e privata. Questa è la proprietà di sicurezza fondamentale di SCEP: la chiave privata viene generata sul dispositivo, memorizzata nell'enclave sicura o nel chip TPM e non viene mai trasmessa sulla rete. Il dispositivo crea quindi una Certificate Signing Request (CSR) e la invia al gateway SCEP. Il gateway convalida la password di verifica, inoltra la CSR alla Certificate Authority, e la CA la firma e restituisce il certificato pubblico al dispositivo.

Da quel momento in poi, quando il dispositivo si connette al tuo SSID WiFi, presenta tale certificato al server RADIUS. Il server RADIUS convalida il certificato rispetto alla catena di attendibilità della CA, controlla la Certificate Revocation List (CRL) per confermare che il certificato non sia stato revocato e, se tutto è in ordine, invia un messaggio di Access-Accept all'access point. Il dispositivo è in rete. L'intero processo è invisibile all'utente.

SCEP vs. PKCS: quale utilizzare per il WiFi

Le piattaforme MDM come Intune supportano due meccanismi di distribuzione dei certificati: SCEP e PKCS (Public Key Cryptography Standards). La differenza architetturale è significativa.

Con SCEP, la chiave privata viene generata sul dispositivo e non lo lascia mai. Con PKCS, la Certificate Authority genera centralmente sia la chiave pubblica che quella privata, e il connettore del certificato invia la coppia di chiavi al dispositivo tramite la rete. Ciò significa che la chiave privata viene trasmessa, il che introduce una superficie di attacco teorica.

PKCS è appropriato per i casi d'uso in cui è richiesto il deposito delle chiavi (key escrow), come la crittografia delle e-mail S/MIME. Per l'autenticazione WiFi, SCEP è la scelta corretta. La chiave privata rimane sul dispositivo.

Proprietà	SCEP	PKCS
Generazione della chiave privata	Sul dispositivo (TPM/Secure Enclave)	Centralizzata (CA)
Trasmissione della chiave privata	Mai	Tramite rete
Server NDES richiesto	Sì (o gateway cloud)	No
Consigliato per il WiFi	Sì	No
Consigliato per S/MIME	No	Sì

Compatibilità hardware

SCEP ed EAP-TLS sono standard indipendenti dal fornitore. Funzionano con gli access point Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. La configurazione RADIUS - che si tratti di Windows NPS, FreeRADIUS o di un servizio RADIUS cloud - è il punto in cui si definiscono i criteri di convalida dei certificati e l'assegnazione dinamica delle VLAN.

L'assegnazione dinamica delle VLAN è il modo in cui vSi segmenta la rete in base all'identità del dispositivo. Un dispositivo del personale ottiene la VLAN 10 con accesso ai sistemi interni. Un dispositivo di un fornitore esterno ottiene la VLAN 20 con solo accesso a Internet. Un terminale POS ottiene la VLAN 30 con accesso esclusivo ai sistemi di elaborazione dei pagamenti. Tutto questo è gestito dagli attributi dei certificati e dalle policy RADIUS, senza alcun intervento manuale per singolo dispositivo.

Per saperne di più su come WiFi Analytics si integra con la segmentazione della rete basata sull'identità, consulta la panoramica della nostra piattaforma di analytics.

Guida all'implementazione: la sequenza di deployment

La configurazione corretta di SCEP per il WiFi aziendale richiede il rispetto rigoroso di una specifica sequenza di deployment. Le piattaforme MDM impongono dipendenze tra i profili: un profilo WiFi che fa riferimento a un certificato SCEP non può essere applicato finché tale certificato non è presente sul dispositivo. La violazione di questa sequenza è la causa più comune di fallimento del deployment.

La sequenza è: prima la Root attendibile (Trusted Root), poi il profilo SCEP, infine il profilo WiFi. Questo ordine non è negoziabile.

Passaggio 1: distribuire il profilo del certificato Root attendibile (Trusted Root)

Prima che un dispositivo possa richiedere un certificato client o considerare attendibile il server RADIUS, deve considerare attendibile l'Autorità di Certificazione (CA) emittente. Esporta il certificato della CA Root - e gli eventuali certificati delle CA intermedie - come file .cer. Nel centro di amministrazione MDM, crea un profilo di Certificato attendibile, carica il file .cer e distribuiscilo al gruppo di dispositivi di destinazione.

Se disponi di una gerarchia PKI a due livelli (scelta consigliata), dovrai distribuire sia il certificato della CA root sia quello della CA emittente como profili di Certificato attendibile separati, oppure come catena in un unico profilo, a seconda della piattaforma MDM utilizzata.

Passaggio 2: configurare il profilo del certificato SCEP

Una volta stabilita la relazione di attendibilità, configura il profilo SCEP per indicare ai dispositivi come ottenere il proprio certificato client.

Crea un nuovo profilo di configurazione e seleziona il tipo di profilo certificato SCEP. Configura il formato del nome del soggetto (Subject name format). Per l'autenticazione basata sull'utente, lo standard è CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo (dispositivi condivisi, IoT, terminali POS), utilizza CN={{AAD_Device_ID}}. Imposta l'utilizzo della chiave (Key usage) su Firma digitale (Digital signature) e Cifratura chiave (Key encipherment). Imposta l'utilizzo avanzato della chiave (Extended Key Usage) su Autenticazione client (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2). Collega questo profilo al profilo del certificato Root attendibile creato nel Passaggio 1. Fornisci l'URL esterno del server NDES.

In particolare per Microsoft Intune, il server NDES deve essere pubblicato tramite Azure AD Application Proxy per consentire ai dispositivi remoti di registrarsi prima di arrivare in sede. Non esporre direttamente NDES a Internet.

Passaggio 3: distribuire il profilo WiFi 802.1X

L'ultimo passaggio consiste nell'inviare la configurazione WiFi che associa i certificati al SSID di rete. Crea un profilo di configurazione Wi-Fi. Inserisci il nome della rete (SSID) esattamente come viene trasmesso dai tuoi access point. Seleziona WPA2-Enterprise o WPA3-Enterprise come tipo di sicurezza. Imposta il tipo EAP su EAP-TLS. Nelle impostazioni di autenticazione, seleziona il profilo del certificato SCEP creato nel Passaggio 2 come certificato di autenticazione client. Specifica il certificato Root attendibile per la convalida del server: questo garantisce che il dispositivo si connetta solo al server RADIUS legittimo e non a un access point non autorizzato.

Integrazione con l'identity provider

Gli attributi del certificato SCEP, in particolare il Subject Alternative Name (SAN), possono contenere il nome principale dell'utente (UPN) proveniente da Microsoft Entra ID, Okta o Google Workspace. Questo associa il certificato a un'identità specifica. Quando si disabilita un account in Entra ID e l'MDM annulla la registrazione del dispositivo, il certificato viene revocato e l'accesso WiFi viene interrotto automaticamente. Questa revoca automatizzata rappresenta un livello di sicurezza che le chiavi precondivise (pre-shared keys) non possono eguagliare.

Per saperne di più su EAP Method WiFi: A Guide to Secure Network Access , inclusi i percorsi di migrazione PEAP-MSCHAPv2, consulta la nostra guida dedicata.

Best practice e standard di settore

Posizionamento del server NDES

Il server NDES deve essere accessibile da Internet in modo che i dispositivi possano registrarsi prima di arrivare in sede. Pubblica l'URL di NDES tramite Azure AD Application Proxy. Ciò garantisce un accesso remoto sicuro senza aprire porte in entrata nel firewall e consente di applicare criteri di accesso condizionale (Conditional Access) al flusso di registrazione. Non esporre mai NDES direttamente a Internet.

Per le reti con più di 500 dispositivi gestiti, considera l'utilizzo di un gateway SCEP cloud anziché di un server NDES on-premises. I gateway cloud eliminano il singolo punto di guasto (single point of failure) di NDES, scalano orizzontalmente e in genere si integrano direttamente con i servizi RADIUS cloud.

Disponibilità della CRL

Il server RADIUS controlla la Certificate Revocation List (CRL) ogni volta che un dispositivo si autentica. Se il punto di distribuzione della CRL (CDP) non è disponibile, ad esempio perché un server è offline o l'URL è cambiato, l'autenticazione fallisce contemporaneamente per tutti i dispositivi della rete. Configura il server NPS o RADIUS per imporre un controllo rigoroso della CRL e rendi i tuoi endpoint CRL altamente disponibili. Testa la revoca prima di andare in produzione.

Il requisito 8.6 di PCI DSS 4.0 impone l'autenticazione a più fattori a livello di rete per gli ambienti con dati dei titolari di carta. EAP-TLS con certificati forniti tramite SCEP soddisfa questo requisito per le reti wireless negli ambienti Retail e Hospitality .

Compatibilità con WPA3

EAP-TLS è completamente compatibile con WPA3-Enterprise. WPA3-Enterprise con la suite di sicurezza a 192 bit (Suite B) richiede obbligatoriamente EAP-TLS ed è la combinazione consigliata dalla Wi-Fi Alliance per le reti governative, finanziarie e sanitarie. Se stai effettuando il deployment in ambienti del settore Healthcare o Transport con requisiti di conformità rigorosi, WPA3-Enterprise con EAP-TLS è l'architettura di destinazione corretta.

BYOD e guest WiFi

SCEP richiede la registrazione MDM per inviare il payload del certificato. Non copre i dispositivi BYOD non gestiti o gli ospiti. Per questi casi d'uso, è necessario un SSID separato con un Captive Portal e la verifica dell'identità. La piattaforma di Purple gestisce questo livello in modo pulito, affiancandosi alla rete del personale autenticata tramite certificato. La nostra piattaforma Guest WiFi supporta l'opt-in consapevole, l'acquisizione di dati di prima parte e l'integrazione con Microsoft Entra ID, Okta e Google Workspace per la verifica dell'identità.

Risoluzione dei problemi e mitigazione dei rischi

Impossibile applicare il profilo WiFi

Sintomo: Il dispositivo riceve i certificati Trusted Root e SCEP, ma il profilo WiFi risulta come Errore o Non applicabile nell'MDM.

Causa principale: Mancata corrispondenza del gruppo di destinazione. Se il profilo SCEP ha come destinazione un gruppo Utenti e il profilo WiFi ha come destinazione un gruppo Dispositivi, l'MDM non può risolvere la dipendenza.

Soluzione: Controlla le assegnazioni. Assicurati che i profili Trusted Root, SCEP e WiFi abbiano tutti come destinazione lo stesso identico gruppo di directory.

Errori NDES 403 Forbidden

Sintomo: I dispositivi non riescono a recuperare il certificato SCEP. I log IIS di NDES mostrano errori HTTP 403.

Causa principale: L'account di servizio MDM Certificate Connector non dispone delle autorizzazioni di Lettura e Registrazione sul modello di certificato, oppure il filtraggio degli URL del firewall blocca i parametri della query string SCEP.

Soluzione: Verifica che l'account del connettore disponga delle autorizzazioni di Lettura e Registrazione sul modello CA. Controlla i log del firewall per assicurarti che gli URL contenenti ?operation=GetCACaps non siano bloccati.

Errore di autenticazione di massa dopo la scadenza della CRL

Sintomo: Tutti i dispositivi sulla rete non riescono a autenticarsi contemporaneamente.

Causa principale: La CRL è scaduta o l'URL CDP non è raggiungibile. Il server RADIUS non può confermare la validità dei certificati e si blocca in modalità protetta (fails closed).

Soluzione: Configura il monitoraggio e gli avvisi per la CRL. Pubblica le CRL con un periodo di validità significativamente più lungo dell'intervallo di pubblicazione. Testa la raggiungibilità del CDP dal server RADIUS prima del go-live.

Scadenza dei certificati che causa errori silenziosi

Sintomo: Singoli dispositivi non riescono a connettersi in modo intermittente, senza un pattern chiaro.

Causa principale: I certificati client sono scaduti e l'MDM non li ha rinnovati correttamente.

Soluzione: Configura il rinnovo del certificato in modo che si attivi all'80% della durata del certificato stesso. Monitora i report sullo stato di registrazione MDM per i dispositivi con errori di certificato. Imposta periodi di validità dei certificati adeguati al ciclo di aggiornamento dei dispositivi, in genere da uno a due anni per gli endpoint gestiti.

ROI e impatto aziendale

La transizione all'autenticazione tramite certificato 802.1X basata su SCEP offre ritorni misurabili in termini di sicurezza, operazioni e conformità.

Riduzione dei ticket di helpdesk: Il WiFi basato su password genera un volume significativo di ticket di supporto: scadenze delle password, blocchi e refusi. L'autenticazione basata su certificato è invisibile all'utente. Le organizzazioni registrano in genere una riduzione del 70-80% del volume di helpdesk relativo al WiFi dopo la migrazione.

Postura di sicurezza: EAP-TLS elimina il furto di credenziali e gli attacchi Man-in-the-Middle. Ciò supporta direttamente la conformità a PCI DSS 4.0 per le reti del settore retail e hospitality, e i requisiti dell'Articolo 32 del GDPR relativi a misure tecniche di sicurezza adeguate.

Revoca automatizzata: Quando un dipendente lascia l'azienda, la disattivazione del suo account in Microsoft Entra ID attiva la revoca automatica del certificato e l'annullamento della registrazione MDM. L'accesso al WiFi viene interrotto senza alcun intervento manuale da parte del team di rete.

Segmentazione della rete: L'assegnazione dinamica della VLAN tramite gli attributi del certificato RADIUS offre una segmentazione della rete applicata crittograficamente. I dispositivi atterrano sul segmento di rete corretto in base alle proprietà del certificato, non alla selezione dell'SSID o al filtraggio degli indirizzi MAC, entrambi facilmente aggirabili.

Purple opera in oltre 80.000 sedi attive con un uptime del 99,999% e la nostra piattaforma è certificata ISO 27001, GDPR, CCPA e Cyber Essentials. Il nostro overlay cloud indipendente dall'hardware si integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet, in modo che la rete del personale autenticata tramite certificato e il nostro livello WiFi per gli ospiti funzionino sulla stessa infrastruttura.

Per saperne di più su come Analisi comportamentale: approfondimenti per le reti WiFi può integrare la distribuzione della tua rete sicura, consulta la nostra guida all'analisi.

Riferimenti

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

A protocol formalised in RFC 8894 that allows managed devices to automatically request and receive X.509 digital certificates from a Certificate Authority via HTTP, using a shared challenge password for initial authentication. The private key is generated on the device and never transmitted.

The standard mechanism used by MDM platforms like Microsoft Intune and Jamf to deploy WiFi authentication certificates to managed endpoints at scale.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

The most secure 802.1X authentication method, requiring both the client device and the RADIUS server to present valid X.509 certificates. Mutual authentication means neither side trusts the other without cryptographic proof.

The target authentication protocol for enterprise WiFi. Mandated or strongly recommended by PCI DSS 4.0, WPA3-Enterprise 192-bit (Suite B), and HIPAA for wireless networks handling sensitive data.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a Registration Authority (RA) between SCEP-enabled devices and a Certificate Authority. It validates challenge passwords and forwards CSRs to the CA on behalf of devices that lack domain credentials.

Required infrastructure for SCEP deployment with Microsoft Intune. Should be published via Azure AD Application Proxy rather than exposed directly to the internet.

PKI (Public Key Infrastructure)

The hierarchy of Certificate Authorities, policies, and procedures used to issue, manage, and revoke digital certificates. A two-tier PKI consists of an offline root CA (the master trust anchor) and an online issuing CA (which handles day-to-day certificate issuance).

The non-negotiable prerequisite for EAP-TLS and SCEP deployment. The root CA should be kept air-gapped; its private key is the foundation of your entire certificate trust chain.

CSR (Certificate Signing Request)

A message generated by a device containing its public key and identity information, sent to a Certificate Authority to request a signed digital certificate. In SCEP, the CSR is generated on-device and wrapped in a PKCS envelope before transmission.

Generated automatically by the device during the SCEP enrollment flow. The private key used to sign the CSR never leaves the device.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date. RADIUS servers check the CRL on every authentication attempt to ensure revoked certificates cannot access the network.

CRL Distribution Point (CDP) availability is critical. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication - causing a network-wide outage.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) for network access. In 802.1X WiFi, the RADIUS server validates client certificates, checks the CRL, and returns an Access-Accept or Access-Reject message to the access point.

The authentication server in the 802.1X supplicant-authenticator-server model. Common implementations include Windows NPS, FreeRADIUS, and cloud RADIUS services.

Dynamic VLAN assignment

A RADIUS feature that places an authenticated device on a specific VLAN based on certificate attributes or directory group membership, rather than relying on SSID selection or MAC address filtering. Enforces network segmentation by device identity.

Enables a single SSID to serve multiple device types with different network access levels. A staff device gets VLAN 10 (internal access); a contractor device gets VLAN 20 (internet only); a POS terminal gets VLAN 30 (payment systems only).

MDM (Mobile Device Management)

Software used by IT teams to enroll, configure, secure, and manage smartphones, tablets, and laptops. MDM platforms like Microsoft Intune and Jamf use SCEP profiles to push certificate enrollment instructions to managed devices without user interaction.

The prerequisite for SCEP-based certificate deployment. Devices must be MDM-enrolled before they can receive SCEP and WiFi profiles. Unmanaged BYOD devices require a separate onboarding approach.

Esempi pratici

A 200-room Premier Inn property needs to secure its staff WiFi for point-of-sale tablets and housekeeping smartphones. They currently use a pre-shared key that has been leaked to contractors. They manage devices via Microsoft Intune and have a mix of iOS and Android devices. The property uses HPE Aruba access points.

Deploy an internal Microsoft AD CS two-tier PKI. Configure NDES on a dedicated Windows Server and publish it via Azure AD Application Proxy.
In Intune, create a Trusted Root Certificate profile containing the Root CA and Issuing CA certificates. Deploy to a 'Property Staff Devices' Azure AD group.
Create a SCEP Certificate profile in Intune pointing to the NDES external URL. Set Subject Name format to CN={{AAD_Device_ID}} since these are shared devices. Set Key Usage to Digital Signature and Key Encipherment, Extended Key Usage to Client Authentication. Deploy to 'Property Staff Devices'.
Create a Wi-Fi profile for the staff SSID, configuring WPA2-Enterprise and EAP-TLS. Select the SCEP profile for client authentication and the Root CA for server validation. Deploy to 'Property Staff Devices'.
Configure the HPE Aruba RADIUS settings to point to Windows NPS. On NPS, configure a Network Policy requiring EAP-TLS and assigning VLAN 10 for staff devices.
Once devices receive profiles and connect successfully, rotate the PSK on the old SSID and schedule its decommission.

Commento dell'esaminatore: This approach correctly identifies that shared devices (POS, housekeeping) require device-based authentication (CN={{AAD_Device_ID}}) rather than user-based authentication, since multiple staff members use the same device. It follows the mandatory profile deployment sequence and ensures all three profiles target the same Azure AD group. Publishing NDES via App Proxy rather than direct internet exposure is the correct security posture for a hospitality environment.

A retail chain with 50 locations wants to deploy 802.1X for corporate laptops across all sites. They use Cisco Meraki access points and Microsoft Intune. They do not want to deploy and maintain on-premises NDES servers or AD CS infrastructure at each location or in their data centre.

Implement a cloud-based PKI and SCEP gateway service that integrates with Intune via the SCEP protocol. The cloud CA issues certificates; the cloud SCEP gateway handles CSR validation.
Configure the cloud RADIUS service (provided by the PKI vendor) within the Cisco Meraki dashboard under Wireless > Access Control for the corporate SSID. Set security to WPA2-Enterprise and point RADIUS to the cloud service.
In Intune, create a Trusted Root Certificate profile containing the cloud CA root certificate. Deploy to 'Corporate Laptops' device group.
Create a SCEP Certificate profile pointing to the cloud SCEP gateway URL. Set Subject Name to CN={{UserPrincipalName}} for user-based authentication. Deploy to 'Corporate Laptops'.
Create a Wi-Fi profile for the corporate SSID with EAP-TLS, referencing the SCEP profile and the cloud CA root. Deploy to 'Corporate Laptops'.
When laptops enroll in Intune, they automatically request certificates from the cloud CA via the cloud SCEP gateway. No on-premises infrastructure is required at any of the 50 locations.

Commento dell'esaminatore: This is the optimal modern architecture for distributed retail environments. By leveraging cloud PKI and cloud RADIUS, the organisation eliminates the need to maintain complex on-premises infrastructure (NDES, AD CS, NPS) at each site. The cloud SCEP gateway scales horizontally and is inherently highly available, removing the single point of failure that on-premises NDES introduces. Cisco Meraki's cloud-managed architecture aligns well with this approach.

Domande di esercitazione

Q1. Your organisation is migrating from PEAP-MSCHAPv2 to EAP-TLS. You have successfully deployed the Trusted Root and SCEP profiles to your 'Corporate Users' Azure AD group in Intune. You deploy the WiFi profile to 'All Corporate Devices'. Users report they cannot connect and the WiFi profile shows as Not Applicable.

Suggerimento: Check the profile dependencies and group targeting rules. Intune resolves profile dependencies based on the assigned group.

Visualizza risposta modello

The issue is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which was targeted at a User group ('Corporate Users'). The WiFi profile was targeted at a Device group ('All Corporate Devices'). Intune cannot resolve the dependency across group types. The fix is to change all three profile assignments - Trusted Root, SCEP, and WiFi - to target the same group. Decide whether to use a User group or a Device group based on your authentication model (user-based vs device-based), and apply that consistently across all three profiles.

Q2. A security audit reveals that when an employee is terminated and their Microsoft Entra ID account is disabled, their corporate smartphone can still connect to the staff WiFi network for up to a week after termination.

Suggerimento: Consider how the RADIUS server determines whether a certificate is still valid after the account is disabled. What is the mechanism for communicating revocation status?

Visualizza risposta modello

The RADIUS server is not performing strict Certificate Revocation List checking, or the CRL is published infrequently. When an employee is terminated, the MDM should unenroll the device and the CA should revoke the certificate. However, if the RADIUS server is not checking the CRL on every authentication attempt - or if the CRL is only published weekly - the revoked certificate continues to be accepted. The fix involves three steps: configure the RADIUS server to enforce strict CRL checking on every authentication; configure the CA to publish the CRL at a shorter interval (daily or more frequently); and ensure the MDM is configured to trigger certificate revocation when a device is unenrolled.

Q3. You need to provide secure WiFi access for headless IoT devices (smart thermostats, digital signage players) that cannot run an MDM agent and cannot display a captive portal. Can you use SCEP for these devices, and if not, what is the recommended alternative?

Suggerimento: Consider the prerequisites for SCEP enrollment and what alternatives exist for devices that cannot be MDM-enrolled or interact with a browser.

Visualizza risposta modello

SCEP cannot be used for these devices. SCEP requires an MDM agent to receive the enrollment URL and challenge password, generate the key pair, and install the resulting certificate. Headless IoT devices that cannot run an MDM agent cannot participate in the SCEP enrollment flow. The recommended alternatives are: (1) MAC Authentication Bypass (MAB) combined with strict VLAN segmentation - the RADIUS server allows the device based on its MAC address and places it on an isolated IoT VLAN with no access to corporate systems; (2) if the device supports it, EST (Enrollment over Secure Transport, RFC 7030) can provision certificates to devices that support HTTPS but not MDM; (3) for devices with a management interface, some vendors support SCEP enrollment directly via the device firmware without requiring an MDM agent. In all cases, IoT devices should be isolated on a dedicated VLAN regardless of the authentication method used.

Continua a leggere questa serie

Come configurare un Captive Portal su Starlink: una guida per sedi remote e marittime

Questa guida spiega in dettaglio come escludere l'hardware nativo di Starlink e integrare un Captive Portal gestito in cloud utilizzando apparecchiature di routing aziendali. Imparerai come superare il limite del CGNAT, applicare la segmentazione VLAN, gestire i vincoli di larghezza di banda satellitare e garantire la conformità normativa.

Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards

Questa guida tecnica descrive in dettaglio come progettare reti WiFi per hotel di livello enterprise, concentrandosi sulla segmentazione VLAN, sull'integrazione PMS per la gestione automatizzata delle sessioni e sull'ottimizzazione del Captive Portal per l'acquisizione di dati conforme al GDPR.

Captive Portal Best Practices: Designing for High Conversion and Compliance

Questa guida tecnica offre a IT manager, architetti di rete e direttori operativi delle sedi un modello completo per l'implementazione di captive portal in grado di bilanciare la sicurezza di rete con un'elevata conversione degli utenti. Copre l'intera architettura, dalla segmentazione VLAN e l'autenticazione RADIUS fino alla progettazione del consenso conforme al GDPR e alla selezione del metodo di autenticazione. Tratta dall'esperienza operativa di Purple in oltre 80.000 sedi e 440 milioni di accessi nel 2024, ogni raccomandazione si basa su dati di implementazione reali.