Aleatorizar la dirección MAC: recupere el control de WiFi Analytics

! ==============================================================================
! WLAN Controller Profile: Passpoint Hotspot 2.0 and ANQP Identity Architecture
! Purpose: Neutralize MAC randomization impact and enable authenticated CRM roaming
! Network: RFC 1918 Private Subnet (10.10.30.0/24) | Safe RFC 5737 Doc RADIUS
! ==============================================================================

wlan passpoint-profile "PURPLE-SECURE-IDENTITY"
  enable
  he-profile "WIFI-6-AX-ENTERPRISE"
  venue-group "Commercial"
  venue-type "ShoppingMall"
  network-type "FreePublic"
  internet-access
  asra-capability
  ip-addr-type-avail "IPv4-Single-NAT,IPv6"

  ! ANQP Roaming Consortium OI for OpenRoaming / Hotspot 2.0
  roaming-consortium "5A-03-BA-00-00"
  roaming-consortium "BA-A2-F0-00-00"

  ! Domain list matching venue identity domain
  domain-name "guest.purple.ai"
  domain-name "connect.venue.internal"

  ! NAI Realm matching authenticated visitor federations
  nai-realm 1 name "purple.ai"
    eap-method eap-tls
    eap-method eap-ttls
      inner-auth mschapv2

  ! 3GPP Cellular Data Offload PLMN hints
  3gpp-plmn 234-15
  3gpp-plmn 234-30

exit

wlan ssid "Purple-Secure-Passpoint"
  vlan 30
  security wpa3-enterprise
  pmf-mode required
  passpoint-profile "PURPLE-SECURE-IDENTITY"

  ! Client Isolation on internal private broadcast domain
  station-isolation enable

  ! Remote RADIUS AAA Configuration (Safe RFC 5737 doc endpoints, placeholder secrets)
  radius-server primary host 192.0.2.10 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  radius-server secondary host 192.0.2.11 auth-port 1812 acct-port 1813
    key <RADIUS_SHARED_SECRET>
    timeout 3
    retransmit 2

  accounting-server-group "PURPLE-RADIUS-CLUSTER"
    interim-update-interval 600
exit

interface vlan 30
  description "Purple Guest Isolated Client Network"
  ip address 10.10.30.1 255.255.255.0
  ip access-group "ISOLATE-INTERNAL-SUBNETS" in
exit

Su establecimiento está concurrido. El vestíbulo está lleno, la cola de la cafetería llega hasta la puerta y su panel de control de WiFi indica que los visitantes recurrentes han caído en picado. Los dispositivos que se conectaron ayer parecen completamente nuevos hoy. Las sesiones del Captive Portal no dejan de reaparecer. Las tendencias de afluencia oscilan sin motivo aparente.

Ese suele ser el momento en que los equipos empiezan a culpar a la plataforma de analítica, al proveedor de AP o a una versión de firmware defectuosa. En muchos entornos, el cambio real es más sencillo. Los clientes ahora randomize mac address de forma predeterminada, y la red sigue intentando tratar las direcciones MAC como si fueran una identidad estable.

Esa discrepancia rompe más que los informes. Afecta al control de acceso, a la aplicación de políticas, a la resolución de problemas y a la experiencia de los invitados. Y tampoco va a desaparecer. Las funciones de privacidad ya están integradas en los principales sistemas operativos y hacen exactamente lo que se diseñó para ellas: dificultar el seguimiento de dispositivos entre redes.

La respuesta práctica no es luchar contra esta función para siempre. Consiste en reconocer que la dirección MAC ya no es una clave primaria fiable para el WiFi moderno y rediseñar el sistema en torno a señales de identidad más sólidas. Ahí es donde Passpoint, OpenRoaming, el registro basado en certificados y el acceso respaldado por directorios empiezan a cobrar importancia.

El misterioso caso de los dispositivos que desaparecen

El lunes por la mañana, los números de la red WiFi de invitados no cuadran. Los visitantes recurrentes disminuyen, los nuevos dispositivos aumentan y el servicio de soporte técnico tiene una cola de usuarios que aseguran haber completado el proceso de registro la semana pasada. En hoteles, parques comerciales, hospitales y complejos residenciales, he visto que este patrón desencadena la misma reacción una y otra vez. Los equipos empiezan a revisar los controladores, los registros del Captive Portal y las notas de firmware, a pesar de que la WLAN suele funcionar exactamente como fue diseñada.

