Comment configurer SCEP pour un WiFi d'entreprise sécurisé et le provisionnement BYOD

Ce guide technique explique comment configurer le protocole SCEP (Simple Certificate Enrollment Protocol) pour automatiser l'authentification WiFi d'entreprise 802.1X sécurisée et le provisionnement BYOD. Il fournit aux architectes réseau et aux responsables informatiques une séquence de déploiement définitive, des scénarios de mise en œuvre réels issus de l'hôtellerie et du commerce de détail, ainsi que des stratégies d'atténuation des risques pour éliminer les clés pré-partagées vulnérables et le MAC Authentication Bypass des réseaux d'entreprise.

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

Écouter ce guide

Voir la transcription du podcast

Welcome to this technical briefing from Purple. I am your host, and today we are diving deep into the configuration of SCEP for secure enterprise WiFi and BYOD provisioning.

For IT managers, network architects, and CTOs operating in hospitality, retail, and public sectors, managing network access is a constant balancing act between security and operational efficiency. You are dealing with hundreds, sometimes thousands of devices connecting to your network every day. Staff smartphones, contractor laptops, point-of-sale tablets. And the old ways of handling this are simply not good enough anymore.

Relying on Pre-Shared Keys, or PSKs, for staff and BYOD WiFi is a security vulnerability waiting to be exploited. A shared password, once compromised, gives anyone access to your network. And MAC Authentication Bypass, or MAB, is no better. Modern smartphones use randomised MAC addresses by default, which breaks MAB entirely, and MAC addresses can be spoofed in seconds.

Modern network architecture demands 802.1X authentication using EAP-TLS. This ensures every device is cryptographically verified before it touches the network. But here is the challenge: how do you distribute unique client certificates to thousands of unmanaged devices without overwhelming your helpdesk? The answer is the Simple Certificate Enrollment Protocol, or SCEP.

Let us start with the architecture. SCEP is the industry standard for enterprise device enrollment, defined in RFC 8894. It has been around since 1999, originally created by VeriSign, and it has stood the test of time because it solves a genuinely hard problem elegantly.

In a SCEP workflow, the device generates its own private and public key pair locally. It creates a Certificate Signing Request, or CSR, and sends it via a Network Device Enrollment Service, known as NDES, to your Certificate Authority, or CA. The CA validates the request and returns the signed public certificate to the device.

The critical security advantage here is that the private key never leaves the device. It is generated locally and stored in the device's hardware secure enclave. On a Windows laptop, that is the Trusted Platform Module, or TPM. On an iPhone, it is the Secure Enclave. The private key is never transmitted across the network. This is what makes SCEP vastly superior to alternatives like PKCS for network authentication, where the CA generates the key pair centrally and transmits it to the device.

Now, let us talk about BYOD. This is where it gets genuinely interesting from an operational standpoint. You want staff to be able to use their personal devices to access internal tools, but you do not want to force them to enrol in your corporate MDM. That is a privacy concern, and it meets strong resistance from staff.

The solution is a self-service onboarding portal. Here is how it works. The user connects their personal device to a dedicated provisioning SSID. This network is a walled garden, restricting access to everything except the onboarding portal and your identity provider. The user authenticates using their corporate credentials, typically via SAML integration with Microsoft Entra ID, Okta, or Google Workspace. Upon successful authentication, the system generates a unique, device-specific client certificate via SCEP. A configuration profile is pushed to the device containing the certificate, the root CA certificate, and the network settings. The device then automatically connects to the secure corporate SSID using EAP-TLS.

It is seamless for the user and secure for the enterprise. They do not need to know anything about certificates or 802.1X. They just log in once and they are connected.

Now, let us walk through the implementation in detail. The deployment sequence is critical, and getting it wrong is the most common cause of failure.

Step one: deploy the Trusted Root Certificate. Before any device can request a client certificate or trust your RADIUS server, it must trust the issuing Certificate Authority. Export your Root CA certificate as a .cer file and deploy it to your target device groups. This step is non-negotiable. Without it, the entire chain fails.

Step two: configure the SCEP Certificate Profile. This instructs devices on how to obtain their client certificate. You need to configure the subject name format. For user-driven authentication, the standard is CN equals UserPrincipalName. For device authentication, use CN equals the Azure AD Device ID. Set the key usage to digital signature and key encipherment. Under extended key usage, specify Client Authentication with the OID 1.3.6.1.5.5.7.3.2. Link this profile to the Trusted Root certificate profile from step one. And provide the external URL of your NDES server.

