L'impatto della randomizzazione MAC sul NAC e come superarla
Questa guida fornisce un riferimento tecnico approfondito sull'impatto della randomizzazione degli indirizzi MAC sui sistemi Network Access Control (NAC) e sulle architetture WiFi per ospiti. Spiega i meccanismi della rotazione MAC per-network e periodica su iOS, Android e Windows, e descrive in dettaglio i fallimenti a cascata che ciò provoca — dalla stanchezza del captive portal e l'esaurimento del DHCP alla rottura dell'applicazione delle policy e all'analisi inaccurata. I leader IT e gli architetti di rete troveranno strategie attuabili e neutrali rispetto al fornitore per migrare dall'autenticazione basata sul dispositivo a quella basata sull'identità utilizzando IEEE 802.1X, Passpoint (Hotspot 2.0) e OpenRoaming, con indicazioni concrete per l'implementazione in ambienti di ospitalità, vendita al dettaglio, sanità e settore pubblico.
Listen to this guide
View podcast transcript
Riepilogo Esecutivo
La randomizzazione degli indirizzi MAC — ora il comportamento predefinito su iOS 14+, Android 10+ e Windows 11 — ha fondamentalmente compromesso il modello di autenticazione basato sul dispositivo su cui i sistemi NAC aziendali hanno fatto affidamento per due decenni. Quando un dispositivo ruota il suo indirizzo MAC, la rete lo tratta come un client completamente nuovo. Le conseguenze sono immediate e operative: i captive portal costringono gli ospiti di ritorno a riautenticarsi, gli ambiti DHCP si esauriscono in ambienti ad alta densità, le policy NAC non vengono applicate e le piattaforme di analisi riportano conteggi di visitatori eccessivamente gonfiati.
Per i leader IT che gestiscono proprietà Ospitalità , complessi Vendita al Dettaglio , campus Sanità o hub Trasporto , questo non è un rischio teorico — è un problema operativo attivo che influisce sulla soddisfazione degli ospiti, sulla postura di sicurezza e sulla qualità dei dati di marketing.
La soluzione è architetturale, non cosmetica. Le reti devono migrare dall'autenticazione degli identificatori hardware (indirizzi MAC) all'autenticazione delle identità utente verificate tramite IEEE 802.1X, Passpoint (Hotspot 2.0) e OpenRoaming. Questa guida fornisce la profondità tecnica e la roadmap di implementazione per effettuare tale transizione in questo trimestre.
Approfondimento Tecnico: I Meccanismi della Randomizzazione MAC
La randomizzazione MAC non è uno standard monolitico. La sua implementazione varia significativamente tra gli ecosistemi dei dispositivi, creando sfide imprevedibili e stratificate per gli ingegneri di rete.
Come i Sistemi Operativi Gestiscono la Randomizzazione
I moderni sistemi operativi implementano la randomizzazione MAC in due modalità distinte, entrambe le quali interrompono le architetture NAC legacy:
Randomizzazione Per-Network (Comportamento Predefinito): Il dispositivo genera un indirizzo MAC unico, amministrato localmente, per ogni SSID a cui si connette. Questo indirizzo è derivato da un hash dell'SSID e da un seed specifico del dispositivo, il che significa che è stabile per quella specifica rete ma completamente diverso dal MAC hardware. Questo è il comportamento predefinito su iOS 14+, Android 10+ e Windows 11.
Rotazione Periodica (Modalità Privacy Migliorata): Funzionalità come 'Indirizzo Wi-Fi Privato' di Apple (iOS 15+) e 'Usa MAC randomizzato' di Android con protezione avanzata dal tracciamento ruoteranno l'indirizzo MAC randomizzato per un dato SSID su base giornaliera o settimanale, o dopo un periodo configurabile di inattività. Questa è la modalità più dirompente per gli ambienti aziendali.
Inoltre, i dispositivi utilizzano MAC randomizzati durante la scansione attiva (Probe Requests) — prima che avvenga qualsiasi associazione. Ciò significa che anche i motori di analisi passiva che tracciano le probe requests non possono contare in modo affidabile i dispositivi unici.
La Cascata di Fallimenti sull'Infrastruttura di Rete
Quando un dispositivo ruota il suo indirizzo MAC, la rete lo tratta come un client completamente nuovo. Questo singolo evento innesca una cascata di fallimenti architetturali su più livelli di rete:
| Modalità di Fallimento | Causa Tecnica | Impatto sul Business |
|---|---|---|
| Stanchezza del Captive Portal | Cache di sessione NAC basata su MAC; la rotazione invalida la voce della cache | Ospiti di ritorno costretti a riautenticarsi; aumento dei ticket di supporto |
| Esaurimento dell'Ambito DHCP | Ogni nuovo MAC consuma un nuovo lease IP; i vecchi lease non vengono rilasciati fino alla scadenza del TTL | Nuovi dispositivi impossibilitati a ottenere indirizzi IP; interruzione della rete per gli ospiti |
| Discrepanza Policy NAC | Policy (VLAN, rate limit, ACL) legate al MAC; il nuovo MAC non ha policy | Bypass dei controlli di sicurezza; gli ospiti potrebbero finire sulla VLAN sbagliata |
| Inflazione delle Analisi | Analisi basate sul MAC di Livello 2; un dispositivo appare come più visitatori unici | Dati di affluenza inaccurati; decisioni di marketing basate su metriche false |
| Perdita di Continuità della Sessione | Il roaming AP e il bilanciamento del carico si basano sul MAC per il passaggio di sessione | Esperienza di roaming degradata; sessioni interrotte durante il movimento |
Il Contesto dello Standard IEEE
Il bit dell'indirizzo amministrato localmente (il secondo bit meno significativo del primo ottetto) è impostato su 1 nei MAC randomizzati, distinguendoli dagli indirizzi hardware globalmente unici. Un MAC che inizia con 02:, 06:, 0A: o 0E: nel primo ottetto è definitivamente un indirizzo amministrato localmente (potenzialmente randomizzato). Gli ingegneri di rete possono usarlo per rilevare i client randomizzati a livello di server RADIUS o DHCP, sebbene il solo rilevamento non risolva il problema di autenticazione.
Per un ulteriore contesto sull'ambiente RF in cui operano questi dispositivi, consulta la nostra guida su Frequenze Wi-Fi: Una Guida alle Frequenze Wi-Fi nel 2026 .
Guida all'Implementazione: Migrare all'Architettura Centrata sull'Identità
L'unica soluzione duratura alla randomizzazione MAC è quella di disaccoppiare completamente l'autenticazione e l'applicazione delle policy dagli identificatori hardware. La seguente roadmap di implementazione in tre fasi fornisce un percorso neutrale rispetto al fornitore verso una rete centrata sull'identità.
Fase 1: Mitigazioni Immediate (Settimana 1–2)
Prima di intraprendere una migrazione architetturale completa, implementare queste mitigazioni tattiche per stabilizzare l'ambiente:
- Ridurre i Tempi di Lease DHCP: Sulle VLAN per ospiti, ridurre la durata del lease dalle tipiche 24 ore a 1–4 ore. Questo recupera gli indirizzi IP dai dispositivi transitori più velocemente e previene l'esaurimento dell'ambito. Negli stadi o nei centri congressi con elevato turnover, considerare lease di soli 30 minuti.
- Aumentare la Dimensione del Pool DHCP: Espandere l'ambito DHCP per ospiti per accogliere la domanda gonfiata dai MAC rotanti come buffer a breve termine.
- Aggiornare gli Script dell'Helpdesk: Istruire il personale di supporto che, durante la risoluzione di un problema di connessione di un ospite, deve chiedere il MAC randomizzato attuale del dispositivo per quella specific SSID (trovato nei dettagli della rete Wi-Fi), non il MAC hardware dalle impostazioni generali del dispositivo.
Fase 2: Implementare IEEE 802.1X per gli Utenti Conosciuti (Mesi 1–3)
IEEE 802.1X è la pietra angolare dell'accesso alla rete incentrato sull'identità. Invece di autenticare il dispositivo tramite il suo MAC, la rete autentica l'utente tramite credenziali, certificati o identità tokenizzate attraverso uno scambio EAP (Extensible Authentication Protocol) con un server RADIUS.
Fasi chiave di configurazione:
- Implementare un server RADIUS (ad es. FreeRADIUS, Cisco ISE, Aruba ClearPass) integrato con la directory delle identità (Active Directory, LDAP o un IdP cloud).
- Creare un SSID WPA3-Enterprise dedicato per gli utenti conosciuti (personale, ospiti registrati, membri fedeltà).
- Fornire le credenziali 802.1X tramite una soluzione di Mobile Device Management (MDM) per i dispositivi aziendali, o tramite un portale di onboarding self-service per BYOD e ospiti registrati.
- Aggiornare le policy NAC per applicare l'assegnazione VLAN, gli ACL e i limiti di velocità basati sugli attributi RADIUS (ad es.
Tunnel-Private-Group-IDper l'assegnazione VLAN) piuttosto che sugli indirizzi MAC.
Fase 3: Implementare Passpoint e OpenRoaming per gli Ospiti Temporanei (Mesi 3–6)
Per gli ospiti temporanei — visitatori di hotel, acquirenti al dettaglio, partecipanti a eventi sportivi — la gestione individuale delle credenziali 802.1X è impraticabile. Passpoint (Hotspot 2.0 / IEEE 802.11u) risolve questo problema consentendo un'autenticazione senza interruzioni, automatizzata e crittografata senza un captive portal.
Passpoint consente a un dispositivo di scoprire automaticamente una rete compatibile e di autenticarsi utilizzando le credenziali fornite da un Identity Provider (IdP) affidabile. L'utente non vede mai una pagina di login.
Il ruolo di Purple come Identity Provider: La piattaforma Guest WiFi di Purple funge da identity provider gratuito per servizi come OpenRoaming con la licenza Connect. Quando un ospite si autentica tramite un captive portal o un'app fedeltà basata su Purple in una sede, Purple gli fornisce le credenziali Passpoint. Nelle visite successive a qualsiasi sede abilitata OpenRoaming nella federazione, il dispositivo si connette automaticamente e in modo sicuro — con l'identità dell'utente verificata al Layer 7, indipendentemente dal suo indirizzo MAC.
Questa architettura si integra anche direttamente nella piattaforma WiFi Analytics , dove il numero di visitatori, i tempi di permanenza e i tassi di ritorno sono calcolati da identità verificate piuttosto che da indirizzi MAC effimeri.
Best Practice per la Distribuzione Enterprise
Le seguenti best practice, indipendenti dal fornitore, si applicano a tutte le scale di distribuzione:
Scollegare la Policy dagli Indirizzi MAC: Verificare ogni policy NAC nel proprio ambiente. Qualsiasi policy che faccia riferimento a un indirizzo MAC specifico o a un gruppo di dispositivi basato su MAC deve essere migrata per fare riferimento a un attributo di identità utente (nome utente RADIUS, gruppo Active Directory, CN del certificato). Questo è un prerequisito non negoziabile per una rete resiliente alla randomizzazione MAC.
Segmentare i Dispositivi IoT Separatamente: La maggior parte dei dispositivi IoT enterprise (lettori di controllo accessi, controller HVAC, segnaletica digitale) non implementa la randomizzazione MAC. Tuttavia, dovrebbero essere isolati su una VLAN dedicata utilizzando l'autenticazione basata su MPSK o certificati piuttosto che il MAC Authentication Bypass (MAB), che rimane vulnerabile allo spoofing. Per un trattamento dettagliato di questo argomento, consultare la nostra guida su Gestione della sicurezza dei dispositivi IoT con NAC e MPSK (también disponible en español: Gestión de la seguridad de dispositivos IoT con NAC y MPSK ).
Adottare WPA3 come Base: WPA3-Personal (SAE) e WPA3-Enterprise offrono una protezione significativamente più forte rispetto a WPA2 e sono richiesti per le implementazioni Passpoint R3. Assicurarsi che il firmware del punto di accesso e i supplicanti client supportino WPA3 prima di iniziare la Fase 3.
Convalidare la Registrazione della Conformità: Ai sensi del GDPR e del PCI DSS, è necessario essere in grado di attribuire l'attività di rete a un utente o dispositivo specifico. Un sistema di logging basato su MAC non è più sufficiente. Assicurarsi che la propria infrastruttura SIEM e di logging acquisisca le identità degli utenti autenticati dai record di accounting RADIUS, non solo gli indirizzi MAC dai log DHCP.
Per un contesto sulle decisioni di networking enterprise correlate, consultare la nostra guida su SD-WAN vs MPLS: La Guida alla Rete Enterprise 2026 e il nostro primer su BLE Low Energy Spiegato per l'Enterprise .
Risoluzione dei Problemi e Mitigazione del Rischio
Modalità di Guasto Comuni e Risoluzioni
Sintomo: Pool DHCP esaurito durante le ore di punta nonostante il normale afflusso. Diagnosi: Controllare i log di lease DHCP per più lease assegnati allo stesso dispositivo fisico (identificabile correlando con i log di associazione AP). Se un singolo dispositivo ha consumato più di 3 lease in 24 ore, la rotazione MAC è confermata. Risoluzione: Ridurre immediatamente i tempi di lease. Implementare la Fase 2 (802.1X) per gli utenti ad alta frequenza per stabilizzare la loro identità.
Sintomo: Ospiti di ritorno reindirizzati ripetutamente al captive portal. Diagnosi: La cache della sessione NAC è basata sul MAC. Confermare verificando se il MAC attuale dell'ospite corrisponde al MAC memorizzato nella cache della sua ultima sessione. Risoluzione: Implementare Passpoint per gli ospiti di ritorno tramite un'app fedeltà o il provisioning del profilo. Questa è l'unica soluzione permanente.
Sintomo: I report di Analytics mostrano un numero di visitatori unici 3 volte superiore all'atteso. Diagnosi: La piattaforma di analytics sta contando gli indirizzi MAC unici piuttosto che le sessioni autenticate uniche. Risoluzione: Migrare gli analytics per basarsi sui dati di identità del Layer 7 dai log di autenticazione del captive portal o dall'accounting RADIUS. Abbandonare completamente il conteggio dei visitatori basato su MAC.
Sintomo: Il dispositivo IoT perde l'assegnazione VLAN dopo un'apparente riconnessione. Diagnosi: Confermare se il firmware del dispositivo IoT implementa la randomizzazione MACizzazione (rara ma presente in alcuni dispositivi IoT di livello consumer distribuiti in ambienti aziendali). Risoluzione: Migrare l'autenticazione IoT a MPSK o 802.1X basata su certificati. Non fare affidamento su MAB per alcun dispositivo che possa implementare la randomizzazione.
ROI e Impatto sul Business
Affrontare la randomizzazione MAC non è un centro di costo — è un abilitatore di ricavi e conformità.
Riduzione dei Costi Operativi: L'eliminazione dei ticket di supporto relativi al captive portal offre risparmi immediati. Per una grande catena alberghiera con 200 proprietà, la riduzione delle chiamate di supporto WiFi per gli ospiti anche solo del 30% può rappresentare decine di migliaia di sterline in riduzione annuale dei costi di helpdesk.
Qualità dei Dati di Marketing: Analisi accurate dei visitatori basate sull'identità migliorano direttamente il ROI delle campagne di marketing. Quando i dati di affluenza si basano su identità verificate anziché su MAC rotanti, i calcoli del tasso di conversione, l'analisi del tempo di permanenza e l'attribuzione delle visite di ritorno diventano input affidabili per le decisioni aziendali.
Garanzia di Conformità: Il GDPR richiede che il trattamento dei dati sia legato a individui identificabili con il consenso appropriato. Un sistema basato su MAC non può collegare in modo affidabile l'attività di rete a una persona specifica. Un sistema incentrato sull'identità con autenticazione verificata fornisce la traccia di audit richiesta per la conformità GDPR e la registrazione della segmentazione di rete PCI DSS.
Esperienza degli Ospiti e Ricavi: Nel settore dell'ospitalità, una connessione Wi-Fi automatica e senza attriti (tramite Passpoint) è sempre più un fattore di differenziazione competitivo. Hotel e strutture che eliminano il captive portal per gli ospiti di ritorno riportano punteggi di soddisfazione degli ospiti misurabilmente più alti e un aumento del tempo di permanenza — entrambi correlati a maggiori ricavi accessori per visita.
Key Definitions
MAC Address Randomization
A privacy feature in modern operating systems (iOS 14+, Android 10+, Windows 11) where a device generates a locally administered, temporary MAC address instead of using its burned-in hardware address when connecting to or scanning for Wi-Fi networks. The randomized address may be per-network (stable for a given SSID) or periodically rotated.
IT teams encounter this when devices fail to bypass captive portals on return visits, when analytics platforms report inflated unique visitor counts, or when DHCP scopes exhaust unexpectedly in high-density environments.
Network Access Control (NAC)
A security framework and associated technology that enforces policy on devices attempting to access a network, determining the level of access granted based on device identity, posture (compliance state), and user credentials. Common NAC platforms include Cisco ISE, Aruba ClearPass, and Forescout.
NAC systems traditionally relied on MAC addresses for device profiling, policy enforcement, and session tracking — a paradigm that MAC randomization has fundamentally undermined.
Captive Portal
A web page that intercepts a user's HTTP traffic and requires interaction (login, terms acceptance, or payment) before granting network access. Captive portals typically use MAC address caching to recognise returning users and bypass re-authentication.
MAC randomization breaks the 'Remember Me' functionality of captive portals, as the returning device presents a new MAC address that does not match the cached session.
IEEE 802.1X
An IEEE standard for port-based Network Access Control that provides an authentication mechanism for devices connecting to a LAN or WLAN. It uses the Extensible Authentication Protocol (EAP) to authenticate users or devices against a RADIUS server, binding network access to a verified identity rather than a hardware address.
802.1X is the primary architectural solution to MAC randomization for enterprise environments, shifting authentication from the device layer to the identity layer.
Passpoint (Hotspot 2.0 / IEEE 802.11u)
A Wi-Fi Alliance certification programme and associated IEEE standard that enables devices to automatically discover, select, and authenticate to Wi-Fi networks using credentials provided by a trusted Identity Provider, without user interaction or captive portal redirection.
Passpoint is the recommended solution for eliminating MAC-dependent captive portals for transient guest populations in hospitality, retail, and public venues.
OpenRoaming
A Wireless Broadband Alliance (WBA) federation of Wi-Fi networks and identity providers that enables devices to seamlessly and securely connect to participating networks globally, using their existing cellular, enterprise, or social credentials.
Purple acts as an identity provider for OpenRoaming under the Connect licence, allowing venues to offer automatic, secure guest Wi-Fi access while maintaining identity visibility for analytics and compliance.
DHCP Scope Exhaustion
A network condition where a DHCP server has assigned all available IP addresses in its configured pool and cannot service new DHCP requests, causing new clients to fail to obtain network connectivity.
A direct operational symptom of MAC randomization in high-density environments. A single physical device rotating its MAC address can consume multiple IP leases, rapidly depleting the available pool.
Layer 7 Identity Binding
The process of associating network activity, session data, and analytics with a specific authenticated user identity at the application layer (Layer 7 of the OSI model), rather than relying on network-layer identifiers such as MAC addresses (Layer 2) or IP addresses (Layer 3).
Essential for accurate Wi-Fi analytics, GDPR-compliant session logging, and reliable NAC policy enforcement in a post-MAC randomization network architecture.
Locally Administered Address (LAA)
A MAC address in which the second-least-significant bit of the first octet (the 'U/L' bit) is set to 1, indicating the address has been assigned by software rather than the hardware manufacturer. Randomized MAC addresses are always locally administered addresses.
Network engineers can detect randomized clients at the RADIUS or DHCP server by checking for the LAA bit. First octets of 02, 06, 0A, or 0E indicate a locally administered address.
Worked Examples
A 500-store retail chain is experiencing DHCP pool exhaustion during peak weekend trading hours. The network team has not increased footfall, but DHCP logs show the guest VLAN scope is consistently exhausted by midday on Saturdays. The current lease time is 24 hours.
Step 1 — Confirm the root cause: Pull DHCP lease logs and cross-reference with AP association logs. Look for multiple leases assigned to the same physical device within a 24-hour window. If a device appears with 3+ different MAC addresses in a single day, MAC rotation is confirmed as the primary driver.
Step 2 — Immediate mitigation: Reduce DHCP lease times on the guest VLAN from 24 hours to 2 hours. This reclaims IP addresses from transient shoppers and rotating MACs significantly faster. Also expand the DHCP pool size as a buffer.
Step 3 — Medium-term fix: Implement Passpoint provisioning via the brand's loyalty app. Frequent shoppers who install the app receive a Passpoint profile that authenticates them automatically on 802.1X, bypassing the MAC-dependent captive portal. Their session is now tied to their loyalty identity, not their MAC.
Step 4 — Update NAC policies: Ensure VLAN assignment and rate limiting policies reference the RADIUS username attribute, not the MAC address. This ensures consistent policy application regardless of MAC rotation.
A 400-room hotel group is receiving guest complaints that they have to log in to the hotel WiFi every day of their stay, despite the captive portal displaying a 'Remember this device for 7 days' option. The hotel's IT team has confirmed the NAC is configured correctly with a 7-day session cache.
Step 1 — Diagnose the MAC rotation: Ask a guest to check their iPhone or Android settings for the specific hotel SSID. On iOS, navigate to Settings > Wi-Fi > [Hotel SSID] and check if 'Private Wi-Fi Address' is set to 'Rotating'. If enabled, the device rotates its MAC daily, invalidating the 7-day session cache every 24 hours.
Step 2 — Short-term guest communication: Update the hotel's WiFi welcome screen and in-room materials to instruct guests on how to set their Private Wi-Fi Address to 'Fixed' for the hotel SSID. This is a stopgap measure only.
Step 3 — Permanent architectural fix: Deploy a Passpoint R2 configuration on the hotel's access points. Integrate with Purple's Guest WiFi platform as the Identity Provider. Guests who authenticate once via the captive portal on day one are provisioned with a Passpoint profile. For the remainder of their stay — and on future visits — their device connects automatically and securely without any portal interaction.
Step 4 — Validate with RADIUS accounting: Confirm that RADIUS accounting logs are capturing the guest's authenticated identity (email or loyalty ID) rather than just the MAC address, to ensure GDPR-compliant session logging.
Practice Questions
Q1. A stadium IT director notices that their guest Wi-Fi analytics platform is reporting 58,000 unique visitors during a match, but the stadium's verified capacity is 32,000. The analytics vendor confirms the platform counts unique MAC addresses. What is the most likely cause, and what architectural change is required to produce accurate visitor counts?
Hint: Consider how many times a single device's MAC address might rotate during a 3-hour event, and what layer of the network stack the analytics platform is reading from.
View model answer
The analytics platform is counting unique MAC addresses at Layer 2, and MAC randomization is causing each physical device to appear as multiple unique visitors as it rotates its address during the event. The 58,000 figure likely represents MAC rotation events rather than actual individuals. The architectural fix is to migrate the analytics platform to count unique authenticated identities at Layer 7 — specifically, unique captive portal authentication sessions or RADIUS accounting records. Each authenticated session is tied to a verified identity (email, phone number, or social login), which does not change when the MAC rotates. This will produce an accurate, GDPR-compliant visitor count.
Q2. You are the network architect for a large NHS trust deploying a new NAC solution. You need to ensure that medical IoT devices (infusion pumps, patient monitoring systems) remain securely connected to a clinical VLAN, while guest devices (patients and visitors) are isolated on an internet-only VLAN. The trust's CISO has flagged that MAC Authentication Bypass (MAB) is insufficient for clinical device security. How do you design the authentication architecture for each device class?
Hint: Differentiate the authentication capabilities of headless medical IoT devices versus consumer smartphones. Consider which devices can support 802.1X certificates and which cannot.
View model answer
For medical IoT devices: Deploy 802.1X with EAP-TLS (certificate-based authentication) for devices that support it. For legacy devices that cannot support 802.1X, use MPSK (Multi Pre-Shared Key) with a unique PSK per device, ensuring each device is isolated even if one PSK is compromised. Maintain a strict device inventory and provision certificates or PSKs via the MDM/device management system. Assign clinical VLAN via RADIUS attributes on successful authentication.
For guest devices (patients and visitors): Assume all MACs are randomized. Deploy a captive portal for initial authentication (email/SMS verification for GDPR consent). For returning guests, integrate with Purple's Passpoint/OpenRoaming to enable automatic reconnection on subsequent visits. Assign all guest traffic to an internet-only VLAN with no access to clinical networks, enforced at the RADIUS level by user group, not by MAC address.
Q3. A luxury retail brand wants to implement a 'frictionless' Wi-Fi experience where VIP loyalty members connect automatically without any portal interaction when they enter any of the brand's 80 flagship stores globally. Given that MAC randomization makes MAC-based session caching unreliable, what is the most robust architectural approach, and what data does the brand gain as a result?
Hint: MAC caching is not a viable mechanism for 'frictionless' return visits. Consider what persistent, non-rotating identifier can be used instead, and how it is provisioned to the device.
View model answer
The most robust approach is Passpoint (Hotspot 2.0) provisioned via the brand's loyalty app. When a VIP member first authenticates (via the app or a one-time captive portal), the Purple Guest WiFi platform provisions a Passpoint profile containing 802.1X credentials tied to the member's loyalty identity. The profile is installed on the device and stored securely. On subsequent visits to any of the 80 stores, the device automatically discovers the Passpoint-enabled SSID and authenticates in the background using the stored credentials — no portal, no interaction, no MAC dependency.
The brand gains: (1) accurate, identity-linked connection events for each store visit, enabling precise footfall attribution to specific loyalty members; (2) dwell time and visit frequency data tied to verified identities for CRM enrichment; (3) a GDPR-compliant audit trail linking network access to explicit consent captured during initial onboarding; and (4) the ability to trigger real-time personalised marketing messages based on in-store presence, using the WiFi Analytics platform.