Comment implémenter SCEP pour l'enrôlement automatisé de certificats WiFi

Ce guide explique comment implémenter SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi dans les établissements d'entreprise. Il couvre l'ensemble du schéma architectural - de la conception de la PKI et de l'intégration MDM à la séquence de déploiement obligatoire en trois étapes - et montre aux responsables informatiques et aux architectes réseau comment éliminer les identifiants partagés, automatiser la gestion du cycle de vie des certificats et répondre aux exigences PCI DSS et GDPR à grande échelle.

📖 10 min de lecture📝 2,383 mots🔧 2 exemples concrets❓ 4 questions d'entraînement📚 10 définitions clés

Écouter ce guide

Voir la transcription du 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.

Points clés à retenir

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

Résumé exécutif

Pour les exploitants de sites proposant du Guest WiFi dans des hôtels, des commerces, des stades et des centres de conférence, s'appuyer sur des clés pré-partagées ou des Captive Portals basiques pour l'accès au réseau du personnel constitue une faille de sécurité. L'architecture réseau moderne exige une authentification 802.1X via EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantissant que chaque appareil est vérifié par cryptographie avant d'accéder au réseau. Le défi réside dans la distribution : comment déployer des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android sans surcharger votre support technique ?

La réponse est SCEP - le Simple Certificate Enrollment Protocol. Formalisé par l'IETF sous la RFC 8894 en 2020, SCEP automatise l'enrôlement des certificats sur les flottes d'appareils gérés. Lorsqu'il est intégré à une plateforme MDM telle que Microsoft Intune ou Jamf, SCEP offre un provisionnement de certificats sans contact (zero-touch) : les appareils demandent, reçoivent et renouvellent leurs propres certificats sans aucune intervention informatique. La clé privée est générée localement sur l'appareil et n'est jamais transmise sur le réseau - un avantage de sécurité fondamental par rapport à la distribution basée sur PKCS.

Ce guide détaille l'ensemble du flux d'implémentation de SCEP : l'architecture PKI, la configuration de la passerelle NDES, la séquence de déploiement MDM obligatoire en trois étapes et les contrôles opérationnels - en particulier la vérification CRL et le ciblage de groupes - qui déterminent si un déploiement réussit ou stagne. Deux scénarios réels illustrent cette approche dans les secteurs de l'hôtellerie et du commerce de détail. Purple opère dans plus de 80 000 sites actifs et auprès de 350 millions d'utilisateurs uniques ; les modèles décrits ici reflètent ce qui fonctionne à cette échelle.

Analyse technique approfondie

Ce que fait réellement SCEP

SCEP se positionne entre votre plateforme MDM et votre autorité de certification (CA). Il fournit un mécanisme standardisé basé sur HTTP permettant aux appareils de demander, recevoir et renouveler des certificats X.509 sans nécessiter d'identifiants liés au domaine ni d'intervention manuelle de l'administrateur. Le protocole a été initialement développé au début des années 2000 et a été largement adopté dans les environnements MDM d'entreprise avant que l'IETF ne le publie officiellement sous la RFC 8894.

Le flux d'enrôlement en six étapes fonctionne comme suit. Premièrement, l'appareil géré se connecte à l'URL de la passerelle SCEP préconfigurée dans son profil MDM. Deuxièmement, l'appareil génère localement une paire de clés privée/publique et crée une demande de signature de certificat (CSR). Troisièmement, la passerelle SCEP valide l'autorisation de l'appareil à l'aide d'un mot de passe de défi (challenge password) ou d'un OTP intégré dans la politique MDM. Quatrièmement, la passerelle transmet la CSR validée à la CA. Cinquièmement, la CA signe le certificat et le renvoie à la passerelle. Sixièmement, la passerelle fournit le certificat signé à l'appareil. Les futurs renouvellements suivent le même parcours automatisé - l'appareil se réenrôle avant l'expiration sans aucune action de l'utilisateur ou de l'administrateur.

SCEP vs PKCS : la décision qui compte

Microsoft Intune et la plupart des plateformes MDM prennent en charge deux mécanismes de distribution de certificats : SCEP et PKCS. La distinction est d'ordre architectural, et non cosmétique.

