Randomize MAC Address: Recupere el control de los análisis de WiFi

! ==============================================================================
! 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á lleno. El lobby está completo, la fila de la cafetería llega hasta la puerta y su panel de WiFi muestra que los visitantes recurrentes han disminuido drásticamente. Los dispositivos que se conectaron ayer parecen completamente nuevos hoy. Las sesiones del Captive Portal siguen reapareciendo. Las tendencias de afluencia fluctúan sin motivo aparente.

Ahí es donde los equipos suelen empezar a culpar a la plataforma de analíticas, al proveedor de AP o a una mala actualización de firmware. En muchos entornos, el cambio real es más simple. Los clientes ahora aleatorizan la dirección MAC de forma predeterminada, y la red sigue intentando tratar las direcciones MAC como si fueran una identidad estable.

Esa incompatibilidad afecta mucho más que los informes. Impacta el control de acceso, la aplicación de políticas, la resolución de problemas y la experiencia de los invitados. Además, es algo que llegó para quedarse. Las funciones de privacidad ya están integradas en los sistemas operativos más comunes y hacen exactamente aquello para lo que fueron diseñadas: dificultar el rastreo de dispositivos entre redes.

La respuesta práctica no es luchar contra esta función para siempre. Es reconocer que la dirección MAC ya no es una clave primaria confiable para el WiFi moderno y luego rediseñar en función de señales de identidad más fuertes. 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

Lunes por la mañana, los números de la red WiFi de invitados no cuadran. Los visitantes que regresan han disminuido, los nuevos dispositivos van al alza y el equipo de soporte técnico tiene una fila de usuarios que aseguran haber completado el proceso de registro la semana pasada. He visto este patrón desencadenar la misma reacción en hoteles, centros comerciales, hospitales y complejos residenciales multi-inquilino. Los equipos comienzan a revisar los controladores, los registros del Captive Portal y las notas de firmware, aunque la WLAN suele comportarse exactamente como fue diseñada.

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

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 comienza a parecerse a la pérdida de clientes, re-registro o fallas en las políticas.

Qué es 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 métricas de análisis exageran la adquisición y subestiman la fidelidad.
• Vuelven a aparecer los avisos del Captive Portal: Los usuarios se vuelven a conectar pero reciben el trato de invitados primerizos porque la dirección ya no coincide con la sesión original.
• Las políticas basadas en MAC fallan de manera inconsistente: Las reglas vinculadas a una dirección específica dejan de aplicarse después de que el cliente rota su identidad.
• La resolución de problemas se vuelve más lenta: Los equipos de soporte ven múltiples registros de dispositivos para un mismo teléfono y pierden tiempo rastreando el historial incorrecto.

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 métricas analíticas

Este no es solo un problema de reportes. Los controles que dependen de las direcciones MAC muestran su obsolescencia rápidamente una vez que la rotación de direcciones se vuelve la norma. Las reservas de DHCP, el bypass de autenticación por MAC, las listas de permitidos de dispositivos, 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.

Esto no significa que la aleatorización de MAC sea un error. Resuelve un problema real de privacidad, especialmente en redes WiFi públicas donde el rastreo 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 tratan como desechable.

La solución es arquitectónica. Utilice la dirección MAC solo donde todavía sea de ayuda, luego cambie 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 de hardware estática, revise dónde la autenticación por dirección MAC en WiFi comienza a fallar y dónde el onboarding basado en la identidad le ofrece políticas más limpias, mejor capacidad de auditoría y análisis más confiables.

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

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

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

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

Cómo detectar una dirección aleatorizada

Hay una pista técnica rápida que la mayoría de los administradores pueden usar 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 pista clave
• Eso importa porque las suposiciones basadas en OUI ya no se aplican

Si su controlador de WLAN, plataforma NAC o registros RADIUS pueden exponer las direcciones MAC de los clientes al momento de la conexión, generalmente puede filtrar este patrón rápidamente.

Por qué fallan los diseños de WiFi más antiguos

Los diseños de WiFi heredados asumían que una dirección MAC representaba a un dispositivo de manera lo suficientemente constante como para anclar el acceso y la política. Es por eso que tantos entornos todavía la utilizan para:

• Decisiones de acceso: ACL de MAC y omisión de autenticación de MAC
• Gestión de direcciones: Asignaciones estáticas de DHCP
• Atajos de segmentación: Asignación de VLAN o roles específicos para cada dispositivo
• Registro heredado: Asignaciones simples de clave precompartida

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

Para un análisis más detallado de dónde choca esto con el onboarding heredado, esta guía de autenticación de 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 manera errónea a los dispositivos cliente que tengan habilitada la privacidad.

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

El cambio no afectó a todas las redes WLAN al mismo tiempo. Una red construida en la era de la aleatorización por escaneo podía parecer estable durante años y, de repente, empezar a mostrar dispositivos duplicados, fallas en el registro recurrente y análisis ruidosos después de una actualización rutinaria de los teléfonos. La infraestructura se mantuvo igual. El modelo de identidad de los clientes cambió.

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

