How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Ce guide explique comment configurer SCEP (Simple Certificate Enrollment Protocol) pour l'enrôlement automatisé de certificats WiFi d'entreprise, couvrant l'ensemble de l'architecture, de la PKI et de NDES jusqu'au déploiement de profils MDM et à la validation RADIUS. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de magasins, de stades, de centres de conférences et d'organisations du secteur public qui souhaitent abandonner les clés pré-partagées pour implémenter une authentification 802.1X EAP-TLS évolutive et basée sur l'identité. La plateforme cloud overlay de Purple, indépendante du matériel, s'intègre directement à cette architecture, fournissant la couche WiFi pour les invités et le BYOD qui coexiste avec le réseau de votre personnel authentifié par certificat.

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

Écouter ce guide

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

Points clés à retenir

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

Synthèse opérationnelle

Pour les grands sites d'entreprise — qu'il s'agisse d'un hôtel de 200 chambres, d'une chaîne de magasins de 50 points de vente ou d'un grand centre de conférences —, s'appuyer sur des clés pré-partagées pour le WiFi du personnel constitue une faille de sécurité et un goulot d'étranglement opérationnel. Un seul mot de passe divulgué expose l'ensemble du réseau. L'authentification par certificat via IEEE 802.1X et EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) élimine totalement ce risque. Chaque appareil prouve son identité de manière cryptographique avant que le point d'accès ne lui accorde l'accès au réseau.

Le défi réside dans la distribution. Déployer manuellement des certificats clients uniques sur des milliers d'appareils Windows, iOS et Android n'est pas viable. Le protocole SCEP (Simple Certificate Enrollment Protocol), formalisé sous la norme RFC 8894 par l'IETF en 2020, résout ce problème. Il automatise le processus de demande, d'émission et d'installation de certificats numériques sur les appareils gérés via votre plateforme MDM — sans aucune interaction de l'utilisateur.

Ce guide couvre l'ensemble de l'architecture : le fonctionnement de SCEP, son intégration avec Microsoft Intune, Jamf et d'autres plateformes MDM, la séquence de déploiement exacte que la plupart des équipes ratent, et les pièges opérationnels qui provoquent des pannes. Nous abordons également deux scénarios de déploiement réels dans l'hôtellerie et le commerce de détail, et expliquons comment la plateforme Guest WiFi de Purple s'intègre aux côtés de votre réseau de personnel authentifié par certificat.

Écoutez le podcast d'accompagnement :

Analyse technique approfondie : SCEP, PKI et 802.1X

Ce que fait réellement SCEP

SCEP ne remplace pas votre infrastructure à clés publiques (PKI). Il s'agit de la couche d'enrôlement automatisée qui se superpose à celle-ci. Votre PKI — généralement une hiérarchie à deux niveaux avec une CA racine hors ligne et une CA émettrice en ligne — reste l'ancre de confiance. SCEP automatise l'étape au cours de laquelle un appareil demande un certificat à cette CA, éliminant ainsi le besoin de générer manuellement des CSR et d'installer des certificats.

Dans le contexte de l'authentification WiFi, le protocole cible est EAP-TLS. Il s'agit de la méthode d'authentification 802.1X qui exige que l'appareil client et le serveur RADIUS présentent tous deux des certificats X.509 valides. Aucune des deux parties ne fait confiance à l'autre sans preuve cryptographique. Ce modèle d'authentification mutuelle élimine le vol d'identifiants et protège contre les attaques de type « evil twin » (jumeau malveillant), où un attaquant déploie un point d'accès pirate pour intercepter les noms d'utilisateur et les mots de passe.

Pour une analyse détaillée de la liaison (handshake) EAP-TLS, consultez notre guide sur l' Authentification par certificat WiFi : Accès réseau sécurisé .

Le flux d'enrôlement SCEP, étape par étape

La chaîne d'enrôlement complète fonctionne comme suit. Votre plateforme MDM — Microsoft Intune, Jamf ou un autre MDM — pousse une charge utile (payload) SCEP vers un appareil géré. Cette charge utile contient deux éléments : l'URL SCEP pointant vers votre serveur NDES (Network Device Enrollment Service) ou votre passerelle SCEP cloud, et un mot de passe de défi (challenge password) ou secret partagé.