Lo que ha cambiado es la señal de identidad. Los dispositivos cliente siguen apareciendo. Simplemente dejan de presentar una dirección de hardware que se pueda tratar como persistente. Un mismo teléfono puede mostrarse con diferentes valores de MAC en los escaneos, asociaciones o SSIDs, según la plataforma y la configuración de privacidad activa.

Eso rompe la confianza en el lugar equivocado. Si la red sigue tratando la dirección MAC como la clave principal, el comportamiento normal del usuario empieza a parecerse a un abandono, a un nuevo registro o a un fallo en las políticas.

Lo que los administradores suelen notar primero

Las primeras pistas suelen ser operativas, no teóricas:

• Los recuentos de visitantes recurrentes se desvían: Un dispositivo conocido parece nuevo, por lo que las analíticas exageran la captación y subestiman la fidelidad.
• Vuelven a aparecer las solicitudes del Captive Portal: Los usuarios se vuelven a conectar pero se les trata como invitados nuevos porque la dirección ya no coincide con la sesión original.
• Las políticas basadas en MAC fallan de forma inconsistente: Las reglas vinculadas a una dirección específica dejan de aplicarse una vez que el cliente rota su identidad.
• La resolución de problemas se ralentiza: Los equipos de soporte ven múltiples registros de dispositivo para un mismo terminal y pierden tiempo analizando el historial equivocado.

La red sigue transportando al cliente. Simplemente ya no tiene una forma estable basada en MAC para reconocerlo.

Por qué esto va más allá de las analíticas

Esto no es solo un problema de informes. Los controles basados en direcciones MAC muestran su obsolescencia rápidamente una vez que la rotación de direcciones pasa a ser lo normal. Las reservas de DHCP, la omisión de autenticación por MAC, las listas de dispositivos permitidos, algunos métodos de perfilado NAC y los flujos de trabajo de invitados más antiguos dependen de una continuidad que muchos clientes modernos ya no ofrecen.

Eso no convierte a la aleatorización de MAC en un error. Resuelve un problema real de privacidad, especialmente en redes WiFi públicas donde el seguimiento pasivo solía ser demasiado sencillo. El problema operativo es que muchas redes se crearon en torno a un identificador que los sistemas operativos ahora consideran desechable.

La solución es arquitectónica. Utilice la dirección MAC solo donde siga siendo útil, y luego traslade el control de acceso y las políticas a señales de identidad más sólidas, como certificados, autenticación de usuario, estado del dispositivo, perfiles Passpoint y modelos de federación como OpenRoaming. Si su diseño actual todavía depende en gran medida de la identidad estática del hardware, revise dónde la autenticación por dirección MAC en WiFi comienza a fallar y dónde el registro basado en la identidad le proporciona políticas más claras, una mejor capacidad de auditoría y análisis más fiables.

Las redes que se adaptan a ese modelo dejan de perseguir dispositivos invisibles y empiezan, en su lugar, a rastrear usuarios autenticados, dispositivos de confianza y sesiones válidas.

¿Qué es la aleatorización de direcciones MAC?

Una dirección MAC de fábrica es como una tarjeta de identificación permanente impresa en el momento de la fabricación. La aleatorización de direcciones MAC es la tarjeta desechable que un dispositivo elige usar en su lugar, para que las redes cercanas no puedan seguirlo fácilmente de un establecimiento a otro.

Ese es el caso de la privacidad en términos sencillos. Los operadores de WiFi público, los anunciantes y los terceros solían depender en gran medida de las direcciones MAC estables para el reconocimiento pasivo. La aleatorización reduce esa visibilidad al reemplazar la dirección de hardware por una administrada localmente.

Cómo detectar una dirección aleatoria

Existe una pista técnica rápida que la mayoría de los administradores pueden utilizar de inmediato. Una dirección MAC aleatorizada se puede identificar porque su segundo dígito hexadecimal será 2, 6, A o E, como se muestra en la guía de Mist sobre la aleatorización de direcciones MAC. La misma guía señala que las políticas heredadas que esperan una OUI asignada por el fabricante fallarán con una tasa de rechazo del 100 % frente a esas direcciones.

Ejemplo:

• 92:B1:B8:42:D1:85 indica una dirección administrada localmente
• El segundo dígito hexadecimal es la clave que lo revela
• Esto es importante porque las suposiciones basadas en OUI ya no se aplican

Si tu controlador WLAN, plataforma NAC o registros RADIUS pueden exponer las direcciones MAC de los clientes en el momento de la unión, normalmente puedes filtrar por este patrón de forma rápida.