Step three: deploy the 802.1X WiFi Profile. This ties the certificates to the network SSID. Enter the network name exactly as it is broadcast by your access points. Set the security type to WPA2-Enterprise or WPA3-Enterprise. Set the EAP type to EAP-TLS. Select the SCEP certificate profile as the client authentication certificate. And specify the Trusted Root certificate for server validation.

This sequence is the most important thing to remember from this entire briefing. Trust, then certificate, then WiFi. In that order, every time.

Now let me walk you through some best practices that will save you significant pain in production.

First, publish your NDES server via Azure AD Application Proxy. The NDES server must be accessible from the internet to allow remote devices to provision certificates before they arrive on-site. But exposing an internal server directly to the internet is a significant security risk. Application Proxy gives you secure remote access without opening inbound firewall ports.

Second, implement short-lived certificates for BYOD devices. Instead of a certificate valid for three years, issue certificates valid for 90 days. When the certificate expires, the user must re-authenticate through the onboarding portal. This naturally prunes stale devices from the network. A device that has not been used in 90 days simply drops off. No manual cleanup required.

Third, and this is absolutely critical, configure your RADIUS server to enforce strict Certificate Revocation List checking. When an employee leaves the organisation, disabling their Active Directory account may not immediately revoke their WiFi access if their client certificate remains valid. Your RADIUS server must check the CRL before granting access. Ensure your CRL Distribution Points are highly available. If the RADIUS server cannot reach the CRL, authentication fails for everyone. That is a widespread outage.

Now let us look at some common failure modes and how to avoid them.

The most frequent issue is the WiFi profile failing to apply. The device receives the Trusted Root and SCEP certificates, but the WiFi profile shows as Error in the MDM console. Nine times out of ten, this is a group targeting mismatch. If the SCEP profile is assigned to a User Group, but the WiFi profile is assigned to a Device Group, the MDM cannot resolve the dependency. Audit your assignments. Ensure all three profiles target the exact same group.

The second common issue is NDES 403 Forbidden errors. Devices fail to retrieve the SCEP certificate, and the NDES IIS logs show HTTP 403 errors. This is usually caused by the connector service account lacking the necessary permissions on the certificate template, or a firewall blocking the specific query string parameters used by SCEP. Verify that the connector account has Read and Enroll permissions on the CA template. Check your firewall logs to ensure URLs containing the operation equals GetCACaps parameter are not being blocked.

Let me give you two real-world scenarios to illustrate how this plays out in practice.

Scenario one: a 200-room hotel with 50 housekeeping staff using personal smartphones to access the scheduling app. The IT manager wants to avoid full MDM enrolment to respect staff privacy. The solution is a self-service portal integrated with Microsoft Entra ID. Staff connect to the provisioning SSID, log in with their Entra ID credentials, and download a SCEP profile. The SCEP server issues a 30-day client certificate directly to the device. The device connects to the Staff WiFi SSID using EAP-TLS. The RADIUS server assigns these devices to a restricted VLAN that only allows access to the scheduling app. When a staff member resigns, their Entra ID account is disabled, and the RADIUS server instantly denies network access.

Scenario two: a national retail chain with 500 stores deploying secure WiFi for corporate-owned point-of-sale tablets. The network architect needs to ensure that even if a tablet is stolen, the credentials cannot be extracted. The solution is Microsoft Intune deploying certificates via SCEP. Intune pushes the Trusted Root certificate, followed by a SCEP profile that instructs the tablet to generate its own private key in its hardware secure enclave. The tablet submits a CSR to the NDES server, receives the client certificate, and connects to the Retail POS SSID using EAP-TLS. Because the private key is generated locally and never transmitted, a stolen tablet's credentials cannot be used elsewhere. This satisfies PCI DSS compliance requirements.

Now, let us talk about the business case. Transitioning to SCEP 802.1X certificate deployment delivers measurable returns across security and operations.

Password-based WiFi generates a significant volume of helpdesk tickets. Password expirations, lockouts, typos. Certificate-based authentication is invisible to the user. Devices connect automatically. This typically reduces WiFi-related helpdesk volume by 70%. That is a material reduction in operational cost.

EAP-TLS eliminates the risk of credential harvesting and Man-in-the-Middle attacks. This is critical for compliance with PCI DSS in retail environments and GDPR across all sectors. The cost of a data breach far exceeds the cost of deploying a proper PKI infrastructure.

