Vai al contenuto principale

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.

📖 10 minuti di lettura📝 2,314 parole🔧 2 esempi pratici4 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's 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's 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's 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.

header_image.png

Executive summary

Un Captive Portal è la pagina di accesso su un WiFi pubblico. Rappresenta anche la decisione più importante 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 copre entrambe.

L'architettura di base colloca 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 spostandolo nella 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). Questo è un requisito PCI DSS in qualsiasi ambiente in cui i terminali di pagamento condividono l'infrastruttura fisica con il WiFi degli ospiti.

Sul fronte della conversione, 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 il rischio di dipendenza da terze parti. L'OTP via SMS offre la massima qualità dei dati ma la conversione più bassa. Il click-through è la scelta corretta per gli ambienti del settore pubblico senza obiettivi di marketing.

Purple gestisce l'infrastruttura Guest WiFi in oltre 80.000 sedi. Le linee guida contenute in questo documento riflettono i 440 milioni di accessi elaborati nel 2024 (dati interni Purple, 2024).


Technical deep-dive

Cosa fa effettivamente un Captive Portal

Un Captive Portal intercetta le richieste HTTP e HTTPS dopo che un dispositivo si associa a un SSID. L'access point colloca il dispositivo in una VLAN di quarantena, dove un firewall consente solo le query DNS e un set limitato di destinazioni pre-approvate: il walled garden. Il sistema operativo del dispositivo rileva questo stato di restrizione interrogando un URL noto (ad esempio, captive.apple.com su iOS o connectivitycheck.gstatic.com su Android). Quando l'interrogazione restituisce una risposta imprevista, il sistema operativo avvia automaticamente il portale.

L'utente si autentica. Il portale comunica il risultato al server RADIUS della rete tramite un messaggio CoA. L'access controller rimuove le restrizioni di quarantena, sposta il dispositivo nella VLAN di produzione e registra la sessione con timestamp, indirizzo MAC, identità e policy applicata. Dall'inizio alla fine, questo flusso richiede da uno a dieci secondi a seconda del metodo di autenticazione.

security_architecture_diagram.png

Network segmentation

La VLAN di quarantena non è opzionale. Senza di essa, un dispositivo non autenticato su un SSID aperto può sondare la rete interna, accedere alle interfacce di gestione o raggiungere i sistemi POS. In un ambiente rientrante nell'ambito PCI DSS (qualsiasi sede in cui i terminali di pagamento con carta condividono l'infrastruttura fisica con il WiFi degli ospiti), il Payment Card Industry Data Security Standard v4.0 richiede il completo isolamento della rete tra gli ambienti dei dati dei titolari di carta e le reti degli ospiti.

La segmentazione viene implementata a livello di access controller. Su Cisco Meraki, questa viene configurata tramite Group Policies. Su HPE Aruba, tramite User Roles. Su Ruckus, tramite Zone configuration. Su Juniper Mist, tramite WLAN policies. Il principio è identico per tutti e quattro: i dispositivi non autenticati ricevono una policy restrittiva; i dispositivi autenticati ricevono una policy di produzione. Il server RADIUS applica la transizione.

Per le sedi con più tipi di utenti (ospiti, personale, appaltatori), distribuisci SSID separati, ciascuno mappato su una VLAN distinta con le proprie regole di firewall e policy di larghezza di banda. Non tentare di servire tutti i tipi di utenti da un unico SSID con un solo Captive Portal. La complessità della gestione delle policy supera qualsiasi percepita semplicità.

Proteggere il perimetro wireless

Il Captive Portal opera al Livello 7. Non crittografa il collegamento wireless. Su un SSID aperto, il traffico tra il dispositivo e l'access point non è crittografato ed è visibile a qualsiasi dispositivo nel raggio radio.

Tre approcci affrontano questo problema:

WPA3 con Captive Portal. WPA3-Personal fornisce la Simultaneous Authentication of Equals (SAE), che elimina gli attacchi con dizionario offline possibili contro WPA2-PSK. Il Captive Portal si attiva comunque per l'autenticazione, ma il collegamento wireless è crittografato. Questo è lo standard minimo accettabile per le nuove implementazioni nel 2026.

