Meilleures pratiques du Captive Portal : concevoir pour une conversion élevée et la conformité

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

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

Écouter ce guide

Voir la transcription du podcast

Welcome to the Purple Technical Briefing. Today we are dissecting captive portals. Specifically, how to optimise them for maximum network security and user conversion.

If you manage IT for a hotel group, a retail chain, or a large public venue, the captive portal is your front door. It is the intersection where network security meets marketing operations. Get it right, and you secure your network while building a first-party database of verified contacts. Get it wrong, and you frustrate users, break compliance, and leave your network exposed.

Let us start with the architecture. A captive portal is not just a web page. It is a system of network segmentation. When a guest device associates with your SSID, your access point, whether that is Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist, places that device into a quarantine VLAN.

In this quarantine state, the device has no internet access. A firewall blocks everything except DNS queries and a specific list of allowed destinations, known as the walled garden. This walled garden is critical. It must include the portal URL and any external services needed for login, such as Google authentication servers or your payment gateway. If your walled garden is misconfigured, the portal will not load. It is the number one cause of failure in the field.

Once the user completes the login, the portal communicates with your RADIUS server. RADIUS stands for Remote Authentication Dial-In User Service. It is the standard protocol for centralised authentication on enterprise networks. The portal sends a Change of Authorisation message, known as a CoA. This tells the access controller: this device is authenticated, drop the quarantine. The device is then moved to the production VLAN, and internet access is granted.

This segmentation ensures that unauthenticated devices cannot probe your network or reach your point-of-sale systems. If you are operating in a PCI DSS scope environment, meaning you have card payment terminals on the same physical infrastructure, this isolation is not optional. It is a compliance requirement.

Now let us talk about conversion. The captive portal is a choke point. Every device that connects passes through it. That makes it one of the most valuable marketing surfaces in your venue. But it is also fragile. Every field you add to your login form reduces your conversion rate by roughly ten percent.

If you deploy a simple click-through portal, where the user just accepts the terms and connects, you will see conversion rates above ninety percent. But you collect almost no data. If you ask for an email address, conversion drops to around seventy percent. If you demand a full form with name, email, phone, and postcode, you will be lucky to see forty percent completion.

So you must choose the right method for your venue and your objectives. Let me walk through the five main options.

Click-through is the lowest friction option. It is right for public sector venues, NHS waiting rooms, libraries, and council buildings. You are not in the business of building marketing databases from public WiFi, and the compliance overhead of collecting personal data in that context is significant.

Email capture is the workhorse of guest WiFi marketing. It is the right default for hospitality, retail, and events. You get a directly owned email address, no dependency on third-party platforms, and a clear data trail for GDPR purposes.

Social login via OAuth, covering Google, Apple, and LinkedIn, reduces friction and returns verified data from the identity provider. It works well in consumer-facing environments. But there is a dependency risk. If a provider changes its API terms, your authentication flow breaks. Always deploy at least one non-OAuth method alongside social login.

SMS one-time passcode is the gold standard for data quality. A verified mobile number is significantly more valuable than an unverified email address for loyalty schemes and time-sensitive communications. The trade-off is lower conversion, around fifty percent, and a per-message cost. At a stadium processing fifty thousand logins per event, that is a line item you need in your business case.

Full form registration gives you the richest data but the lowest conversion. It makes sense where the data is genuinely used, such as a hotel group pre-populating guest profiles or a healthcare provider capturing patient preferences.

Now, compliance. This is where most deployments go wrong. Under GDPR, you must separate the connection from the collection. You can grant network access based on legitimate interest. But you cannot use that same justification to send marketing emails. Marketing requires explicit, affirmative consent.

Do not use pre-ticked boxes. Provide a clear, separate checkbox for marketing opt-ins. The checkbox must be unticked by default. If you bundle network access terms with marketing consent in a single checkbox, you are in breach of UK GDPR. Your legal team will be dealing with the consequences for years.

Let me give you two real-world scenarios.