And for organisations already running Purple's Guest WiFi and analytics platform, extending secure onboarding to staff BYOD devices provides a unified network management strategy. Purple's hardware-agnostic cloud overlay integrates with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet, so you are not locked into a single hardware vendor. Purple operates across 80,000 live venues and has processed 440 million logins in 2024, holding ISO 27001, GDPR, CCPA, and Cyber Essentials certifications.

Let me close with a rapid-fire summary of the key decisions you need to make.

Should you use SCEP or PKCS? Use SCEP for WiFi authentication. The private key stays on the device. Use PKCS only for email encryption where key escrow is required.

How long should certificates be valid? 90 days for BYOD. One to two years for corporate-managed devices.

Should you use user or device targeting in your MDM? Use device targeting for corporate devices that need to connect before user login. Use user targeting for BYOD where the certificate should be tied to the individual.

How do you handle Android fragmentation? Use Passpoint, also known as Hotspot 2.0, where possible. It provides a consistent connection experience across Android manufacturers.

And finally, what is the single most important thing to get right? CRL checking on your RADIUS server. Without it, a revoked certificate can still grant network access.

That is the end of today's briefing. If you want to go deeper on any of these topics, Purple's technical guides on enterprise WiFi security and EAP-TLS certificate authentication are available on the Purple website at purple.ai. Thank you for listening.

Points clés à retenir

✓802.1X EAP-TLS is the standard for secure enterprise WiFi, requiring client certificates on all devices. Pre-shared keys and MAC Authentication Bypass are not viable for enterprise environments.
✓SCEP automates certificate deployment at scale. The private key is generated on the 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. All three profiles must target the exact same group in your MDM.
✓For BYOD, a self-service captive portal integrated with Microsoft Entra ID, Okta, or Google Workspace allows staff to onboard personal devices without full MDM enrolment.
✓Issue 90-day certificates for BYOD devices to automatically prune stale devices. Configure your RADIUS server for strict CRL or OCSP checking to revoke access instantly when staff leave.
✓Publish your NDES server via Azure AD Application Proxy to allow remote certificate provisioning without exposing internal infrastructure to the internet.
✓SCEP-based 802.1X typically reduces WiFi-related helpdesk ticket volume by 70% and satisfies PCI DSS and GDPR compliance requirements for retail, hospitality, and healthcare environments.

Résumé opérationnel

Pour les établissements d'entreprise opérant dans les secteurs de l'hôtellerie, du commerce de détail et du secteur public, s'appuyer sur des clés pré-partagées (PSK) ou sur le MAC Authentication Bypass (MAB) pour le WiFi du personnel et des appareils BYOD 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 opérationnel consiste à distribuer des certificats clients uniques à des milliers d'appareils non gérés sans submerger votre support informatique de tickets d'assistance.

Le protocole SCEP (Simple Certificate Enrollment Protocol), défini dans la RFC 8894, résout ce problème de distribution grâce à une gestion automatisée du cycle de vie des certificats. En s'appuyant sur SCEP, les équipes informatiques déploient des certificats racines et clients de confiance sur les terminaux, garantissant que la clé privée ne quitte jamais l'appareil. Ce guide fournit un schéma d'architecture définitif et une stratégie de mise en œuvre étape par étape pour le déploiement de certificats WiFi SCEP. Nous couvrons la séquence de déploiement critique requise pour réussir, des scénarios réels issus de l'hôtellerie et du commerce de détail, ainsi que des stratégies d'atténuation des risques pour garantir que votre Guest WiFi et vos réseaux d'entreprise restent sécurisés et performants.

Analyse technique approfondie : l'architecture SCEP

SCEP est la norme de l'industrie pour l'enregistrement des appareils d'entreprise, créée par VeriSign et publiée en tant que projet Internet de l'IETF en 1999. Il automatise la délivrance de certificats X.509 au sein d'un environnement d'infrastructure à clés publiques (PKI), éliminant ainsi le besoin de gestion manuelle des certificats à grande échelle.

Dans un flux de travail SCEP, l'appareil génère localement sa propre paire de clés privée et publique. Il crée une demande de signature de certificat (CSR) et l'envoie via un serveur NDES (Network Device Enrollment Service) à votre autorité de certification (CA). La CA valide la demande à l'aide d'un secret partagé et renvoie le certificat public signé à l'appareil. L'avantage de sécurité critique est que la clé privée ne quitte jamais l'appareil. Elle est générée localement et stockée dans l'enclave sécurisée matérielle de l'appareil : le module TPM (Trusted Platform Module) sous Windows, ou la Secure Enclave sur iOS. Cela fait de SCEP l'approche fortement recommandée pour l'authentification 802.1X, par rapport au PKCS (Public Key Cryptography Standards) où la CA génère la paire de clés de manière centralisée et la transmet sur le réseau.

