Passer au contenu principal

L'authentification EAP-TLS expliquée : la sécurité WiFi basée sur les certificats

EAP-TLS est la référence absolue en matière de sécurité WiFi d'entreprise, remplaçant l'authentification vulnérable par mot de passe par des certificats numériques robustes et mutuellement authentifiés. Ce guide propose aux responsables informatiques et aux architectes réseau une analyse technique approfondie de la liaison EAP-TLS, des exigences architecturales et des stratégies de déploiement pratiques pour les environnements d'appareils mixtes.

📖 6 min de lecture📝 1,285 mots🔧 2 exemples concrets3 questions d'entraînement📚 8 définitions clés

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans ce briefing technique de Purple. Je suis votre hôte, et aujourd'hui nous plongeons au cœur de l'authentification EAP-TLS, la référence absolue en matière de sécurité WiFi basée sur les certificats. Si vous êtes responsable informatique, architecte réseau ou CTO confronté à des environnements d'entreprise tels que des hôtels, des chaînes de magasins ou des espaces publics, cette session est faite pour vous. Nous allons expliquer ce qu'est l'EAP-TLS, comment il se compare aux méthodes plus anciennes comme le PEAP, et ce dont vous avez exactement besoin pour le déployer avec succès sur un parc d'appareils hétérogènes. Commençons par le contexte. Pourquoi parlons-nous d'EAP-TLS aujourd'hui ? Pendant des années, de nombreuses organisations se sont appuyées sur PEAP-MSCHAPv2, c'est-à-dire une authentification par identifiant et mot de passe sur le WiFi. Mais face aux menaces actuelles, les mots de passe représentent une vulnérabilité majeure. Ils peuvent être hameçonnés, partagés ou volés. C'est là qu'intervient l'EAP-TLS. EAP signifie Extensible Authentication Protocol, et TLS signifie Transport Layer Security. Ensemble, ils créent un cadre d'authentification mutuelle utilisant des certificats numériques X.509 au lieu de mots de passe. Imaginez cela comme un contrôle de passeport numérique. Le point d'accès réseau, ou l'authentificateur, demande à l'appareil son identifiant. L'appareil ne se contente pas de fournir un mot de passe ; il présente un certificat signé cryptographiquement. Mais surtout, cette démarche est mutuelle. Le serveur présente également son certificat à l'appareil. Les deux parties se vérifient mutuellement auprès d'une autorité de certification de confiance avant que tout accès au réseau ne soit accordé. Cela élimine le vol d'identifiants et rend les attaques de type "man-in-the-middle" pratiquement impossibles. Entrons maintenant dans les détails techniques. Comment fonctionne concrètement la liaison (handshake) ? Lorsqu'un appareil, appelé le suppliant, tente de se connecter, le point d'accès bloque tout le trafic à l'exception des messages EAP. Le point d'accès envoie une requête EAP-Request/Identity. L'appareil répond, et le point d'accès transmet cette réponse au serveur RADIUS. Le serveur RADIUS lance alors un tunnel TLS. Il envoie son certificat de serveur à l'appareil. L'appareil valide ce certificat. Si la vérification est concluante, l'appareil renvoie son propre certificat client dans le tunnel. Le serveur RADIUS valide le certificat client par rapport à l'autorité de certification ou au fournisseur d'identité. Une fois que les deux parties sont satisfaites, la liaison TLS est établie, un secret maître est généré pour le chiffrement, et le serveur RADIUS envoie un message Access-Accept. Le point d'accès ouvre alors le port, et l'appareil est connecté au réseau. Alors, comment cela se compare-t-il au PEAP ? Le PEAP ne requiert qu'un certificat côté serveur. Le client utilise toujours un mot de passe à l'intérieur du tunnel TLS. Cela rend le PEAP plus facile à déployer initialement, en particulier pour les appareils non gérés, mais vous laisse vulnérable à la collecte d'identifiants si un utilisateur se connecte à un point d'accès usurpé. L'EAP-TLS exige des certificats des deux côtés. Certes, son déploiement est légèrement plus complexe, mais le niveau de sécurité est infiniment supérieur. C'est pourquoi l'EAP-TLS est la norme recommandée pour la conformité PCI DSS dans le commerce de détail, et pour la norme ISO 27001 dans les environnements d'entreprise. Parlons de la mise en œuvre. Le déploiement d'EAP-TLS nécessite trois composants principaux : une infrastructure à clés publiques ou PKI pour émettre les certificats, un serveur RADIUS pour gérer l'authentification, et une plateforme de gestion des appareils mobiles ou MDM pour distribuer les certificats à vos terminaux. Si vous gérez un parc d'ordinateurs portables et de smartphones d'entreprise, votre MDM est votre meilleur allié ici. Vous configurez un profil qui pousse à la fois le certificat de l'autorité de certification racine (Root CA) et le certificat client individuel vers l'appareil, ainsi que le profil WiFi. L'utilisateur n'a rien à faire. Il lui suffit d'ouvrir son ordinateur portable pour qu'il se connecte de manière sécurisée. Cependant, il y a des pièges à éviter. Le plus important est la gestion du cycle de vie des certificats. Les certificats expirent. Si vous ne disposez pas d'un processus de renouvellement automatisé via votre MDM ou d'un protocole d'enregistrement automatisé comme SCEP ou EST, vous passerez une très mauvaise journée lorsque tous vos appareils se déconnecteront du réseau simultanément. Un autre problème courant est le redoutable « parc d'appareils mixtes ». Que faites-vous des appareils BYOD ou des invités ? Vous ne pouvez pas facilement pousser des certificats sur des appareils non gérés. Pour les invités, vous utilisez un Captive Portal, comme la solution Guest WiFi de Purple. Pour le personnel en BYOD, vous pouvez utiliser un portail d'intégration qui fournit temporairement un certificat, ou vous pouvez les maintenir sur un SSID distinct et moins privilégié en utilisant une méthode d'authentification différente. Place à une session rapide de questions-réponses basée sur les questions courantes des clients. Question un : Dois-je créer ma propre autorité de certification (CA) sur site ? Réponse : Plus maintenant. Les solutions de PKI cloud intégrées à Azure AD ou Okta sont beaucoup plus faciles à gérer et à faire évoluer. Question deux : L'EAP-TLS a-t-il un impact sur les performances d'itinérance ? Réponse : La liaison initiale (handshake) est légèrement plus lourde que celle de PEAP en raison de l'échange de certificats, mais une fois connecté, les protocoles d'itinérance rapide comme le 802.11r gèrent les transitions entre points d'accès de manière transparente. Question trois : Puis-je utiliser EAP-TLS pour les appareils IoT ? Réponse : Oui, si l'appareil prend en charge le 802.1X et l'installation de certificats. Mais de nombreux appareils IoT existants ne le font pas, c'est pourquoi vous avez souvent besoin d'un réseau séparé avec contournement d'authentification MAC (MAC Auth Bypass) ou clé pré-partagée pour ces appareils spécifiques. En résumé : EAP-TLS est la norme définitive pour un WiFi d'entreprise sécurisé. Il remplace les mots de passe vulnérables par des certificats numériques robustes et mutuellement authentifiés. Bien que la configuration initiale nécessite une coordination entre votre PKI, RADIUS et MDM, les avantages à long terme en matière de sécurité, de conformité et d'expérience utilisateur sont indéniables. Il élimine complètement le vol d'identifiants et offre une expérience de connexion transparente et sans intervention pour les appareils gérés. Merci d'avoir participé à ce briefing technique Purple. Pour en savoir plus sur la sécurisation de votre réseau et l'exploitation des analyses WiFi, visitez notre centre de ressources.