Por qué se rompen los diseños de WiFi antiguos

Los diseños de WiFi heredados asumían que una dirección MAC representaba a un dispositivo de forma lo suficientemente constante como para servir de anclaje para el acceso y las políticas. Por eso, muchos entornos todavía la utilizan para:

• Decisiones de acceso: ACL de MAC y omisión de autenticación MAC
• Gestión de direcciones: Asignaciones DHCP estáticas
• Atajos de segmentación: VLAN específica del dispositivo o asignación de roles
• Registro heredado: Asignaciones sencillas de clave previamente compartida

Esos flujos de trabajo tenían sentido cuando el identificador de hardware permanecía fijo. No se sostienen cuando los clientes realizan la aleatorización por diseño.

Para un análisis más detallado de dónde choca esto con los procesos de incorporación tradicionales, esta guía de autenticación por dirección MAC para WiFi es una lectura complementaria muy útil.

Regla práctica: Si su política depende de las OUI del fabricante, asuma que clasificará de forma incorrecta a los dispositivos cliente que tengan activada la privacidad.

La evolución de la aleatorización en los dispositivos

El cambio no afectó a todas las WLAN a la vez. Una red construida en la era de la aleatorización por escaneo podía parecer estable durante años, para luego empezar a mostrar dispositivos duplicados, fallos de reasociación y analíticas distorsionadas tras una renovación habitual de terminales. La infraestructura seguía siendo la misma. El modelo de identidad del cliente cambió.

De la privacidad de escaneo a la identidad de conexión

La aleatorización de MAC inicial protegía principalmente el tráfico de sondeo. Los dispositivos enmascaraban su identidad mientras buscaban redes y, a menudo, utilizaban una dirección estable una vez conectados. Esto afectaba a las analíticas pasivas de afluencia y a algunos servicios de localización, pero muchas políticas de WLAN de producción sobrevivieron porque la dirección MAC del cliente asociado seguía siendo lo suficientemente predecible para el control de acceso.

Posteriormente se produjo una ruptura operativa significativa, cuando las principales plataformas de clientes comenzaron a aplicar por defecto la aleatorización en la asociación como un comportamiento de privacidad. En ese momento, la dirección MAC dejó de ser un anclaje fiable para el registro, la aplicación de políticas y la generación de informes. Los administradores que habían tolerado los sondeos aleatorios de repente tuvieron que lidiar con identidades aleatorias en la sesión activa.

Esa distinción es importante. La aleatorización de sondeo afectaba principalmente a los observadores. La aleatorización de asociación afecta a los sistemas de los que dependes cada día.

Los sistemas operativos también tomaron caminos diferentes. Apple impulsó políticas de privacidad estrictas por defecto desde el principio y continuó perfeccionándolas. Android adoptó la misma dirección general, pero el comportamiento sigue variando según el fabricante, el chipset y la política de gestión. Windows suele presentar la mayor diversidad, especialmente en ordenadores portátiles que se mueven entre SSIDs corporativos gestionados y redes de invitados o domésticas no gestionadas.

Comportamiento de la aleatorización MAC por sistema operativo a partir de 2026

Sistema Operativo	Comportamiento por Defecto	Ámbito de la Aleatorización	Notas para el Administrador
iOS	Activado por defecto en redes WiFi modernas	Comúnmente persistente por SSID	Privacidad estricta por defecto. Los controles heredados basados en MAC suelen fallar a menos que el SSID se gestione de forma explícita.
Android	Activado por defecto en versiones modernas	A menudo por SSID, con cierta variación según el dispositivo y la política	Las diferencias entre fabricantes son importantes. Pruebe Samsung, Pixel, Zebra y otros tipos de flotas por separado.
Windows 10 and 11	Varía según el perfil y la capacidad del dispositivo	Puede basarse en el perfil, con comportamientos de rotación opcionales	Atención a los ordenadores portátiles de uso mixto. Los SSIDs corporativos pueden necesitar ajustes gestionados mientras que los SSIDs de invitados pueden mantener la privacidad activada.

Por qué el calendario es importante a nivel operativo

Muchos diseños empresariales aún reflejan suposiciones del periodo de transición. Un equipo puede recordar que la aleatorización era "principalmente un problema de escaneo" y subestimar los cambios que se produjeron después de que las versiones de OS más recientes convirtieran las MAC privadas en parte del comportamiento normal de asociación. Así es como los flujos de trabajo de MAB heredados, las reservas DHCP específicas de cada dispositivo y los registros de invitados vinculados a la MAC siguen en producción mucho después de que el lado del cliente dejara de cooperar.