First, a two-hundred-room hotel using HPE Aruba access points wants to provide tiered WiFi. Basic free access for standard guests, high-speed access for loyalty members. The right approach is a single guest SSID integrated with the Property Management System via API. The portal presents two options: log in with room number and name, or log in with loyalty credentials. When a loyalty member authenticates, the portal queries the PMS, verifies the tier, and sends a RADIUS Change of Authorisation to the Aruba controller with a vendor-specific attribute assigning the high-bandwidth role. Standard guests receive a rate-limited default role. One SSID, dynamic policy, clean user experience.

Second, a national retail chain with five hundred locations wants to capture email addresses for marketing. The legal team is concerned about GDPR. The portal design is straightforward. A single email input field. Two checkboxes below it. The first checkbox, mandatory, reads: I accept the Terms of Service and Privacy Policy for network access. The second checkbox, optional and unticked by default, reads: I consent to receive marketing communications and special offers. The backend logs the timestamp, IP address, and consent event for each user. Clean audit trail, clear lawful basis, compliant by design.

Now let us address the common failure modes.

The most frequent issue is the portal not appearing. This almost always comes down to the walled garden. The device operating system sends a captivity probe to a known URL, such as captive.apple.com for iOS devices. If your firewall blocks that domain, the OS cannot detect that it is on a captive network, and the portal never launches. Check your walled garden first, every time.

The second issue is MAC address randomisation. Modern iOS and Android devices use randomised MAC addresses by default to prevent tracking. This means a returning guest appears as a new user. The portal re-challenges them, and they have to log in again. The solution is to encourage users to install a Passpoint profile or use an app-based authentication flow that relies on an identity token rather than the MAC address.

The third issue is DHCP and DNS exhaustion at scale. In a stadium or conference centre, thousands of devices connect simultaneously. If your DHCP pool runs out of addresses, or your DNS server cannot handle the query volume, the authentication flow stalls before it even reaches the portal. Size your infrastructure for peak load, not average load.

Now for some rapid-fire questions.

Which authentication method is most GDPR-compliant? All methods can be made compliant. Click-through has the lowest overhead. The key variable is what you do with the data after collection, not which method you use to collect it.

Can I run multiple authentication methods on the same portal? Yes, and you should. Purple Verify supports all five methods simultaneously, with configuration by venue type, user device, or time of day.

Does SMS OTP work internationally? Yes, but costs vary significantly by country. Use a provider with broad international carrier coverage and budget accordingly.

What about Apple Private Relay? Private Relay can interfere with captive portal detection on iOS devices. Ensure your portal is served over HTTPS and that your captivity probe domains are whitelisted.

To summarise. Segment your traffic with VLANs and maintain a clean, accurate walled garden. Choose your authentication method based on your venue type and data objectives, not on what is easiest to deploy. Minimise form fields to maximise conversion. Separate your network access terms from your marketing consent. And plan for MAC randomisation and peak load from day one.

Purple runs captive portal infrastructure across eighty thousand venues, with four hundred and forty million logins in 2024. The frameworks in this guide reflect that operational experience. If you want to go deeper on any of these topics, the full technical reference guide is available on purple.ai.

Thank you for listening.

Points clés à retenir

✓Place every guest device in a quarantine VLAN until RADIUS authentication completes - this is the security foundation of every captive portal deployment.
✓The walled garden is the most common failure point: if OS captivity probe URLs are blocked, the portal never appears.
✓Every additional form field reduces conversion by approximately 10% - ask only for data you actively use.
✓Email capture delivers 65-80% conversion with directly owned data and is the right default for hospitality, retail, and events.
✓GDPR requires two separate, unticked checkboxes: one for WiFi access terms, one for marketing consent. Pre-ticked boxes are not valid consent.
✓Size DHCP pools and DNS resolvers for peak concurrent connections - DHCP exhaustion is the leading cause of portal failures at scale.
✓Always deploy at least one non-OAuth authentication method alongside social login to eliminate single points of failure.

Résumé analytique