header_image.png

Résumé exécutif

Pour les environnements d'entreprise, qu'il s'agisse de sièges sociaux, de chaînes de Retail ou d'établissements de Healthcare , la sécurisation des accès sans fil n'est plus une simple exigence opérationnelle : c'est un impératif de conformité critique. Historiquement, les organisations s'appuyaient sur PEAP-MSCHAPv2, qui sécurise un nom d'utilisateur et un mot de passe au sein d'un tunnel TLS. Cependant, à une époque marquée par le vol massif d'identifiants et les attaques de phishing sophistiquées, l'authentification par mot de passe sur le WiFi représente une vulnérabilité majeure.

C'est là qu'intervient EAP-TLS (Extensible Authentication Protocol - Transport Layer Security). EAP-TLS représente la référence absolue en matière de contrôle d'accès réseau 802.1X. Au lieu de s'appuyer sur des mots de passe générés par les utilisateurs, EAP-TLS impose une authentification mutuelle à l'aide de certificats numériques X.509. L'appareil client et le serveur d'authentification doivent tous deux prouver leur identité avant qu'un accès au réseau ne soit accordé. Cette approche élimine le risque de vol d'identifiants, atténue les attaques de type "man-in-the-middle" (MitM) et offre une expérience de connexion fluide et sans intervention pour les appareils gérés. Ce guide de référence technique explore les mécanismes de la liaison (handshake) EAP-TLS, la compare aux méthodes existantes et présente une architecture de déploiement pratique pour les entreprises modernes.

