L'impact de la randomisation MAC sur le NAC et comment y remédier
Ce guide fournit une référence technique approfondie sur l'impact de la randomisation des adresses MAC sur les systèmes de contrôle d'accès réseau (NAC) et les architectures WiFi pour invités. Il explique les mécanismes de rotation MAC par réseau et périodique sur iOS, Android et Windows, et détaille les défaillances en cascade que cela provoque — de la fatigue du Captive Portal et de l'épuisement DHCP à la rupture de l'application des politiques et aux analyses inexactes. Les leaders IT et les architectes réseau trouveront des stratégies actionnables et neutres vis-à-vis des fournisseurs pour migrer d'une authentification centrée sur les appareils vers une authentification centrée sur l'identité en utilisant IEEE 802.1X, Passpoint (Hotspot 2.0) et OpenRoaming, avec des conseils de mise en œuvre concrets pour les environnements hôteliers, de vente au détail, de santé et du secteur public.
Listen to this guide
View podcast transcript
Résumé Exécutif
La randomisation des adresses MAC — désormais le comportement par défaut sur iOS 14+, Android 10+ et Windows 11 — a fondamentalement brisé le modèle d'authentification centré sur les appareils sur lequel les systèmes NAC d'entreprise s'appuient depuis deux décennies. Lorsqu'un appareil fait pivoter son adresse MAC, le réseau le traite comme un tout nouveau client. Les conséquences sont immédiates et opérationnelles : les Captive Portal forcent les invités de retour à se réauthentifier, les portées DHCP s'épuisent dans les environnements à haute densité, les politiques NAC ne s'appliquent pas et les plateformes d'analyse signalent des nombres de visiteurs considérablement gonflés.
Pour les leaders IT gérant des propriétés Hôtellerie , des parcs Commerce de détail , des campus Santé ou des centres de Transport , il ne s'agit pas d'un risque théorique — c'est un problème opérationnel actif affectant la satisfaction des invités, la posture de sécurité et la qualité des données marketing.
La solution est architecturale, pas cosmétique. Les réseaux doivent migrer de l'authentification des identifiants matériels (adresses MAC) vers l'authentification des identités d'utilisateur vérifiées via IEEE 802.1X, Passpoint (Hotspot 2.0) et OpenRoaming. Ce guide fournit la profondeur technique et la feuille de route de mise en œuvre pour effectuer cette transition ce trimestre.
Plongée Technique Approfondie : Les Mécaniques de la Randomisation MAC
La randomisation MAC n'est pas une norme monolithique. Sa mise en œuvre varie considérablement selon les écosystèmes d'appareils, créant des défis imprévisibles et superposés pour les ingénieurs réseau.
Comment les Systèmes d'Exploitation Gèrent la Randomisation
Les systèmes d'exploitation modernes implémentent la randomisation MAC selon deux modes distincts, qui perturbent tous deux les architectures NAC héritées :
Randomisation par réseau (Comportement par défaut) : L'appareil génère une adresse MAC unique, administrée localement, pour chaque SSID auquel il se connecte. Cette adresse est dérivée d'un hachage du SSID et d'une graine spécifique à l'appareil, ce qui signifie qu'elle est stable pour ce réseau spécifique mais entièrement différente de l'adresse MAC matérielle. C'est le comportement par défaut sur iOS 14+, Android 10+ et Windows 11.
Rotation Périodique (Mode de Confidentialité Amélioré) : Des fonctionnalités telles que l'« Adresse Wi-Fi Privée » d'Apple (iOS 15+) et l'« Utiliser une adresse MAC aléatoire » d'Android avec une protection de suivi améliorée feront pivoter l'adresse MAC aléatoire pour un SSID donné selon un calendrier quotidien ou hebdomadaire, ou après une période d'inactivité configurable. C'est le mode le plus perturbateur pour les environnements d'entreprise.
De plus, les appareils utilisent des MAC aléatoires lors de la recherche active (Probe Requests) — avant toute association. Cela signifie que même les moteurs d'analyse passifs qui suivent les requêtes de sondage ne peuvent pas compter de manière fiable les appareils uniques.
La Cascade de Défaillances sur l'Infrastructure Réseau
Lorsqu'un appareil fait pivoter son adresse MAC, le réseau le traite comme un tout nouveau client. Cet événement unique déclenche une cascade de défaillances architecturales à travers plusieurs couches réseau :
| Mode de Défaillance | Cause Technique | Impact Commercial |
|---|---|---|
| Fatigue du Captive Portal | Cache de session NAC indexé sur MAC ; la rotation invalide l'entrée du cache | Les invités de retour sont forcés de se réauthentifier ; augmentation des tickets de support |
| Épuisement de la Portée DHCP | Chaque nouvelle MAC consomme un nouveau bail IP ; les anciens baux ne sont pas libérés avant l'expiration du TTL | Les nouveaux appareils ne peuvent pas obtenir d'adresses IP ; panne réseau pour les invités |
| Inadéquation de la Politique NAC | Politiques (VLAN, limite de débit, ACL) liées à la MAC ; la nouvelle MAC n'a pas de politique | Contournement des contrôles de sécurité ; les invités peuvent atterrir sur le mauvais VLAN |
| Inflation des Analyses | Analyses indexées sur la MAC de Couche 2 ; un appareil apparaît comme plusieurs visiteurs uniques | Données de fréquentation inexactes ; décisions marketing basées sur de fausses métriques |
| Perte de Continuité de Session | L'itinérance AP et l'équilibrage de charge reposent sur la MAC pour le transfert de session | Expérience d'itinérance dégradée ; sessions interrompues pendant le déplacement |
Le Contexte de la Norme IEEE
Le bit d'adresse administrée localement (le deuxième bit le moins significatif du premier octet) est défini sur 1 dans les MAC aléatoires, les distinguant des adresses matérielles globalement uniques. Une MAC commençant par 02:, 06:, 0A: ou 0E: dans le premier octet est définitivement une adresse administrée localement (potentiellement aléatoire). Les ingénieurs réseau peuvent l'utiliser pour détecter les clients aléatoires au niveau du serveur RADIUS ou DHCP, bien que la détection seule ne résolve pas le problème d'authentification.
Pour plus de contexte sur l'environnement RF dans lequel ces appareils opèrent, consultez notre guide sur les Fréquences Wi-Fi : Un Guide des Fréquences Wi-Fi en 2026 .
Guide d'Implémentation : Migration vers une Architecture Centrée sur l'Identité
La seule solution durable à la randomisation MAC est de découpler entièrement l'authentification et l'application des politiques des identifiants matériels. La feuille de route d'implémentation en trois phases suivante fournit un chemin neutre vis-à-vis des fournisseurs vers un réseau centré sur l'identité.
Phase 1 : Atténuations Immédiates (Semaines 1-2)
Avant d'entreprendre une migration architecturale complète, mettez en œuvre ces atténuations tactiques pour stabiliser l'environnement :
- Réduire les Durées de Bail DHCP : Sur les VLAN invités, réduisez la durée du bail de 24 heures typiques à 1-4 heures. Cela récupère plus rapidement les adresses IP des appareils transitoires et prévient l'épuisement de la portée. Dans les stades ou les centres de conférence à fort roulement, envisagez des baux aussi courts que 30 minutes.
- Augmenter la Taille du Pool DHCP : Étendez la portée DHCP des invités pour s'adapter à la demande gonflée des MAC rotatives comme tampon à court terme.
- Mettre à Jour les Scripts du Service d'Assistance : Demandez au personnel de support, lors du dépannage d'un problème de connexion invité, de demander la MAC aléatoire actuelle de l'appareil pour cette spécific SSID (trouvé dans les détails du réseau Wi-Fi), et non l'adresse MAC matérielle des paramètres généraux de l'appareil.
Phase 2 : Déployer IEEE 802.1X pour les utilisateurs connus (Mois 1–3)
IEEE 802.1X est la pierre angulaire de l'accès réseau centré sur l'identité. Au lieu d'authentifier l'appareil via son adresse MAC, le réseau authentifie l'utilisateur via des identifiants, des certificats ou des identités tokenisées par un échange EAP (Extensible Authentication Protocol) avec un serveur RADIUS.
Étapes de configuration clés :
- Déployer un serveur RADIUS (par exemple, FreeRADIUS, Cisco ISE, Aruba ClearPass) intégré à votre annuaire d'identités (Active Directory, LDAP ou un IdP cloud).
- Créer un SSID WPA3-Enterprise dédié pour les utilisateurs connus (personnel, invités enregistrés, membres de programmes de fidélité).
- Provisionner les identifiants 802.1X via une solution de gestion des appareils mobiles (MDM) pour les appareils d'entreprise, ou via un portail d'intégration en libre-service pour les BYOD et les invités enregistrés.
- Mettre à jour les politiques NAC pour appliquer l'attribution de VLAN, les ACL et les limites de débit basées sur les attributs RADIUS (par exemple,
Tunnel-Private-Group-IDpour l'attribution de VLAN) plutôt que sur les adresses MAC.
Phase 3 : Implémenter Passpoint et OpenRoaming pour les invités de passage (Mois 3–6)
Pour les invités de passage — visiteurs d'hôtel, clients de magasins, spectateurs de stade — la gestion individuelle des identifiants 802.1X est peu pratique. Passpoint (Hotspot 2.0 / IEEE 802.11u) résout ce problème en permettant une authentification transparente, automatisée et chiffrée sans captive portal.
Passpoint permet à un appareil de découvrir automatiquement un réseau compatible et de s'authentifier en utilisant les identifiants fournis par un fournisseur d'identité (IdP) de confiance. L'utilisateur ne voit jamais de page de connexion.
Le rôle de Purple en tant que fournisseur d'identité : La plateforme Purple's Guest WiFi agit comme un fournisseur d'identité gratuit pour des services comme OpenRoaming sous la licence Connect. Lorsqu'un invité s'authentifie via un captive portal alimenté par Purple ou une application de fidélité dans un lieu, Purple lui fournit des identifiants Passpoint. Lors des visites ultérieures dans tout lieu compatible OpenRoaming de la fédération, l'appareil se connecte automatiquement et en toute sécurité — l'identité de l'utilisateur étant vérifiée à la couche 7, quelle que soit son adresse MAC.
Cette architecture alimente également directement la plateforme WiFi Analytics , où les nombres de visiteurs, les temps de séjour et les taux de visites de retour sont calculés à partir d'identités vérifiées plutôt que d'adresses MAC éphémères.
Bonnes pratiques pour le déploiement en entreprise
Les bonnes pratiques neutres vis-à-vis des fournisseurs suivantes s'appliquent à toutes les échelles de déploiement :
Dissocier la politique des adresses MAC : Auditez chaque politique NAC dans votre environnement. Toute politique qui fait référence à une adresse MAC spécifique ou à un groupe d'appareils basé sur l'adresse MAC doit être migrée pour faire référence à un attribut d'identité utilisateur (nom d'utilisateur RADIUS, groupe Active Directory, CN de certificat). C'est un prérequis non négociable pour un réseau résilient à la randomisation MAC.
Segmenter les appareils IoT séparément : La plupart des appareils IoT d'entreprise (lecteurs de contrôle d'accès, contrôleurs CVC, affichage numérique) n'implémentent pas la randomisation MAC. Cependant, ils doivent être isolés sur un VLAN dédié en utilisant l'authentification MPSK ou basée sur certificat plutôt que le MAC Authentication Bypass (MAB), qui reste vulnérable à l'usurpation d'identité. Pour un traitement détaillé de ce sujet, consultez notre guide sur La gestion de la sécurité des appareils IoT avec NAC et MPSK (también disponible en español: Gestión de la seguridad de dispositivos IoT con NAC y MPSK ).
Adopter WPA3 comme référence : WPA3-Personal (SAE) et WPA3-Enterprise offrent une protection significativement plus forte que WPA2 et sont requis pour les déploiements Passpoint R3. Assurez-vous que le firmware de votre point d'accès et les supplicants clients prennent en charge WPA3 avant de commencer la Phase 3.
Valider la journalisation de conformité : Conformément au GDPR et au PCI DSS, vous devez être en mesure d'attribuer l'activité réseau à un utilisateur ou un appareil spécifique. Un système de journalisation basé sur les adresses MAC n'est plus suffisant. Assurez-vous que votre SIEM et votre infrastructure de journalisation capturent les identités des utilisateurs authentifiés à partir des enregistrements de comptabilité RADIUS, et non seulement les adresses MAC des journaux DHCP.
Pour plus de contexte sur les décisions de réseau d'entreprise connexes, consultez notre guide sur SD-WAN vs MPLS : Le guide du réseau d'entreprise 2026 et notre introduction sur BLE Low Energy expliqué pour l'entreprise .
Dépannage et atténuation des risques
Modes de défaillance courants et résolutions
Symptôme : Pool DHCP épuisé pendant les heures de pointe malgré une fréquentation normale. Diagnostic : Vérifiez les journaux de baux DHCP pour plusieurs baux attribués au même appareil physique (identifiable en corrélant avec les journaux d'association AP). Si un seul appareil a consommé plus de 3 baux en 24 heures, la rotation MAC est confirmée. Résolution : Réduisez immédiatement les durées de bail. Implémentez la Phase 2 (802.1X) pour les utilisateurs à haute fréquence afin de stabiliser leur identité.
Symptôme : Les invités de retour sont redirigés à plusieurs reprises vers le captive portal. Diagnostic : Le cache de session NAC est indexé sur l'adresse MAC. Confirmez en vérifiant si l'adresse MAC actuelle de l'invité correspond à l'adresse MAC mise en cache de sa dernière session. Résolution : Implémentez Passpoint pour les invités de retour via une application de fidélité ou le provisionnement de profil. C'est la seule solution permanente.
Symptôme : Les rapports d'analyse indiquent 3 fois le nombre attendu de visiteurs uniques. Diagnostic : La plateforme d'analyse compte les adresses MAC uniques plutôt que les sessions authentifiées uniques. Résolution : Migrez l'analyse pour qu'elle s'appuie sur les données d'identité de la couche 7 provenant des journaux d'authentification du captive portal ou de la comptabilité RADIUS. Abandonnez entièrement le comptage des visiteurs basé sur les adresses MAC.
Symptôme : L'appareil IoT perd son attribution de VLAN après une reconnexion apparente. Diagnostic : Confirmez si le firmware de l'appareil IoT implémente la randomisation MACisation (rare mais présente dans certains appareils IoT grand public déployés dans des environnements d'entreprise). Résolution : Migrez l'authentification IoT vers MPSK ou 802.1X basé sur certificat. Ne vous fiez pas au MAB pour tout appareil susceptible d'implémenter la randomisation.
ROI et impact commercial
Aborder la randomisation MAC n'est pas un centre de coûts — c'est un catalyseur de revenus et de conformité.
Réduction des coûts opérationnels : L'élimination des tickets de support liés au Captive Portal génère des économies immédiates. Pour une grande chaîne hôtelière de 200 établissements, réduire les appels de support WiFi des clients de seulement 30 % peut représenter des dizaines de milliers de livres sterling en réduction annuelle des coûts du service d'assistance.
Qualité des données marketing : Des analyses précises des visiteurs basées sur l'identité améliorent directement le ROI des campagnes marketing. Lorsque les données de fréquentation sont basées sur des identités vérifiées plutôt que sur des adresses MAC tournantes, les calculs de taux de conversion, l'analyse du temps de présence et l'attribution des visites de retour deviennent des données fiables pour les décisions commerciales.
Assurance de conformité : Le GDPR exige que le traitement des données soit lié à des individus identifiables avec un consentement approprié. Un système basé sur les adresses MAC ne peut pas relier de manière fiable l'activité réseau à une personne spécifique. Un système centré sur l'identité avec une authentification vérifiée fournit la piste d'audit requise pour la conformité au GDPR et la journalisation de la segmentation réseau PCI DSS.
Expérience client et revenus : Dans l'hôtellerie, une connexion Wi-Fi automatique et sans friction (via Passpoint) est de plus en plus un facteur de différenciation concurrentiel. Les hôtels et les lieux qui éliminent le Captive Portal pour les clients réguliers signalent des scores de satisfaction client mesurablement plus élevés et un temps de présence accru — deux éléments qui sont corrélés à des revenus auxiliaires plus élevés par visite.
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.