Esto también forma parte de una tendencia de privacidad más amplia, no es una anomalía aislada de la WiFi. El modelo de privacidad iCloud Private Relay de Apple apunta en la misma dirección. Los proveedores de dispositivos finales están reduciendo los identificadores pasivos en toda la infraestructura, lo que significa que los equipos de red necesitan métodos de identidad que sobrevivan a este cambio.

La respuesta práctica no consiste en forzar de nuevo una identidad de hardware permanente en el diseño. Se trata de trasladar la decisión de confianza a un nivel superior de la pila. Passpoint, el registro basado en certificados y OpenRoaming ofrecen a los administradores una forma estable de identificar a usuarios y dispositivos sin depender de una dirección MAC de fábrica que las plataformas modernas tratan cada vez más como privada.

Si el diseño de una red WiFi depende de una dirección de hardware permanente para reconocer a un cliente, ese diseño se está quedando obsoleto. El acceso basado en la identidad ofrece un camino más limpio que intentar recuperar la visibilidad de las MAC.

Cómo altera la aleatorización las operaciones de red

La forma más clara de describir el daño es esta: la aleatorización rompe el antiguo atajo entre "dispositivo detectado" y "dispositivo conocido". Una vez que ese atajo desaparece, varias prácticas operativas comunes se desmoronan al mismo tiempo.

Más del 30 % de los dispositivos móviles recurren por defecto a la aleatorización de MAC, lo que genera una relación de 1 a muchos entre un dispositivo físico y sus MAC registradas, complicando el recuento de dispositivos únicos y alterando las analíticas y la personalización, según el análisis de CUJO sobre el impacto en los operadores de servicios de red.

Controles de seguridad que dejan de ser fiables

Las primeras víctimas suelen ser los controles basados en MAC:

• Las ACL de MAC pierden sentido: un dispositivo puede presentar una dirección diferente a la que usted aprobó.
• Los flujos de trabajo de tipo MAB se vuelven frágiles: la lista blanca es tan estable como el identificador que contiene.
• Las reservas de DHCP estáticas se rompen: la reserva pertenece a una dirección que el cliente ya no puede usar.
• Las asignaciones de iPSK heredadas se fragmentan: un solo usuario o un solo terminal pueden parecer múltiples endpoints.

Esto no siempre genera un fallo evidente, y eso es precisamente lo que lo hace operativamente costoso. Los equipos ven quejas intermitentes de acceso, desajustes de políticas o roles de dispositivos aplicados de manera inconsistente, y la causa raíz se encuentra un nivel por debajo del síntoma.

Analíticas que se vuelven más difíciles de confiar

Para los establecimientos, el impacto en las analíticas suele ser el problema empresarial más visible. El análisis de afluencia, tiempo de permanencia, tasa de retorno y recorrido dependen de cierta confianza en que las observaciones repetidas pertenecen a la misma entidad. La aleatorización debilita esa confianza.

Un centro comercial puede seguir teniendo un tráfico intenso, pero las visitas recurrentes pueden parecer bajas porque los teléfonos que antes eran conocidos ahora aparecen bajo nuevos identificadores. Un hotel puede pensar que tiene más huéspedes primerizos en la red de los que realmente tiene. Un centro sanitario puede tener dificultades para diferenciar claramente la movilidad del personal de la actividad de los visitantes.

Si su equipo depende de los informes de presencia y comportamiento, esta guía de analítica WiFi es una referencia útil para las métricas que tienen más probabilidades de verse afectadas.

Problemas de experiencia de usuario que se ocultan a simple vista

Algunos de los problemas más complejos se sitúan en el límite de la autenticación:

• Los Captive Portals pueden volver a solicitar credenciales a los usuarios de forma inesperada
• Los flujos de reautenticación se vuelven inconsistentes entre visitas
• La resolución de problemas se vuelve más lenta porque la MAC de ayer no es la MAC de hoy
• El historial del dispositivo se fragmenta en los registros del servicio de soporte

Los equipos de operaciones a menudo describen esto como "WiFi inestable" cuando la RF funciona perfectamente y el fallo real está en la continuidad de la identidad.

Técnicas prácticas de detección y mitigación

No se puede modernizar una infraestructura si antes no se cuantifica el problema. El objetivo inmediato no es eliminar la aleatorización, sino identificar dónde aparece, qué flujos de trabajo dependen de direcciones MAC estables y qué SSIDs están más expuestos.