Les quatre étapes de l'enregistrement de certificat SCEP sont les suivantes. Premièrement, l'appareil se connecte à l'URL du point de terminaison SCEP hébergé par le serveur NDES. Deuxièmement, l'appareil présente un secret partagé SCEP (soit un mot de passe statique, soit un défi dynamique généré par la plateforme MDM) pour authentifier la demande d'enregistrement. Troisièmement, l'appareil génère une CSR contenant sa clé publique et ses informations d'identité. Quatrièmement, la CA valide la CSR et délivre le certificat X.509 signé, qui est renvoyé à l'appareil.

SCEP vs PKCS : choisir le bon mécanisme

Lors de la conception de votre stratégie de déploiement de certificats, le choix entre SCEP et PKCS a des implications directes sur la sécurité. Le tableau ci-dessous résume les principales différences.

Attribut	SCEP	PKCS
Génération de la clé privée	Sur l'appareil (enclave sécurisée)	Sur le serveur de la CA
Transmission de la clé privée	Jamais transmise	Transmise sur le réseau
Exigence d'infrastructure	Serveur NDES requis	Aucun NDES requis
Idéal pour	Authentification WiFi et VPN	Chiffrement des e-mails S/MIME
Posture de sécurité pour le 802.1X	Recommandé	Non recommandé

Pour le WiFi d'entreprise, choisissez toujours SCEP. Le fait que la clé privée reste sur l'appareil est la propriété de sécurité fondamentale qui rend l'authentification 802.1X basée sur des certificats supérieure à toute méthode basée sur des identifiants.

Flux d'intégration BYOD en libre-service

La base d'une intégration BYOD sécurisée est la transition d'une authentification héritée vers EAP-TLS sans nécessiter d'enregistrement complet dans une gestion des appareils mobiles (MDM). Forcer le personnel à enregistrer ses smartphones personnels dans un MDM d'entreprise soulève des préoccupations légitimes en matière de confidentialité et se heurte à une forte résistance. Un portail d'intégration en libre-service résout ce problème.

L'utilisateur connecte son appareil personnel à un SSID de provisionnement dédié, qui agit comme un environnement fermé (walled garden) limitant l'accès uniquement au portail d'intégration et au fournisseur d'identité. L'utilisateur s'authentifie via une intégration SAML ou OAuth avec Microsoft Entra ID, Okta ou Google Workspace. Une fois l'authentification réussie, le système génère un certificat client unique et propre à l'appareil via SCEP. Un profil de configuration (un fichier Apple .mobileconfig ou un profil Android Passpoint) est envoyé à l'appareil. L'appareil se connecte ensuite automatiquement au SSID d'entreprise sécurisé à l'aide d'EAP-TLS. L'utilisateur n'a jamais besoin d'avoir des connaissances sur les certificats ou le 802.1X.

Guide de mise en œuvre : la séquence de déploiement

La configuration réussie de SCEP pour le 802.1X nécessite le respect strict d'une séquence de déploiement spécifique. La confiance doit être établie avant que l'authentification puisse être configurée. S'écarter de cet ordre est la cause la plus fréquente d'échec de déploiement.