Un Captive Portal est la page de connexion sur un WiFi public. C'est également votre décision de sécurité réseau la plus cruciale et, si vous gérez un programme marketing, votre surface de capture de données la plus précieuse. Ces deux objectifs (sécurité et conversion) ne sont pas contradictoires. Ils nécessitent des décisions de configuration différentes, et ce guide couvre les deux.

L'architecture de base place chaque appareil invité dans un VLAN de quarantaine jusqu'à la fin de l'authentification. Un serveur RADIUS gère la session, et un message de changement d'autorisation (CoA) libère l'appareil vers le VLAN de production. La segmentation réseau garantit que le trafic des invités n'atteint jamais l'infrastructure de l'entreprise ou les systèmes de point de vente. Dans tout environnement où les terminaux de paiement partagent l'infrastructure physique avec le WiFi invité, cette isolation est une exigence PCI DSS, et non une simple recommandation.

Du côté de la conversion, chaque champ de formulaire supplémentaire réduit les taux d'inscription de 8 à 12 %. La bonne méthode d'authentification dépend de votre type d'établissement et de vos objectifs en matière de données. La capture d'e-mails offre une conversion de 65 à 80 % avec des données détenues en propre. La connexion via les réseaux sociaux (OAuth 2.0) réduit les frictions mais introduit des dépendances vis-à-vis de tiers. Ce guide fournit le modèle technique pour équilibrer ces exigences, issu de l'expérience opérationnelle de Purple sur plus de 80 000 sites et 440 millions de connexions en 2024 (données internes de Purple).

Pour en savoir plus sur les décisions d'architecture réseau associées, consultez notre guide sur comment optimiser les Captive Portals pour une sécurité réseau maximale et une conversion utilisateur optimale .

Analyse technique approfondie

Un Captive Portal intercepte les requêtes HTTP ou HTTPS d'un appareil s'associant à votre SSID, redirigeant l'utilisateur vers une page d'accueil (splash page) avant de lui accorder l'accès à Internet. Le mécanisme sous-jacent repose sur la synergie entre la segmentation réseau et l'authentification RADIUS.

Lorsqu'un appareil se connecte, le point d'accès (qu'il s'agisse de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet) le place dans un VLAN de quarantaine. Dans cet état, le pare-feu bloque tout le trafic à l'exception des requêtes DNS et de l'accès à une liste spécifique de destinations autorisées appelée « walled garden » (jardin clos). Le walled garden doit inclure l'URL du portail et tous les services d'authentification externes (tels que Google Workspace ou Microsoft Entra ID). Si le walled garden est mal configuré et que le test de captivité du système d'exploitation (par exemple, captive.apple.com sur iOS) est bloqué, le portail ne se chargera pas. C'est le mode de défaillance le plus courant sur le terrain.

Une fois que l'utilisateur a terminé le processus de connexion, le portail communique avec votre serveur RADIUS. Le serveur envoie un message de changement d'autorisation (CoA) au contrôleur d'accès, lui demandant de lever l'état de quarantaine et de basculer l'appareil vers le VLAN de production. Cette isolation est essentielle : dans un réseau plat, un appareil invité compromis peut sonder les systèmes internes. La segmentation VLAN garantit que les appareils non authentifiés ne peuvent pas accéder aux systèmes de point de vente ou aux bases de données de l'entreprise.

Comparatif des méthodes d'authentification

Les cinq principales méthodes d'authentification des Captive Portals présentent chacune des compromis distincts en termes de taux de conversion, de qualité des données et de contraintes de conformité. Le tableau ci-dessous résume les variables clés.

