Best practice per il Captive Portal: progettare per conversioni elevate e conformità

Questa guida tecnica offre a IT manager, architetti di rete e direttori operativi delle sedi un modello completo per l'implementazione di captive portal in grado di bilanciare la sicurezza di rete con un'elevata conversione degli utenti. Copre l'intera architettura, dalla segmentazione VLAN e l'autenticazione RADIUS fino alla progettazione del consenso conforme al GDPR e alla selezione del metodo di autenticazione. Tratta dall'esperienza operativa di Purple in oltre 80.000 sedi e 440 milioni di accessi nel 2024, ogni raccomandazione si basa su dati di implementazione reali.

📖 8 minuti di lettura📝 1,948 parole🔧 2 esempi pratici❓ 4 domande di esercitazione📚 9 definizioni chiave

Ascolta questa guida

Visualizza trascrizione del 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.

Punti chiave

✓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.

Sintesi operativa

Un Captive Portal è la pagina di accesso su una rete WiFi pubblica. Rappresenta inoltre la decisione più rilevante per la sicurezza della tua rete e, se gestisci un programma di marketing, la tua superficie di acquisizione dati più preziosa. I due obiettivi, sicurezza e conversione, non sono in conflitto. Richiedono decisioni di configurazione diverse e questa guida le tratta entrambe.

L'architettura di base inserisce ogni dispositivo ospite in una VLAN di quarantena fino al completamento dell'autenticazione. Un server RADIUS gestisce la sessione e un messaggio di Change of Authorisation (CoA) sblocca il dispositivo trasferendolo alla VLAN di produzione. La segmentazione della rete garantisce che il traffico degli ospiti non raggiunga mai l'infrastruttura aziendale o i sistemi POS (point-of-sale). In qualsiasi ambiente in cui i terminali di pagamento condividono l'infrastruttura fisica con il WiFi degli ospiti, questo isolamento è un requisito PCI DSS, non una raccomandazione.

Sul fronte delle conversioni, ogni campo aggiuntivo del modulo riduce i tassi di opt-in dell'8-12%. Il metodo di autenticazione corretto dipende dal tipo di sede e dagli obiettivi relativi ai dati. L'acquisizione dell'e-mail offre una conversione dal 65 all'80% con dati di proprietà diretta. Il social login tramite OAuth 2.0 riduce gli ostacoli ma introduce dipendenze da terze parti. Questa guida fornisce il modello tecnico per bilanciare questi requisiti, tratto dall'esperienza operativa di Purple in oltre 80.000 sedi e 440 milioni di accessi nel 2024 (dati interni Purple).

Per un contesto più approfondito sulle relative decisioni di architettura di rete, consulta la nostra guida su come ottimizzare i captive portal per la massima sicurezza di rete e conversione degli utenti .

Approfondimento tecnico

Un Captive Portal intercetta le richieste HTTP o HTTPS da un dispositivo che si associa al tuo SSID, reindirizzando l'utente a una splash page prima di concedere l'accesso a Internet. Il meccanismo alla base si affida alla segmentazione della rete e all'autenticazione RADIUS che lavorano in sinergia.

Quando un dispositivo si connette, l'access point (che si tratti di Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) lo inserisce in una VLAN di quarantena. In questo stato, the firewall blocca tutto il traffico ad eccezione delle query DNS e dell'accesso a un elenco specifico di destinazioni consentite noto come walled garden. Il walled garden deve includere l'URL del portale e qualsiasi servizio di autenticazione esterno (come Google Workspace o Microsoft Entra ID). Se il walled garden è configurato in modo errato e il probe di cattività del sistema operativo (ad esempio, captive.apple.com su iOS) è bloccato, il portale non si caricherà. Questa è la causa di errore più comune sul campo.

Una volta che l'utente completa il flusso di accesso, il portale comunica con il server RADIUS. Il server invia un messaggio di Change of Authorisation (CoA) all'access controller, istruendolo a rimuovere lo stato di quarantena e a spostare il dispositivo nella VLAN di produzione. Questo isolamento è fondamentale: in una rete piatta, un dispositivo ospite compromesso può sondare i sistemi interni. La segmentazione VLAN garantisce che i dispositivi non autenticati non possano raggiungere i sistemi POS o i database aziendali.

Metodi di autenticazione a confronto

I cinque principali metodi di autenticazione del Captive Portal comportano ciascuno compromessi distinti in termini di tasso di conversione, qualità dei dati e oneri di conformità. La tabella seguente riassume le variabili chiave.