L'appareil génère localement sa propre paire de clés publique et privée. C'est la propriété de sécurité essentielle de SCEP : la clé privée est générée sur l'appareil, stockée dans l'enclave sécurisée ou la puce TPM, et n'est jamais transmise sur le réseau. L'appareil crée ensuite une demande de signature de certificat (CSR) et l'envoie à la passerelle SCEP. La passerelle valide le mot de passe de défi, transmet la CSR à votre autorité de certification (CA), et la CA la signe puis renvoie le certificat public à l'appareil.

À partir de ce moment, lorsque l'appareil se connecte à votre SSID WiFi, il présente ce certificat au serveur RADIUS. Le serveur RADIUS valide le certificat par rapport à la chaîne de confiance de votre CA, vérifie la liste de révocation de certificats (CRL) pour confirmer que le certificat n'a pas été révoqué et, si tout est correct, envoie un message Access-Accept au point d'accès. L'appareil est connecté au réseau. L'ensemble du processus est invisible pour l'utilisateur.

SCEP vs PKCS : lequel utiliser pour le WiFi

Les plateformes MDM comme Intune prennent en charge deux mécanismes de distribution de certificats : SCEP et PKCS (Public Key Cryptography Standards). La différence architecturale est significative.

Avec SCEP, la clé privée est générée sur l'appareil et ne le quitte jamais. Avec PKCS, l'autorité de certification génère à la fois la clé publique et la clé privée de manière centralisée, et le connecteur de certificat pousse la paire de clés vers l'appareil via le réseau. Cela signifie que la clé privée est transmise, ce qui introduit une surface d'attaque théorique.

Le PKCS est approprié pour les cas d'usage où le séquestre de clés est requis, comme le chiffrement des e-mails S/MIME. Pour l'authentification WiFi, SCEP est le choix correct. La clé privée reste sur l'appareil.

Propriété	SCEP	PKCS
Génération de la clé privée	Sur l'appareil (TPM/Enclave sécurisée)	Centralisée (CA)
Transmission de la clé privée	Jamais	Via le réseau
Serveur NDES requis	Oui (ou passerelle cloud)	Non
Recommandé pour le WiFi	Oui	Non
Recommandé pour S/MIME	Non	Oui

Compatibilité matérielle

SCEP et EAP-TLS sont des normes indépendantes des fournisseurs. Elles fonctionnent sur les points d'accès Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. C'est dans votre configuration RADIUS — qu'il s'agisse de Windows NPS, FreeRADIUS ou d'un service RADIUS cloud — que vous définissez la politique de validation des certificats et l'attribution dynamique des VLAN.

L'attribution dynamique de VLAN est la manière dont vou segmentez le réseau par identité d'appareil. Un appareil du personnel obtient le VLAN 10 avec accès aux systèmes internes. Un appareil de prestataire obtient le VLAN 20 avec un accès internet uniquement. Un terminal de point de vente obtient le VLAN 30 avec un accès uniquement aux systèmes de traitement des paiements. Tout cela est géré par les attributs de certificat et la politique RADIUS, sans aucune intervention manuelle par appareil.

Pour en savoir plus sur la façon dont WiFi Analytics s'intègre à la segmentation réseau basée sur l'identité, consultez notre présentation de la plateforme d'analyse.

Guide d'implémentation : la séquence de déploiement

La configuration réussie de SCEP pour le WiFi d'entreprise nécessite le respect strict d'une séquence de déploiement spécifique. Les plateformes MDM imposent des dépendances de profil : un profil WiFi qui fait référence à un certificat SCEP ne peut pas s'appliquer tant que ce certificat n'existe pas sur l'appareil. Le non-respect de cette séquence est la cause la plus fréquente d'échecs de déploiement.

La séquence est : Racine de confiance en premier, profil SCEP en deuxième, profil WiFi en troisième. Cet ordre est non négociable.

Step 1: deploy the Trusted Root Certificate profile

