Come implementare SCEP per la registrazione automatizzata dei certificati WiFi

Questa guida spiega come implementare SCEP (Simple Certificate Enrollment Protocol) per la registrazione automatizzata dei certificati WiFi nelle sedi aziendali. Copre l'intero progetto architetturale - dalla progettazione PKI e integrazione MDM alla sequenza di implementazione obbligatoria in tre fasi - e mostra ai responsabili IT e agli architetti di rete come eliminare le credenziali condivise, automatizzare la gestione del ciclo di vita dei certificati e soddisfare i requisiti PCI DSS e GDPR su scala.

📖 10 minuti di lettura📝 2,383 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 10 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del podcast

INTRODUCTION AND CONTEXT - 0:00 to 1:00

Hello, and welcome to this technical briefing from Purple. Today we are unpacking SCEP, the Simple Certificate Enrollment Protocol, and how to implement it for automated WiFi certificate enrollment. If you are a network architect, an IT director, or managing infrastructure for large venues like retail chains, hospitals, or stadiums, this briefing is for you. We are cutting through the noise to discuss how to deploy EAP-TLS at scale, why SCEP is the right choice for device identity, and how you can practically deploy it in your environment. Let us get straight into it.

TECHNICAL DEEP-DIVE - 1:00 to 6:00

So, what exactly is the challenge we are solving here? In the world of enterprise WiFi security, EAP-TLS represents the gold standard. Unlike legacy methods such as PEAP or EAP-TTLS, which rely on user passwords, EAP-TLS mandates mutual certificate-based authentication. This means the client device must verify the network identity via a server certificate, and the network must verify the client identity via a unique client certificate.

Think about the vulnerability of passwords. They can be shared, phished, or stolen. In a sprawling enterprise environment, a compromised password can grant a bad actor access to your entire internal network. EAP-TLS eliminates this vector entirely. The authentication relies on X.509 certificates issued by a Public Key Infrastructure, or PKI.

But the core challenge with EAP-TLS is not the protocol itself. It is the logistics of getting unique client certificates onto thousands of devices, whether they are Windows laptops, iPads, or point-of-sale tablets. You cannot manually install certificates on thousands of devices. This is where Mobile Device Management platforms like Microsoft Intune or Jamf come into play. But how do you deliver those certificates securely?

You generally have two choices: PKCS or SCEP. Let me be absolutely clear on this. For WiFi authentication, you want SCEP. Here is why it matters. With SCEP, the MDM instructs the endpoint device to generate its own private key locally. That key stays locked in the device secure hardware. It never travels across the network. The device just sends a Certificate Signing Request to your Certificate Authority via a gateway, usually an NDES server.

Contrast that with PKCS, where the Certificate Authority generates the private key centrally and pushes it down over the network to the device. While PKCS has its place, say, for email encryption where you need key escrow, transmitting private keys over the network is a risk you do not need to take for network authentication. Keep the keys on the device. Use SCEP.

Now, let us talk implementation. If you take away one thing from this briefing, it is this rule of thumb: Trust before Authentication. You cannot just push a WiFi profile and expect it to work. There is a strict, three-step deployment sequence you must follow.

Step one: Deploy the Trusted Root Certificate. Before a device can ask for a client certificate, or trust your RADIUS server, it has to trust the issuing Certificate Authority. Push this profile first.

Step two: Configure and push the SCEP Certificate Profile. This tells the device how to talk to the SCEP gateway, what format to use for its subject name, and what the certificate is actually for. In this case, Client Authentication. You must link this profile to the Trusted Root you deployed in step one.

Step three: Deploy the 802.1X WiFi Profile. This is where you tie it all together. You specify the SSID, select WPA3-Enterprise, set the EAP type to EAP-TLS, and point it to the SCEP certificate for client authentication.

IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 6:00 to 8:00

Here is a major pitfall we see all the time. A client calls us and says, the certificates are on the device, but the WiFi profile shows an error in Intune. Almost every single time, this is a group targeting mismatch. If you assign the SCEP profile to a Users group, but assign the WiFi profile to a Devices group, the MDM cannot resolve the dependency. Match your targets exactly across all three profiles.

Let us look at a real-world scenario. Imagine a 200-room hotel. They have 150 managed iOS devices for housekeeping staff. Currently, they use a standard password network, and staff keep sharing the password with guests. It is a genuine operational headache. By migrating to WPA2-Enterprise with EAP-TLS via SCEP, the IT Director eliminates the password entirely. The iOS devices authenticate silently in the background using their certificates.