Avec SCEP, la clé privée est générée sur l'appareil et y reste. La CA ne la voit jamais. Le TPM de l'appareil (sur Windows) ou la Secure Enclave (sur iOS/macOS) protège la clé au niveau matériel. Avec PKCS, la CA génère la paire de clés de manière centralisée et la transmet à l'appareil via le réseau. La CA en conserve une copie, ce qui permet le séquestre de clés (key escrow) - utile pour le chiffrement des e-mails S/MIME mais introduisant un risque inutile pour l'authentification réseau.

Pour l'authentification WiFi 802.1X, utilisez SCEP. La clé privée ne quitte jamais l'appareil. C'est la règle.

Critère	SCEP	PKCS
Clé privée générée sur	Appareil	CA (centralisée)
Clé privée transmise sur le réseau	Jamais	Oui
Prise en charge de TPM / Secure Enclave	Oui	Non
Recommandé pour l'authentification WiFi	Oui	Non
Recommandé pour le chiffrement des e-mails (S/MIME)	Non	Oui
Séquestre de clés possible	Non	Oui

802.1X et EAP-TLS : le cadre d'authentification

La norme IEEE 802.1X est le standard de contrôle d'accès réseau basé sur les ports qui sous-tend la sécurité WiFi d'entreprise. Elle définit trois rôles : le suppliant (l'appareil client), l'authentificateur (le point d'accès - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet) et le serveur d'authentification (un serveur RADIUS tel que Microsoft NPS, FreeRADIUS ou Cisco ISE).

EAP-TLS est la méthode EAP la plus sécurisée pour le 802.1X. Les deux parties présentent des certificats : le serveur RADIUS présente son certificat au client, et le client présente son certificat provisionné par SCEP au serveur RADIUS. Aucune des deux parties ne peut usurper l'identité de l'autre sans un certificat valide et non révoqué provenant de la hiérarchie de CA de confiance. Ce modèle d'authentification mutuelle élimine le vol d'identifiants, les attaques de type "Evil Twin" (jumeau malveillant) et les risques de points d'accès non autorisés en une seule décision architecturale.

EAP-TLS répond à l'exigence 8.6 de la norme PCI DSS 4.0 concernant l'authentification multifacteur au niveau de la couche réseau. Il est requis pour les déploiements WPA3 Enterprise 192 bits (Suite B). Pour tout réseau sans fil entrant dans le champ d'application du traitement des données de cartes de paiement - commerce de détail point de vente, réception d'hôtel, billetterie de stade - EAP-TLS est le choix idéal.

Pour un aperçu plus approfondi de l'architecture WiFi sécurisé et de la manière dont l'authentification par certificat s'intègre dans une posture de sécurité plus large, consultez notre guide essentiel.

Guide d'implémentation

La séquence de déploiement est non négociable. Intune et Jamf résolvent les dépendances de profil dans l'ordre : le profil WiFi dépend du profil SCEP, qui dépend du profil Trusted Root. Déployez-les dans le désordre et le profil WiFi ne s'appliquera pas.

Étape 1 : Concevez votre PKI

Avant de toucher à une console MDM, concevez votre hiérarchie de certificats. Une PKI à deux niveaux est la norme : une CA racine hors ligne (offline root CA) et une CA d'émission en ligne (online issuing CA). La clé privée de la CA racine est l'ancre de confiance maîtresse pour l'ensemble de votre infrastructure de certificats - conservez-la isolée physiquement (air-gapped). La CA d'émission gère la délivrance quotidienne des certificats et publie la liste de révocation de certificats (CRL) et le répondeur OCSP.

Pour la plupart des déploiements de sites d'entreprise, les services de certificats Active Directory de Microsoft (AD CS) exécutés sur Windows Server fournissent la CA d'émission. Les services PKI hébergés dans le cloud de fournisseurs tels que SCEPman ou SecureW2 éliminent complètement le besoin d'infrastructure sur site et méritent d'être évalués pour les déploiements sur des parcs distribués au sein de groupes hôteliers, de chaînes de vente au détail ou d'organisations du secteur public multisites.

Étape 2 : Déployez le serveur NDES (ou la passerelle SCEP cloud)

NDES (Network Device Enrollment Service) est le rôle Windows Server de Microsoft qui fait office de passerelle SCEP entre votre MDM et votre CA. Exigences clés de configuration :

Publiez l'URL NDES en externe via le proxy d'application Azure AD (ou un proxy inverse équivalent). Cela permet aux appareils distants de s'enregistrer avant d'arriver sur site, sans ouvrir de ports de pare-feu entrants.
Le compte de service NDES requiert des autorisations de lecture et d'inscription (Read and Enroll) sur le modèle de certificat de la CA.
Configurez le modèle de certificat avec l'utilisation de la clé (Key Usage) définie sur Signature numérique (Digital Signature) et Chiffrement de la clé (Key Encipherment), et l'utilisation étendue de la clé (Extended Key Usage) définie sur Authentification client (Client Authentication) (OID : 1.3.6.1.5.5.7.3.2).
Définissez une période de validité de certificat appropriée. Un an est la norme pour les certificats clients ; deux ans sont acceptables pour les certificats d'appareils dans des parcs stables.

Si vous préférez éviter l'infrastructure NDES sur site, les passerelles SCEP cloud s'intègrent directement à Intune et à votre CA via API, éliminant complètement la dépendance à IIS.

Étape 3 : Déployez le profil de certificat Trusted Root

Dans votre plateforme MDM, créez un profil de certificat approuvé (Trusted Certificate) et téléchargez votre certificat de CA racine (et tous les certificats de CA intermédiaires) sous forme de fichiers .cer. Déployez ce profil sur vos groupes d'appareils cibles avant tout autre profil de certificat ou WiFi. Sans cette étape, les appareils ne peuvent pas valider le certificat du serveur RADIUS lors de la négociation (handshake) EAP-TLS, et ils ne peuvent pas faire confiance à la CA d'émission lors de la demande de leur propre certificat SCEP.

Règle générale : Ciblez toujours le même groupe Azure AD (soit Utilisateurs, soit Appareils) pour les trois profils associés. Une incompatibilité à ce niveau est la cause la plus fréquente d'échec du déploiement des profils WiFi.

Étape 4 : Configurez le profil de certificat SCEP

Créez un profil de configuration de certificat SCEP dans votre MDM :

Format du nom de l'objet (Subject name format) : Pour l'authentification basée sur l'utilisateur, utilisez CN={{UserPrincipalName}}. Pour l'authentification de l'appareil (recommandée pour les appareils partagés et l'IoT), utilisez CN={{AAD_Device_ID}}.
Utilisation de la clé (Key usage) : Signature numérique (Digital Signature), Chiffrement de la clé (Key Encipherment).
Utilisation étendue de la clé (Extended key usage) : Authentification client (Client Authentication) (OID : 1.3.6.1.5.5.7.3.2).
URL du serveur SCEP : L'URL NDES publiée en externe.
Certificat racine (Root certificate) : Liez au profil Trusted Root de l'étape 3.
Période de validité du certificat : Doit correspondre au modèle configuré sur la CA.

Étape 5 : Déployez le profil WiFi 802.1X

Créez un profil de configuration WiFi :

SSID : Saisissez le nom du réseau exactement tel qu'il est diffusé par vos points d'accès.
Type de sécurité : WPA2-Enterprise ou WPA3-Enterprise.
Type d'EAP : EAP-TLS.
Certificat d'authentification client : Sélectionnez le profil de certificat SCEP de l'étape 4.
Validation du serveur : Spécifiez le certificat Trusted Root de l'étape 3 et saisissez le nom attendu du serveur RADIUS. Cela empêche les appareils de se connecter à des points d'accès malveillants présentant des certificats frauduleux.

Bonnes pratiques

Imposez une vérification stricte de la CRL sur votre serveur RADIUS

La révocation de certificat est le contrôle opérationnel qui comble le fossé entre la désactivation d'un compte et le blocage de l'accès au réseau. Lorsqu'un appareil est perdu, volé, ou qu'un employé s'en va, désactivez le compte AD et révoquez le certificat au niveau de la CA. Votre serveur RADIUS doit être configuré pour vérifier la CRL à chaque tentative d'authentification. Si la CRL est indisponible - parce que le CDP (point de distribution de CRL) est inaccessible - la plupart des serveurs RADIUS échouent par défaut en mode ouvert (fail open), ce qui constitue un risque de sécurité. Assurez-vous que vos CDP sont hautement disponibles et que votre serveur RADIUS est configuré pour échouer en mode fermé (fail closed) si la CRL ne peut pas être récupérée.

Pour une révocation en temps réel, configurez OCSP (Online Certificate Status Protocol) en plus de la CRL. L'OCSP fournit des réponses sur le statut de chaque certificat sans nécessiter que le serveur RADIUS télécharge et analyse l'intégralité de la CRL.

Utilisez des certificats d'appareil pour les appareils partagés et IoT

Pour les appareils partagés - tablettes du personnel d'étage d'hôtel, terminaux de point de vente (POS) de vente au détail, lecteurs de contrôle d'accès de stade - utilisez des certificats d'appareil plutôt que des certificats d'utilisateur. Les certificats d'appareil sont liés à l'identité de la machine, et non à un compte utilisateur. Cela signifie que l'appareil s'authentifie quel que soit l'utilisateur connecté, et la révocation est liée à l'enregistrement de l'appareil plutôt qu'au départ d'un employé.

Pour les déploiements dans le secteur du commerce de détail , les certificats d'appareil sur le matériel POS répondent également à l'exigence PCI DSS concernant l'identité de l'appareil au niveau de la couche réseau, sans introduire la complexité des identifiants utilisateur au point de vente.

Automatisez le renouvellement des certificats

SCEP prend en charge le renouvellement automatique : le MDM demande à l'appareil de se réinscrire avant que le le certificat n'expire. Configurez votre profil SCEP pour déclencher le renouvellement à 20 % de la période de validité restante du certificat. Pour un certificat d'un an, le renouvellement commence environ 73 jours avant l'expiration. Cette fenêtre offre suffisamment de temps pour résoudre tout échec de renouvellement avant que le certificat n'expire et que les appareils ne perdent l'accès au réseau.

Les certificats expirés causant des échecs d'authentification de masse sont l'incident opérationnel le plus courant dans les déploiements 802.1X. Le renouvellement automatisé via SCEP élimine entièrement ce risque.

Segmenter les réseaux par attribut de certificat

Les serveurs RADIUS peuvent lire les attributs des certificats - Subject, SAN ou OID personnalisés - et les utiliser pour attribuer dynamiquement des appareils aux VLAN. Une tablette du personnel d'entretien avec un certificat émis à partir du modèle HousekeepingDevices se connecte au VLAN d'entretien. Un terminal de point de vente (POS) avec un certificat du modèle RetailPOS se connecte au VLAN concerné par la norme PCI. Il s'agit d'une segmentation réseau renforcée par cryptographie, bien plus fiable que les approches basées sur l'SSID ou sur l'adresse MAC.

Pour les opérateurs du secteur de l' hôtellerie qui exploitent un réseau Guest WiFi aux côtés du WiFi du personnel sur la même infrastructure physique, l'attribution de VLAN via les attributs de certificat garantit que les clients et le personnel se trouvent toujours sur des segments de réseau distincts, quel que soit l'SSID auquel un appareil se connecte.

Dépannage et atténuation des risques

Le profil WiFi affiche 'Erreur' ou 'Non applicable' dans Intune

Cause racine : Incohérence de ciblage de groupe. Le profil SCEP est attribué à un groupe différent de celui du profil WiFi. Intune ne peut pas résoudre la dépendance du certificat.

Solution : Auditez les trois profils (Trusted Root, SCEP, WiFi). Assurez-vous qu'ils sont tous attribués exactement au même groupe Azure AD. Si vous effectuez un déploiement vers des utilisateurs (Users), les trois profils doivent cibler un groupe d'utilisateurs. Si vous déployez vers des appareils (Devices), les trois doivent cibler un groupe d'appareils.

NDES renvoie des erreurs HTTP 403

Cause racine : Le compte de service Intune Certificate Connector ne dispose pas des autorisations de lecture (Read) ou d'inscription (Enroll) sur le modèle de certificat de l'AC, ou le filtrage d'URL du pare-feu bloque les chaînes de requête SCEP.

Solution : Vérifiez que le compte du connecteur dispose des autorisations de lecture (Read) et d'inscription (Enroll) sur le modèle dans la console de l'AC. Vérifiez les journaux du pare-feu pour détecter les requêtes bloquées contenant ?operation=GetCACaps ou ?operation=PKIOperation. Ces chaînes de requête doivent passer sans modification.

Les appareils ne parviennent pas à renouveler les certificats avant l'expiration

Cause racine : La fenêtre de renouvellement SCEP est trop courte, ou le serveur NDES est injoignable au moment du renouvellement.

Solution : Définissez le seuil de renouvellement à 20 % de la validité du certificat. Assurez-vous que l'URL NDES est publiée via un proxy inverse hautement disponible. Surveillez les journaux IIS de NDES pour détecter les échecs de demande de renouvellement et générez des alertes de manière proactive.

RADIUS rejette les certificats valides

Cause racine : Le magasin d'AC de confiance du serveur RADIUS n'inclut pas le certificat de l'AC émettrice, ou la CRL est obsolète.

Solution : Importez la chaîne d'AC complète (AC racine + AC émettrice) dans le magasin de confiance du serveur RADIUS. Vérifiez que la CRL est récupérée avec succès et que l'URL CDP est accessible depuis le serveur RADIUS. Vérifiez l'horodatage de la prochaine mise à jour de la CRL : s'il est dépassé, l'AC doit publier une nouvelle CRL.

Pour des considérations plus larges sur les performances réseau en plus de la sécurité, consultez notre guide de gestion de la bande passante .

ROI et impact commercial

L'argument commercial en faveur de l'enregistrement de certificats basé sur SCEP est simple. Le WiFi basé sur mot de passe génère un volume prévisible de tickets d'assistance : expirations de mots de passe, verrouillages de comptes, partage d'identifiants par le personnel avec les clients et frictions lors de l'intégration des nouveaux arrivants. L'authentification par certificat est invisible pour l'utilisateur final. Les appareils se connectent automatiquement. Il n'y a aucun mot de passe à expirer, à partager ou à oublier.

Les organisations qui migrent d'un WiFi basé sur mot de passe vers l'EAP-TLS avec SCEP signalent généralement une réduction de 70 à 80 % des tickets d'assistance liés au WiFi (données internes de Purple, 2024, basées sur des déploiements dans des parcs de l'hôtellerie et du commerce de détail). Les économies réalisées sur le support technique justifient souvent à elles seules le coût de mise en œuvre dès la première année.