Passpoint (Hotspot 2.0) con 802.1X. Passpoint utilizza EAP-TLS o PEAP to fornire un'autenticazione basata su certificati o credenziali. Il Captive Portal gestisce l'onboarding iniziale e l'acquisizione del consenso. Alla seconda visita, Passpoint autentica il dispositivo in modo silenzioso utilizzando il profilo configurato, bypassando completamente il portale. Questa è l'architettura utilizzata da OpenRoaming, lo standard di roaming di livello carrier. Per maggiori dettagli sui metodi EAP, consulta la nostra guida a EAP Method WiFi: una guida all'accesso sicuro alla rete .

iPSK (Identity Pre-Shared Key). iPSK assegna una passphrase WPA2 o WPA3 univoca a ciascun utente o dispositivo tramite il portale. La passphrase viene memorizzata nel server RADIUS e mappata su una VLAN e una policy specifiche. Ciò fornisce crittografia e responsabilità individualizzate su un SSID condiviso, senza il sovraccarico infrastrutturale di un'implementazione 802.1X completa. È l'architettura standard per il WiFi multi-tenant negli ambienti build-to-rent e negli alloggi per studenti.

Per i dettagli sull'autenticazione basata su certificati, consulta Autenticazione con certificato WiFi: accesso sicuro alla rete .


Guida all'implementazione

Passaggio 1: Definire il walled garden

Mappa ogni dipendenza esterna richiesta per l'autenticaz" azion prima di configurare il portale. Se offri il social login con Google, inserisci nella whitelist accounts.google.com e i domini di autenticazione Google associati. Se utilizzi Stripe per l'accesso a pagamento, inserisci nella whitelist gli endpoint API di Stripe. Se utilizzi l'accesso con Apple, inserisci nella whitelist appleid.apple.com.

La mancata gestione di un walled garden accurato è la causa principale dei problemi di rendering del Captive Portal in produzione. Utilizza un validatore di walled garden per generare regole copia-incolla per il tuo controller specifico. Purple fornisce un Walled Garden Domain Validator gratuito che genera regole pronte all'uso per i controller Cisco Meraki, Ubiquiti UniFi, HPE Aruba e Catalyst.

Fase 2: Configurare l'integrazione RADIUS

Integra i tuoi controller di accesso con un provider RADIUS cloud. Configura i controller per reindirizzare il traffico non autenticato all'URL del portale e specifica i server RADIUS per l'autenticazione e l'accounting. Assicurati che i segreti condivisi RADIUS siano lunghi almeno 22 caratteri, contengano lettere maiuscole e minuscole, caratteri speciali e vengano ruotati ogni 90 giorni.

Per le distribuzioni Cisco Meraki, configura il server RADIUS in Wireless > Access Control. Per HPE Aruba, configura in Security > Authentication Servers. Per Ruckus, configura in Services > Authentication. Per Juniper Mist, configura in Network > WLAN.

Fase 3: Selezionare i metodi di autenticazione

authentication_conversion_chart.png

La tabella seguente associa il tipo di location al metodo di autenticazione consigliato e all'intervallo di conversione previsto.

Tipo di location Metodo consigliato Conversione prevista Dati acquisiti
Hotel e hospitality Acquisizione e-mail + social login 65-80% E-mail, nome, dati demografici opzionali
Retail Acquisizione e-mail 68-75% E-mail, nome
Stadi ed eventi SMS OTP 45-55% Numero di cellulare verificato
Centri congressi Social login + e-mail 60-70% E-mail, profilo professionale
Settore pubblico Click-through 90-95% Solo indirizzo MAC, timestamp
Sanità Click-through 90-95% Solo indirizzo MAC, timestamp

Fonte: dati di rete Purple, 440 milioni di accessi, 2024.

Fase 4: Progettare il flusso di consenso

Separa i termini richiesti per l'accesso alla rete dal consenso richiesto per le comunicazioni di marketing. Si tratta di due basi giuridiche distinte ai sensi del GDPR del Regno Unito (Regolamento (UE) 2016/679 come recepito nella legislazione del Regno Unito).

L'accesso alla rete può essere concesso sulla base del legittimo interesse ai sensi dell'Articolo 6(1)(f), che copre la gestione e la sicurezza della rete. Le comunicazioni di marketing richiedono il consenso esplicito ai sensi dell'Articolo 6(1)(a). Il consenso deve essere libero, specifico, informato e inequivocabile. Le caselle preselezionate non soddisfano questo standard.

Implementa due caselle di controllo distinte sul portale. La prima, obbligatoria, copre i termini di servizio e l'accesso alla rete. La seconda, facoltativa e deselezionata per impostazione predefinita, copre l'opt-in di marketing. Registra il timestamp, l'indirizzo IP, l'indirizzo MAC e lo stato del consenso per ogni sessione. Questo registro di controllo costituisce la prova di conformità in caso di indagine normativa.