Al principio, la aleatorización de MAC protegía principalmente el tráfico de sondeo. Los dispositivos enmascaraban su identidad mientras buscaban redes y luego solían usar una dirección estable una vez que se conectaban. Eso de todos modos afectaba las métricas pasivas de afluencia y algunos servicios de ubicación, pero muchas políticas de WLAN en producción sobrevivieron porque la dirección MAC del cliente asociado seguía siendo lo suficientemente predecible para el control de acceso.

Una ruptura operativa importante ocurrió más tarde, cuando las principales plataformas de clientes comenzaron a aplicar la aleatorización en la asociación como un comportamiento de privacidad predeterminado. En ese punto, la dirección MAC dejó de ser un anclaje confiable para el registro, la aplicación de políticas y los 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 importa. La aleatorización de sondeo afectaba principalmente a los observadores. La aleatorización de asociación afecta a los sistemas de los que depende todos los días.

Los sistemas operativos también tomaron caminos diferentes. Apple impulsó políticas de privacidad predeterminadas estrictas desde el principio y continuó perfeccionándolas. Android adoptó la misma dirección general, pero el comportamiento aún varía según el fabricante, el chipset y la política de administración. Windows suele ser el más variado, especialmente en laptops que se mueven entre SSIDs corporativos administrados y redes residenciales o de invitados no administradas.

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

Sistema Operativo	Comportamiento Predeterminado	Alcance de la Aleatorización	Notas para el Administrador
iOS	Habilitado de forma predeterminada en redes WiFi modernas	Comúnmente persistente por SSID	Fuertes valores predeterminados de privacidad. Los controles heredados basados en MAC suelen fallar a menos que el SSID se administre explícitamente.
Android	Habilitado de forma predeterminada en versiones modernas	A menudo por SSID, con cierta variación según el dispositivo y la política	Las diferencias entre proveedores importan. 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	Supervise las laptops de uso mixto. Los SSIDs corporativos pueden requerir configuraciones administradas, mientras que los SSIDs de invitados pueden mantener un enfoque respetuoso con la privacidad.

Por qué el cronograma es importante a nivel operativo

Muchos diseños empresariales aún reflejan supuestos de la época de transición. Un equipo de TI podría recordar que la aleatorización era "principalmente un problema de escaneo" y subestimar lo que cambió después de que los sistemas operativos más recientes convirtieran las direcciones MAC privadas en parte del comportamiento normal de asociación. Es así como los flujos de trabajo heredados de MAB, las reservas de DHCP específicas para dispositivos y los registros de invitados vinculados a la MAC siguen en producción mucho después de que el lado del cliente dejó de cooperar.

Esto también forma parte de una tendencia de privacidad más amplia, no es una anomalía aislada de 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 pila, lo que significa que los equipos de red necesitan métodos de identidad que resistan este cambio.

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

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

Cómo interrumpe 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 visto" 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 utilizan por defecto la aleatorización de direcciones MAC, lo que genera una relación de 1 a muchos entre un dispositivo físico y sus direcciones MAC reportadas. Esto complica el conteo de dispositivos únicos y afecta las analíticas y la personalización, de acuerdo con el análisis de CUJO sobre el impacto en los operadores de servicios de red.

Controles de seguridad que dejan de ser confiables

Las primeras bajas 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 estilo 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 podría ya no utilizar.
• Los mapeos de iPSK heredados se fragmentan: Un usuario o un teléfono pueden parecer múltiples endpoints.

Esto no siempre falla de forma evidente. Eso es lo que lo hace operativamente costoso. Los equipos ven quejas de acceso intermitente, 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.

Métricas analíticas en las que resulta más difícil confiar

Para los establecimientos, el impacto en las analíticas suele ser el problema comercial más visible. El análisis de afluencia, tiempo de permanencia, tasa de retorno y el recorrido del cliente 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 fuerte, pero las visitas recurrentes pueden parecer bajas porque los dispositivos antes familiares ahora aparecen con identificadores nuevos. Un hotel puede creer que tiene más huéspedes primerizos en la red de los que realmente tiene. Un centro de salud puede tener dificultades para separar claramente la movilidad del personal de la actividad de los visitantes.

Si su equipo depende de informes de presencia y comportamiento, esta guía de analítica de 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 plena vista

Algunos de los problemas más complejos se presentan al 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 de dispositivos se fragmenta en los registros de la mesa de ayuda

Los equipos de operaciones a menudo describen esto como "WiFi inestable" cuando la RF está bien y la verdadera falla es la continuidad de la identidad.

Técnicas aplicables para la detección y mitigación

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

Comience con la detección en las herramientas que ya ejecuta

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

Busque tres cosas:

1. Clientes con el segundo dígito hexadecimal con valor de 2, 6, A o E
2. Fallas repetidas de registro vinculadas al mismo usuario pero con diferentes MAC
3. Anomalías específicas de SSID, especialmente en redes de invitados, BYOD y redes residenciales compartidas