Écoutez notre podcast d'information technique d'accompagnement pour un aperçu exécutif :

Analyse technique approfondie

Explication de la liaison (handshake) EAP-TLS

L'avantage fondamental d'EAP-TLS réside dans sa rigueur cryptographique. Le processus d'authentification est une conversation en plusieurs étapes entre le Supplicant (l'appareil client), l'Authentificateur (le point d'accès WiFi ou le commutateur) et le serveur d'authentification (généralement un serveur RADIUS).

eap_tls_handshake_diagram.png

  1. Initialisation : Lorsqu'un appareil tente de se connecter au SSID, le point d'accès bloque tout le trafic à l'exception des trames EAP over LAN (EAPoL). Le point d'accès envoie un EAP-Request/Identity à l'appareil.
  2. Réponse d'identité : L'appareil répond par un EAP-Response/Identity (souvent une identité externe anonyme pour des raisons de confidentialité), que le point d'accès transmet au serveur RADIUS.
  3. Établissement du tunnel TLS : Le serveur RADIUS lance la liaison TLS en envoyant un TLS ServerHello accompagné de son propre certificat numérique.
  4. Validation du serveur : L'appareil client examine le certificat du serveur. Il vérifie les dates de validité, le nom alternatif du sujet (SAN) et, surtout, s'assure que le certificat a été signé par une autorité de certification racine (CA) de confiance installée dans son magasin de confiance local.
  5. Présentation du certificat client : Une fois le serveur validé, l'appareil client renvoie son propre certificat X.509 (et éventuellement sa chaîne de certificats) au serveur RADIUS.
  6. Authentification mutuelle : Le serveur RADIUS valide le certificat du client par rapport à son intégration CA ou fournisseur d'identité (IdP). Il vérifie la révocation (via CRL ou OCSP) et valide l'identité de l'utilisateur ou de l'appareil.
  7. Dérivation de clé : Une fois la validation mutuelle réussie, la liaison TLS se termine. Les deux parties dérivent indépendamment une clé de session principale (MSK).
  8. Accès réseau : Le serveur RADIUS envoie un message RADIUS Access-Accept à l'AP, contenant la MSK. L'AP utilise cette clé pour établir les clés de chiffrement WPA2/WPA3 finales (PTK/GTK) avec le client, et ouvre le port réseau pour le trafic IP standard.

EAP-TLS vs PEAP-MSCHAPv2

Comprendre la distinction entre EAP-TLS et PEAP est essentiel pour les architectes réseau qui planifient une migration.

eap_tls_vs_peap_comparison.png