Metodo	Tasso di conversione	Qualità dei dati	Oneri GDPR	Idoneità ottimale
Click-through / Solo T&C	90-95%	Minima (MAC + timestamp)	Basso	Settore pubblico, biblioteche, NHS
Acquisizione e-mail	65-80%	Alta (proprietà diretta)	Medio	Hospitality, retail, eventi
Social login (OAuth 2.0)	55-70%	Media (dipendente dal provider)	Medio-Alto	Sedi consumer con utenti Google/Apple
SMS OTP	45-60%	Molto alta (cellulare verificato)	Medio	Focalizzato sulla fidelizzazione: QSR, stadi, retail
Registrazione con modulo completo	30-45%	Massima (profilo dettagliato)	Alto	Hotel, sanità, retail di fascia alta

Fonte: dati operativi Purple, 440 milioni di accessi nel 2024.

Per la maggior parte dei gestori di sedi, il punto di partenza ottimale è un portale a doppio metodo: l'acquisizione dell'e-mail come opzione principale e l'accesso con Google come opzione secondaria. Questa combinazione consente in genere di ottenere tassi di conversione dal 65 al 75%, creando al contempo un database di e-mail di proprietà diretta. Non dipendi interamente da un provider OAuth di terze parti, ma offri un'opzione comoda per gli utenti che la preferiscono.

Per le strutture del settore hospitality che gestiscono programmi di fidelizzazione, aggiungi l'SMS OTP come terza opzione o rendilo il metodo principale. Il tasso di conversione inferiore è accettabile poiché la qualità dei dati lo giustifica. Un numero di cellulare verificato nel tuo CRM vale molto di più di un indirizzo e-mail non verificato.

Per le implementazioni nel settore pubblico (comuni, trust NHS, biblioteche), il click-through con l'accettazione dei termini è la scelta corretta. L'onere di conformità legato alla raccolta di dati personali in un contesto di settore pubblico è notevole e l'obiettivo è la connettività, non la creazione di un CRM.

Architettura di conformità

Ai sensi del GDPR, è necessario separare la connessione dalla raccolta dei dati. È possibile gconcedere l'accesso alla rete sulla base del legittimo interesse ai sensi dell'Articolo 6(1)(f) del GDPR del Regno Unito. Non è possibile utilizzare la stessa giustificazione per inviare e-mail di marketing. Il marketing richiede un consenso esplicito e affermativo ai sensi dell'Articolo 6(1)(a).

Il tuo portale deve presentare caselle di controllo separate e non selezionate. Una riguarda i termini di servizio per l'accesso WiFi. Una seconda casella di controllo distinta riguarda il consenso al marketing. Le caselle preselezionate non costituiscono un consenso valido. Il sistema deve registrare ogni evento di consenso, memorizzando chi ha acconsentito, quando e l'esatta versione dell'informativa sulla privacy visualizzata. Questo registro di controllo è la tua prova di conformità in caso di indagine normativa.

Per gli operatori del settore retail con terminali di pagamento con carta in loco, lo standard PCI DSS richiede che l'ambiente dei dati dei titolari di carta sia isolato da tutto l'altro traffico di rete. Una corretta segmentazione VLAN può ridurre l'ambito dell'audit PCI DSS dal 60 all'80% (Specgravity, 2024) e abbassare i costi di conformità annuali.

Guida all'implementazione

La distribuzione di un Captive Portal che sia al contempo sicuro e ad alto tasso di conversione richiede un approccio strutturato. Il seguente framework in cinque fasi si applica a tutte le piattaforme hardware.

Fase 1 - Classificazione del traffico. Prima di toccare una singola porta dello switch, documenta ogni tipo di dispositivo e classe di traffico nel tuo ambiente: dispositivi degli ospiti, dispositivi del personale, IoT, terminali di pagamento, sistemi di gestione dell'edificio, CCTV. Ognuno necessita di una VLAN dedicata.

Fase 2 - Progettazione della VLAN. Assegna un ID VLAN e una subnet IP a ciascuna classe di traffico. Mantieni la VLAN degli ospiti su una subnet completamente separata, senza instradamento verso lo spazio di indirizzamento interno. Il tuo firewall deve avere una regola esplicita di negazione totale (deny-all) tra la VLAN degli ospiti e tutto ciò che è interno, consentendo solo l'accesso a Internet in uscita.

Fase 3 - Configurazione del walled garden. Consenti esplicitamente l'URL del portale, i domini dei provider di identità (Google Workspace, Microsoft Entra ID, Okta) e gli URL di probe di cattività del sistema operativo. Effettua test su dispositivi iOS, Android e Windows prima della messa in servizio.