Comienza con la detección en herramientas que ya ejecutas

La mayoría de las plataformas WLAN empresariales ya exponen suficiente telemetría para detectar direcciones de privacidad. En Meraki, Aruba, Juniper Mist, Ruckus y plataformas similares, inspeccione las listas de clientes, los fallos de autenticación y el historial de sesiones para identificar patrones de MAC administradas localmente. Combine esto con los registros de RADIUS si utiliza motores de políticas o NAC.

Busque tres cosas:

1. Clientes con el segundo dígito hexadecimal como 2, 6, A o E
2. Errores repetidos de incorporación vinculados al mismo usuario pero con diferentes MAC
3. Anomalías específicas del SSID, especialmente en redes de invitados, BYOD y redes residenciales compartidas

Una revisión interna sencilla suele revelar que la aleatorización no se distribuye de manera uniforme. Los SSID de invitados suelen ser los primeros en mostrarla. Los SSID de empleados empiezan a dar problemas cuando se conectan dispositivos no gestionados o con una gestión básica. Los entornos multiinquilino suelen ser los más afectados, ya que la red intenta dar soporte a dispositivos de consumo y aplicar políticas al mismo tiempo.

Decide dónde es defendible el bloqueo

Muchos equipos se hacen la misma pregunta a continuación: ¿Deberíamos bloquear las MAC aleatorias? La respuesta sincera es que puede ser útil como control temporal en un conjunto reducido de casos, pero es una mala estrategia a largo plazo.

El bloqueo puede ayudar cuando:

• Un SSID corporativo requiere una postura estricta de dispositivo gestionado
• Necesita preservar un flujo de trabajo heredado mientras se implementa un reemplazo
• Una clase de dispositivo específica debe usar una identidad fija y conocida por razones operativas o de cumplimiento normativo

El bloqueo suele ser contraproducente cuando:

• El SSID es público, está orientado a invitados o tiene una alta rotación
• Los usuarios no entienden fácilmente cómo desactivar la función
• Su servicio de soporte no está equipado para asesorar sobre cada variante de sistema operativo
• Necesita un acceso sin fricciones, no otra ruta de excepción

La compensación es simple. El bloqueo restablece cierto control, pero normalmente degrada la experiencia de usuario y crea costes de soporte evitables.

Mitigaciones tácticas que funcionan hoy

Vale la pena recurrir a las mitigaciones a corto plazo si sirven para ganar tiempo de cara a un rediseño adecuado:

• Segmentar por caso de uso: Mantenga el acceso gestionado del personal separado del acceso de invitados y BYOD.
• Utilizar MDM donde controle los dispositivos: En los SSIDs corporativos, distribuya perfiles de red en lugar de depender de que los usuarios cambien la configuración de privacidad manualmente.
• Retirar las suposiciones dependientes de la MAC: Audite las reservas de DHCP, los accesos directos de NAC y las reglas específicas de dispositivos.
• Documentar los flujos de trabajo de excepción: Si un dispositivo médico, impresora o consola necesita una identidad estable, trátelo como una excepción específica, no como el modelo por defecto.

Ninguna de esas correcciones resuelve el problema de identidad subyacente. Solo evitan que se extienda a cada rincón de las operaciones.

Abrazando el futuro con redes basadas en la identidad

La respuesta más sólida a la aleatorización de MAC es dejar de tratar la dirección MAC como el centro de confianza. Ese es el cambio de diseño fundamental. Las redes basadas en la identidad trasladan el punto de decisión de un token de hardware mutable a algo en lo que la red pueda confiar: un usuario, un certificado, un objeto de directorio, una decisión sobre el estado del dispositivo o un estado de registro federado.

Por qué Passpoint y OpenRoaming cambian la ecuación

Passpoint y OpenRoaming se convierten, por lo tanto, en algo más que meras funciones de conveniencia. Reducen la dependencia de los Captive Portals y las contraseñas compartidas, y permiten que la red tome decisiones de confianza antes incluso de que comience el antiguo flujo de trabajo de invitados.

Esto es importante porque el 72 % de los dispositivos móviles del Reino Unido ahora aleatorizan las direcciones MAC de forma predeterminada, y las redes sin la compatibilidad adecuada pueden experimentar hasta un 40 % de fallos de autenticación en el primer paquete. El mismo borrador del IETF señala que la implementación de Hotspot 2.0 con indicaciones de aleatorización ANQP puede reducir las reasociaciones en un 35 %, razón por la cual el borrador del IETF sobre la aleatorización de direcciones MAC merece una lectura detenida por parte de los arquitectos que planifican entornos residenciales y de invitados.