Avant qu'un appareil ne puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification (CA) émettrice. Exportez votre certificat CA racine (Root CA) - et tous les certificats CA intermédiaires - sous forme de fichiers .cer. Dans votre centre d'administration MDM, créez un profil de certificat de confiance (Trusted Certificate), téléchargez le fichier .cer et déployez-le sur votre groupe d'appareils cible.

Si vous disposez d'une hiérarchie PKI à deux niveaux (recommandé), vous devez déployer à la fois le certificat de la CA racine et celui de la CA émettrice en tant que profils de certificats de confiance distincts, ou sous forme de chaîne dans un seul profil, selon votre plateforme MDM.

Step 2: configure the SCEP Certificate profile

Une fois la confiance établie, configurez le profil SCEP pour indiquer aux appareils comment obtenir leur certificat client.

Créez un nouveau profil de configuration et sélectionnez le type de profil de certificat SCEP. Configurez le format du nom de l'objet (Subject name). Pour l'authentification basée sur l'utilisateur, CN={{UserPrincipalName}} est la norme. Pour l'authentification des appareils (appareils partagés, IoT, terminaux de point de vente), utilisez CN={{AAD_Device_ID}}. Définissez l'utilisation de la clé (Key usage) sur Signature numérique (Digital signature) et Chiffrement de la clé (Key encipherment). Définissez l'utilisation étendue de la clé (Extended Key Usage) sur Authentification client (Client Authentication) (OID : 1.3.6.1.5.5.7.3.2). Associez ce profil au profil de certificat de racine de confiance créé à l'étape 1. Saisissez l'URL externe de votre serveur NDES.

Pour Microsoft Intune spécifiquement, the NDES server must be published via Azure AD Application Proxy to allow remote devices to enroll before arriving on-site. Do not expose NDES directly to the internet.

Step 3: deploy the 802.1X WiFi profile

La dernière étape consiste à pousser la configuration WiFi qui lie les certificats au SSID du réseau. Créez un profil de configuration Wi-Fi. Saisissez le nom du réseau (SSID) exactement tel qu'il est diffusé par vos points d'accès. Sélectionnez WPA2-Enterprise ou WPA3-Enterprise comme type de sécurité. Définissez le type d'EAP sur EAP-TLS. Dans les paramètres d'authentification, sélectionnez le profil de certificat SCEP créé à l'étape 2 comme certificat d'authentification client. Spécifiez le certificat de racine de confiance pour la validation du serveur - cela garantit que l'appareil se connecte uniquement à votre serveur RADIUS légitime et non à un point d'accès pirate.

Identity provider integration

Les attributs du certificat SCEP - en particulier le nom alternatif du sujet (SAN) - peuvent contenir le nom principal de l'utilisateur provenant de Microsoft Entra ID, Okta ou Google Workspace. Cela lie le certificat à une identité spécifique. Lorsque vous désactivez un compte dans Entra ID et que le MDM désinscrit l'appareil, le certificat est révoqué et l'accès WiFi est coupé automatiquement. Cette révocation automatisée est l'argument de sécurité que les clés pré-partagées ne peuvent pas égaler.

Pour en savoir plus sur EAP Method WiFi: A Guide to Secure Network Access , y compris les chemins de migration PEAP-MSCHAPv2, consultez notre guide dédié.

Bonnes pratiques et normes de l'industrie

Emplacement du serveur NDES

Le serveur NDES doit être accessible depuis Internet afin que les appareils puissent s'enregistrer avant d'arriver sur site. Publiez l'URL NDES via le proxy d'application Azure AD. Cela fournit un accès à distance sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'inscription. N'exposez jamais NDES directement à Internet.

Pour les réseaux de plus de 500 appareils gérés, envisagez une passerelle SCEP cloud plutôt qu'un NDES sur site. Les passerelles cloud éliminent le point de défaillance unique du NDES, évoluent horizontalement et s'intègrent généralement directement aux services RADIUS cloud.

Disponibilité de la CRL