Fase 5: Applicare le policy di larghezza di banda tramite VSA RADIUS

Configura il server RADIUS per restituire gli attributi specifici del fornitore (VSA, Vendor-Specific Attributes) in seguito a un'autenticazione riuscita. Le VSA indicano all'access point di applicare limiti specifici di larghezza di banda, filtri di contenuto e timeout di sessione in base al profilo dell'utente.

Su HPE Aruba, la VSA Aruba-User-Role assegna l'utente a un ruolo specifico con policy predefinite. Su Cisco Meraki, gli ID delle policy di gruppo vengono restituiti tramite l'attributo Filter-Id. Su Ruckus, l'attributo Ruckus-User-Groups mappa l'utente su un gruppo configurato. Questo meccanismo consente l'applicazione dinamica delle policy senza richiedere SSID separati per i diversi livelli di utente.


Best practice

Ottimizzazione delle conversioni

La profilazione progressiva supera la raccolta dati in un'unica sessione. Richiedi un indirizzo e-mail alla prima visita. Alla seconda visita, richiedi la data di nascita o il codice postale. Alla terza, richiedi le preferenze di marketing. Questo approccio mantiene tassi di conversione elevati, costruendo al contempo un profilo più ricco nel tempo.

Oltre l'85% delle interazioni con il Captive Portal avviene su dispositivi mobili (dati interni Purple, 2024). Progetta per schermi di piccole dimensioni. I pulsanti devono essere abbastanza grandi da poter essere toccati senza zoomare. Il testo deve essere leggibile con la dimensione del carattere predefinita. Il flusso di accesso deve completarsi in tre tocchi o meno.

Per le distribuzioni nel settore Retail , integra il portale con il tuo CRM o la tua piattaforma di fidelizzazione. Pizza Express ha utilizzato un Captive Portal personalizzato per aggiungere 3,7 milioni di ospiti al proprio CRM in due anni, trasformando ogni connessione WiFi in un opt-in di marketing verificato (dati dei clienti Purple, Pizza Express). Il portale è diventato il canale principale per l'iscrizione ai programmi fedeltà e il re-engagement promozionale.

Integrazione dell'analisi comportamentale

La sessione del Captive Portal è la chiave di unione tra l'analisi della location fisica e i sistemi di marketing digitale. Ogni sessione autenticata genera un evento di affluenza con timestamp, tempo di permanenza e stato delle visite ripetute. Integrati con WiFi Analytics , questi dati guidano l'attribuzione dell'affluenza, la segmentazione demografica e la misurazione del ROI delle campagne.

Per approfondire come i dati comportamentali delle reti WiFi informano le operazioni delle location, consulta Analisi comportamentale: approfondimenti per le reti WiFi .

Rafforzamento della sicurezza

Esegui il portale esclusivamente tramite HTTPS con un certificato TLS valido rilasciato da un'Autorità di Certificazione attendibile. I portali HTTP espongono le credenziali degli utenti all'intercettazione e attivano avvisi di sicurezza del browser che riducono le conversioni. Implementa l'HTTP Strict Transport Security (HSTS) con un max-age minimo di 31536000 secondi.

Implementa la limitazione della frequenza (rate limiting) sull'endpoint di autenticazione. Senza limitazione della frequenza, il portale è vulnerabile ad attacchi di credential stuffing e brute-force contro i codici voucher. Limita l'autetentativi di autenticazione a cinque al minuto per indirizzo IP.

Eseguire test di penetrazione sull'applicazione del portale almeno una volta all'anno. Purple possiede la certificazione ISO 27001 e la certificazione Cyber Essentials, e si sottopone regolarmente a test di penetrazione di terze parti. Per le distribuzioni nei settori Healthcare e Transport , lo standard appropriato prevede test trimestrali.


Risoluzione dei problemi e mitigazione dei rischi

Il portale non viene visualizzato

Questa è la modalità di guasto più comune. Il sistema operativo del dispositivo invia un probe di cattività a un URL noto. Se il firewall blocca quel dominio, il sistema operativo non può rilevare lo stato captive e il portale non si avvia mai automaticamente. L'utente deve navigare manualmente verso un URL non HTTPS per attivare il reindirizzamento.