But what happens if a housekeeper loses a device, or leaves the company? Disabling their Active Directory account is not enough, because the certificate on that device is still cryptographically valid. This brings us to a critical security control: strict CRL checking. You must configure your RADIUS server to check the Certificate Revocation List. If a device goes missing, you revoke the certificate at the CA. The RADIUS server sees the revocation on the CRL and immediately blocks network access. Without strict CRL checking, your security posture is incomplete.

RAPID-FIRE Q&A - 8:00 to 9:00

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

Question one: Is EAP-TLS required for WPA3 Enterprise? While WPA3 Enterprise supports other methods, EAP-TLS is strongly recommended and is required if you are implementing the WPA3 Enterprise 192-bit security suite, often called Suite B.

Question two: Can we use public certificates for clients? No. You must use a private internal CA for client certificates. Public CAs are for public-facing web servers. Your internal RADIUS server needs to trust your specific internal Root CA to validate your corporate devices.

Question three: How does this fit with OpenRoaming? OpenRoaming relies on Passpoint and 802.1X. Purple acts as a free identity provider for services like OpenRoaming under the Connect licence, facilitating seamless, secure roaming across venues using underlying certificate and identity frameworks.

SUMMARY AND NEXT STEPS - 9:00 to 10:00

To wrap up, transitioning to automated SCEP certificate deployment delivers real, measurable returns. You will see a 70 to 80 percent reduction in WiFi-related helpdesk tickets, because users are not getting locked out or typing passwords incorrectly. More importantly, you eliminate the risk of credential harvesting, ensuring you meet compliance frameworks like PCI DSS and GDPR.

Automating enterprise WiFi security is not just about locking things down. It is about making the secure path the easiest path for your users. Your next steps: audit your current 802.1X deployment. If you are still relying on passwords, design your PKI and plan the migration to EAP-TLS with SCEP. Check whether your RADIUS server is enforcing strict CRL or OCSP checking. And verify that your three deployment profiles all target the same group.

Thank you for listening to this technical briefing from Purple. For more detailed deployment guides and to understand how our analytics and identity platforms can integrate with your secure networks, visit purple dot ai.

Punti chiave

✓SCEP (RFC 8894) automates X.509 certificate enrollment for managed devices. The private key is generated locally on the device and never transmitted over the network - this is the core security advantage over PKCS.
✓For 802.1X EAP-TLS WiFi authentication, always use SCEP. Reserve PKCS for use cases requiring key escrow, such as S/MIME email encryption.
✓The deployment sequence is non-negotiable: Trusted Root Certificate first, then SCEP Certificate Profile, then 802.1X WiFi Profile. All three profiles must target the exact same Azure AD group.
✓Strict CRL or OCSP checking on the RADIUS server is mandatory. Disabling an AD account does not revoke a certificate. Revoke at the CA and ensure the RADIUS server acts on it.
✓EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer and is required for WPA3 Enterprise 192-bit (Suite B) deployments.
✓Organisations migrating from password-based WiFi to EAP-TLS with SCEP typically report a 70-80% reduction in WiFi-related helpdesk tickets (Purple internal data, 2024).
✓For distributed estates (hotel groups, retail chains, multi-site public-sector), cloud-hosted SCEP gateways and managed PKI services eliminate the on-premises NDES infrastructure requirement without compromising security.

Sintesi esecutiva

Per i gestori di sedi che offrono il Guest WiFi in hotel, complessi commerciali, stadi e centri congressi, affidarsi a chiavi pre-condivise o a Captive Portal di base per l'accesso alla rete del personale rappresenta un rischio per la sicurezza. L'architettura di rete moderna richiede l'autenticazione 802.1X tramite EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantendo che ogni dispositivo sia verificato crittograficamente prima di accedere alla rete. La sfida risiede nella distribuzione: come distribuire certificati client univoci a migliaia di dispositivi Windows, iOS e Android senza sovraccaricare l'helpdesk?

La risposta è SCEP - il Simple Certificate Enrollment Protocol. Formalizzato dall'IETF come RFC 8894 nel 2020, SCEP automatizza la registrazione dei certificati su flotte di dispositivi gestiti. Se integrato con una piattaforma MDM come Microsoft Intune o Jamf, SCEP offre un provisioning dei certificati zero-touch: i dispositivi richiedono, ricevono e rinnovano i propri certificati senza alcun intervento da parte dell'IT. La chiave privata viene generata localmente sul dispositivo e non viene mai trasmessa sulla rete: un vantaggio fondamentale in termini di sicurezza rispetto alla distribuzione basata su PKCS.