Méthode	Taux de conversion	Qualité des données	Contraintes GDPR	Idéal pour
Clic unique / CGU uniquement	90-95 %	Minimale (MAC + horodatage)	Faible	Secteur public, bibliothèques, NHS
Capture d'e-mails	65-80 %	Élevée (détenue en propre)	Moyenne	Hôtellerie, commerce de détail, événements
Connexion via les réseaux sociaux (OAuth 2.0)	55-70 %	Moyenne (dépend du fournisseur)	Moyenne-Élevée	Sites grand public avec utilisateurs Google/Apple
SMS OTP	45-60 %	Très élevée (mobile vérifié)	Moyenne	Programmes de fidélité : restauration rapide, stades, commerce de détail
Formulaire d'inscription complet	30-45 %	Maximale (profil riche)	Élevée	Hôtels, santé, commerce de détail haut de gamme

Source : données opérationnelles de Purple, 440 millions de connexions en 2024.

Pour la plupart des exploitants de sites, le point de départ optimal est un portail à double méthode : la capture d'e-mails comme option principale, et la connexion Google comme option secondaire. Cette combinaison permet généralement d'atteindre des taux de conversion de 65 à 75 % tout en constituant une base de données d'e-mails détenue en propre. Vous ne dépendez pas entièrement d'un fournisseur OAuth tiers, tout en offrant une option de commodité aux utilisateurs qui la préfèrent.

Pour les établissements du secteur de l' hôtellerie qui gèrent des programmes de fidélité, ajoutez le SMS OTP comme troisième option ou faites-en la méthode principale. Le taux de conversion plus faible est acceptable car la qualité des données le justifie. Un numéro de mobile vérifié dans votre CRM a bien plus de valeur qu'une adresse e-mail non vérifiée.

Pour les déploiements dans le secteur public (municipalités, trusts du NHS, bibliothèques), le clic unique avec acceptation des conditions est le choix idéal. Les contraintes de conformité liées à la collecte de données personnelles dans le secteur public sont considérables, et l'objectif est la connectivité, non la constitution d'un CRM.

Architecture de conformité

Sous le GDPR, vous devez séparer la connexion de la collecte. Vous pouvez gaccorder l'accès au réseau sur la base de l'intérêt légitime en vertu de l'article 6(1)(f) du GDPR britannique. Vous ne pouvez pas utiliser cette même justification pour envoyer des e-mails marketing. Le marketing requiert un consentement explicite et positif en vertu de l'article 6(1)(a).

Votre portail doit comporter des cases à cocher distinctes et non pré-cochées. L'une concerne les conditions d'utilisation pour l'accès WiFi. Une seconde case, distincte, concerne le consentement marketing. Les cases pré-cochées ne constituent pas un consentement valide. Le système doit enregistrer chaque événement de consentement, en consignant qui a consenti, quand, et la version exacte de l'avis de confidentialité consultée. Cette piste d'audit constitue votre preuve de conformité en cas d'enquête réglementaire.

Pour les opérateurs du commerce de détail disposant de terminaux de paiement par carte sur site, la norme PCI DSS exige que l'environnement des données des titulaires de cartes soit isolé de tout autre trafic réseau. Une segmentation VLAN appropriée peut réduire la portée de l'audit PCI DSS de 60 à 80 % (Specgravity, 2024) et abaisser les coûts de conformité annuels.

Guide d'implémentation

Le déploiement d'un Captive Portal à la fois sécurisé et à fort taux de conversion nécessite une approche structurée. Le cadre en cinq phases suivant s'applique à toutes les plateformes matérielles.

Phase 1 - Classification du trafic. Avant de toucher à un seul port de commutateur, documentez chaque type d'appareil et classe de trafic dans votre environnement : appareils des invités, appareils du personnel, IoT, terminaux de paiement, systèmes de gestion technique du bâtiment, vidéosurveillance. Chacun nécessite un VLAN dédié.

Phase 2 - Conception du VLAN. Attribuez un ID de VLAN et un sous-réseau IP à chaque classe de trafic. Maintenez le VLAN invité sur un sous-réseau complètement distinct, sans route vers votre espace d'adressage interne. Votre pare-feu doit comporter une règle d'interdiction stricte (deny-all) entre le VLAN invité et tout élément interne, seul l'accès Internet sortant étant autorisé.