Verificare innanzitutto la configurazione del walled garden. Assicurarsi che i seguenti domini siano accessibili prima dell'autenticazione: captive.apple.com, www.apple.com, connectivitycheck.gstatic.com, clients3.google.com e msftconnecttest.com. Questi sono gli URL di probe utilizzati rispettivamente da iOS, Android e Windows.

Randomizzazione dell'indirizzo MAC

iOS 14 e Android 10 hanno introdotto di default la randomizzazione dell'indirizzo MAC per rete. Un dispositivo che ritorna presenta un nuovo indirizzo MAC a ogni connessione, interrompendo la persistenza della sessione. Il portale richiede nuovamente l'autenticazione all'utente, che deve effettuare nuovamente l'accesso.

Mitigare questo problema fornendo un profilo Passpoint al primo accesso. Il profilo contiene una credenziale che il dispositivo utilizza per le connessioni successive, aggirando completamente l'identificazione basata su MAC. In alternativa, utilizzare un flusso di autenticazione basato su app che si affida a un token di identità memorizzato nell'app, anziché all'indirizzo MAC del dispositivo.

Esaurimento di DHCP e DNS su larga scala

Nelle grandi strutture (stadi, centri congressi, hub di trasporto), migliaia di dispositivi si connettono simultaneamente all'inizio di un evento o di una sessione. Se il pool DHCP è sottodimensionato, i dispositivi non possono ottenere un indirizzo IP. Se il server DNS non è in grado di gestire il volume di query, il probe di cattività fallisce e il portale non viene visualizzato.

Dimensionare il pool DHCP per le connessioni simultanee di picco, non per la media. Per uno stadio con 60.000 posti a sedere, ipotizzare 40.000 dispositivi simultanei. Allocare un pool DHCP di almeno 50.000 indirizzi con un tempo di lease breve (da 15 a 30 minuti) per riciclare rapidamente gli indirizzi. Distribuire un risolutore DNS dedicato per la rete guest, separato dall'infrastruttura DNS aziendale.

Modifiche alle API dei provider OAuth

I provider di social login modificano i termini delle loro API senza preavviso. Facebook ha progressivamente limitato i dati disponibili tramite la sua Graph API. Se il social login è l'unico metodo di autenticazione e il provider modifica i suoi termini, il portale smette di funzionare per tutti gli utenti.

Implementare sempre almeno un metodo non OAuth insieme al social login. L'acquisizione dell'e-mail è la soluzione standard di fallback. Configurare il monitoraggio sull'endpoint di autenticazione OAuth per segnalare tassi di errore elevati, che in genere precedono o coincidono con le modifiche alle API.


ROI e impatto aziendale

Il captive portal è un centro di costo se lo si valuta solo in base alla spesa per l'infrastruttura. È una risorsa di ricavo se lo si valuta in base al valore dei dati che acquisisce e ai programmi di marketing che abilita.

Una catena di vendita al dettaglio con 500 punti vendita che elabora 10.000 accessi al mese per sede, con un tasso di opt-in del 65%, genera annualmente 39 milioni di contatti CRM verificati. Con un'attribuzione prudente dei ricavi da email marketing pari a £0,10 per contatto all'anno, si ottengono £3,9 milioni di ricavi attribuibili da un singolo canale di acquisizione dati.

Per gli operatori del settore Hospitality , il portale rappresenta il primo punto di contatto nel percorso dell'ospite. Premier Inn e Whitbread utilizzano i dati del WiFi degli ospiti per definire la progettazione dei programmi di fidelizzazione e misurare la correlazione tra il coinvolgimento sul WiFi e i tassi di prenotazione ripetuta (dati dei clienti Purple, Whitbread).

Per gli operatori di trasporto, il portale fornisce dati sui flussi di passeggeri che informano il posizionamento dei punti vendita, le decisioni sul personale e le prestazioni delle concessioni. Manchester Airports Group (MAG) utilizza l'analisi WiFi per misurare il tempo di permanenza dei passeggeri per zona del terminal, correlando i dati delle sessioni WiFi con la spesa al dettaglio per passeggero (dati dei clienti Purple, MAG).