L'impact sur la conformité est tout aussi concret. L'EAP-TLS répond à l'exigence 8.6 de la norme PCI DSS 4.0 relative à l'authentification multifacteur au niveau de la couche réseau. Pour les environnements de la santé , il s'aligne sur les exigences de protection technique de la loi HIPAA pour l'accès aux réseaux sans fil. Pour les organisations du secteur public, il prend en charge les exigences de certification Cyber Essentials Plus du NCSC pour le contrôle d'accès au réseau.

Pour les opérateurs de transport - franchises ferroviaires, exploitants d'aéroports, réseaux de bus - l'authentification par certificat sur les appareils du personnel garantit que les réseaux opérationnels transportant des données critiques pour la sécurité sont isolés du WiFi des passagers et protégés contre les attaques basées sur les identifiants.

La plateforme WiFi Analytics de Purple s'intègre aux réseaux sécurisés par la norme 802.1X pour fournir des informations sur les données de première partie sans compromettre la posture de sécurité de l'infrastructure sous-jacente. Les 29 milliards de points de données collectés sur le réseau de Purple démontrent que la sécurité et les analyses sont des objectifs complémentaires et non concurrents.

Pour la gestion des commentaires et de l'expérience parallèlement au déploiement de votre réseau sécurisé, consultez notre guide pratique sur la collecte de commentaires dans les établissements .