Questa guida illustra l'intero flusso di lavoro per l'implementazione di SCEP: l'architettura PKI, la configurazione del gateway NDES, la sequenza obbligatoria di implementazione MDM in tre fasi e i controlli operativi - in particolare il controllo CRL e il targeting dei gruppi - che determinano il successo o il blocco di un rollout. Due scenari reali illustrano l'approccio in ambienti ricettivi e commerciali. Purple opera in oltre 80.000 sedi attive e conta 350 milioni di utenti unici; i modelli descritti qui riflettono ciò che funziona su tale scala.

Approfondimento tecnico

Cosa fa effettivamente SCEP

SCEP si colloca tra la piattaforma MDM e la Certificate Authority (CA). Fornisce un meccanismo standardizzato basato su HTTP che consente ai dispositivi di richiedere, ricevere e rinnovare certificati X.509 senza richiedere credenziali associate al dominio o l'intervento manuale dell'amministratore. Il protocollo è stato originariamente sviluppato nei primi anni 2000 e ha ottenuto un'ampia adozione negli ambienti MDM aziendali prima che l'IETF lo pubblicasse formalmente come RFC 8894.

Il flusso di registrazione in sei fasi funziona come segue. In primo luogo, il dispositivo gestito si connette all'URL del gateway SCEP preconfigurato nel suo profilo MDM. In secondo luogo, il dispositivo genera localmente una coppia di chiavi privata/pubblica e crea una Certificate Signing Request (CSR). In terzo luogo, il gateway SCEP convalida l'autorizzazione del dispositivo utilizzando una password di verifica o OTP incorporata nella policy MDM. In quarto luogo, il gateway inoltra la CSR convalidata alla CA. In quinto luogo, la CA firma il certificato e lo restituisce al gateway. In sesto luogo, il gateway distribuisce il certificato firmato al dispositivo. I rinnovi futuri seguono lo stesso percorso automatizzato: il dispositivo si registra nuovamente prima della scadenza senza alcuna azione da parte dell'utente o dell'amministratore.

SCEP vs PKCS: la decisione che conta

Microsoft Intune e la maggior parte delle piattaforme MDM supportano due meccanismi di distribuzione dei certificati: SCEP e PKCS. La distinzione è architetturale, non estetica.

Con SCEP, la chiave privata viene generata sul dispositivo e rimane lì. La CA non la vede mai. Il TPM del dispositivo (su Windows) o il Secure Enclave (su iOS/macOS) proteggono la chiave a livello hardware. Con PKCS, la CA genera la coppia di chiavi centralmente e la trasmette al dispositivo tramite la rete. La CA ne conserva una copia, consentendo il key escrow, utile per la crittografia delle e-mail S/MIME ma che introduce rischi non necessari per l'autenticazione di rete.

Per l'autenticazione WiFi 802.1X, utilizza SCEP. La chiave privata non lascia mai il dispositivo. Questa è la regola.

Criterio	SCEP	PKCS
Chiave privata generata su	Dispositivo	CA (centralmente)
Chiave privata trasmessa sulla rete	Mai	Sì
Supporta TPM / Secure Enclave	Sì	No
Consigliato per l'autenticazione WiFi	Sì	No
Consigliato per la crittografia e-mail (S/MIME)	No	Sì
Key escrow possibile	No	Sì

802.1X ed EAP-TLS: il framework di autenticazione