Votre serveur RADIUS vérifie la liste de révocation de certificats (CRL) à chaque fois qu'un appareil s'authentifie. Si votre point de distribution CRL (CDP) est indisponible - parce qu'un serveur est en panne ou que l'URL a changé - l'authentification échoue simultanément pour tous les appareils du réseau. Configurez votre serveur NPS ou RADIUS pour imposer une vérification stricte de la CRL, et rendez vos points de terminaison CRL hautement disponibles. Testez la révocation avant la mise en production.

L'exigence 8.6 de la norme PCI DSS 4.0 impose une authentification multifacteur au niveau de la couche réseau pour les environnements de données de titulaires de cartes. L'EAP-TLS avec des certificats provisionnés par SCEP répond à cette exigence pour les réseaux sans fil dans les environnements du Commerce de détail et de l' Hôtellerie .

Compatibilité WPA3

L'EAP-TLS est entièrement compatible avec WPA3-Enterprise. WPA3-Enterprise avec la suite de sécurité 192 bits (Suite B) impose l'EAP-TLS et constitue la combinaison recommandée par la Wi-Fi Alliance pour les réseaux gouvernementaux, financiers et de santé. Si vous effectuez un déploiement dans des environnements de la Santé ou des Transports avec des exigences de conformité strictes, WPA3-Enterprise avec EAP-TLS est l'architecture cible appropriée.

BYOD et W invitésiFi

SCEP requiert l'enrôlement MDM pour pousser la charge utile du certificat. Il ne couvre pas les appareils BYOD non gérés ou les invités. Pour ces cas d'usage, vous avez besoin d'un SSID distinct avec un Captive Portal et une vérification d'identité. La plateforme de Purple gère cette couche de manière transparente, en parallèle de votre réseau d'employés authentifié par certificat. Notre plateforme Guest WiFi prend en charge les opt-ins par choix conscient, la capture de données de première partie (first-party) et l'intégration avec Microsoft Entra ID, Okta et Google Workspace pour la vérification d'identité.

Résolution des problèmes et atténuation des risques

Échec de l'application du profil WiFi

Symptôme : L'appareil reçoit les certificats de racine de confiance (Trusted Root) et SCEP, mais le profil WiFi s'affiche comme Erreur ou Non applicable dans le MDM.

Cause racine : Incohérence de ciblage de groupe. Si le profil SCEP cible un groupe d'utilisateurs et le profil WiFi cible un groupe d'appareils, le MDM ne peut pas résoudre la dépendance.

Solution : Auditez vos affectations. Assurez-vous que les profils de racine de confiance (Trusted Root), SCEP et WiFi ciblent tous exactement le même groupe d'annuaire.

Erreurs NDES 403 Forbidden

Symptôme : Les appareils ne parviennent pas à récupérer le certificat SCEP. Les journaux IIS de NDES affichent des erreurs HTTP 403.

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

Solution : Vérifiez que le compte du connecteur dispose des autorisations de lecture et d'inscription sur le modèle d'autorité de certification (CA). Vérifiez les journaux du pare-feu pour vous assurer que les URL contenant ?operation=GetCACaps ne sont pas bloquées.

Échec d'authentification de masse après l'expiration de la CRL

Symptôme : Tous les appareils du réseau échouent à s'authentifier simultanément.

Cause racine : La CRL a expiré ou l'URL CDP est inaccessible. Le serveur RADIUS ne peut pas confirmer la validité des certificats et échoue en mode fermé (fails closed).

Solution : Configurez la surveillance et les alertes de CRL. Publiez des CRL avec une période de validité nettement supérieure à l'intervalle de publication. Testez l'accessibilité du CDP depuis le serveur RADIUS avant la mise en production.

L'expiration des certificats provoque des échecs silencieux

Symptôme : Des appareils individuels ne parviennent pas à se connecter par intermittence, sans motif clair.

Cause racine : Les certificats clients ont expiré et le MDM ne les a pas renouvelés avec succès.

Solution : Configurez le renouvellement des certificats pour qu'il se déclenche à 80 % de la durée de vie du certificat. Surveillez les rapports d'état d'enrôlement MDM pour les appareils présentant des erreurs de certificat. Définissez des périodes de validité de certificat adaptées au cycle de renouvellement de vos appareils - généralement un à deux ans pour les terminaux gérés.