Phase 3 - Configuration du walled garden. Autorisez explicitement l'URL du portail, les domaines des fournisseurs d'identité (Google Workspace, Microsoft Entra ID, Okta) et les URL de test de captivité du système d'exploitation. Testez sur les appareils iOS, Android et Windows avant la mise en service.

Phase 4 - Politique de pare-feu. Documentez explicitement chaque flux inter-VLAN autorisé. Interdisez tout le reste par défaut. C'est là que la plupart des déploiements échouent : l'architecture VLAN n'est forte que dans la mesure où les règles de pare-feu qui l'appliquent le sont.

Phase 5 - Surveillance et validation. Déployez une surveillance réseau et validez le bon fonctionnement de la segmentation. Effectuez des tests d'intrusion périodiques ou, au minimum, utilisez un outil d'analyse depuis un appareil invité pour confirmer que vous ne pouvez pas atteindre les sous-réseaux internes.

La plateforme Guest WiFi de Purple s'intègre à tous les principaux fournisseurs de réseaux sans fil d'entreprise via les protocoles standards RADIUS et le marquage VLAN. Vous n'avez pas besoin de remplacer vos points d'accès existants. La plateforme gère le rendu du Captive Portal, la gestion du consentement et les analyses WiFi Analytics en aval sur les déploiements Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet deployments.

Bonnes pratiques

Les recommandations suivantes reflètent les modèles opérationnels observés sur l'ensemble des plus de 80 000 sites de Purple.

Minimisez les champs de formulaire. Chaque champ que vous ajoutez à votre formulaire de connexion réduit votre taux de conversion. Ne demandez que les données que vous utilisez activement. Une adresse e-mail et un prénom suffisent pour la plupart des cas d'usage marketing. La date de naissance, le code postal et le numéro de téléphone ne doivent apparaître que si votre flux de travail CRM l'exige réellement.

Séparez l'accès et le consentement marketing. Assurez-vous que votre Captive Portal comporte des cases à cocher distinctes et non pré-cochées pour les conditions d'utilisation du WiFi et l'inscription au marketing. Confondre les deux est l'erreur de conformité au GDPR la plus courante que nous observons sur le terrain.

Activez l'isolation des clients. Configurez le contrôleur d'accès pour empêcher les appareils connectés au SSID invité de communiquer directement entre eux. Cela élimine les vecteurs d'attaque de pair à pair sur le réseau invité.

Gérez la bande passante. Implémentez une limitation de débit par client (généralement 5 à 20 Mbps en débit descendant) sur le VLAN invité. Cela évite qu'un seul utilisateur ne sature la liaison montante et ne dégrade l'expérience de tous les autres.

Anticipez la randomisation des adresses MAC. Les appareils iOS et Android modernes utilisent par défaut des adresses MAC aléatoires. Un visiteur de retour apparaît comme un nouvel utilisateur, et le portail le sollicite à nouveau. Atténuez ce problème en encourageant les utilisateurs à installer un profil Passpoint ou en utilisant un flux d'authentification basé sur une application qui s'appuie sur un jeton d'identité plutôt que sur l'adresse MAC.

Limitez le nombre de SSID. Chaque SSID supplémentaire que vous diffusez consomme du temps d'antenne pour les trames de balise (beacons). Dans un site dense comptant des centaines de points d'accès, la diffusion de plus de quatre SSID par radio peut dégrader de manière mesurable le débit. Trois est l'objectif pratique : invité, entreprise, IoT.

Pour une perspective plus large sur les normes d'authentification, consultez notre guide sur EAP Method WiFi : un guide pour un accès réseau sécurisé .

Dépannage et atténuation des risques

Le problème le plus fréquent sur le terrain est le non-affichage du portail. Il s'agit presque toujours d'une erreur de configuration du walled garden. Si le pare-feu bloque le test de captivité du système d'exploitation de l'appareil, ce dernier ne peut pas détecter le réseau captif et le portail ne se lance jamais. Vérifiez d'abord vos entrées de walled garden, à chaque fois.