Fase 4 - Criteri del firewall. Documenta esplicitamente ogni flusso inter-VLAN consentito. Nega tutto il resto per impostazione predefinita (default-deny). È qui che la maggior parte delle distribuzioni fallisce: l'architettura VLAN è forte solo quanto le regole del firewall che la impongono.

Fase 5 - Monitoraggio e convalida. Distribuisci il monitoraggio di rete e convalida che la segmentazione funzioni. Esegui penetration test periodici o, come minimo, utilizza uno strumento di scansione da un dispositivo ospite per confermare che non sia possibile raggiungere le subnet interne.

La piattaforma Guest WiFi di Purple si integra con tutti i principali fornitori di soluzioni wireless aziendali tramite RADIUS standard e tagging VLAN. Non è necessario sostituire gli access point esistenti. La piattaforma gestisce il rendering del Captive Portal, la gestione del consenso e la WiFi Analytics a valle su distribuzioni Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.

Best practice

Le seguenti raccomandazioni riflettono i modelli operativi osservati in oltre 80.000 sedi che utilizzano Purple.

Riduci al minimo i campi del modulo. Ogni campo aggiunto al modulo di accesso riduce il tasso di conversione. Richiedi solo i dati che utilizzi attivamente. Un indirizzo e-mail e un nome sono sufficienti per la maggior parte dei casi d'uso di marketing. La data di nascita, il codice postale e il numero di telefono dovrebbero apparire solo quando il flusso di lavoro del CRM lo richiede effettivamente.

Separa il consenso all'accesso da quello al marketing. Assicurati che il tuo Captive Portal presenti caselle di controllo distinte e non selezionate per i termini del WiFi e per l'adesione al marketing. Unire le due cose è l'errore di conformità al GDPR più comune che riscontriamo sul campo.

Abilita l'isolamento dei client. Configura l'access controller per impedire ai dispositivi sul SSID ospite di comunicare direttamente tra loro. Ciò elimina i vettori di attacco peer-to-peer sulla rete ospite.

Gestisci la larghezza di banda. Implementa la limitazione della tariffa per client (in genere da 5 a 20 Mbps in downstream) sulla VLAN degli ospiti. Ciò evita che un singolo utente saturi l'uplink e peggiori l'esperienza per tutti gli altri.

Pianifica la randomizzazione dei MAC. I moderni dispositivi iOS e Android utilizzano indirizzi MAC randomizzati per impostazione predefinita. Un ospite che ritorna appare come un nuovo utente e il portale gli richiede nuovamente l'autenticazione. Mitiga questo problema incoraggiando gli utenti a installare un profilo Passpoint o utilizzando un flusso di autenticazione basato su app che si affida a un token di identità anziché all'indirizzo MAC.

Mantieni basso il numero di SSID. Ogni SSID aggiuntivo trasmesso consuma tempo di trasmissione per i frame di beacon. In una sede densamente popolata con centinaia di access point, trasmettere più di quattro SSID per radio può ridurre sensibilmente la velocità di trasmissione. Tre è l'obiettivo pratico: guest, corporate, IoT.

Per una prospettiva più ampia sugli standard di autenticazione, consulta la nostra guida su EAP Method WiFi: una guida all'accesso sicuro alla rete .

Risoluzione dei problemi e mitigazione dei rischi

Il problema più frequente riscontrato sul campo è la mancata visualizzazione del portale. Quasi sempre si tratta di un errore di configurazione del walled garden. Se il firewall blocca il probe di cattività del sistema operativo del dispositivo, il sistema operativo non può rilevare la rete captive e il portale non viene mai avviato. Controlla prima di tutto le voci del walled garden, ogni volta.

La seconda modalità di errore comune è l'esaurimento del pool DHCP. In ambienti ad alta densità come stadi o centri congressi, migliaia di dispositivi si connettono contemporaneamente. Se il pool DHCP esaurisce gli indirizzi, il flusso di autenticazione si blocca prima che il portale possa essere servito. Dimensiona la tua infrastruttura per le connessioni simultanee di picco, non per il carico medio.

Un terzo rischio è la dipendenza da OAuth senza un'alternativa (fallback). Se distribuisci il social login come unico metodo di autenticazione e il provider modifica i termini delle sue API, il flusso di autenticazione si interrompe. È successo con le Graph API di Facebook. Distribuisci sempre almeno un metodo di proprietà diretta insieme al social login.