IEEE 802.1X è lo standard di controllo dell'accesso alla rete basato su porte alla base della sicurezza WiFi aziendale. Definisce tre ruoli: il supplicant (il dispositivo client), l'authenticator (l'access point - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) e l'authentication server (un server RADIUS come Microsoft NPS, FreeRADIUS o Cisco ISE).

EAP-TLS è il metodo EAP più sicuro per 802.1X. Entrambe le parti presentano certificati: il server RADIUS presenta il proprio certificato al client e il client presenta il proprio certificato fornito tramite SCEP al server RADIUS. Nessuna delle due parti può impersonare l'altra senza un certificato valido e non revocato proveniente dalla gerarchia CA attendibile. Questo modello di autenticazione reciproca elimina il furto di credenziali, gli attacchi Evil Twin e i rischi di access point non autorizzati in un'unica decisione architetturale.

EAP-TLS soddisfa il requisito 8.6 di PCI DSS 4.0 per l'autenticazione a più fattori a livello di rete. È richiesto per le distribuzioni WPA3 Enterprise a 192 bit (Suite B). Per qualsiasi rete wireless nell'ambito dell'elaborazione dei dati dei titolari di carta - retail point-of-sale, reception dell'hotel, biglietteria dello stadio - EAP-TLS è la scelta corretta.

Per un approfondimento sull'architettura di secure WiFi e su come l'autenticazione basata su certificati si inserisca in un contesto di sicurezza più ampio, consulta la nostra guida essenziale.

Guida all'implementazione

La sequenza di distribuzione non è negoziabile. Intune e Jamf risolvono le dipendenze dei profili in ordine: il profilo WiFi dipende dal profilo SCEP, che a sua volta dipende dal profilo Trusted Root. Se distribuiti fuori sequenza, l'applicazione del profilo WiFi non andrà a buon fine.

Passaggio 1: Progetta la tua PKI

Prima di toccare una console MDM, progetta la gerarchia dei certificati. Una PKI a due livelli è lo standard: una CA radice (root CA) offline e una CA emittente (issuing CA) online. La chiave privata della root CA è l'ancora di attendibilità principale (master trust anchor) per l'intera infrastruttura di certificati: mantienila isolata (air-gapped). La CA emittente gestisce il rilascio quotidiano dei certificati e pubblica la Certificate Revocation List (CRL) e il risponditore OCSP.

Per la maggior parte delle distribuzioni in grandi strutture aziendali, Microsoft Active Directory Certificate Services (AD CS) eseguito su Windows Server fornisce la CA emittente. I servizi PKI ospitati in cloud di provider come SCEPman o SecureW2 eliminano completamente la necessità di un'infrastruttura on-premises e meritano di essere valutati per distribuzioni distribuite su gruppi alberghieri, catene di vendita al dettaglio o organizzazioni del settore pubblico multi-sito.

Passaggio 2: Distribuisci il server NDES (o il gateway SCEP cloud)

NDES (Network Device Enrollment Service) è il ruolo di Microsoft Windows Server che funge da gateway SCEP tra l'MDM e la CA. Requisiti di configurazione chiave:

Pubblica l'URL NDES esternamente tramite Azure AD Application Proxy (or proxy inverso equivalente). Ciò consente ai dispositivi remoti di registrarsi prima di arrivare in sede, senza aprire porte del firewall in entrata.
L'account di servizio NDES richiede le autorizzazioni di Lettura e Registrazione (Read and Enroll) sul modello di certificato della CA.
Configura il modello di certificato con Key Usage impostato su Digital Signature e Key Encipherment, ed Extended Key Usage impostato su Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
Imposta un periodo di validità del certificato appropriato. Un anno è lo standard per i certificati client; due anni sono accettabili per i certificati dei dispositivi in flotte stabili.

Se preferisci evitare l'infrastruttura NDES on-premises, i gateway SCEP cloud si integrano direttamente con Intune e la tua CA tramite API, eliminando completamente la dipendenza da IIS.

Passaggio 3: Distribuisci il profilo Trusted Root Certificate

Nella tua piattaforma MDM, crea un profilo Trusted Certificate e carica il certificato della tua Root CA (e gli eventuali certificati delle CA intermedie) come file .cer. Distribuisci questo profilo ai gruppi di dispositivi di destinazione prima di qualsiasi altro profilo di certificato o WiFi. Senza questo passaggio, i dispositivi non possono convalidare il certificato del server RADIUS durante l'handshake EAP-TLS e non possono considerare attendibile la CA emittente quando richiedono il proprio certificato SCEP.

Regola empirica: Indirizza sempre lo stesso gruppo Azure AD (Utenti o Dispositivi) in tutti e tre i profili correlati. Un disallineamento in questo punto è la causa più comune in assoluto del fallimento della distribuzione del profilo WiFi.

Passaggio 4: Configura il profilo SCEP Certificate

Crea un profilo di configurazione del certificato SCEP nel tuo MDM:

Formato del nome del soggetto (Subject name format): Per l'autenticazione guidata dall'utente, usa CN={{UserPrincipalName}}. Per l'autenticazione del dispositivo (consigliata per dispositivi condivisi e IoT), usa CN={{AAD_Device_ID}}.
Key usage: Digital Signature, Key Encipherment.
Extended key usage: Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
URL del server SCEP: L'URL NDES pubblicato esternamente.
Certificato radice (Root certificate): Collega al profilo Trusted Root del Passaggio 3.
Periodo di validità del certificato: Deve corrispondere al modello configurato sulla CA.

Passaggio 5: Distribuisci il profilo WiFi 802.1X

Crea un profilo di configurazione WiFi:

SSID: Inserisci il nome della rete esattamente come trasmesso dai tuoi access point.
Tipo di sicurezza: WPA2-Enterprise o WPA3-Enterprise.
Tipo EAP: EAP-TLS.
Certificato di autenticazione client: Seleziona il profilo del certificato SCEP dal Passaggio 4.
Convalida del server: Specifica il certificato Trusted Root del Passaggio 3 e inserisci il nome del server RADIUS previsto. Ciò impedisce ai dispositivi di connettersi ad access point non autorizzati che presentano certificati fraudolenti.

Best practice

Imponi un controllo rigoroso della CRL sul tuo server RADIUS

La revoca del certificato è il controllo operativo che colma il divario tra la disattivazione di un account e il blocco dell'accesso alla rete. Quando un dispositivo viene smarrito, rubato o un dipendente lascia l'azienda, disattiva l'account AD e revoca il certificato presso la CA. Il tuo server RADIUS deve essere configurato per controllare la CRL a ogni tentativo di autenticazione. Se la CRL non è disponibile (perché il CDP, ovvero il CRL Distribution Point, è irraggiungibile), la maggior parte dei server RADIUS per impostazione predefinita consente l'accesso (fail open), il che rappresenta un rischio per la sicurezza. Assicurati che i tuoi CDP siano altamente disponibili e che il tuo server RADIUS sia configurato per bloccare l'accesso (fail closed) se non è possibile recuperare la CRL.

Per la revoca in tempo reale, configura OCSP (Online Certificate Status Protocol) in aggiunta alla CRL. OCSP fornisce risposte sullo stato del singolo certificato senza richiedere al server RADIUS di scaricare e analizzare l'intera CRL.

Utilizza i certificati del dispositivo per i dispositivi condivisi e IoT

Per i dispositivi condivisi (tablet per il servizio di pulizia degli hotel, terminali POS per la vendita al dettaglio, lettori per il controllo degli accessi negli stadi), utilizza i certificati del dispositivo anziché i certificati utente. I certificati del dispositivo sono legati all'identità della macchina, non a un account utente. Ciò significa che il dispositivo si autentica indipendentemente dall'utente che ha effettuato l'accesso e la revoca è legata al record del dispositivo anziché alla partenza di un dipendente.

Per le distribuzioni nel settore retail , i certificati del dispositivo sull'hardware POS soddisfano anche il requisito PCI DSS per l'identità del dispositivo a livello di rete, senza introdurre la complessità delle credenziali utente nel point-of-sale.

Automatizza il rinnovo dei certificati

SCEP supporta il rinnovo automatico: l'MDM indica al dispositivo di registrarsi nuovamente prima che il certificate expires. Configure your SCEP profile to trigger renewal at 20% of the certificate's remaining validity period. For a one-year certificate, renewal begins approximately 73 days before expiry. This window provides enough time to resolve any renewal failures before the certificate expires and devices lose network access.

Expired certificates causing mass authentication failures are the most common operational incident in 802.1X deployments. Automated renewal via SCEP eliminates this risk entirely.

Segment networks by certificate attribute

RADIUS servers can read certificate attributes - Subject, SAN, or custom OIDs - and use them to assign devices to VLANs dynamically. A housekeeping tablet with a certificate issued from the HousekeepingDevices template lands on the housekeeping VLAN. A POS terminal with a certificate from the RetailPOS template lands on the PCI-scoped VLAN. This is cryptographically enforced network segmentation - far more reliable than SSID-based or MAC-based approaches.

For hospitality operators running Guest WiFi alongside Staff WiFi on the same physical infrastructure, VLAN assignment via certificate attributes ensures guests and staff are always on separate network segments, regardless of which SSID a device connects to.

Troubleshooting & risk mitigation

WiFi profile shows 'Error' or 'Not Applicable' in Intune

Root cause: Group targeting mismatch. The SCEP profile is assigned to a different group than the WiFi profile. Intune cannot resolve the certificate dependency.

Fix: Audit all three profiles (Trusted Root, SCEP, WiFi). Ensure they are all assigned to the exact same Azure AD group. If you are deploying to Users, all three profiles must target a Users group. If deploying to Devices, all three must target a Devices group.

NDES returns HTTP 403 errors

Root cause: The Intune Certificate Connector service account lacks Read or Enroll permissions on the CA certificate template, or firewall URL filtering is blocking SCEP query strings.

Fix: Verify the connector account has Read and Enroll permissions on the template in the CA console. Check firewall logs for blocked requests containing ?operation=GetCACaps or ?operation=PKIOperation. These query strings must pass through without modification.

Devices fail to renew certificates before expiry

Root cause: The SCEP renewal window is too short, or the NDES server is unreachable at the time of renewal.

Fix: Set the renewal threshold to 20% of certificate validity. Ensure the NDES URL is published via a highly available reverse proxy. Monitor NDES IIS logs for renewal request failures and alert on them proactively.

RADIUS rejects valid certificates

Root cause: The RADIUS server's trusted CA store does not include the issuing CA certificate, or the CRL is stale.

Fix: Import the full CA chain (Root CA + Issuing CA) into the RADIUS server's trusted store. Verify the CRL is being fetched successfully and that the CDP URL is reachable from the RADIUS server. Check the CRL's next-update timestamp - if it has passed, the CA needs to publish a new CRL.

For broader network performance considerations alongside security, see our bandwidth management guide .

ROI & business impact

The business case for SCEP-based certificate enrollment is straightforward. Password-based WiFi generates a predictable volume of helpdesk tickets: password expirations, lockouts, staff sharing credentials with guests, and onboarding friction for new starters. Certificate-based authentication is invisible to the end user. Devices connect automatically. There are no passwords to expire, share, or forget.

Organisations that migrate from password-based WiFi to EAP-TLS with SCEP typically report a 70-80% reduction in WiFi-related helpdesk tickets (Purple internal data, 2024, based on deployments across hospitality and retail estates). The helpdesk saving alone often justifies the implementation cost within the first year.

The compliance impact is equally concrete. EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer. For healthcare environments, it aligns with HIPAA technical safeguard requirements for wireless network access. For public-sector organisations, it supports NCSC Cyber Essentials Plus certification requirements for network access control.

For transport operators - rail franchises, airport operators, bus networks - certificate-based authentication on staff devices ensures that operational networks carrying safety-critical data are isolated from passenger WiFi and protected against credential-based attacks.

Purple's WiFi Analytics platform integrates with 802.1X-secured networks to deliver first-party data insights without compromising the security posture of the underlying infrastructure. The 29 billion data points collected across Purple's network demonstrate that security and analytics are complementary, not competing, objectives.

For feedback and experience management alongside your secure network deployment, see our venue feedback playbook .

Definizioni chiave

SCEP (Simple Certificate Enrollment Protocol)

An IETF-standardised protocol (RFC 8894) that automates X.509 certificate enrollment for managed devices. The device generates its own private key locally and sends only a Certificate Signing Request to the CA via a gateway. The private key never leaves the device.

IT teams encounter SCEP when configuring MDM platforms (Intune, Jamf) to deploy WiFi authentication certificates at scale. It is the recommended mechanism for 802.1X EAP-TLS deployments because the private key is hardware-protected on the endpoint.

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

The most secure 802.1X authentication method. Both the client device and the RADIUS server present X.509 certificates. Neither side can authenticate without a valid, non-revoked certificate from the trusted CA hierarchy.

EAP-TLS is the target authentication protocol that SCEP certificate deployment enables. It satisfies PCI DSS 4.0 Requirement 8.6 and is required for WPA3 Enterprise 192-bit (Suite B) deployments.

PKCS (Public Key Cryptography Standards)

A certificate delivery mechanism where the CA generates both the public and private key pair centrally and transmits them to the endpoint. The CA retains a copy of the private key, enabling key escrow.

IT teams choose between SCEP and PKCS when configuring certificate profiles in Intune. PKCS is appropriate for S/MIME email encryption where key escrow is required. It is not recommended for WiFi authentication because the private key is transmitted over the network.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as the SCEP gateway between an MDM platform and a Certificate Authority. It validates device enrollment requests and forwards CSRs to the CA.

NDES is a required infrastructure component for on-premises SCEP deployments with Microsoft Intune. It must be published externally via an application proxy to allow remote devices to enroll. Cloud SCEP gateways are an alternative that eliminates the on-premises NDES dependency.

CRL (Certificate Revocation List)

A list published by the CA containing the serial numbers of certificates that have been revoked before their expiry date. RADIUS servers check the CRL to ensure devices with revoked certificates cannot authenticate.

CRL checking is the operational control that enforces certificate revocation. IT teams must configure their RADIUS server to check the CRL on every authentication attempt and ensure the CRL Distribution Point (CDP) is highly available.

802.1X

An IEEE standard for port-based network access control. It defines the three-party authentication framework (supplicant, authenticator, authentication server) used in enterprise WiFi and wired networks.

802.1X is the framework within which EAP-TLS and SCEP operate. IT teams encounter it when configuring WPA2-Enterprise or WPA3-Enterprise SSIDs and when setting up RADIUS server policies.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised authentication, authorisation, and accounting (AAA) for network access. In 802.1X deployments, the RADIUS server validates client certificates and enforces VLAN assignment policies.

The RADIUS server is the authentication decision point in every 802.1X deployment. Common implementations include Microsoft NPS, FreeRADIUS, and Cisco ISE. It must be configured with the trusted CA chain and strict CRL or OCSP checking.

CSR (Certificate Signing Request)

A block of encoded text generated by a device that contains the device's public key and identity information. The device sends the CSR to the CA (via the SCEP gateway) to request a signed certificate. The corresponding private key is generated and retained on the device.

The CSR is the core artifact in the SCEP enrollment flow. IT teams configure the CSR format (subject name, key usage, EKU) in the SCEP certificate profile within their MDM platform.

PKI (Public Key Infrastructure)

The combination of hardware, software, policies, and procedures required to create, manage, distribute, and revoke digital certificates. A standard enterprise PKI consists of an offline root CA and an online issuing CA.

PKI is the prerequisite for any EAP-TLS deployment. IT teams must design and deploy a two-tier CA hierarchy before configuring SCEP. Cloud-hosted PKI services reduce the infrastructure burden for distributed estate deployments.

VLAN (Virtual Local Area Network)

A logical network segment that isolates traffic at Layer 2. In 802.1X deployments, RADIUS servers assign devices to VLANs dynamically based on certificate attributes, user identity, or policy.

VLAN assignment via RADIUS is the mechanism that enforces network segmentation in enterprise WiFi. IT teams use it to separate POS devices onto PCI-scoped VLANs, guest devices onto internet-only VLANs, and staff devices onto corporate VLANs - all from a single physical infrastructure.

Esempi pratici

A 200-room Premier Inn property needs to deploy secure WiFi for 150 iOS housekeeping devices. Staff are currently sharing a WPA2-Personal password with guests, creating a compliance and operational risk. The IT Director needs to eliminate the shared password without disrupting daily operations.

The IT Director implements a Jamf-driven SCEP deployment in three phases. Phase one: the Root CA certificate is pushed to all 150 iOS devices via a Jamf Trusted Certificate profile, targeting the 'Housekeeping Devices' smart group. Phase two: a SCEP certificate profile is deployed, directing devices to an Azure AD App Proxy-published NDES server. The subject name uses CN={{SERIALNUMBER}} to tie the certificate to the device hardware. Phase three: a WPA2-Enterprise WiFi profile is pushed, specifying EAP-TLS and linking to the SCEP certificate. Devices authenticate silently. The shared password SSID is decommissioned. The RADIUS server is configured with strict CRL checking and VLAN assignment: housekeeping devices land on VLAN 20 (operations), guest devices on VLAN 10 (internet-only).

Commento dell'esaminatore: The key design decisions here are device certificates (not user certificates) for shared hardware, and VLAN assignment via certificate attributes rather than SSID. This means a device that somehow connects to the guest SSID still lands on the correct VLAN. The CRL checking configuration is non-negotiable: when a housekeeper leaves, the device certificate is revoked at the CA, and the RADIUS server blocks access within the CRL refresh interval - typically 15 minutes with OCSP, or up to one hour with CRL.

A retail chain with 500 locations needs to secure corporate WiFi for Windows POS tablets running payment processing software. PCI DSS 4.0 compliance requires multi-factor authentication at the network layer. The current WPA2-Personal setup fails the PCI DSS Requirement 8.6 assessment.

The network architect deploys EAP-TLS via Microsoft Intune and SCEP across all 500 locations. The deployment uses device certificates with CN={{AAD_Device_ID}} as the subject name, tying each certificate to the Intune device record. The three-profile sequence (Trusted Root, SCEP, WiFi) is deployed to the 'POS Devices' Azure AD group - the same group across all three profiles. The RADIUS server assigns POS devices to a dedicated PCI-scoped VLAN (VLAN 100) based on the certificate's issuing template. The CRL is published to a highly available CDN-hosted endpoint with a four-hour validity window. OCSP is enabled for real-time revocation checking. The deployment is validated against PCI DSS 4.0 Requirement 8.6 by the QSA.

Commento dell'esaminatore: The PCI DSS alignment is achieved by the combination of EAP-TLS (something you have - the certificate) and the device identity bound to the Intune record (something you are - the enrolled managed device). The VLAN assignment via certificate template ensures POS devices are always on the PCI-scoped network segment, regardless of physical location across the 500-site estate. The CDN-hosted CRL endpoint is a critical reliability decision: if the CRL is unreachable, authentication fails, causing a site-wide outage. High availability for the CRL is as important as high availability for the RADIUS server itself.

Domande di esercitazione

Q1. You have deployed Trusted Root and SCEP certificate profiles to the 'All Staff' user group in Intune. You then deploy the WiFi profile to the 'Corporate Devices' device group. Devices receive the certificates but the WiFi profile shows 'Error' in the Intune console. What is the most likely cause, and how do you fix it?

Suggerimento: Consider how Intune resolves dependencies between profiles and what happens when profiles target different group types.

Visualizza risposta modello

The root cause is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which depends on the Trusted Root profile. Intune cannot resolve these dependencies when the profiles target different group types (Users vs Devices). Fix: redeploy all three profiles to the same group. If the WiFi profile targets 'Corporate Devices' (a device group), the SCEP and Trusted Root profiles must also target 'Corporate Devices'. Alternatively, move all three to a user group if user-based authentication is required.

Q2. A hotel housekeeper's iPad is reported stolen. You immediately disable the housekeeper's Active Directory account. The next morning, the stolen iPad is still connecting to the hotel's WPA2-Enterprise network. Why, and what two actions do you take to prevent this?

Suggerimento: Think about what the RADIUS server actually validates during EAP-TLS authentication, and what controls govern certificate validity.

Visualizza risposta modello

Disabling the AD account does not revoke the client certificate stored on the iPad. The RADIUS server validates the certificate, not the AD account status, during EAP-TLS authentication. The two required actions are: (1) revoke the device certificate at the CA - this adds the certificate serial number to the CRL; (2) ensure the RADIUS server is configured with strict CRL checking so it fetches the updated CRL and rejects the revoked certificate on the next authentication attempt. For faster revocation, configure OCSP on the RADIUS server for real-time certificate status checks.

Q3. A retail chain is deploying 802.1X WiFi to 500 POS locations. The security architect proposes using PKCS certificate delivery instead of SCEP to avoid deploying an NDES server. The QSA reviewing the PCI DSS 4.0 assessment raises a concern. What is the concern, and what is the correct recommendation?

Suggerimento: Consider what PCI DSS says about private key handling and what PKCS does with the private key during delivery.

Visualizza risposta modello

The QSA's concern is that PKCS transmits the private key over the network from the CA to the device. PCI DSS 4.0 Requirement 3.5 requires that private keys used for authentication are protected against disclosure. Transmitting the private key over the network - even encrypted - introduces a risk that SCEP eliminates entirely. The correct recommendation is to use SCEP, where the private key is generated on the POS device and never leaves it. To avoid on-premises NDES infrastructure, the architect should evaluate a cloud SCEP gateway service that integrates directly with Intune and the CA via API.

Q4. You are designing a WiFi network for a large conference centre that hosts 50+ events per year. Staff devices need to be on a secure 802.1X network. You want to ensure that if a contractor's device is compromised, it can be isolated from the network within 15 minutes. What certificate revocation mechanism do you configure, and why?

Suggerimento: Compare CRL and OCSP in terms of revocation latency and what determines how quickly a RADIUS server acts on a revocation.

Visualizza risposta modello

Configure OCSP (Online Certificate Status Protocol) on the RADIUS server. CRL-based revocation has a latency determined by the CRL's validity period - typically one to 24 hours - meaning a revoked certificate may still authenticate until the RADIUS server fetches the next CRL. OCSP provides real-time per-certificate status responses: when a certificate is revoked at the CA, the OCSP responder immediately returns a 'revoked' status on the next query. With OCSP configured on the RADIUS server, a revoked contractor certificate is blocked on the next authentication attempt, typically within seconds. Ensure the OCSP responder is highly available - if it is unreachable and the RADIUS server is configured to fail closed, all authentications will fail.

Continua a leggere questa serie

La guida aziendale a SCEP: implementare il Simple Certificate Enrollment Protocol per la sicurezza automatizzata del WiFi nei campus

Questa guida di riferimento tecnico fornisce un modello architetturale definitivo e una strategia di implementazione passo-passo per l'implementazione dei certificati WiFi aziendali tramite SCEP. Copre le differenze cruciali tra SCEP e PKCS, l'esatta sequenza di implementazione necessaria per il successo e le strategie reali di mitigazione del rischio per i leader IT.

Perché il mio WiFi per gli ospiti non si connette? Risoluzione dei problemi del Captive Portal

Questa guida di riferimento tecnico autorevole spiega i meccanismi alla base del rilevamento del Captive Portal e descrive in dettaglio le sei principali modalità di errore che impediscono la connessione del WiFi per gli ospiti. Fornisce ai responsabili IT e agli architetti di rete un framework pratico di risoluzione dei problemi per risolvere i problemi di reindirizzamento HTTP, i conflitti DNS e le sfide di randomizzazione MAC.

GDPR e Guest WiFi: Guida alla conformità per i responsabili marketing e IT delle strutture

Questa guida fornisce ai manager IT e ai gestori delle strutture un framework pratico per garantire che i servizi Guest WiFi siano pienamente conformi al GDPR. Copre l'architettura tecnica, i meccanismi di consenso, la conservazione dei dati e come trasformare la conformità in un asset sicuro di dati di prima parte.