Étape 1 : Déployer le certificat racine de confiance. Avant qu'un appareil puisse demander un certificat client ou faire confiance à votre serveur RADIUS, il doit faire confiance à l'autorité de certification émettrice. Exportez votre certificat de CA racine (et tout certificats d'AC intermédiaire) sous forme de fichiers .cer. Déployez ce profil sur vos groupes d'appareils cibles via votre plateforme MDM. Cette étape est non négociable.

Étape 2 : Configurer le profil de certificat SCEP. Cela indique aux appareils comment obtenir leur certificat client. Configurez le format du nom de l'objet - pour l'authentification basée sur l'utilisateur, CN={{UserPrincipalName}} est la norme ; pour l'authentification de l'appareil, utilisez CN={{AAD_Device_ID}}. Définissez l'utilisation de la clé sur Digital signature et Key encipherment. Sous l'utilisation étendue de la clé, spécifiez Client Authentication (OID : 1.3.6.1.5.5.7.3.2). Associez ce profil au profil de certificat de racine de confiance de l'étape 1. Fournissez l'URL externe de votre serveur NDES.

Étape 3 : Déployer le profil WiFi 802.1X. Poussez la configuration WiFi qui lie les certificats au SSID du réseau. Saisissez le nom du réseau exactement tel qu'il est diffusé par vos points d'accès. Définissez le type de sécurité sur WPA2-Enterprise ou WPA3-Enterprise. Définissez le type EAP sur EAP-TLS. Sélectionnez le profil de certificat SCEP comme certificat d'authentification client. Spécifiez le certificat de racine de confiance pour la validation du serveur afin de vous assurer que l'appareil se connecte uniquement à votre serveur RADIUS légitime.

Cette séquence s'applique à toutes les plateformes matérielles prises en charge : Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. L'overlay cloud agnostique de Purple s'intègre à l'ensemble de ces solutions, ce qui signifie que votre infrastructure de certificats n'est pas liée à un seul fournisseur de matériel.

Bonnes pratiques

Publier NDES via le proxy d'application Azure AD. Le serveur NDES doit être accessible depuis Internet pour permettre aux appareils distants de provisionner des certificats avant d'arriver sur site. Exposer un serveur interne directement à Internet représente un risque de sécurité majeur. La publication via le proxy d'application Azure AD fournit un accès distant sécurisé sans ouvrir de ports de pare-feu entrants et vous permet d'appliquer des politiques d'accès conditionnel au flux d'enregistrement.

Émettre des certificats à courte durée de vie pour le BYOD. Les appareils BYOD n'étant pas gérés, le risque qu'un appareil compromis reste sur le réseau est plus élevé. Émettez des certificats valides pour 90 jours plutôt que pour plusieurs années. À l'expiration du certificat, l'utilisateur doit se réauthentifier via le portail d'intégration. Cela permet de nettoyer naturellement les appareils obsolètes du réseau sans intervention informatique manuelle.

Imposer une vérification stricte de la CRL sur le serveur RADIUS. Le déploiement de certificats ne représente que la moitié de l'équation de sécurité. Si un employé est licencié, la désactivation de son compte Active Directory peut ne pas révoquer immédiatement son accès WiFi si son certificat client reste valide. Configurez votre serveur RADIUS pour imposer une vérification stricte de la liste de révocation de certificats (CRL). Assurez-vous que vos points de distribution de CRL (CDP) sont hautement disponibles. Si le serveur RADIUS ne peut pas atteindre la CRL, l'authentification échoue pour tous les utilisateurs, ce qui entraîne une panne généralisée.

Segmenter le BYOD sur un VLAN dédié. Les appareils BYOD ne sont pas gérés. Vous ne contrôlez pas leurs mises à jour d'OS, l'état de leur antivirus ou leurs applications installées. Placez les appareils BYOD sur un VLAN dédié qui fournit un accès Internet et un accès restreint uniquement aux applications internes spécifiques requises pour le rôle de l'employé. Ne placez jamais d'appareils BYOD sur le même VLAN que les serveurs de l'entreprise ou les appareils gérés.

Dépannage et atténuation des risques

Échec de l'application du profil WiFi. L'appareil reçoit les certificats de racine de confiance et SCEP, mais le profil WiFi s'affiche comme « Erreur » dans la console MDM. Cela est presque toujours dû à une incompatibilité de ciblage de groupe. Si le profil SCEP est attribué à un groupe d'utilisateurs mais que le profil WiFi est attribué à un groupe d'appareils, le MDM ne peut pas résoudre la dépendance. Auditez vos attributions et assurez-vous que les profils de racine de confiance, SCEP et WiFi ciblent tous exactement le même groupe Azure AD.

Erreurs NDES 403 Forbidden. Les appareils ne parviennent pas à récupérer le certificat SCEP et les journaux IIS de NDES affichent des erreurs HTTP 403. Le compte de service du connecteur manque probablement des autorisations nécessaires sur le modèle de certificat, ou votre pare-feu bloque les paramètres de chaîne de requête spécifiques utilisés par SCEP. Vérifiez que le compte du connecteur dispose des autorisations « Lecture » et « Inscription » sur le modèle d'AC. Vérifiez les journaux du pare-feu pour vous assurer que les URL contenant ?operation=GetCACaps ne sont pas bloquées.

Fragmentation Android. Les appareils Apple iOS gèrent les profils .mobileconfig de manière cohérente. Android est extrêmement fragmenté : les différents fabricants et versions d'OS gèrent les profils WiFi et l'installation des certificats de manière différente. Fournissez des instructions claires et spécifiques à chaque OS sur le portail d'intégration. L'utilisation de Passpoint (Hotspot 2.0) améliore considérablement l'expérience Android en offrant un flux de connexion cohérent entre les différents fabricants.

Délais de révocation de certificat. Lorsqu'un employé s'en va, son accès doit être révoqué immédiatement. La désactivation de son compte IdP est la première étape, mais le serveur RADIUS doit également vérifier le statut du certificat. Configurez votre serveur RADIUS pour utiliser le protocole OCSP (Online Certificate Status Protocol) en plus de la vérification de la CRL. L'OCSP fournit un statut de révocation en temps réel plutôt que de s'appuyer sur une liste mise à jour périodiquement.

ROI et impact commercial

La transition vers le déploiement de certificats SCEP 802.1X offre des retours mesurables en matière de sécurité et d'opérations. Le WiFi basé sur mot de passe génère un volume important de tickets d'assistance liés aux expirations de mots de passe, aux verrouillages et aux fautes de frappe. L'authentification par certificat est invisible pour l'utilisateur : les appareils se connectent automatiquement. Cela réduit généralement de 70 % le volume de tickets d'assistance liés au WiFi, libérant ainsi le personnel informatique pour qu'il se concentre sur des tâches stratégiques.

L'EAP-TLS élimine le risque de vol d'identifiants et d'attaques de l'homme du milieu (MitM). Cela est essentiel pour la conformité avec PCI DSS dans les environnements de Commerce de détail et avec le GDPR pour l'enles secteurs. Dans le secteur de l' Hôtellerie , où le personnel gère des données de paiement et des informations personnelles des clients, le coût d'une violation de données dépasse de loin celui du déploiement d'une infrastructure PKI appropriée. Pour les opérateurs de Transport et les établissements de Santé , les mêmes exigences de conformité s'appliquent.

Pour les sites qui utilisent déjà la plateforme de WiFi invité et de WiFi Analytics de Purple, étendre l'intégration sécurisée aux appareils BYOD du personnel offre une stratégie de gestion de réseau unifiée et robuste. Purple est présent dans plus de 80 000 sites actifs et a traité 440 millions de connexions en 2024 (données internes de Purple), tout en détenant les certifications ISO 27001, GDPR, CCPA et Cyber Essentials. Nos extensions de sécurité SecurePass et Shield s'intègrent directement à l'architecture d'authentification basée sur des certificats décrite dans ce guide.

Pour une vision plus large de la sécurité des réseaux d'entreprise, consultez notre guide Sécurité WiFi d'entreprise : le guide complet pour 2026 . Pour les questions de conformité au GDPR spécifiques aux administrateurs réseau, consultez Le guide de l'administrateur réseau pour la conformité au GDPR et à la confidentialité des données des invités .

Définitions clés

SCEP (Simple Certificate Enrollment Protocol)

A protocol defined in RFC 8894 that automates the issuance of X.509 digital certificates to devices within a PKI environment. The device generates its own private key locally, which never leaves the device.

Used to deploy WiFi authentication certificates to corporate and BYOD devices at scale without manual IT intervention. The industry standard for 802.1X certificate provisioning.

802.1X

An IEEE standard (IEEE Std 802.1X-2020) for port-based network access control. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN before they are granted access to network resources.

The foundation of secure enterprise WiFi, replacing vulnerable pre-shared keys. Requires a RADIUS server, a supplicant on the client device, and an authenticator on the access point.

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

An authentication framework that requires both the server and the client to present valid digital certificates. Provides mutual authentication, ensuring the device trusts the network and the network trusts the device.

The most secure method for 802.1X authentication. Eliminates credential theft and Man-in-the-Middle attacks. The target authentication protocol that SCEP certificate deployment is designed to enable.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a bridge, allowing devices without domain credentials to obtain certificates from an Active Directory Certificate Services CA via SCEP.

A required infrastructure component when implementing SCEP with Microsoft Intune. Should be published via Azure AD Application Proxy to allow secure remote certificate provisioning.

BYOD (Bring Your Own Device)

The practice of allowing employees to use their personal smartphones, tablets, or laptops to access enterprise networks and applications.

Requires careful network segmentation and secure onboarding to prevent unmanaged devices from compromising the corporate network. Full MDM enrolment is often impractical for personal devices due to privacy concerns.

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.

Must be checked by the RADIUS server during every authentication attempt to ensure terminated employees or compromised devices cannot access the network. CRL Distribution Points must be highly available.

CSR (Certificate Signing Request)

A message generated by a device and sent to a Certificate Authority to apply for a digital identity certificate. Contains the device's public key and identity information.

Generated by the device during the SCEP process. The private key used to sign the CSR remains on the device and is never transmitted.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users and devices connecting to a network.

The server that validates the client certificate during 802.1X authentication and grants or denies network access. Must be configured to enforce strict CRL or OCSP checking.

PKCS (Public Key Cryptography Standards)

A set of standards where both the public and private keys are generated by the Certificate Authority and then securely delivered to the endpoint.

Less suitable than SCEP for WiFi authentication because the private key is transmitted over the network. Better suited for S/MIME email encryption where key escrow is required.

OCSP (Online Certificate Status Protocol)

A protocol that provides real-time certificate revocation status, as an alternative to the periodically updated CRL.

Preferred over CRL for high-security environments because it provides instant revocation status rather than relying on a list that may be hours old.

Exemples concrets

A 200-room hotel needs to provide secure WiFi access for 50 housekeeping staff using their personal smartphones (BYOD) to access the housekeeping scheduling app. The IT manager wants to avoid full MDM enrolment to respect staff privacy, but needs to ensure access is revoked immediately when a staff member resigns.

The hotel deploys a self-service onboarding portal integrated with Microsoft Entra ID. Staff connect to an open provisioning SSID, authenticate with their Entra ID credentials, and download a SCEP profile. The SCEP server issues a 30-day client certificate directly to the device, with the private key generated and stored locally on the smartphone's secure enclave. The device automatically connects to the 'Staff_WiFi' SSID using EAP-TLS. The RADIUS server assigns these devices to a restricted VLAN that permits access only to the scheduling app and the internet. When a staff member resigns, their Entra ID account is disabled. The RADIUS server, configured for strict CRL checking, denies network access at the next authentication attempt. The 30-day certificate validity ensures that even if CRL checking were delayed, access would lapse within a month.

Commentaire de l'examinateur : This approach balances security with staff privacy. By using SCEP via a captive portal rather than full MDM enrolment, the hotel avoids installing a management profile on personal devices. The 30-day certificate validity and strict CRL checking provide layered access control. The VLAN segmentation ensures that even a compromised BYOD device cannot reach corporate servers or payment systems.

A national retail chain with 500 stores needs to deploy secure WiFi for corporate-owned point-of-sale (POS) tablets running Windows. The network architect must ensure that even if a tablet is stolen, the network credentials cannot be extracted and used to access the corporate network from another device. PCI DSS compliance is mandatory.

The network architect configures Microsoft Intune to deploy certificates via SCEP. Intune pushes the Trusted Root certificate to the 'POS Devices' group, followed by a SCEP profile that instructs each tablet to generate its own private key in the Windows TPM. The tablet submits a CSR to the NDES server, receives the client certificate, and connects to the 'Retail_POS' SSID using WPA3-Enterprise and EAP-TLS. The RADIUS server authenticates the certificate and places the device on the isolated POS VLAN, which only permits traffic to the payment processor and inventory management system. All three Intune profiles - Trusted Root, SCEP, and WiFi - are assigned to the same 'POS Devices' device group to prevent dependency failures. NDES is published via Azure AD Application Proxy to allow certificate renewal without requiring the tablet to be on-site.

Commentaire de l'examinateur : This is the optimal architecture for corporate devices in a PCI DSS environment. Because SCEP ensures the private key is generated locally in the TPM and never transmitted, a stolen tablet's credentials cannot be extracted and replayed from another device. The WPA3-Enterprise standard provides forward secrecy, ensuring that captured traffic cannot be decrypted retroactively. The VLAN isolation limits the blast radius of any compromised device to the POS network segment only.

Questions d'entraînement

Q1. You are deploying a SCEP profile via Intune to a fleet of Windows laptops. The devices successfully receive the Trusted Root certificate, but the WiFi profile fails to apply and shows as 'Error' in the Intune console. The SCEP profile is assigned to the 'All Users' Azure AD group, while the WiFi profile is assigned to the 'Corporate Laptops' device group. What is the cause of the failure and how do you resolve it?

Conseil : Consider the dependencies between the profiles and how Intune resolves group targeting when a profile depends on another profile.

Voir la réponse type

The failure is caused by a group targeting mismatch. Intune cannot resolve the dependency between the SCEP profile and the WiFi profile because they target different group types - one targets users and the other targets devices. To resolve this, audit all three profile assignments and ensure the Trusted Root, SCEP, and WiFi profiles are all deployed to the exact same Azure AD group. Choose either user targeting or device targeting consistently across all profiles.

Q2. A retail venue wants to secure its POS tablets. The IT director suggests using PKCS instead of SCEP because it simplifies infrastructure by removing the need for an NDES server. As the network architect, why should you recommend SCEP for 802.1X WiFi authentication, and under what circumstances would PKCS be the correct choice?

Conseil : Think about where the private key is generated and stored in both protocols, and consider the security implications for network authentication versus email encryption.

Voir la réponse type

Recommend SCEP for 802.1X WiFi authentication because the private key is generated locally on the device and stored in its hardware secure enclave. The private key never leaves the device and is never transmitted across the network. If a tablet is stolen, the credentials cannot be extracted and used from another device. With PKCS, the CA generates the key pair centrally and transmits it to the device, introducing a transmission risk that is unacceptable for network authentication. PKCS is the correct choice only for S/MIME email encryption, where key escrow is required to allow encrypted emails to be decrypted if the original device is lost.

Q3. You are designing a BYOD onboarding portal for a 500-bed hospital. Clinical staff will use their personal smartphones to access non-critical internal apps such as the staff rota and internal messaging. You need to minimise the risk of stale devices remaining on the network after staff leave, without requiring manual IT intervention for each departure. What specific certificate configuration should you implement?

Conseil : Consider the lifecycle of the certificate and how you can force devices to re-authenticate periodically without requiring IT to manually revoke each certificate.

Voir la réponse type

Implement short-lived certificates with a validity period of 30 to 90 days. When the certificate expires, the BYOD device is forced to re-authenticate through the captive portal using the staff member's corporate IdP credentials. If the staff member has left and their IdP account has been disabled, they cannot complete re-authentication and will not receive a new certificate. This naturally prunes stale devices from the network without requiring IT to manually revoke individual certificates. Combine this with OCSP checking on the RADIUS server to ensure immediate revocation when an account is disabled, providing defence in depth between certificate expiry cycles.

Q4. Your NDES server is returning HTTP 403 Forbidden errors for all SCEP certificate requests. The NDES server is accessible from the internet via Azure AD Application Proxy. What are the two most likely causes of this error and how do you diagnose each one?

Conseil : Consider both the permissions on the certificate template and the network path between the device and the NDES server.

Voir la réponse type

The two most likely causes are: first, the Intune Certificate Connector service account lacks the necessary permissions on the CA certificate template. Verify that the service account has 'Read' and 'Enroll' permissions on the template in the CA console. Second, the firewall or Application Proxy is blocking the specific query string parameters used by SCEP. Check firewall and Application Proxy logs for requests containing parameters such as '?operation=GetCACaps' or '?operation=PKIOperation'. These are standard SCEP operations that must be permitted. If the Application Proxy is stripping query strings, adjust the pre-authentication settings to allow pass-through for the NDES URL path.

Continuer la lecture de cette série

Mesurer le ROI commercial du WiFi invité et des analyses de localisation

Ce guide fournit un cadre technique et opérationnel pour mesurer le ROI commercial du WiFi invité et des analyses de localisation. Il détaille comment calculer la valeur des investissements matériels grâce à l'augmentation du temps de séjour, à l'efficacité opérationnelle et à la capture de données de première partie dans les secteurs du commerce de détail, de l'hôtellerie et des lieux publics. Les responsables informatiques, les architectes réseau, les CTO et les directeurs d'exploitation de sites y trouveront des cadres de mesure concrets, des études de cas réelles et des conseils de conformité pour justifier et maximiser leur investissement WiFi.

Conformité GDPR pour le WiFi : comment collecter en toute sécurité les données des invités via des Captive Portals

Ce guide technique offre aux responsables informatiques, architectes réseau et directeurs d'exploitation de sites un cadre pratique pour assurer la conformité GDPR de leurs déploiements WiFi invités. Il explique comment les captive portals collectent les données personnelles, comment obtenir un consentement explicite et comment mettre en œuvre des politiques automatisées de rétention des données afin de protéger votre organisation contre des amendes réglementaires pouvant atteindre 4 % du chiffre d'affaires mondial. La plateforme WiFi invités de Purple s'aligne directement sur chaque exigence de conformité, de l'enregistrement du consentement à la suppression des données en un clic.

Guide de configuration SCEP d'entreprise : Authentification Wi-Fi basée sur les certificats pour l'enseignement supérieur et les grands réseaux

Ce guide fournit un schéma technique complet pour le déploiement de l'authentification WiFi basée sur les certificats à l'aide de SCEP. Il couvre la transition architecturale des clés pré-partagées vers EAP-TLS, les séquences de déploiement sur les plateformes MDM et les stratégies de mitigation des risques critiques pour les réseaux à grande échelle.