Le deuxième mode de défaillance courant est l'épuisement du pool DHCP. Dans les environnements à haute densité comme les stades ou les centres de conférence, des milliers d'appareils se connectent simultanément. Si votre pool DHCP manque d'adresses, le flux d'authentification s'interrompt avant que le portail ne puisse être affiché. Dimensionnez votre infrastructure pour les pics de connexions simultanées, et non pour la charge moyenne.

Un troisième risque est la dépendance à OAuth sans solution de repli. Si vous déployez la connexion via les réseaux sociaux comme unique méthode d'authentification et que le fournisseur modifie les conditions de son API, votre flux d'authentification s'interrompt. Cela s'est produit avec l'API Graph de Facebook. Déployez toujours au moins une méthode détenue en propre aux côtés de la connexion sociale.

Pour les hubs de transport et les grands lieux d'événements, un quatrième risque est la surcharge du résolveur DNS. À grande échelle, le volume de requêtes DNS lors des pics de connexion peut submerger un résolveur sous-dimensionné. Déployez une infrastructure DNS dédiée pou le VLAN invité et surveiller les taux de requêtes.

Pour les environnements de santé , une cinquième considération est l'isolation des dispositifs médicaux. Les dispositifs médicaux doivent se trouver sur un VLAN distinct du WiFi invité à usage général, conformément aux directives de NHS Digital. L'architecture du captive portal ne doit pas permettre aux appareils invités d'accéder à un sous-réseau acheminant le trafic des dispositifs médicaux.

ROI et impact commercial

Un captive portal bien conçu transforme le WiFi invité d'un centre de coûts en un actif stratégique. En collectant des données de première main (first-party), vous constituez une base de données CRM vérifiée qui alimente les programmes de fidélité et les campagnes marketing ciblées.

Le succès se mesure par deux indicateurs clés : le taux de conversion (le pourcentage d'appareils connectés qui finalisent l'authentification) et le taux d'opt-in (le pourcentage d'utilisateurs authentifiés qui consentent au marketing). Une chaîne de magasins collectant des adresses e-mail peut suivre la conversion des utilisateurs WiFi en membres du programme de fidélité et mesurer l'augmentation consécutive de la fréquentation et des dépenses.

Pour un réseau de vente au détail de 500 points de vente réalisant une collecte d'e-mails avec un taux de conversion de 70 %, 10 000 sessions WiFi quotidiennes sur l'ensemble du réseau génèrent 7 000 contacts CRM nouveaux ou existants par jour. Avec un taux de conversion e-mail-vers-visite prudent de 2 % pour les campagnes marketing, cela représente 140 visites supplémentaires en magasin par jour attribuables au canal WiFi.

De plus, une segmentation réseau appropriée réduit le périmètre des audits PCI DSS. Une segmentation adéquate peut réduire le périmètre d'audit PCI DSS de 60 à 80 % (Specgravity, 2024), abaissant ainsi les coûts de conformité annuels et atténuant le risque financier d'une violation de données. La non-conformité au GDPR entraîne des amendes pouvant aller jusqu'à 4 % du chiffre d'affaires annuel mondial, ce qui fait d'une architecture de portail conforme une mesure directe d'atténuation des risques financiers.

La plateforme de Purple est certifiée ISO 27001, GDPR, CCPA et Cyber Essentials, fournissant la documentation de conformité requise par vos équipes juridiques et d'achats. Avec un taux de disponibilité de 99,999 % sur plus de 80 000 sites, l'infrastructure est dimensionnée pour des déploiements à l'échelle de l'entreprise.

Pour aller plus loin sur les concepts réseau associés, consultez notre Définition du réseau WAN : un guide pratique pour 2026 .

Définitions clés

Captive portal

A web page that intercepts network traffic and requires user interaction - authentication or terms acceptance - before granting full internet access. Defined in IETF RFC 8952.

The primary interface for guest onboarding, security enforcement, and first-party data capture at any public or semi-public WiFi venue.