Alors que PEAP établit un tunnel TLS sécurisé (authentification côté serveur), l'authentification interne repose toujours sur MSCHAPv2, un protocole basé sur un mot de passe. Si un utilisateur se connecte à un point d'accès malveillant de type "Evil Twin" et ignore l'avertissement du certificat du serveur, son mot de passe haché peut être capturé et piraté hors ligne. EAP-TLS élimine complètement ce vecteur ; sans la clé privée correspondant au certificat client, un attaquant ne peut pas s'authentifier, même s'il possède le mot de passe de l'utilisateur.

Guide de déploiement

Le déploiement d'EAP-TLS nécessite une orchestration entre trois piliers d'infrastructure principaux : la couche réseau, la couche d'authentification et la couche de gestion des identités et des terminaux.

eap_tls_deployment_architecture.png

1. Infrastructure à clés publiques (PKI)

Vous devez disposer d'un mécanisme pour émettre et gérer les certificats X.509. Historiquement, cela signifiait déployer un environnement Microsoft Active Directory Certificate Services (AD CS) sur site. Aujourd'hui, les architectures modernes exploitent des solutions Cloud PKI intégrées à des fournisseurs d'identité (IdP) comme Azure AD, Okta ou Google Workspace. Ces CA cloud-natives simplifient le cycle de vie d'émission et de révocation.

2. Serveur d'authentification RADIUS

Le serveur RADIUS (par exemple, FreeRADIUS, Cisco ISE, Aruba ClearPass ou un RADIUS basé sur le cloud) doit être configuré pour prendre en charge EAP-TLS. Il nécessite son propre certificat de serveur, signé par une CA de confiance pour tous les appareils clients. Si vous l'intégrez à un IdP moderne, notre guide sur Okta et RADIUS : Étendre votre fournisseur d'identité à l'authentification WiFi vous sera particulièrement utile pour relier l'identité cloud au matériel réseau sur site.

3. Gestion des appareils mobiles (MDM)

Le principal obstacle au déploiement d'EAP-TLS est la distribution des certificats aux appareils clients. L'installation manuelle n'est pas viable à grande échelle. Vous devez vous appuyer sur une plateforme MDM (telle que Microsoft Intune, Jamf Pro ou VMware Workspace ONE) pour automatiser ce processus. Le profil MDM doit déployer :

  • Le certificat de la CA racine (pour faire confiance au serveur RADIUS).
  • Le certificat client individuel (souvent généré via les protocoles SCEP ou EST).
  • Le profil WiFi configuré pour utiliser WPA2/WPA3-Enterprise, EAP-TLS, et faisant spécifiquement référence aux certificats déployés.

Bonnes pratiques

  1. Automatiser la gestion du cycle de vie des certificats : Les certificats expirent. Si vous ne disposez pas d'un mécanisme de renouvellement automatique (comme SCEP/EST via MDM), les appareils se déconnecteront silencieusement du réseau à l'expiration de leur certificat, ce qui entraînera une explosion des tickets d'assistance. Définissez des périodes de validité qui équilibrent la sécurité (par exemple, 1 an) et la charge opérationnelle.
  2. Imposer une validation stricte du serveur : Configurez les profils WiFi des clients pour valider strictement le certificat du serveur RADIUS. Spécifiez les noms de serveur exacts et les CA racines de confiance dans le profil. N'autorisez pas les utilisateurs à ignorer les avertissements de certificat.
  3. Mettre en œuvre une révocation robuste : Assurez-vous que votre serveur RADIUS vérifie les listes de révocation de certificats (CRL) ou utilise le protocole OCSP (Online Certificate Status Protocol). Lorsqu'un employé s'en va ou qu'un appareil est perdu, la révocation du certificat doit immédiatement couper l'accès au réseau.
  4. Gérer un parc d'appareils hétérogène : EAP-TLS est parfait pour les appareils d'entreprise gérés. Cependant, vous serez confronté à des appareils BYOD (Bring Your Own Device) non gérés et à des appareils d'invités. Pour les invités, déployez une solution de Captive Portal robuste comme le Guest WiFi de Purple. Pour le BYOD du personnel, envisagez un portail d'intégration qui fournit temporairement un certificat, ou utilisez un SSID distinct avec une méthode d'authentification différente, isolé du réseau d'entreprise principal.

