Cómo configurar un servidor RADIUS para la autenticación WiFi
Esta guía autorizada ofrece a los líderes de TI y arquitectos de red un plan integral para implementar un servidor RADIUS para la autenticación WiFi empresarial. Cubre las ventajas y desventajas arquitectónicas entre las implementaciones locales y en la nube, la selección del método EAP, la integración con Active Directory y la asignación dinámica de VLAN. Los operadores de recintos y los equipos de TI encontrarán pasos de implementación prácticos, casos de estudio reales y estrategias de mitigación de riesgos para pasar de un entorno PSK inseguro a una infraestructura 802.1X sólida este trimestre.
Escuchar esta guía
Ver transcripción del podcast
- Executive Summary
- Technical Deep-Dive
- The 802.1X Architecture
- Choosing an EAP Method
- Implementation Guide
- Step 1: Architectural Decision — On-Premise vs. Cloud RADIUS
- Step 2: Install and Configure the RADIUS Server
- Step 3: Configure Access Points
- Step 4: Directory Integration
- Step 5: Client Configuration and Certificate Validation
- Step 6: Implement Dynamic VLAN Assignment
- Best Practices
- Troubleshooting & Risk Mitigation
- ROI & Business Impact

Executive Summary
For enterprise environments — whether a sprawling university campus, a high-density stadium, or a distributed retail chain — relying on a Pre-Shared Key (PSK) for WiFi access is a significant security liability. A single compromised credential exposes the entire network, and revoking access requires changing the password for every device on the estate. Implementing 802.1X authentication via a RADIUS (Remote Authentication Dial-In User Service) server eliminates this problem entirely: each user authenticates individually, access can be revoked instantly, and network segmentation is enforced dynamically.
This guide provides a definitive roadmap for IT managers and network architects to deploy RADIUS authentication. We cover the architectural trade-offs between on-premise and cloud-hosted deployments, the configuration of Extensible Authentication Protocol (EAP) methods, and the integration with directory services like Active Directory. We also demonstrate how a robust authentication layer integrates with Guest WiFi solutions to provide seamless access for visitors, while capturing the WiFi Analytics that turn your network into a business intelligence asset.
Technical Deep-Dive
The 802.1X Architecture
The IEEE 802.1X standard defines port-based Network Access Control (PNAC). In a wireless context, it involves three primary roles working in concert:
| Role | Component | Responsibility |
|---|---|---|
| Supplicant | Client device (laptop, smartphone) | Presents credentials to request network access |
| Authenticator | WiFi Access Point or Controller | Enforces access control; relays EAP messages |
| Authentication Server | RADIUS Server | Validates credentials; returns accept/reject and policy attributes |
When a supplicant associates with an access point, the AP blocks all data traffic except EAP (Extensible Authentication Protocol) messages. The AP encapsulates these EAP messages in RADIUS packets and forwards them to the RADIUS server. The server verifies the credentials against a backend database — typically LDAP or Active Directory — and returns an Access-Accept or Access-Reject message. If accepted, the AP unblocks the port and the client's traffic flows freely.

Choosing an EAP Method
The security of your RADIUS deployment depends heavily on the EAP method selected. The two most prevalent in enterprise deployments are:
EAP-TLS (Transport Layer Security) is the gold standard. It requires digital certificates on both the RADIUS server and every client device, eliminating passwords entirely. Even if an attacker captures the full authentication exchange, there are no credentials to extract. The trade-off is administrative overhead: deploying and managing client certificates requires a functioning Public Key Infrastructure (PKI) and an MDM solution (e.g., Microsoft Intune, Jamf) to distribute certificates to endpoints.
PEAP-MSCHAPv2 (Protected EAP) is the most widely deployed method in practice. It uses a server-side certificate to establish an encrypted TLS tunnel, inside which the client authenticates with a username and password. This is significantly easier to deploy than EAP-TLS because only one certificate — the server's — needs to be managed. However, it carries a critical caveat: if client devices are not explicitly configured to validate the RADIUS server's certificate, they are vulnerable to Man-in-the-Middle (MitM) attacks via rogue access points.
> Critical Security Note: Failing to enforce strict certificate validation on client devices effectively nullifies the security benefits of PEAP-MSCHAPv2. An attacker can deploy a rogue AP, present a fraudulent certificate, and capture user credentials in plaintext. This is not a theoretical risk — it is a well-documented attack vector that has been exploited in real-world environments.
Implementation Guide
Step 1: Architectural Decision — On-Premise vs. Cloud RADIUS
The first decision is where to host the RADIUS infrastructure. This is primarily an operational and cost question, not a security one — both models can be deployed securely.