VLAN (Virtual Local Area Network)

A logical grouping of network devices that behave as if they are on a single isolated LAN, regardless of physical location. Defined in IEEE 802.1Q.

Used to segment guest traffic from corporate infrastructure. Required by PCI DSS to isolate the cardholder data environment.

Walled garden

A restricted network environment that allows access only to specific approved URLs and IP addresses before authentication completes.

Must include the portal URL, identity provider domains, and OS captivity probe URLs. Misconfiguration is the leading cause of portal failures.

RADIUS

Remote Authentication Dial-In User Service. A networking protocol providing centralised authentication, authorisation, and accounting for network access.

The backend system that verifies credentials and instructs the access point to grant or deny network access. Required for enterprise captive portal deployments.

Change of Authorisation (CoA)

A RADIUS message that dynamically alters the authorisation state of an active user session without requiring re-authentication.

Used to move a device from the quarantine VLAN to the production VLAN after successful portal login, or to revoke access when a session policy changes.

Client isolation

A wireless controller feature that prevents devices connected to the same SSID from communicating directly with each other at Layer 2.

Essential for guest networks to prevent peer-to-peer attacks and lateral movement between guest devices.

Passpoint (Hotspot 2.0)

An IEEE 802.11u-based protocol that enables devices to automatically and securely connect to WiFi networks using credentials from a service provider, without requiring manual portal interaction.

Used to overcome MAC address randomisation and provide seamless roaming across venues. Relevant for loyalty-focused deployments where session persistence matters.

PCI DSS

Payment Card Industry Data Security Standard. An information security standard for organisations that handle branded credit cards from major card schemes.

Requires strict network segmentation to isolate the cardholder data environment from guest WiFi traffic. Non-compliance carries financial penalties and loss of card processing rights.

OAuth 2.0

An open authorisation framework that enables third-party applications to obtain limited access to user accounts on an HTTP service, such as Google Workspace or Microsoft Entra ID.

Used for social login on captive portals. Reduces friction but introduces dependency on the identity provider's API terms and availability.

Exemples concrets

A 200-room hotel using HPE Aruba access points needs to provide tiered WiFi: basic free access for standard guests and high-speed access for loyalty members, without broadcasting multiple SSIDs.

Deploy a single guest SSID integrated with the Property Management System (PMS) via API. The portal presents two options: log in with room number and surname, or log in with loyalty programme credentials. When a loyalty member authenticates, the portal queries the PMS via API, verifies the tier, and sends a RADIUS Change of Authorisation (CoA) to the Aruba controller with a vendor-specific attribute (VSA) assigning the high-bandwidth role. Standard guests receive a rate-limited default role. One SSID, dynamic policy enforcement at the RADIUS layer, clean user experience with no additional RF overhead.

Commentaire de l'examinateur : This approach avoids SSID proliferation while delivering differentiated service. The key technical detail is the RADIUS VSA, which allows the controller to apply per-user bandwidth and access policies without requiring separate network segments. The PMS integration is the data source for tier verification, making the portal a genuine extension of the hotel's guest management workflow.

A national retail chain with 500 locations wants to capture email addresses for marketing across all sites, but the legal team has flagged GDPR compliance concerns about the existing portal design.

Redesign the portal with a single email input field and two distinct checkboxes. The first checkbox is mandatory and reads: 'I accept the Terms of Service and Privacy Policy for network access.' The second checkbox is optional, unticked by default, and reads: 'I consent to receive marketing communications and special offers from [Brand].' The backend logs the timestamp, IP address, portal version, and consent event for each user. The lawful basis for WiFi access is legitimate interest. The lawful basis for marketing is explicit consent. These are recorded separately in the CRM.

Commentaire de l'examinateur : The critical fix is separating the two lawful bases. Many retail deployments bundle both into a single checkbox, which is a breach of UK GDPR. The audit trail - timestamp, IP, portal version, and consent flag - is the evidence you need to respond to a Data Subject Access Request or a regulatory inquiry. Purple's platform automates this logging and provides the consent management tools to handle DSARs at scale.