Définitions clés

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.

Exemples concrets

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

Commentaire de l'examinateur : 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.

Commentaire de l'examinateur : 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.

Questions d'entraînement

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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?

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

Voir la réponse type

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.

Continuer la lecture de cette série

Le guide de l'entreprise pour SCEP : Déployer Simple Certificate Enrollment Protocol pour une sécurité WiFi automatisée des campus

Ce guide de référence technique fournit un modèle d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi d'entreprise à l'aide de SCEP. Il couvre les différences critiques entre SCEP et PKCS, la séquence de déploiement exacte requise pour réussir, et des stratégies concrètes de réduction des risques pour les responsables informatiques.

Pourquoi mon WiFi invité ne se connecte-t-il pas ? Dépannage des problèmes de Captive Portal

Ce guide de référence technique faisant autorité explique les mécanismes sous-jacents de la détection de Captive Portal et détaille les six principaux modes de défaillance qui empêchent le WiFi invité de se connecter. Il fournit aux responsables informatiques et aux architectes réseau un cadre de dépannage pratique pour résoudre les problèmes de redirection HTTP, les conflits DNS et les défis liés à la randomisation des adresses MAC.

GDPR et Guest WiFi : Guide de conformité pour les marketeurs de lieux et l'IT

Ce guide fournit aux responsables IT et aux exploitants de sites un cadre pratique pour garantir que les services Guest WiFi sont pleinement conformes au GDPR. Il couvre l'architecture technique, les mécanismes de consentement, la conservation des données et la manière de transformer la conformité en un actif de données de première partie sécurisé.