Misurare le prestazioni del portale rispetto a tre metriche: tasso di opt-in (target superiore al 60% per l'acquisizione dell'e-mail), tasso di qualità dei dati (percentuale di indirizzi e-mail che superano la verifica, target superiore all'80%) e tasso di visite ripetute (percentuale di utenti di ritorno che si autenticano senza reinserire le credenziali, target superiore al 70%).

La piattaforma WiFi Analytics di Purple fornisce queste metriche in tempo reale per tutte le sedi, con segmentazione per posizione, periodo di tempo e coorte di utenti.

Definizioni chiave

Captive portal

A web application that intercepts network traffic after a device associates with an SSID, requiring user interaction (authentication, payment, or terms acceptance) before granting internet access.

The primary mechanism for onboarding visitors onto public or guest WiFi networks. Every device that connects passes through it, making it the most consistent data capture surface in a physical venue.

Walled garden

A restricted network environment that allows access only to specific, approved IP addresses or domains prior to authentication.

Required to allow devices to reach the captive portal page, DNS servers, and necessary third-party authentication services before full internet access is granted. Misconfiguration is the leading cause of portal rendering failures.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised authentication, authorisation, and accounting management for users connecting to a network service.

The standard protocol used by captive portals to communicate with access points and controllers. Every enterprise-grade access point from Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, and Ubiquiti UniFi supports RADIUS.

Change of Authorisation (CoA)

A RADIUS extension defined in RFC 5176 that allows a server to dynamically modify the authorisation attributes of an active session.

Used by the captive portal to instruct the access controller to move a device from the quarantine VLAN to the production VLAN immediately after successful login, without requiring the device to reconnect.

Passpoint (Hotspot 2.0)

An IEEE 802.11u-based standard that enables mobile devices to automatically discover and connect to WiFi networks securely using 802.1X authentication, without manual portal interaction.

The standard approach for returning-user authentication in enterprise venues. The captive portal handles first-visit onboarding and consent capture; Passpoint handles all subsequent visits silently and securely.

VLAN (Virtual Local Area Network)

A logical subnetwork that groups devices from different physical network segments, enforcing traffic isolation at the data link layer.

Used to segment guest traffic from corporate traffic. Without VLAN segmentation, a guest device on the same physical switch as a point-of-sale terminal can probe or attack it.

iPSK (Identity Pre-Shared Key)

A security method where each user or device is assigned a unique WPA2 or WPA3 passphrase for the same SSID, stored and enforced by the RADIUS server.

Provides individualised encryption and per-user policy enforcement on a shared SSID without the infrastructure overhead of a full 802.1X deployment. Standard architecture for Multi-Tenant WiFi.

MAC address randomisation

A privacy feature in iOS 14+, Android 10+, and Windows 10+ that generates a per-network randomised MAC address to prevent cross-network device tracking.

Breaks MAC-based session persistence on captive portals. A returning device presents a new MAC address, triggering re-authentication. Mitigated by Passpoint profiles or app-based identity tokens.

Vendor-Specific Attribute (VSA)

A RADIUS attribute in the vendor-specific namespace (attribute 26) that carries hardware-vendor-specific policy instructions from the RADIUS server to the access controller.

Used to assign bandwidth limits, VLAN IDs, content filter policies, and session timeouts dynamically based on the authenticated user's profile. Each hardware vendor (Aruba, Meraki, Ruckus) defines its own VSA namespace.

Esempi pratici

A 200-room hotel using HPE Aruba access points needs tiered WiFi: basic free access for standard guests and high-speed access for loyalty members. How should the captive portal and network be configured?

Deploy a single guest SSID across the property. Configure the captive portal to integrate with the hotel's Property Management System (PMS) via API. Present two authentication options on the portal: 'Log in with Room Number and Name' and 'Log in with Loyalty Credentials'. When a loyalty member authenticates, the portal queries the PMS, verifies the tier, and sends a RADIUS CoA to the Aruba controller. The RADIUS response includes an Aruba-User-Role VSA assigning the user to a high-bandwidth role (for example, 50 Mbps down, 20 Mbps up). Standard guests receive a default rate-limited role (5 Mbps down, 2 Mbps up). Both user types connect to the same SSID and VLAN, but receive different bandwidth policies enforced by the controller.

Commento dell'esaminatore: This approach uses a single SSID, reducing channel overhead and simplifying the user experience. RADIUS VSAs handle dynamic policy enforcement without requiring separate SSIDs or complex pre-shared key management. The PMS integration ensures that loyalty status is verified in real time, preventing guests from self-selecting a higher tier.

A national retail chain with 500 locations wants to implement guest WiFi to capture email addresses for marketing. The legal team has flagged GDPR compliance concerns. How should the portal consent flow be designed?

Design a portal with a single email input field. Below the field, implement two distinct checkboxes. Checkbox 1 (mandatory, unticked by default): 'I accept the Terms of Service and Privacy Policy. I understand that my device data will be processed to provide network access.' Checkbox 2 (optional, unticked by default): 'I consent to receive marketing communications, offers, and promotions by email.' Configure the backend to log the timestamp, IP address, MAC address, and the state of both checkboxes for each session. Store this consent audit trail in a GDPR-compliant data store with a retention period aligned to the marketing programme (typically 24 months from last interaction). Integrate the email addresses from Checkbox 2 opt-ins directly into the CRM via API.

Commento dell'esaminatore: This design strictly separates the two lawful bases. Network access is granted on the basis of a contract (terms of service). Marketing communications rely on explicit consent under Article 6(1)(a) of UK GDPR. The consent audit trail is the evidence of compliance. Pre-ticked boxes, or a single checkbox covering both purposes, would constitute a compliance breach.

Domande di esercitazione

Q1. A stadium IT director reports that during halftime, the captive portal fails to load for thousands of users simultaneously, even though WiFi signal strength is strong across the venue. What is the most likely architectural bottleneck, and what is the remediation?

Suggerimento: Consider the services a device requires before it can even request the portal page. Signal strength is not the constraint.

Visualizza risposta modello

The most likely bottleneck is DHCP pool exhaustion or DNS resolver overload. When thousands of devices connect simultaneously, each must obtain an IP address via DHCP and resolve the OS captivity probe URL via DNS before the portal can load. If the DHCP pool is undersized or the DNS server cannot handle the query volume, the process stalls before the user sees anything. Remediation: size the DHCP pool for peak concurrent connections (not average), set a short lease time of 15 to 30 minutes to recycle addresses, and deploy a dedicated DNS resolver for the guest network with sufficient capacity for peak query rates.

Q2. You are deploying a captive portal in a hospital waiting room. The primary goal is providing internet access for patients and visitors. There is no marketing objective. Which authentication method should you choose, and what are the compliance implications?

Suggerimento: Balance friction against the value of the data collected. Consider what happens when you collect personal data you do not need.

Visualizza risposta modello

Click-through (terms and conditions only) is the correct choice. It delivers 90 to 95% conversion with minimal friction. Since there is no marketing objective, collecting personal data such as email addresses introduces GDPR compliance obligations (lawful basis, data minimisation, retention policies, subject access rights) without providing any business value. In a healthcare environment, the reputational risk of a data breach involving patient or visitor personal data is particularly significant. Click-through limits data collection to MAC address and timestamp, which is sufficient for network management under legitimate interest.

Q3. A retailer wants to offer Google and Apple social login on their captive portal. Their network uses Cisco Meraki access points. What network configuration is mandatory for social login to function, and what is the fallback risk?

Suggerimento: How does the device reach the identity provider before it has internet access? What happens if the provider changes its terms?

Visualizza risposta modello

You must configure the walled garden on the Meraki access controller to whitelist the authentication domains for both providers: accounts.google.com and associated Google OAuth endpoints, and appleid.apple.com and associated Apple authentication endpoints. Without these entries, the quarantine VLAN will block the OAuth request, and social login will fail silently. The fallback risk is provider API change: if Google or Apple modifies its OAuth terms or API endpoints, the authentication flow breaks for all users who rely on that method. Always deploy email capture as a parallel authentication option so users have a non-OAuth fallback.

Q4. A conference centre operator wants to use SMS OTP as the primary authentication method for a three-day event with an expected 8,000 unique logins per day. What cost implications should be modelled before committing to this method?

Suggerimento: SMS OTP has a per-message cost. Calculate the total at scale and consider the conversion rate impact.

Visualizza risposta modello

At 8,000 logins per day over three days, you are processing 24,000 SMS messages. At a typical UK carrier rate of 2 to 5 pence per message, the cost is between £480 and £1,200 for the event. If attendees are international, costs increase significantly (up to 10 to 15 pence per message for some markets). Additionally, SMS OTP conversion rates are 45 to 55%, meaning approximately 4,400 to 4,800 of the 8,000 expected logins will complete. The remaining attendees will need an alternative method. Model the per-message cost, factor in the conversion rate, and ensure a fallback method (email capture or click-through) is available for users who do not complete SMS verification.

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.

Leggi la guida →

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.

Leggi la guida →

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.

Leggi la guida →