Dépannage et atténuation des risques

En cas d'échec d'EAP-TLS, les symptômes sont souvent opaques pour l'utilisateur final. L'appareil ne parvient tout simplement pas à se connecter. Les équipes informatiques doivent s'appuyer sur les journaux RADIUS pour le diagnostic.

  • Erreur : "CA inconnue" ou "Racine non approuvée" : L'appareil client ne possède pas le certificat de la CA racine qui a signé le certificat du serveur RADIUS dans son magasin de confiance. Vérifiez la charge utile du MDM.
  • Erreur : "Certificat expiré" : Le certificat client ou le certificat serveur a dépassé sa date NotAfter. Vérifiez l'automatisation du cycle de vie des certificats.
  • Erreur : "Client Certificate Not Found" : L'appareil tente une authentification EAP-TLS mais ne parvient pas à localiser un certificat valide correspondant aux critères spécifiés dans le profil WiFi. Assurez-vous que le certificat a été déployé avec succès par le MDM et que le Subject Alternative Name (SAN) correspond au format attendu (par exemple, le User Principal Name ou l'adresse MAC).
  • Désynchronisation de l'horloge (Clock Skew) : Le protocole TLS repose sur une mesure précise du temps. Si l'horloge système d'un appareil est considérablement désynchronisée par rapport au serveur RADIUS, la validation du certificat échouera car les certificats apparaîtront comme "pas encore valides" ou "expirés".

ROI et impact commercial

La transition vers EAP-TLS représente une maturation significative de la posture de sécurité d'une organisation. Le principal retour sur investissement (ROI) réside dans la réduction des risques. En éliminant l'authentification WiFi basée sur des mots de passe, vous réduisez considérablement la surface d'attaque pour le vol d'identifiants et les mouvements latéraux au sein du réseau. Cela est particulièrement critique dans les secteurs de l' Hôtellerie et les environnements d'entreprise où la segmentation du réseau est primordiale.

De plus, EAP-TLS améliore l'expérience de l'utilisateur final. Une fois configurée via le MDM, la connexion est entièrement automatisée (zero-touch). Les utilisateurs n'ont jamais besoin de mettre à jour leurs mots de passe WiFi lorsque leur mot de passe d'entreprise expire, ce qui réduit les appels au support technique liés aux problèmes de connectivité. En combinant EAP-TLS pour les appareils gérés du personnel avec des outils intelligents de WiFi Analytics et des portails captifs pour les invités, les établissements peuvent bénéficier d'un environnement sans fil sécurisé et performant, qui soutient à la fois la sécurité opérationnelle et l'engagement des clients.

Définitions clés

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

Une méthode d'authentification 802.1X qui nécessite une authentification mutuelle à l'aide de certificats numériques sur le client et le serveur, éliminant ainsi le besoin de mots de passe.

La norme la plus sécurisée pour l'authentification WiFi d'entreprise, largement exigée pour la conformité dans les environnements hautement sécurisés.

Supplicant

L'appareil client (ordinateur portable, smartphone, tablette) qui tente de se connecter au réseau sécurisé.

Le logiciel supplicant doit prendre en charge EAP-TLS et avoir accès au magasin de certificats de l'appareil.

Authentificateur

L'appareil réseau (généralement un point d'accès WiFi ou un commutateur réseau) qui facilite le processus d'authentification en transmettant les messages EAP entre le Supplicant et le serveur d'authentification.

L'AP n'effectue pas l'authentification lui-même ; il agit comme un contrôleur d'accès jusqu'à ce que le serveur RADIUS émette un Access-Accept.

Serveur RADIUS