Questions d'entraînement

Q1. A stadium IT director reports that during halftime, users can associate with the guest SSID but the captive portal fails to load for thousands of devices simultaneously. The walled garden has been verified as correct. What is the most likely architectural failure?

Conseil : Consider the infrastructure resources required before a device can route HTTP traffic to the portal - specifically, what happens before DNS resolution.

Voir la réponse type

DHCP pool exhaustion or DNS resolver overload. In high-density environments, if the DHCP pool cannot assign IP addresses fast enough, or the DNS resolver cannot handle the query volume from thousands of simultaneous connections, the authentication flow stalls before the portal can be served. The infrastructure must be sized for peak concurrent connections, not average load. Separate DHCP and DNS infrastructure for the guest VLAN is the recommended mitigation.

Q2. A retail marketing team wants to collect customer dates of birth via the captive portal to send birthday offers. They plan to make the DOB field mandatory to access the WiFi. Is this compliant with UK GDPR? If not, how should it be redesigned?

Conseil : Review the principles of data minimisation (Article 5(1)(c)) and the requirement for consent to be freely given.

Voir la réponse type

No. Making marketing data mandatory for service access violates the principle that consent must be freely given - a user cannot freely consent if refusal means losing access to a service. Furthermore, collecting DOB when it is not strictly necessary for network access violates the data minimisation principle. The correct design: DOB is an optional field, clearly labelled as optional, with a separate unticked checkbox for birthday marketing consent. The lawful basis for WiFi access remains legitimate interest. The lawful basis for birthday marketing is explicit consent.

Q3. A hotel's security audit reveals that a device connected to the guest WiFi can ping the IP address of a point-of-sale terminal in the restaurant. The IT team confirms that the guest network and POS network are on separate VLANs. What configuration step was missed?

Conseil : VLANs provide logical separation, but traffic between VLANs must pass through a routing device. What governs what that device allows?

Voir la réponse type

Inter-VLAN routing rules on the firewall are misconfigured or absent. While the guest traffic and POS traffic are on separate VLANs, the firewall must enforce a default-deny policy between them with explicit permit rules for only the required flows. The guest VLAN should have rules permitting only outbound internet access - no routes to any internal subnet, including the POS VLAN. The fix is to audit and correct the inter-VLAN firewall policy, then validate by attempting to reach internal subnets from a guest device.

Q4. A conference centre deploys social login (Google OAuth) as its only captive portal authentication method. Three months after launch, Google updates its OAuth API and the portal breaks for all users. How should the deployment have been architected to prevent this?

Conseil : Consider the single point of failure and what a resilient multi-method design looks like.

Voir la réponse type

The deployment should have included at least one non-OAuth authentication method as a fallback - email capture being the most practical choice. A dual-method portal with email capture as primary and Google OAuth as secondary would have maintained continuity when the OAuth flow broke. The email capture method has no third-party dependency and provides a directly owned data asset. OAuth providers should always be treated as convenience options, not primary authentication infrastructure.

Continuer la lecture de cette série

Comment configurer un Captive Portal sur Starlink : un guide pour les sites isolés et maritimes

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

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

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

Comment optimiser les Captive Portals pour une sécurité réseau maximale et une conversion utilisateur optimale

Ce guide fournit un plan technique complet pour optimiser les Captive Portals dans les établissements d'entreprise, couvrant l'architecture de segmentation réseau, la sélection des méthodes d'authentification, la conception de consentements conformes au GDPR et l'optimisation de la conversion. Il s'adresse aux responsables informatiques, architectes réseau et CTO d'hôtels, de chaînes de magasins, de stades et d'organisations du secteur public qui doivent concilier sécurité réseau et capture de données de première partie. Purple exploite une infrastructure de Captive Portal sur plus de 80 000 sites avec 440 millions de connexions en 2024, et les frameworks présentés ici reflètent cette expérience opérationnelle.