Un mot de passe Wi-Fi partagé ne protège rien
Dans la majorité des PME suisses de 20 à 150 employés, le Wi-Fi corporate tourne encore en WPA2-PSK ou WPA3-SAE avec une clé partagée. Ce modèle a un défaut structurel : révoquer l'accès d'un collaborateur sortant exige de changer la clé sur l'ensemble du parc — ce que personne ne fait systématiquement. EAP-TLS avec certificats individuels supprime ce problème à la source : chaque endpoint possède son propre certificat X.509, révocable en 30 secondes via l'infrastructure PKI ou le MDM, sans toucher aux autres.
Pourquoi EAP-TLS et pas PEAP-MSCHAPv2
PEAP-MSCHAPv2 reste répandu parce qu'il ne nécessite qu'un couple identifiant/mot de passe Active Directory. Son problème est connu depuis des années : il est vulnérable aux attaques de type « evil twin » où un point d'accès malveillant capture le handshake et permet une attaque hors-ligne sur le hash NTLMv2. Des outils publics réalisent cette attaque en quelques heures sur un mot de passe de complexité standard.
NIST CSF classe l'authentification mutuelle TLS comme contrôle de niveau « Protect » recommandé pour les accès réseau sensibles. Les CIS Benchmarks pour Microsoft Windows 11 (section 18.9 sur les réseaux sans fil) préconisent explicitement l'authentification par certificat pour les réseaux d'entreprise.
EAP-TLS garantit une authentification mutuelle : le serveur RADIUS présente son certificat à l'endpoint, et l'endpoint présente le sien au serveur. Pas de secret partagé. Pas de mot de passe transmis, même chiffré.
Architecture technique : les composants nécessaires
Infrastructure PKI
Une PKI à deux niveaux suffit pour une PME de moins de 500 endpoints :
- CA racine : offline, clé RSA 4096 bits ou EC P-384, stockée hors ligne (HSM ou support chiffré).
- CA intermédiaire : en ligne, émet les certificats endpoint et le certificat serveur RADIUS. Durée de vie recommandée : 5 ans pour la CA intermédiaire, 1 an pour les certificats endpoint.
Pour une PME sans compétences PKI interne, Microsoft Active Directory Certificate Services (AD CS) sur Windows Server 2019/2022, ou une CA hébergée (ex. EJBCA Community sur une VM) couvrent ce besoin. La CA racine peut être générée avec OpenSSL en 20 minutes sur un poste offline.
Serveur RADIUS
FreeRADIUS 3.2.x (Linux) ou NPS (Network Policy Server) intégré à Windows Server gèrent EAP-TLS. NPS est gratuit avec toute licence Windows Server. Configuration critique :
- Port UDP 1812 (authentification), 1813 (accounting) — ouvrir uniquement depuis les contrôleurs d'accès Wi-Fi.
- Secret partagé RADIUS entre le point d'accès et NPS : minimum 32 caractères aléatoires.
- Vérification de la CRL (Certificate Revocation List) : activer
check_crl = yesdans FreeRADIUS ou activer la vérification CRL dans NPS. Sans ça, un certificat révoqué reste valide aux yeux du serveur.
Distribution des certificats via MDM
C'est ici que le MDM devient indispensable. Distribuer manuellement des certificats sur 50 endpoints est une opération à risque d'erreur et non reproductible.
- Apple (macOS/iOS via ABM) : profil de configuration avec payload
com.apple.security.sceppointant vers votre SCEP server (Simple Certificate Enrollment Protocol). Le profil Wi-Fi associé référence le certificat via son UUID de payload. Apple Business Manager permet le déploiement zero-touch : l'endpoint reçoit son certificat avant même que l'utilisateur se connecte pour la première fois. - Windows via Autopilot + Intune : policy SCEP dans Intune (Device Configuration > SCEP Certificate). La policy déploie le certificat machine ou utilisateur selon le contexte d'authentification choisi. Pour EAP-TLS en mode machine, l'endpoint s'authentifie avant le login Windows — utile pour les GPO et les scripts de démarrage qui ont besoin du réseau.
- Android (Android Enterprise via MDM) : le MDM pousse un profil Wi-Fi avec EAP-TLS et un certificat via l'API
KeyChain. Fonctionne sur Samsung Knox, Google Pixel et la majorité des terminaux Android 10+. - Linux / FleetDM : CIS Benchmarks pour Ubuntu 22.04 recommandent
wpa_supplicantconfiguré aveckey_mgmt=WPA-EAPeteap=TLS. FleetDM peut vérifier la présence et la validité du certificat via une query osquery, mais la distribution reste manuelle ou via Ansible/Chef.
Révocation
La CRL doit être publiée à une URL accessible depuis le serveur RADIUS (pas forcément depuis Internet). OCSP (Online Certificate Status Protocol) est préférable à une CRL statique pour les parcs de plus de 100 endpoints : la réponse OCSP est instantanée, la CRL peut avoir un délai de publication de 24 à 48 heures selon la configuration.
Procédure de révocation lors d'un départ :
- RH notifie le DSI/RSSI le jour J avant 12h00.
- DSI révoque le certificat dans la CA (commande
certutil -revokesous AD CS, ou interface web EJBCA). - MDM désactive/supprime l'appareil (si terminal d'entreprise) ou envoie un wipe sélectif (BYOD).
- NPS/FreeRADIUS refuse la prochaine tentative de connexion Wi-Fi dès la prochaine vérification CRL/OCSP.
- Documenter l'action dans le registre des accès (exigence nLPD art. 8 sur les mesures techniques organisationnelles).
Cadre réglementaire suisse
La nouvelle loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose des mesures techniques et organisationnelles proportionnées à la sensibilité des données traitées (art. 8). Un réseau Wi-Fi sans authentification forte qui donne accès à des données clients, des fiches de paie ou des dossiers médicaux constitue un manquement direct à cette obligation. Le Préposé fédéral à la protection des données (PFPDT) peut ouvrir une enquête d'office sur signalement ou incident.
Pour les entités régulées par la FINMA (banques, assurances, gestionnaires de fortune), la circulaire FINMA 2023/1 « Risques opérationnels et résilience » exige une segmentation réseau et une authentification forte pour les accès aux systèmes critiques — EAP-TLS sur le Wi-Fi y contribue directement.
En cas de violation de données liée à un accès Wi-Fi non sécurisé, la notification au PFPDT doit intervenir dans les meilleurs délais (art. 24 nLPD). Le Centre national pour la cybersécurité (NCSC) recommande également de signaler les incidents à son portail pour alimenter la statistique nationale des cyberincidents.
Cas pratique : fiduciaire genevoise de 45 postes
Contexte : Cabinet fiduciaire à Genève, 45 collaborateurs, mix macOS 14 (Sonoma) et Windows 11 23H2, 8 iPhones d'entreprise. Réseau Wi-Fi Cisco Meraki MR46, Active Directory sur Windows Server 2022, licences Microsoft 365 Business Premium (inclut Intune). Pas de RSSI dédié, DSI externalisé à 20 % ETP.
Problème initial : Réseau Wi-Fi en WPA2-PSK. La clé n'a pas été changée depuis 18 mois. Trois anciens collaborateurs connaissent la clé. Les données clients (déclarations fiscales, bilans) sont accessibles via des partages SMB sur le réseau interne.
Décision : Migration vers EAP-TLS en 6 semaines, budget estimé à CHF 4'800 (3 jours DSI externalisé + licence NPS incluse dans Windows Server existant + certificats via AD CS).
Procédure déployée
- Semaine 1 — PKI : Création de la CA racine sur un poste offline (Ubuntu Live USB, OpenSSL 3.x). Génération de la CA intermédiaire sur Windows Server 2022 avec AD CS. Publication de la CRL sur un partage IIS interne (port TCP 80, accessible depuis la DMZ RADIUS). Durée : 1 jour.
- Semaine 2 — RADIUS : Activation du rôle NPS sur Windows Server 2022. Configuration du certificat serveur RADIUS (émis par la CA intermédiaire). Ajout des points d'accès Meraki comme clients RADIUS avec secret de 40 caractères. Politique réseau NPS : groupe AD « Corp-WiFi-Users », méthode EAP-TLS. Test sur 2 postes pilotes. Durée : 0,5 jour.
- Semaine 3 — Intune (Windows) : Création d'un profil SCEP dans Intune pointant vers le Network Device Enrollment Service (NDES) sur Windows Server. Profil Wi-Fi Intune avec EAP-TLS, certificat référencé. Déploiement sur le groupe pilote (5 postes Windows 11). Vérification des logs NPS : authentifications EAP-TLS réussies. Durée : 0,5 jour.
- Semaine 4 — Apple (macOS/iOS) : Création d'un profil Apple dans Intune (endpoint manager) : payload SCEP + payload Wi-Fi EAP-TLS. Déploiement via Apple Business Manager sur les 22 Mac et 8 iPhones. Validation sur macOS 14.4 : le certificat apparaît dans le trousseau système. Durée : 0,5 jour.
- Semaine 5 — Basculement : Le Meraki bascule le SSID corporate de WPA2-PSK vers WPA2-Enterprise (RADIUS). Fenêtre de maintenance : vendredi 18h00–20h00. Les endpoints Intune se reconnectent automatiquement via leur profil. Aucun appel support. Durée effective : 45 minutes.
- Semaine 6 — Vérification et documentation : Audit des logs NPS sur 5 jours : 100 % des connexions en EAP-TLS, 0 tentative PEAP résiduelle. Test de révocation : certificat d'un compte test révoqué, reconnexion refusée dans les 15 minutes (délai CRL). Documentation dans le registre des mesures techniques (exigence nLPD). Durée : 0,5 jour.
Résultat : Surface d'attaque Wi-Fi réduite à zéro pour les comptes révoqués. Le prochain départ de collaborateur prendra 5 minutes à sécuriser (révocation certificat + désactivation compte AD) contre une demi-journée de changement de clé PSK sur tout le parc auparavant.
Exceptions et cas limites
Appareils invités et BYOD non gérés
EAP-TLS s'applique au SSID corporate. Les appareils invités et le BYOD non inscrit au MDM restent sur un SSID isolé (réseau invité), idéalement en VLAN séparé sans accès au réseau interne. Ne jamais tenter de distribuer des certificats sur des appareils non gérés : la surface d'attaque sur la CA augmenterait sans bénéfice réel.
Imprimantes et IoT
Les terminaux sans support EAP-TLS (imprimantes, caméras IP, capteurs IoT) doivent être isolés sur un SSID ou VLAN dédié avec filtrage MAC et accès réseau minimal. Le filtrage MAC seul n'est pas un contrôle d'accès — il est spoofable en quelques secondes — mais il reste utile comme couche de traçabilité.
Sites distants sans serveur local
Pour un site distant de 5 à 10 personnes sans contrôleur AD local, le serveur RADIUS central peut être joignable via VPN IPsec ou SD-WAN. Latence acceptable pour EAP-TLS : moins de 300 ms aller-retour. Au-delà, envisager un serveur RADIUS secondaire en lecture seule sur le site distant (réplication NPS via AD).
SynGuard accompagne les PME romandes dans le déploiement de ces architectures MDM + PKI, de l'audit initial jusqu'à la documentation nLPD.
Checklist opérationnelle
- PKI — CA racine offline créée, clé stockée hors ligne, CA intermédiaire en ligne avec CRL publiée sur URL accessible depuis RADIUS.
- RADIUS — NPS ou FreeRADIUS configuré, vérification CRL/OCSP activée, secret RADIUS ≥ 32 caractères, ports UDP 1812/1813 restreints aux IP des points d'accès.
- MDM — Windows — Profil SCEP + profil Wi-Fi EAP-TLS déployés via Intune, certificat en mode machine pour authentification pré-login.
- MDM — Apple — Payload SCEP + payload Wi-Fi dans Apple Business Manager, certificat visible dans le trousseau système.
- MDM — Android — Profil Android Enterprise avec certificat EAP-TLS, validé sur Android 10+ minimum.
- Révocation — Procédure documentée : RH → DSI → révocation CA → suppression MDM, délai cible < 2 heures après départ.
- SSID invité — VLAN isolé sans accès réseau interne pour appareils non gérés et IoT.
- Audit logs — Logs RADIUS centralisés (SIEM ou agrégateur), revue mensuelle des authentifications anormales (heures atypiques, localisations inattendues).
- Test de révocation — Test trimestriel : révoquer un certificat de test et vérifier le refus de connexion dans le délai CRL configuré.
- Documentation nLPD — Mesures techniques consignées dans le registre des activités de traitement (art. 12 nLPD), mis à jour à chaque modification d'architecture.
Sources
- Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé en vigueur depuis le 01.09.2023, base légale pour les mesures techniques de sécurité.
- Centre national pour la cybersécurité (NCSC) — Recommandations et portail de signalement des cyberincidents pour entreprises suisses.
- Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de surveillance nLPD, procédures de notification en cas de violation de données.
- CIS Benchmarks — Center for Internet Security — Référentiels de configuration sécurisée pour Windows, macOS, Linux et équipements réseau.
- NIST Cybersecurity Framework (CSF) — Cadre de référence pour la gestion du risque cyber, contrôles d'authentification réseau.