On-Premise RADIUS (e.g., Microsoft NPS, FreeRADIUS, Cisco ISE) is suited for organisations with dedicated IT staff, existing on-premise directory infrastructure, and stringent data sovereignty or compliance requirements. It does not depend on internet connectivity for authentication, which is a meaningful advantage for environments where internet uptime cannot be guaranteed.
Cloud RADIUS is increasingly the preferred model for distributed environments — Retail chains, Hospitality groups, and Transport hubs where deploying servers at every location is operationally impractical. Cloud RADIUS integrates natively with cloud identity providers (Azure AD, Google Workspace, Okta) and provides built-in high availability and global scalability.
Step 2: Install and Configure the RADIUS Server
For an on-premise deployment using Microsoft NPS (the most common choice in Windows-centric environments):
- Install the Network Policy Server role via Server Manager.
- Register the NPS server in Active Directory to allow it to read user dial-in properties.
- Create a RADIUS Client entry for each access point or wireless controller, specifying the AP's IP address and a strong, unique Shared Secret.
- Configure a Network Policy defining the conditions (e.g., user group membership) and constraints (e.g., EAP method, session timeout) for access.
- Configure the Connection Request Policy to process requests locally.
For FreeRADIUS on Linux:
- Install via package manager:
sudo apt-get install freeradius freeradius-ldap. - Configure
/etc/freeradius/3.0/clients.confto define RADIUS clients (APs) and their shared secrets. - Configure the LDAP module in
/etc/freeradius/3.0/mods-available/ldapto point to your Active Directory or LDAP server. - Enable the LDAP module:
sudo ln -s /etc/freeradius/3.0/mods-available/ldap /etc/freeradius/3.0/mods-enabled/. - Define EAP methods in
/etc/freeradius/3.0/mods-available/eap.
Step 3: Configure Access Points
On your wireless controller or individual access points:
- Define the RADIUS server IP address(es) and authentication port (default: UDP 1812).
- Configure the Shared Secret — use a minimum of 22 characters, mixing alphanumeric and special characters. Use a unique secret per location or AP group.
- Configure the SSID to use WPA2-Enterprise or WPA3-Enterprise security mode with 802.1X key management.
- Configure a secondary RADIUS server for failover.
Step 4: Directory Integration
For on-premise AD integration, the RADIUS server must be joined to the domain or have LDAP read access. Ensure service accounts used for LDAP binding have the minimum required permissions. For cloud RADIUS, configure the API-based synchronization or SAML/OIDC integration with your IdP.
Define clear user groups in your directory, as these will drive authorization policies. Recommended group structure:
| Group | VLAN | Access Level |
|---|---|---|
Corp_Staff |
VLAN 10 | Full internal network |
Corp_Contractors |
VLAN 20 | Internet + specific internal resources |
Corp_IoT |
VLAN 30 | Isolated, device-specific ports only |
Corp_Guests |
VLAN 100 | Internet only via captive portal |
Step 5: Client Configuration and Certificate Validation
This is the most operationally critical step. Use Group Policy (GPO) for Windows and MDM profiles for macOS/iOS/Android to push WiFi configurations silently to managed devices. The profile must specify:
- The Root CA that issued the RADIUS server's certificate.
- The expected server name (CN or SAN of the server certificate).
- The EAP method and inner authentication protocol.
For unmanaged BYOD devices, provide clear self-service onboarding instructions, ideally via a Network Access Control (NAC) portal.
Step 6: Implement Dynamic VLAN Assignment
Configure the RADIUS server to return VLAN assignment attributes in the Access-Accept response:
Tunnel-Type=VLAN(13)Tunnel-Medium-Type=IEEE-802(6)Tunnel-Private-Group-Id= ``
The access point reads these attributes and places the authenticated client on the specified VLAN — no manual reconfiguration required as users change roles or locations.
Best Practices
Redundancy is non-negotiable. Deploy a minimum of two RADIUS servers (primary and secondary) and configure all access points to fail over automatically. For on-premise deployments, consider placing the secondary server in a different physical location or availability zone. A RADIUS outage means nobody can authenticate, which is a complete network outage for 802.1X-protected SSIDs.
Monitor certificate expiry proactively. A RADIUS server certificate expiry is one of the most common causes of sudden, widespread authentication failures. Implement monitoring to alert administrators at least 30 days before expiry. This applies to both the server certificate and any intermediate CA certificates in the chain.
Treat the Shared Secret as a critical credential. The shared secret between the AP and the RADIUS server encrypts RADIUS packets. Use unique secrets per location or AP group, store them in a secrets manager, and rotate them periodically. See our guide on Protect Your Network with Strong DNS and Security for broader network security hygiene recommendations.
Align with compliance frameworks. For environments subject to PCI DSS (e.g., retail payment networks), 802.1X authentication directly supports requirements for network access control and audit logging. For GDPR compliance, RADIUS accounting logs (port 1813) provide a detailed audit trail of who accessed the network, from where, and when — valuable for incident response. For Healthcare environments, network segmentation via dynamic VLAN assignment supports HIPAA requirements for protecting electronic protected health information (ePHI).
Troubleshooting & Risk Mitigation
| Failure Mode | Symptom | Resolution |
|---|---|---|
| Certificate expiry | Sudden mass authentication failures | Monitor expiry; renew and redeploy certificate |
| NTP desynchronisation | Intermittent EAP-TLS failures | Ensure RADIUS server and DCs sync to same NTP source |
| LDAP connectivity loss | Authentication fails when AD is unreachable | Deploy redundant DCs; configure RADIUS to cache recent authentications |
| Incorrect Shared Secret | AP logs show RADIUS timeout or Bad authenticator |
Verify secret matches on both AP and RADIUS server |
| Client certificate mismatch | EAP-TLS failures for specific devices | Verify client cert is issued by trusted CA; check cert validity period |
| VLAN not assigned | User authenticated but on wrong network segment | Verify RADIUS attributes are correctly returned; check AP VLAN configuration |
For a deeper dive into the 802.1X configuration process itself, the How to Configure 802.1X WiFi Authentication: A Step-by-Step Guide provides granular, vendor-specific configuration walkthroughs.
ROI & Business Impact
Transitioning from PSK to RADIUS-backed 802.1X requires an initial investment in configuration, and potentially licensing for cloud solutions or hardware for on-premise deployments. The ROI case is straightforward:
Risk mitigation: The average cost of a data breach in the UK is in excess of £3 million (IBM Cost of a Data Breach Report). A compromised PSK can expose the entire network. 802.1X limits the blast radius to a single compromised user account, which can be disabled in seconds via the directory.
Operational efficiency: Dynamic VLAN assignment eliminates manual network reconfiguration as staff change roles. Onboarding a new employee means adding them to the correct AD group — the network access follows automatically.
Compliance posture: For organisations subject to PCI DSS, ISO 27001, or Cyber Essentials Plus, 802.1X is a direct control that auditors expect to see. Deploying it strengthens your compliance posture and reduces audit remediation costs.
Guest experience and analytics: For venue operators, integrating RADIUS for staff authentication with Purple's Guest WiFi platform for visitor access creates a unified, tiered access model. Staff authenticate silently via 802.1X; guests connect via a branded captive portal. Purple's WiFi Analytics platform then provides real-time visibility into visitor dwell times, repeat visit rates, and engagement metrics — data that directly informs marketing spend and venue operations decisions.
For further reading, see the Como Configurar a Autenticação 802.1X WiFi: Um Guia Passo a Passo for Portuguese-language implementation guidance, and What Is a Leased Line? Dedicated Business Internet for guidance on ensuring the underlying connectivity meets enterprise requirements.
Definiciones clave
RADIUS (Remote Authentication Dial-In User Service)
Un protocolo de red que proporciona una gestión centralizada de Autenticación, Autorización y Contabilidad (AAA) para los usuarios que se conectan a un servicio de red. Definido en RFC 2865.
El componente de servidor principal que valida las credenciales de usuario contra un directorio antes de otorgar acceso WiFi. Cada despliegue de WiFi empresarial que utiliza 802.1X requiere un servidor RADIUS.
802.1X
Un estándar IEEE para el Control de Acceso a Red basado en puertos (PNAC). Proporciona un mecanismo de autenticación a los dispositivos que desean conectarse a una LAN o WLAN, bloqueando todo el tráfico que no sea EAP hasta que la autenticación se realice con éxito.
El estándar de marco global que define cómo se comunican el Supplicant, el Authenticator y el Servidor de Autenticación. Cuando los equipos de TI se refieren a la "seguridad WiFi empresarial", normalmente se refieren a WPA2/WPA3-Enterprise con 802.1X.
Supplicant
El dispositivo cliente — o más precisamente, la pila de software 802.1X en ese dispositivo — que inicia el proceso de autenticación presentando las credenciales a la red.
En Windows, el supplicant integrado es el servicio Wireless AutoConfig. En macOS e iOS, es nativo del sistema operativo. Garantizar que el supplicant esté configurado correctamente (especialmente para la validación de certificados) es la fuente más común de problemas de despliegue.
Authenticator
El dispositivo de red — normalmente un punto de acceso WiFi o un controlador inalámbrico — que actúa como intermediario entre el Supplicant y el servidor RADIUS, aplicando el control de acceso en función del resultado de la autenticación.
El AP bloquea todo el tráfico de datos en el puerto hasta que recibe un Access-Accept del servidor RADIUS. También lee los atributos RADIUS (por ejemplo, la asignación de VLAN) de la respuesta Access-Accept y los aplica a la sesión.
EAP (Extensible Authentication Protocol)
Un marco de autenticación definido en RFC 3748 que proporciona un mecanismo de transporte estandarizado para varios métodos de autenticación (TLS, PEAP, TTLS, etc.) entre el Supplicant y el Servidor de Autenticación.
EAP es el "idioma" que se habla entre el cliente y el servidor RADIUS. La elección del método EAP (EAP-TLS frente a PEAP) determina la solidez de la seguridad y la complejidad del despliegue del sistema de autenticación.
PEAP (Protected EAP)
Un método EAP que primero establece un túnel TLS utilizando el certificado del servidor y luego realiza una autenticación secundaria (normalmente MSCHAPv2 con usuario/contraseña) dentro de ese túnel cifrado.
El método de autenticación WiFi empresarial más común debido a su equilibrio entre seguridad y simplicidad de despliegue. Requiere solo un certificado en el lado del servidor, lo que hace que sea mucho más fácil de implementar que EAP-TLS.
Dynamic VLAN Assignment
Una función de RADIUS en la que el servidor incluye atributos específicos de VLAN (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Private-Group-Id) en la respuesta Access-Accept, indicando al AP que coloque al cliente autenticado en una VLAN específica.
Permite que un único SSID sirva a múltiples poblaciones de usuarios con diferentes requisitos de seguridad. Elimina la necesidad de transmitir múltiples SSID para diferentes grupos de usuarios, reduciendo la sobrecarga de RF y simplificando la experiencia del usuario.
Shared Secret
Una cadena de texto preconfigurada conocida únicamente por el Authenticator (AP) y el servidor RADIUS, utilizada para firmar y cifrar paquetes RADIUS, garantizando la integridad y autenticidad de la comunicación.
Un elemento crítico de configuración de seguridad. Si el shared secret es débil o está comprometido, un atacante podría falsificar respuestas Access-Accept de RADIUS, otorgando acceso no autorizado a la red. Utilice secretos únicos por ubicación y almacénelos en un gestor de secretos.
MAC Authentication Bypass (MAB)
Un mecanismo de autenticación alternativo en el que la dirección MAC de un dispositivo se utiliza como su credencial de identidad, lo que permite el acceso a la red para dispositivos que no admiten supplicants 802.1X.
Se utiliza para dispositivos sin interfaz de usuario (impresoras, sensores IoT, cámaras IP). Debido a que las direcciones MAC son visibles públicamente y fáciles de suplantar, MAB proporciona identificación de dispositivos en lugar de una autenticación sólida. Emparéjelo siempre con una asignación de VLAN restrictiva.
Ejemplos prácticos
Una cadena minorista nacional con 500 ubicaciones necesita implementar WiFi seguro para las tabletas de los gerentes de tienda y las terminales de punto de venta (POS). Actualmente utilizan una única PSK en todas las tiendas, que se comparte con frecuencia con personal y contratistas no autorizados. Utilizan Azure AD para la gestión de identidades y no disponen de personal de TI dedicado en las sucursales.
Implementar una solución Cloud RADIUS integrada directamente con Azure AD. Esto elimina la necesidad de desplegar y gestionar servidores RADIUS locales en 500 ubicaciones. El equipo de TI utiliza Microsoft Intune para enviar un perfil de WiFi a todas las tabletas de los gerentes de tienda y terminales POS configuradas para PEAP-MSCHAPv2, aplicando estrictamente la validación del certificado del servidor Cloud RADIUS. La política de Cloud RADIUS comprueba la pertenencia al grupo de Azure AD del usuario antes de conceder el acceso: el grupo "Store_Managers" recibe la VLAN 10 (acceso completo a POS y back-office), el grupo "Contractors" recibe la VLAN 20 (solo internet). Cuando finaliza el contrato de un colaborador externo, al eliminarlo del grupo de Azure AD se revoca inmediatamente su acceso a la WiFi en las 500 ubicaciones de forma simultánea, sin necesidad de cambiar la PSK.
Un hotel de 400 habitaciones en el centro de la ciudad necesita proporcionar WiFi seguro tanto para el personal (recepción, limpieza, administración) como para los huéspedes. El personal requiere acceso al sistema de gestión de la propiedad (PMS) y a los servidores internos. Los huéspedes solo necesitan acceso a internet. El hotel dispone de un único entorno local de Windows Server.
Implementar Microsoft NPS en una máquina virtual dedicada de Windows Server. Configurar dos SSIDs en la infraestructura inalámbrica: "Hotel_Staff" (WPA2-Enterprise, 802.1X) y "Hotel_Guest" (abierto o WPA2-Personal, que redirige a un Captive Portal). Para el SSID del personal, NPS valida las credenciales contra Active Directory y devuelve asignaciones dinámicas de VLAN: grupo de AD "Management" → VLAN 10 (acceso completo), "FrontDesk" → VLAN 20 (acceso al PMS), "Housekeeping" → VLAN 30 (solo internet + aplicación de programación). Para los huéspedes, integre el Captive Portal con la plataforma Guest WiFi de Purple para ofrecer una experiencia de inicio de sesión personalizada, recopilar datos de origen (correo electrónico, consentimiento de marketing) y obtener análisis sobre el tiempo de permanencia y las visitas recurrentes. El modelo de dos SSIDs mantiene el tráfico del personal y de los huéspedes completamente separado en la capa de red.
Preguntas de práctica
Q1. Su organización está migrando 2.000 portátiles Windows de una PSK compartida a 802.1X con PEAP-MSCHAPv2. Su equipo de seguridad advierte que PEAP es vulnerable a la recopilación de credenciales a través de puntos de acceso no autorizados (rogue AP). ¿Cuál es el paso de configuración más importante para mitigar este riesgo y cómo lo despliega a escala?
Sugerencia: Considere qué impide que un cliente confíe en un servidor RADIUS fraudulento que presenta un certificado autofirmado.
Ver respuesta modelo
El paso crítico es aplicar una validación estricta del certificado del servidor en cada dispositivo cliente. Mediante Objetos de Directiva de Grupo (GPO), envíe un perfil de WiFi a los 2.000 portátiles que especifique: (1) el certificado de la CA raíz exacto que emitió el certificado del servidor RADIUS, (2) el nombre de servidor esperado (CN/SAN) y (3) que el cliente no debe solicitar al usuario que confíe en nuevos certificados. Esto garantiza que incluso si un atacante despliega un AP no autorizado con un certificado fraudulento, el cliente rechazará el saludo TLS y se negará a enviar credenciales. Sin esta configuración, PEAP no proporciona ninguna protección significativa contra ataques de AP no autorizados.
Q2. El director de TI de un hospital necesita proporcionar acceso a la red a 300 dispositivos IoT médicos (bombas de infusión, equipos de monitorización) que no son compatibles con 802.1X. Estos dispositivos coexisten con las estaciones de trabajo del personal en la misma infraestructura inalámbrica. ¿Cómo debe gestionar la infraestructura RADIUS estos dispositivos y qué controles de red deben implementarse?
Sugerencia: Piense en el método de autenticación disponible para dispositivos sin interfaz de usuario (headless) y cómo compensar su debilidad inherente.
Ver respuesta modelo
Configure MAC Authentication Bypass (MAB) en el servidor RADIUS para estos dispositivos específicos. Registre la dirección MAC de cada dispositivo en un grupo dedicado de Active Directory o en la base de datos RADIUS. Dado que las direcciones MAC se pueden suplantar fácilmente, el servidor RADIUS debe utilizar la asignación dinámica de VLAN para ubicar todos los dispositivos autenticados por MAB en una VLAN dedicada y altamente restringida (por ejemplo, VLAN 30 - IoT). Esta VLAN debe estar protegida por un cortafuegos para permitir la comunicación únicamente con direcciones IP de servidores médicos específicos y bloquear todo el demás tráfico, incluido el acceso a Internet y el movimiento lateral hacia las VLAN del personal. Las estaciones de trabajo del personal se autentican mediante 802.1X y se ubican en una VLAN independiente. Esta arquitectura cumple con los requisitos de segmentación de red de HIPAA para dispositivos adyacentes a ePHI.
Q3. Usted es el arquitecto de red de una cadena de restaurantes con 50 establecimientos. La autenticación funciona correctamente en 49 de ellos utilizando Cloud RADIUS, pero un establecimiento específico informa de que todos los dispositivos fallan al autenticarse. El portal de gestión de Cloud RADIUS muestra cero solicitudes de autenticación procedentes de ese establecimiento. ¿Cuál es su enfoque de diagnóstico?
Sugerencia: Si el servidor RADIUS no recibe ninguna solicitud, el problema está en la ruta de comunicación entre el autenticador y el servidor, no en la lógica de autenticación en sí.
Ver respuesta modelo
Dado que el servidor RADIUS no recibe ninguna solicitud de este establecimiento, el fallo se encuentra entre los puntos de acceso y el servidor Cloud RADIUS. Pasos de diagnóstico en orden: (1) Verificar la dirección IP y el puerto del servidor RADIUS (UDP 1812) configurados en los AP o en el controlador inalámbrico del establecimiento (un error tipográfico aquí es la causa más común). (2) Comprobar las reglas del cortafuegos local o del router en ese establecimiento para confirmar que se permite el tráfico UDP 1812 saliente hacia el rango de IP de Cloud RADIUS. (3) Verificar que el Secreto Compartido (Shared Secret) configurado en los AP coincide con el secreto configurado para ese establecimiento en el portal de Cloud RADIUS (una discrepancia hace que el servidor RADIUS descarte silenciosamente los paquetes). (4) Comprobar si la conexión a Internet del establecimiento funciona (Cloud RADIUS requiere conectividad a Internet fiable). Realizar una captura de paquetes en el AP o en el router ascendente confirmará si se están enviando paquetes RADIUS y si se están recibiendo respuestas.
Continúe leyendo esta serie
Server RADIUS: una guía completa para empresas
Esta guía proporciona a directores de TI, arquitectos de redes y directores de tecnología (CTO) una referencia técnica definitiva sobre la autenticación mediante server RADIUS para WiFi empresarial. Cubre el marco AAA, la arquitectura 802.1X, la selección del método EAP, las ventajas y desventajas del despliegue en la nube frente a local y la asignación dinámica de VLAN. Los operadores de recintos del sector de la hostelería, retail, eventos y el sector público encontrarán pautas de implementación prácticas, casos de estudio reales y los marcos de decisión necesarios para migrar de claves precompartidas no seguras a una arquitectura de control de acceso a la red segura y basada en la identidad.
Aruba ClearPass vs. Purple WiFi: comparativa de funciones y codespliegue
Una guía técnica exhaustiva que detalla la arquitectura de codespliegue de Aruba ClearPass y Purple WiFi. Cubre la configuración de proxy RADIUS, la asignación dinámica de VLAN y las mejores prácticas para ofrecer redes de invitados seguras y basadas en analítica junto con el NAC empresarial.
Cisco ISE vs. Purple WiFi: How They Compare and Work Together
Esta guía explica cómo Cisco ISE y Purple WiFi desempeñan funciones distintas pero complementarias en las redes empresariales. Detalla cómo utilizar Cisco ISE para un acceso corporativo 802.1X seguro, al tiempo que se aprovecha Purple para ofrecer un WiFi de invitados que cumpla con el GDPR, análisis de marketing e integración con CRM.