ROI et impact commercial

La transition vers l'authentification par certificat 802.1X basée sur SCEP offre des retours mesurables en matière de sécurité, d'opérations et de conformité.

Réduction des tickets de support : Le WiFi basé sur mot de passe génère un volume important de tickets de support (expirations de mots de passe, verrouillages et fautes de frappe). L'authentification par certificat est invisible pour l'utilisateur. Les organisations constatent généralement une réduction de 70 à 80 % du volume de tickets de support liés au WiFi après la migration.

Posture de sécurité : EAP-TLS élimine le vol d'identifiants et les attaques de l'homme du milieu (Man-in-the-Middle). Cela soutient directement la conformité PCI DSS 4.0 pour les réseaux de vente au détail et d'hôtellerie, ainsi que les exigences de l'article 32 du GDPR concernant les mesures de sécurité techniques appropriées.

Révocation automatisée : Lorsqu'un employé s'en va, la désactivation de son compte dans Microsoft Entra ID déclenche la révocation automatique du certificat et le désenrôlement du MDM. L'accès WiFi est coupé sans aucune intervention manuelle de l'équipe réseau.

Segmentation réseau : L'affectation dynamique de VLAN via les attributs de certificat RADIUS vous offre une segmentation réseau renforcée par cryptographie. Les appareils se connectent au bon segment de réseau en fonction des propriétés du certificat, et non de la sélection du SSID ou du filtrage d'adresses MAC, qui sont tous deux facilement contournés.

Purple opère sur plus de 80 000 sites actifs avec une disponibilité de 99,999 %, et notre plateforme est certifiée ISO 27001, GDPR, CCPA et Cyber Essentials. Notre superposition cloud indépendante du matériel s'intègre à Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Ainsi, votre réseau d'employés authentifié par certificat et notre couche de WiFi invité fonctionnent à partir de la même infrastructure.

Pour en savoir plus sur la manière dont Behavioral Analytics: Insights for WiFi Networks peut compléter le déploiement de votre réseau sécurisé, consultez notre guide d'analyse.

Références

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configurer l'infrastructure pour prendre en charge SCEP avec Intune - Microsoft Learn [3] Directives sans fil PCI DSS - PCI Security Standards Council

Définitions clés

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.

Exemples concrets

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.

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

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

Questions d'entraînement

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.

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

Voir la réponse type

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.

Conseil : 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?

Voir la réponse type

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?

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

Voir la réponse type

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.

Continuer la lecture de cette série

How to Set Up a Captive Portal on Starlink: A Guide for Remote & Maritime Venues

Ce guide explique en détail comment contourner le matériel Starlink natif et intégrer un Captive Portal géré dans le cloud à l'aide d'équipements de routage d'entreprise. Vous apprendrez à surmonter la limitation du CGNAT, à appliquer la segmentation VLAN, à gérer les contraintes de bande passante satellite et à garantir la conformité réglementaire.

Gestion du WiFi pour les clients d'hôtels : Intégration du PMS, des portails et des normes de marque

Ce guide technique détaille comment concevoir des réseaux WiFi hôteliers de classe entreprise, en se concentrant sur la segmentation VLAN, l'intégration PMS pour la gestion automatisée des sessions et l'optimisation du Captive Portal pour une collecte de données conforme au GDPR.

Captive Portal Best Practices: Designing for High Conversion and Compliance

Ce guide technique offre aux responsables informatiques, architectes réseau et directeurs de l'exploitation des sites un modèle complet pour déployer des Captive Portals qui concilient sécurité réseau et taux de conversion élevé. Il couvre l'intégralité de l'architecture, de la segmentation VLAN et l'authentification RADIUS à la conception de consentements conformes au GDPR et à la sélection des méthodes d'authentification. Issu de l'expérience opérationnelle de Purple sur plus de 80 000 sites et 440 millions de connexions en 2024, chaque recommandation s'appuie sur des données de déploiement réelles.