Passpoint cambia el modelo de "¿quién es esta MAC?" a "¿tiene este dispositivo una relación de incorporación válida para esta red?". Esa es una pregunta mucho mejor.

Cómo es un diseño moderno

Una arquitectura práctica suele tener estos rasgos:

• El acceso de invitados utiliza Passpoint o OpenRoaming: El usuario se autentica una vez y obtiene conectividad cifrada desde el primer paquete en sus visitas recurrentes.
• El acceso del personal utiliza la identidad respaldada por el directorio: Microsoft Entra ID, Google Workspace u Okta pueden articular el acceso en torno a la persona y el estado del dispositivo gestionado.
• Los certificados sustituyen a los secretos compartidos siempre que es posible: Se escalan mejor y sobreviven a los cambios de privacidad de forma mucho más limpia que la lógica vinculada a la MAC.
• Los dispositivos heredados obtienen un canal de excepción controlado: iPSK sigue teniendo su utilidad para impresoras, IoT y puntos finales complejos, pero no debería definir todo su modelo de acceso.

Por qué esto es mejor que intentar revertir la privacidad

Puede pasar meses persuadiendo a los usuarios para que desactiven las funciones de privacidad, redactando artículos de ayuda para cada modelo de terminal y lidiando con comportamientos inconsistentes tras cada actualización del sistema operativo. O puede migrar la red a un diseño que asuma que los clientes protegerán su identidad de forma predeterminada.

La segunda opción es más sostenible y también mejora la seguridad. Las contraseñas compartidas, los Captive Portal inestables y las búsquedas de MAC siempre fueron soluciones de compromiso. La aleatorización solo ha dejado al descubierto lo débiles que eran esas soluciones.

El objetivo no es restaurar el antiguo modelo de visibilidad. El objetivo es construir una red que ya no lo necesite.

Preguntas frecuentes sobre la aleatorización MAC

¿La aleatorización MAC mejora la seguridad o solo la privacidad?

Principalmente por privacidad. Ayuda a evitar el rastreo entre redes al ocultar la dirección de hardware permanente. No demuestra automáticamente que el usuario sea de confianza, que el dispositivo cumpla las normas o que la sesión sea segura. Por eso, los controles de identidad, certificados y estado de seguridad siguen siendo importantes.

¿Deberíamos pedir a los usuarios que la desactiven?

Solo en casos muy concretos. Para dispositivos gestionados del personal en un SSID corporativo, esto puede ser razonable si la configuración se distribuye mediante MDM y se vincula a una política clara. Para invitados, residentes o visitantes ocasionales, pedir a los usuarios que desactiven una función de privacidad suele traducirse en una mala experiencia y una carga de soporte técnico.

¿Por qué las residencias de estudiantes y el alquiler residencial (Build-to-Rent) se ven tan afectados?

Porque esos entornos suelen mezclar dispositivos de consumo, patrones de registro heredados y una alta sensibilidad al soporte técnico. En el Reino Unido, las viviendas de alquiler residencial (Build-to-Rent) y las residencias de estudiantes han experimentado un aumento del 31 % en las quejas sobre el acceso WiFi, con un 55 % de ellas vinculadas a que las MAC aleatorias fragmentan las políticas de iPSK, según esta guía sobre problemas de direcciones MAC aleatorias.

Qué funciona mejor en entornos multiinquilino

Separe el problema por áreas. Utilice un proceso de incorporación basado en la identidad para residentes y empleados, mantenga bajo estricto control las excepciones heredadas y evite diseñar en función de la visibilidad persistente de las direcciones MAC. Cuanto más dependa un centro de iPSK como respuesta universal, más inestable se volverá a medida que se amplíen las funciones de privacidad de los clientes.

---

Si está replanteando el WiFi para invitados, personal o multiinquilino en torno a la identidad en lugar de las direcciones de hardware, Purple está diseñado para ese cambio. Es compatible con Passpoint y OpenRoaming, se integra con Microsoft Entra ID, Google Workspace y Okta, y ayuda a reemplazar las contraseñas compartidas y la fricción del Captive Portal por un acceso seguro y sin contraseña que funciona en entornos hoteleros, minoristas, sanitarios, de transporte y residenciales.