Illustration générée par IA — visuel conceptuel.
Pourquoi “sans mot de passe Wi‑Fi” veut dire plusieurs choses
Quand on parle d’objets connectés (IoT) sur Wi‑Fi — caméras IP, contrôleurs CVC, interphonie, passerelles domotiques, supervision énergie, etc. — l’objectif est rarement “juste se connecter”. Le sujet, c’est l’exploitation et la maîtrise du risque : éviter qu’un secret partagé se retrouve partout, pouvoir retirer un équipement sans reconfigurer tout le parc, et limiter les mouvements latéraux si un appareil est compromis.
Dans ce guide, on parle d’authentification Wi‑Fi (qui a le droit de rejoindre le réseau) et, quand c’est pertinent, de l’infrastructure qui l’accompagne (par exemple 802.1X et un serveur RADIUS, qui sert à accepter/refuser une connexion et à appliquer des politiques).
Dans la pratique, “sans mot de passe” recouvre deux intentions très différentes :
- Zéro secret commun (le plus propre) : chaque appareil a une identité propre (idéalement un certificat). On révoque un appareil sans toucher aux autres.
- Zéro secret “humain” à recopier : on évite de saisir un mot de passe, mais il existe quand même un mécanisme d’enrôlement (QR code, provisionnement par un outil, clé unique par appareil…). Souvent acceptable si l’exploitation est maîtrisée.
Ce guide compare trois approches souvent mises en balance : EAP‑TLS (802.1X, certificats), WPA3‑SAE (WPA3‑Personal), et OWE (Wi‑Fi chiffré sans authentification).
Le point de départ : le risque structurel du PSK partagé
Un SSID IoT en WPA2‑PSK/WPA3‑SAE avec un seul mot de passe partagé est simple… mais fragile à long terme :
- Fuite du secret : si le mot de passe circule (prestataire, appareil revendu, sauvegarde oubliée), l’impact est potentiellement global sur le SSID.
- Révocation difficile : retirer un seul appareil peut pousser à changer le secret, donc à reconfigurer tout le parc.
- Traçabilité limitée : côté Wi‑Fi, “qui” se connecte se réduit souvent à une adresse MAC, pas à une identité robuste.
La question n’est donc pas “WPA3 est-il plus fort que WPA2 ?” mais : comment donner une identité (ou au moins un secret distinct) à chaque équipement, et comment rendre le tout exploitable dans le temps.
Option 1 — EAP‑TLS (802.1X) : l’approche “sans mot de passe” la plus propre, quand elle est supportée
Ce que c’est, en clair
Avec EAP‑TLS, l’équipement s’authentifie par certificat (plutôt que par mot de passe). Le serveur d’authentification (RADIUS/AAA) et le client utilisent un échange TLS avec certificats. La spécification EAP‑TLS décrit notamment l’usage d’échanges TLS, les attentes de validation des certificats (y compris l’usage d’Extended Key Usage côté serveur et côté client) et les aspects de révocation (support des CRL requis, OCSP recommandé, avec des contraintes spécifiques au monde Wi‑Fi avant authentification). RFC 5216
EAP‑TLS a également une version modernisée basée sur TLS 1.3, qui met à jour la RFC historique. RFC 9190
Pourquoi c’est intéressant pour une villa ou un petit hôtel
- Révocation “propre” : vous retirez (ou laissez expirer) le certificat d’un appareil → il ne se connecte plus, sans impacter les autres.
- Identité par équipement : on sait quel appareil est autorisé, et on peut structurer des politiques (profil IoT, profil supervision, etc.).
- Meilleure hygiène d’exploitation : rotation, renouvellement, inventaire et procédures deviennent possibles et auditables.
Les contraintes à accepter (et à cadrer au projet)
- Une brique RADIUS/AAA est nécessaire (intégrée à certains environnements, ou déployée à part).
- Une “mini‑PKI” est à organiser : émission, renouvellement, révocation, stockage des clés, et surtout un processus d’enrôlement adapté au parc IoT.
- Compatibilité variable côté IoT : certains équipements (notamment grand public) restent limités au PSK.
Sur le terrain, le risque principal n’est pas “la crypto” mais l’opérationnel : qu’arrive‑t‑il si un certificat expire, si le RADIUS tombe, ou si la chaîne de certificats n’est plus cohérente ? Pour une approche orientée exploitation (certificats, renouvellement, tests), voir aussi : Wi‑Fi 802.1X : éviter la panne quand un certificat expire.
Option 2 — WPA3‑SAE : robuste, mais pas “sans secret” (sauf variantes par appareil selon l’infrastructure)
Ce que WPA3‑SAE apporte
WPA3‑SAE (WPA3‑Personal) reste une authentification basée sur un secret. En revanche, SAE est conçu pour améliorer la résistance aux attaques de devinette, notamment en empêchant certaines attaques de dictionnaire hors‑ligne. La documentation Cisco résume cet objectif et décrit SAE comme résistant aux attaques hors‑ligne. Cisco — WPA3 (Catalyst 9800)
Le point clé en IoT : éviter “un seul secret pour tout le monde”
Si vous déployez WPA3‑SAE avec un seul mot de passe partagé, vous ne réglez pas le cœur du problème IoT : la compromission d’un secret a un impact large.
En revanche, certains environnements proposent des variantes de type PSK par utilisateur / par groupe / par équipement (les noms varient selon les marques). Dans la documentation Cisco, on retrouve par exemple le principe d’iPSK en WPA3‑SAE, avec intégration RADIUS, pour disposer de clés distinctes et limiter l’impact d’une compromission (mise à jour d’une clé plutôt que de tout un SSID). Cisco — WPA3 SAE iPSK
À retenir : WPA3‑SAE peut être un bon compromis pour des objets qui ne supportent pas 802.1X, à condition d’éviter le PSK unique quand votre infrastructure le permet.
Option 3 — OWE : du Wi‑Fi chiffré sans authentification (utile, mais à ne pas confondre avec un contrôle d’accès)
Ce que fait OWE
OWE (souvent présenté sous l’appellation “Enhanced Open” dans certaines documentations Wi‑Fi) vise à apporter du chiffrement sur un réseau autrement “ouvert”, sans authentifier l’utilisateur ou l’équipement. La RFC qui décrit OWE le présente comme un chiffrement opportuniste non authentifié, reposant sur un échange Diffie‑Hellman puis l’utilisation du secret dérivé avec le 4‑way handshake (au lieu d’un PSK). RFC 8110
Un texte ultérieur indique que cette RFC est mise à jour et que la maintenance et le développement futur d’OWE sont transférés au groupe de travail IEEE 802.11. RFC 9672
La documentation Cisco présente également OWE comme un mécanisme chiffrant le médium sans exiger d’identifiants utilisateur. Cisco — OWE
La limite à comprendre absolument
- OWE améliore la confidentialité radio (éviter l’écoute passive triviale sur un réseau ouvert).
- OWE n’est pas une authentification forte : il ne dit pas “cet appareil est autorisé”, il dit “la session radio est chiffrée”.
Conséquence : pour un réseau IoT “bâtiment” (caméras, contrôle d’accès, CVC), OWE est rarement le bon “réseau final”. En revanche, il peut être pertinent pour un réseau d’onboarding (provisionnement), ou pour des usages invités où l’on veut éviter un Wi‑Fi ouvert non chiffré. Pour une comparaison orientée expérience (hôtel/entreprise), voir aussi : Wi‑Fi invités : choisir entre WPA3, OWE, portail captif et 802.1X.
Comparatif : ce qui change vraiment en exploitation
| Critère (exploitation) | EAP‑TLS (802.1X) | WPA3‑SAE | OWE |
|---|---|---|---|
| Secret partagé | Non (identité/certificat) RFC 5216 | Oui par défaut (améliorable via clés distinctes selon l’infrastructure) Cisco | Non (réseau “open” chiffré) |
| Identité forte par équipement | Oui (certificat) | Variable (souvent non, sauf designs spécifiques) | Non (chiffrement opportuniste non authentifié) RFC 8110 |
| Retirer un seul équipement | Bon (révocation/expiration gérées) RFC 5216 | Moyen à bon si clés distinctes; sinon faible (PSK unique) | Faible (pas d’identité à révoquer) |
| Dépendances | RADIUS + PKI (à rendre résilients) | Faibles à moyennes (selon options, éventuel RADIUS si iPSK) | Faibles (mais ne remplace pas la segmentation) |
| Meilleur cas d’usage | Parc IoT “bâtiment” à exploiter dans la durée | IoT ne supportant pas 802.1X, avec besoin de sécurité améliorée | Invités / onboarding / “open chiffré” plutôt que “open en clair” |
Choix rapide : trois scénarios réalistes (villa, résidence, petit hôtel)
Scénario A — Vous voulez une vraie identité par appareil (et une révocation propre)
Priorité : EAP‑TLS. C’est l’option la plus cohérente quand les équipements sont “bâtiment”, installés pour durer, et qu’on accepte de cadrer une exploitation (certificats, renouvellement, tests, sauvegardes).
Scénario B — Vos objets ne supportent pas 802.1X (cas fréquent), mais vous voulez limiter l’effet domino
Priorité : WPA3‑SAE, en évitant autant que possible le PSK unique. Si votre infrastructure le permet, cherchez une approche de type clé distincte par équipement (iPSK/PPSK selon les marques), pour retirer ou faire tourner un seul secret sans tout reconfigurer. La documentation Cisco décrit par exemple l’approche iPSK en WPA3‑SAE avec RADIUS. Cisco
Scénario C — Vous cherchez surtout “pas en clair” et “zéro friction”, pour un réseau non sensible
Option : OWE, en gardant en tête que c’est du chiffrement sans authentification. C’est pertinent si vous compensez par une isolation stricte (réseau séparé, filtrage, pas d’accès aux systèmes sensibles) et si l’objectif est l’expérience plus que le contrôle d’accès. RFC 8110
Le “minimum non négociable” : authentifier, puis isoler
Quel que soit le mécanisme d’accès radio, un design IoT sain repose aussi sur l’architecture réseau :
- Séparer (SSID/VLAN/segments) : IoT ≠ privé/bureautique ≠ invités.
- Filtrer : un objet n’a généralement pas besoin d’accéder à “tout le LAN”.
- Inventorier et administrer : qui possède les accès admin, où sont les sauvegardes, comment on remplace un équipement, comment on retire un prestataire.
Sur des environnements qui s’appuient sur 802.1X/RADIUS, il est utile d’anticiper aussi les dépendances “invisibles” (adressage, noms, authentification) et les modes dégradés. Sur ce point, voir : DNS, DHCP, RADIUS : les services invisibles qui font tomber un site.
Checklist : les questions à poser avant de trancher
Côté objets connectés
- Les équipements supportent-ils réellement 802.1X / EAP‑TLS ? Avec quelles contraintes de certificats ?
- Supportent-ils WPA3‑SAE (ou uniquement WPA2) ?
- Peut-on automatiser l’enrôlement (au lieu d’une configuration manuelle fragile) ?
Côté exploitation
- Qui gère les certificats / secrets : propriétaire, intégrateur, IT de l’hôtel, prestataire infogérant ?
- Quelles procédures existent pour : remplacer un appareil, retirer un appareil, restaurer après panne, gérer une expiration ?
- Quel est le mode dégradé si le RADIUS/AAA n’est plus disponible ? (À cadrer explicitement.)
Conclusion : choisir la bonne promesse
- EAP‑TLS : le meilleur “sans mot de passe” au sens strict (identité par certificat), si vos équipements et votre exploitation peuvent l’assumer. RFC 5216 RFC 9190
- WPA3‑SAE : un bon niveau de sécurité en mode “Personal”, mais le vrai sujet IoT est d’éviter le secret unique ; certaines infrastructures documentent des variantes à clés distinctes (ex. iPSK). Cisco
- OWE : utile pour chiffrer un réseau ouvert sans friction, mais ce n’est pas une authentification forte ; à réserver à des usages où l’isolation compense l’absence d’identité. RFC 8110 RFC 9672
Si vous souhaitez valider une architecture (choix du modèle d’authentification, segmentation IoT, dépendances RADIUS/DHCP/DNS et scénario de reprise), Domocasa peut vous accompagner sur un cadrage technique orienté exploitation, adapté à une villa ou à un site hôtelier.