Remote Authentication Dial-In User Service. Le serveur central qui valide les identifiants (les certificats dans le cas d'EAP-TLS) et autorise l'accès au réseau.

Le serveur RADIUS s'intègre à la PKI ou au fournisseur d'identité pour vérifier la validité et le statut de révocation du certificat client.

PKI (Public Key Infrastructure)

L'ensemble des rôles, politiques, matériels, logiciels et procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques.

Vous avez besoin d'une PKI (sur site ou basée sur le cloud) pour émettre les certificats requis pour EAP-TLS.

Certificat X.509

Un format standard pour les certificats à clé publique, des documents numériques qui associent de manière sécurisée des paires de clés cryptographiques à des identités telles que des sites web, des individus ou des organisations.

Il s'agit du « passeport numérique » utilisé dans EAP-TLS à la place d'un mot de passe.

SCEP / EST

Simple Certificate Enrollment Protocol / Enrollment over Secure Transport. Protocoles utilisés par les plateformes MDM pour automatiser la demande et l'installation de certificats sur les appareils clients.

Crucial pour le déploiement à grande échelle d'EAP-TLS, garantissant que les appareils reçoivent et renouvellent les certificats sans intervention de l'utilisateur.

Attaque Evil Twin

Un point d'accès WiFi malveillant qui se fait passer pour un réseau d'entreprise légitime afin d'intercepter les communications sans fil ou de collecter des identifiants.

EAP-TLS déjoue les attaques Evil Twin car le point d'accès malveillant ne peut pas présenter un certificat de serveur valide signé par l'autorité de certification racine (Root CA) de confiance de l'entreprise.

Exemples concrets

Une grande chaîne de [Retail](/industries/retail) comptant 500 points de vente doit sécuriser l'accès WiFi de ses tablettes de point de vente (POS) fournies par l'entreprise. Elle utilise actuellement une clé pré-partagée (PSK) unique dans tous les magasins, qui a récemment été divulguée. Elle utilise Microsoft Intune pour la gestion des appareils. Comment doit-elle sécuriser le réseau ?

  1. Déployer une PKI Cloud intégrée à son environnement Azure AD.
  2. Configurer Intune pour utiliser SCEP (Simple Certificate Enrollment Protocol) afin de générer et de pousser automatiquement des certificats d'appareil uniques vers chaque tablette POS.
  3. Pousser un nouveau profil WiFi via Intune configuré pour WPA3-Enterprise et EAP-TLS, en spécifiant le nouveau certificat client et l'autorité de certification racine (Root CA) de confiance.
  4. Configurer le serveur RADIUS central pour authentifier les tablettes sur la base de ces certificats.
  5. Une fois que toutes les tablettes s'authentifient avec succès via EAP-TLS, désactiver l'ancien SSID PSK.
Commentaire de l'examinateur : Il s'agit de l'approche optimale pour les appareils gérés. Passer d'une clé PSK globale à EAP-TLS élimine le risque qu'un seul mot de passe divulgué ne compromette l'ensemble du réseau. L'utilisation de SCEP via Intune garantit un provisionnement sans intervention (zero-touch), ce qui est essentiel pour un déploiement à l'échelle de 500 sites sans intervention informatique manuelle sur chaque site.

Un hub de [Transport](/industries/transport) (aéroport) souhaite fournir un WiFi sécurisé à son personnel opérationnel (bagagistes, sécurité) utilisant des iPads gérés, tout en séparant complètement le trafic des invités.

  1. Implémenter EAP-TLS sur un SSID dédié et masqué (par exemple, « Airport-Ops-Secure ») pour les iPads gérés, en poussant les certificats via leur plateforme MDM.
  2. S'assurer que le serveur RADIUS associe ces appareils authentifiés à un VLAN spécifique et restreint qui n'a accès qu'aux serveurs opérationnels nécessaires.
  3. Déployer un SSID ouvert distinct (par exemple, « Airport-Free-WiFi ») pour les passagers, en utilisant un Captive Portal pour l'acceptation des conditions d'utilisation et la limitation de la bande passante.
Commentaire de l'examinateur : Cela démontre une segmentation réseau appropriée. EAP-TLS fournit une authentification forte pour les appareils opérationnels critiques, tandis que le réseau invité est maintenu entièrement séparé. L'utilisation d'un SSID masqué pour les opérations ajoute une légère couche d'obscurité, mais la véritable sécurité repose sur les certificats cryptographiques.

Questions d'entraînement

Q1. Votre organisation migre de PEAP vers EAP-TLS. Pendant la phase pilote, plusieurs ordinateurs portables Windows ne parviennent pas à se connecter. Les journaux RADIUS indiquent des erreurs "Unknown CA" lors de la liaison TLS. Quelle est la cause la plus probable ?

Conseil : Pensez à la partie "mutuelle" de l'authentification mutuelle. De quoi le client a-t-il besoin pour faire confiance au serveur ?

Voir la réponse type

Les appareils clients ne disposent pas du certificat de l'autorité de certification racine (Root CA) dans leur magasin de confiance local qui a signé le certificat du serveur RADIUS. Le profil MDM doit être mis à jour pour s'assurer que la Root CA est déployée sur les appareils en même temps que le certificat client.

Q2. Un hôtel souhaite utiliser EAP-TLS pour tous les appareils, y compris les smartphones des clients, afin de garantir une sécurité maximale. Est-ce une stratégie viable ?

Conseil : Considérez le processus de provisionnement pour EAP-TLS.

Voir la réponse type

Non, ce n'est pas une stratégie viable. EAP-TLS nécessite l'installation de certificats clients sur l'appareil. Bien que cela soit facile pour les appareils d'entreprise gérés via MDM, vous ne pouvez pas contraindre des clients à installer des certificats ou des profils MDM sur leurs appareils personnels. Pour les clients, un Captive Portal (comme Purple Guest WiFi) combiné avec WPA2/WPA3-Personal (ou OWE) est la norme de l'industrie.

Q3. Vous avez déployé EAP-TLS avec succès. Un employé signale le vol de son ordinateur portable d'entreprise. Quelle est l'action technique immédiate requise pour sécuriser le réseau ?

Conseil : Comment invalider un certificat numérique avant sa date d'expiration ?

Voir la réponse type

Vous devez révoquer le certificat client associé à cet ordinateur portable spécifique au sein de votre PKI/CA. Assurez-vous que votre serveur RADIUS est configuré pour vérifier la liste de révocation de certificats (CRL) ou utiliser OCSP, afin que le certificat révoqué soit immédiatement rejeté lors de la prochaine tentative de connexion.

Continuer la lecture de cette série

Per-Device PSK par constructeur : iPSK, DPSK, MPSK et PPSK comparés (et support de WPA3)

Une comparaison complète des implémentations de per-device PSK chez Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet et Ubiquiti UniFi. Découvrez comment le WPA3-SAE impacte les stratégies de clés par appareil et quand déployer des modes de transition par rapport à une migration vers le 802.1X.

Lire le guide →

Comparatif des méthodes d'authentification par Captive Portal

Ce guide de référence technique et d'autorité évalue les compromis architecturaux, opérationnels et de conformité des cinq principales méthodes d'authentification par captive portal. Il fournit aux architectes réseau, directeurs informatiques et responsables marketing les données quantitatives et les cadres de décision nécessaires pour équilibrer la friction d'intégration des invités avec les exigences de collecte de données au sein des sites d'entreprise.

Lire le guide →

Qu'est-ce que l'authentification par adresse MAC ? Quand l'utiliser et quand l'éviter

Ce guide de référence technique faisant autorité couvre l'authentification par adresse MAC dans les environnements WiFi d'entreprise — comment fonctionne l'authentification MAC basée sur RADIUS au niveau de la couche 2, ses vulnérabilités de sécurité inhérentes (y compris le spoofing MAC et l'impact de la randomisation MAC au niveau du système d'exploitation), et les contextes opérationnels précis où elle reste un outil valable pour gérer l'IoT et les appareils sans écran (headless). Il fournit des conseils de déploiement exploitables pour les responsables informatiques et les architectes réseau dans les secteurs de l'hôtellerie, du commerce de détail, de la santé et des espaces publics, avec des exemples concrets, des cadres de décision et le contexte d'intégration pour le WiFi invité et la plateforme d'analyse de Purple.

Lire le guide →