Una simple revisión interna suele revelar que la aleatorización no se distribuye de manera uniforme. Los SSID de invitados suelen mostrarla primero. Los SSID del personal empiezan a presentar problemas cuando se conectan dispositivos no gestionados o ligeramente gestionados. Los entornos de múltiples inquilinos suelen ser los más afectados porque la red intenta admitir dispositivos de consumo y aplicar políticas al mismo tiempo.

Decidir dónde es defendible el bloqueo

Muchos equipos hacen la misma pregunta después. ¿Deberíamos bloquear las MAC aleatorias? La respuesta honesta es que puede ser útil como un 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 administrado
• 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

El bloqueo suele ser contraproducente cuando:

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

El balance es simple. El bloqueo restablece cierto control, pero generalmente degrada la experiencia del usuario y genera costos de soporte evitables.

Mitigaciones tácticas que funcionan hoy en día

Vale la pena utilizar mitigaciones a corto plazo si permiten ganar tiempo para un rediseño adecuado:

• Segmente por caso de uso: Mantenga el acceso administrado del personal separado del acceso de invitados y de dispositivos personales (BYOD).
• Utilice MDM donde controle los dispositivos: En los SSIDs corporativos, impulse perfiles de red en lugar de depender de que los usuarios cambien la configuración de privacidad de forma manual.
• Retire los supuestos dependientes de MAC: Audite las reservas de DHCP, los accesos directos de NAC y las reglas específicas de cada dispositivo.
• Documente 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 y no como el modelo predeterminado.

Ninguna de esas soluciones resuelve el problema de identidad subyacente. Simplemente evitan que se propague a cada rincón de las operaciones.

Adoptar el futuro con redes basadas en 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 puede confiar: un usuario, un certificado, un objeto de directorio, una decisión sobre el estado del dispositivo o un estado de onboarding federado.

Por qué Passpoint y OpenRoaming cambian la ecuación

Passpoint y OpenRoaming se convierten, por lo tanto, en algo más que 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 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 por defecto, y las redes que no cuentan con el soporte adecuado pueden experimentar hasta un 40% de fallas de autenticación en el primer paquete. El mismo borrador de la IETF señala que implementar Hotspot 2.0 con indicaciones de aleatorización ANQP puede reducir las reasociaciones en un 35%, razón por la cual vale la pena leer con atención el borrador de la IETF sobre la aleatorización de direcciones MAC para 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 identidad respaldada por directorio: Entra ID, Google Workspace, u Okta pueden canalizar el acceso en torno a la persona y al estado del dispositivo administrado.
• Los certificados reemplazan a los secretos compartidos siempre que sea posible: Se escalan mejor y resisten los cambios de privacidad de forma mucho más limpia que la lógica vinculada a MAC.
• Los dispositivos heredados obtienen un carril de excepción controlado: iPSK todavía tiene un lugar para impresoras, IoT y endpoints complejos, pero no debe 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, escribiendo artículos de soporte para cada modelo de teléfono y lidiando con comportamientos inconsistentes tras cada actualización del sistema operativo. O bien, puede migrar la red a un diseño que asuma que los clientes protegerán su identidad de forma predeterminada.

El segundo camino es más sostenible. También mejora la seguridad. Las contraseñas compartidas, los Captive Portals frágiles y las búsquedas de MAC siempre fueron soluciones de compromiso. La aleatorización simplemente expuso lo débiles que se habían vuelto 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 de MAC

¿La aleatorización de 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 con 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 específicos. Para dispositivos gestionados del personal en un SSID corporativo, eso puede ser razonable si la configuración se envía mediante MDM y se vincula a una política clara. Para invitados, residentes o visitantes ocasionales, pedirles que desactiven una función de privacidad suele resultar en una mala experiencia y en una carga de soporte técnico.

¿Por qué las residencias de estudiantes y las propiedades de Build-to-Rent se ven tan afectadas?

Porque estos entornos a menudo mezclan dispositivos de consumo, patrones de registro heredados y una alta sensibilidad al soporte técnico. En el Reino Unido, las viviendas de alquiler administrado y las residencias estudiantiles han registrado un aumento del 31% en las quejas sobre el acceso a WiFi, con un 55% vinculadas a direcciones MAC aleatorias que fragmentan las políticas de iPSK, según esta guía sobre problemas de direcciones MAC aleatorias.

Qué funciona mejor en entornos multi-inquilino

Divida el problema en diferentes flujos. Utilice un registro basado en identidad para residentes y personal, mantenga las excepciones heredadas estrictamente controladas y evite diseñar soluciones que dependan de la visibilidad persistente de las direcciones MAC. Cuanto más dependa un sitio de iPSK como respuesta universal, más inestable se volverá a medida que se expandan 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 esa transición. 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 con un acceso seguro y sin contraseñas que funciona en entornos de hotelería, comercio minorista, salud, transporte y residenciales.