Per gli hub di trasporto e i grandi spazi per eventi, un quarto rischio è il sovraccarico del risolutore DNS. Su larga scala, il volume delle query DNS durante gli eventi di picco di connessione può sovraccaricare un risolutore sottodimensionato. Distribuisci un'infrastruttura DNS dedicata po la VLAN ospiti e monitorare i tassi di query.

Per gli ambienti sanitari , una quinta considerazione è l'isolamento dei dispositivi clinici. I dispositivi clinici devono trovarsi su una VLAN separata rispetto al WiFi ospiti generico, in linea con le linee guida di NHS Digital. L'architettura del Captive Portal non deve consentire ai dispositivi degli ospiti di raggiungere alcuna sottorete che trasporti il traffico dei dispositivi clinici.

ROI e impatto aziendale

Un Captive Portal ben progettato trasforma il WiFi ospiti da un centro di costo a una risorsa strategica. Raccogliendo dati di prima parte, si crea un database CRM verificato che alimenta programmi di fidelizzazione e campagne di marketing mirate.

Il successo si misura attraverso due metriche principali: il tasso di conversione (la percentuale di dispositivi connessi che completano l'autenticazione) e il tasso di opt-in (la percentuale di utenti autenticati che acconsentono al marketing). Una catena retail che raccoglie indirizzi e-mail può tracciare la conversione degli utenti WiFi in membri del programma fedeltà e misurare il conseguente aumento di affluenza e spesa.

Per una rete retail di 500 punti vendita con una raccolta e-mail al 70% di conversione, 10.000 sessioni WiFi giornaliere in tutta la rete generano 7.000 contatti CRM nuovi o di ritorno al giorno. Con un tasso di conversione e-mail-visita prudenziale del 2% per le campagne di marketing, si ottengono 140 visite in negozio incrementali al giorno attribuibili al canale WiFi.

Inoltre, una corretta segmentazione della rete riduce l'ambito degli audit PCI DSS. Una corretta segmentazione può ridurre l'ambito dell'audit PCI DSS dal 60 all'80% (Specgravity, 2024), abbassando i costi di conformità annuali e mitigando il rischio finanziario di una violazione dei dati. La mancata conformità al GDPR comporta sanzioni fino al 4% del fatturato globale annuo, rendendo un'architettura di portale conforme una misura diretta di mitigazione del rischio finanziario.

La piattaforma di Purple è certificata ISO 27001, GDPR, CCPA e Cyber Essentials, fornendo la documentazione di conformità richiesta dai team legali e di approvvigionamento. Con un uptime del 99,999% in oltre 80.000 sedi, l'infrastruttura è dimensionata per implementazioni su scala enterprise.

Per ulteriori letture sui concetti di rete correlati, consulta la nostra guida Definizione di computer WAN: una guida pratica per il 2026 .

Definizioni chiave

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.

Esempi pratici

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.

Commento dell'esaminatore: 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.

Commento dell'esaminatore: 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.

Domande di esercitazione

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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?

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

Visualizza risposta modello

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.

Continua a leggere questa serie

Come configurare un Captive Portal su Starlink: una guida per sedi remote e marittime

Questa guida spiega nel dettaglio come escludere l'hardware nativo di Starlink e integrare un captive portal gestito in cloud utilizzando apparecchiature di routing aziendali. Imparerai a superare il limite del CGNAT, applicare la segmentazione VLAN, gestire i vincoli di larghezza di banda satellitare e garantire la conformità normativa.

Gestione del WiFi per gli ospiti degli hotel: integrazione di PMS, portali e standard di brand

Questa guida tecnica descrive in dettaglio come progettare reti WiFi per hotel di livello enterprise, concentrandosi sulla segmentazione VLAN, sull'integrazione PMS per la gestione automatizzata delle sessioni e sull'ottimizzazione del Captive Portal per l'acquisizione di dati conforme al GDPR.

Come ottimizzare i Captive Portal per la massima sicurezza di rete e conversione degli utenti

Questa guida fornisce un blueprint tecnico completo per ottimizzare i Captive Portal in contesti aziendali, coprendo l'architettura di segmentazione della rete, la selezione del metodo di autenticazione, la progettazione del consenso conforme al GDPR e l'ottimizzazione delle conversioni. È scritta per IT manager, architetti di rete e CTO di hotel, catene di vendita al dettaglio, stadi e organizzazioni del settore pubblico che devono bilanciare la sicurezza della rete con l'acquisizione di dati di prima parte. Purple gestisce l'infrastruttura dei Captive Portal in oltre 80.000 sedi con 440 milioni di accessi nel 2024, e i framework qui presentati riflettono tale esperienza operativa.