Randomização do Endereço MAC: Retome o Controlo da Análise 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

O seu espaço está movimentado. O átrio está cheio, a fila do café sai pela porta fora e o seu painel de WiFi diz que os visitantes recorrentes caíram a pique. Dispositivos que se ligaram ontem parecem completamente novos hoje. As sessões do Captive Portal continuam a reaparecer. As tendências de tráfego pedonal oscilam sem motivo aparente.

Esse é geralmente o ponto em que as equipas começam a culpar a plataforma de análise, o fabricante do AP ou uma versão de firmware com problemas. Em muitos ambientes, a alteração real é mais simples. Os clientes agora efetuam a randomize mac address por predefinição, e a rede continua a tentar tratar os endereços MAC como se fossem uma identidade estável.

Essa incompatibilidade prejudica mais do que os relatórios. Afeta o controlo de acessos, a aplicação de políticas, a resolução de problemas e a experiência do convidado. Além disso, não vai desaparecer. As funcionalidades de privacidade estão agora integradas nos sistemas operativos principais e estão a fazer exatamente aquilo para que foram concebidas: dificultar a monitorização de dispositivos entre redes.

A resposta prática não é combater a funcionalidade para sempre. É reconhecer que o endereço MAC já não é uma chave primária fiável para o WiFi moderno e, em seguida, redesenhar em torno de sinais de identidade mais fortes. É aí que o Passpoint, o OpenRoaming, a integração baseada em certificados e o acesso apoiado por diretório começam a ser importantes.

O Caso Misterioso dos Dispositivos que Desaparecem

Na segunda-feira de manhã, os números do WiFi de convidados parecem errados. Os visitantes recorrentes diminuíram, os novos dispositivos aumentaram e o helpdesk tem uma fila de utilizadores que juram que já concluíram o onboarding na semana passada. Em hotéis, parques de retalho, hospitais e condomínios, já vi este padrão desencadear sempre a mesma reação. As equipas começam a verificar os controladores, os registos do Captive Portal e as notas de firmware, embora a WLAN esteja muitas vezes a comportar-se exatamente como foi concebida.

O que mudou foi o sinal de identidade. Os dispositivos dos clientes continuam a aparecer. Simplesmente deixam de apresentar um endereço de hardware que possa tratar como persistente. Um telemóvel pode aparecer sob diferentes valores de MAC em pesquisas, associações ou SSIDs, dependendo da plataforma e das definições de privacidade ativas.

Isso quebra a confiança no ponto errado. Se a rede continuar a tratar o endereço MAC como a chave primária, o comportamento normal do utilizador começa a parecer-se com rotatividade, novo registo ou falha de política.

O que os administradores costumam notar primeiro

As primeiras pistas são normalmente operacionais, não teóricas:

• As contagens de visitantes recorrentes sofrem desvios: Um dispositivo familiar parece novo, pelo que a análise sobrestima a aquisição e subestima a fidelidade.
• Os avisos do Captive Portal regressam: Os utilizadores voltam a ligar-se, mas são tratados como convidados de primeira viagem porque o endereço já não corresponde à sessão original.
• As políticas baseadas em MAC falham de forma inconsistente: As regras associadas a um endereço específico deixam de se aplicar após o cliente rodar a identidade.
• A resolução de problemas torna-se mais lenta: As equipas de suporte veem múltiplos registos de dispositivos para um único telemóvel e perdem tempo a analisar o histórico errado.

A rede continua a suportar o cliente. Simplesmente já não tem uma forma estável baseada em MAC para o reconhecer.

Porque é que isto vai além dos dados analíticos

Isto não é apenas um problema de relatórios. Os controlos dependentes do MAC mostram a sua idade rapidamente assim que a rotação de endereços se torna normal. Reservas DHCP, desvio de autenticação MAC, listas de permissões de dispositivos, alguns métodos de criação de perfis NAC e fluxos de trabalho de convidados mais antigos dependem todos de uma continuidade que muitos clientes modernos já não fornecem.

Isso não faz da aleatoriedade do MAC um erro. Resolve um problema real de privacidade, especialmente em redes WiFi públicas onde a monitorização passiva costumava ser demasiado fácil. O problema operacional é que muitas redes foram construídas em torno de um identificador que os sistemas operativos agora tratam como descartável.

A solução é arquitetural. Utilize o endereço MAC apenas onde ele ainda seja útil, e depois mude o controlo de acesso e as políticas para sinais de identidade mais fortes, tais como certificados, autenticação de utilizador, postura do dispositivo, perfis Passpoint e modelos de federação como o OpenRoaming. Se o seu design atual ainda depende fortemente da identidade de hardware estática, reveja onde a autenticação por endereço MAC em WiFi começa a falhar e onde a integração baseada em identidade lhe oferece políticas mais limpas, melhor auditabilidade e análises mais fiáveis.

As redes que se adaptam a esse modelo deixam de perseguir dispositivos que desaparecem e passam a monitorizar, em vez disso, utilizadores autenticados, dispositivos fidedignos e sessões válidas.

O que é a Randomização de Endereços MAC

Um endereço MAC de fábrica é como um crachá de identificação permanente impresso no momento de fabrico. A aleatorização de endereços MAC é o crachá descartável que um dispositivo escolhe usar em alternativa, para que as redes próximas não o consigam seguir facilmente de um espaço para outro.

Este é o argumento da privacidade em termos simples. Os operadores de WiFi público, os anunciantes e terceiros costumavam depender fortemente de MACs estáveis para reconhecimento passivo. A aleatorização reduz essa visibilidade ao substituir o endereço de hardware por um endereço administrado localmente.

Como detetar um endereço randomizado

Existe uma pista técnica rápida que a maioria dos administradores pode utilizar imediatamente. Um endereço MAC randomizado pode ser identificado porque o seu segundo dígito hexadecimal será 2, 6, A ou E, conforme demonstrado no guia da Mist sobre a randomização de endereços MAC. A mesma orientação observa que as políticas legadas que esperam uma OUI atribuída pelo fabricante irão falhar com uma taxa de rejeição de 100% face a esses endereços.

Exemplo:

• 92:B1:B8:42:D1:85 indica um endereço administrado localmente
• O segundo dígito hexadecimal é o indicador revelador
• Isto importa porque os pressupostos baseados em OUI já não se aplicam

Se o seu controlador WLAN, plataforma NAC ou registos RADIUS conseguirem expor os MACs dos clientes no momento da ligação, normalmente consegue filtrar este padrão rapidamente.

Porque é que os designs antigos de WiFi falham

Os designs de WiFi legados assumiam que um endereço MAC representava um dispositivo de forma suficientemente consistente para ancorar o acesso e a política. É por isso que tantos ambientes ainda o utilizam para:

• Decisões de acesso: ACLs de MAC e bypass de autenticação MAC
• Gestão de endereços: Mapeamentos de DHCP estáticos
• Atalhos de segmentação: VLAN específica do dispositivo ou atribuição de funções
• Integração legada: Mapeamentos simples de chaves pré-partilhadas

Esses fluxos de trabalho faziam sentido quando o identificador de hardware permanecia inalterado. Não funcionam quando os clientes utilizam a aleatoriedade por conceção.

Para uma análise mais detalhada sobre onde isto colide com o registo de utilizadores legado, este guia sobre autenticação por endereço MAC para WiFi é uma leitura complementar útil.

Regra prática: Se a sua política depende de OUIs do fabricante, assuma que irá classificar incorretamente os dispositivos cliente com a privacidade ativada.

A Evolução da Randomização nos Dispositivos

A mudança não atingiu todas as WLANs ao mesmo tempo. Uma rede construída na era da digitalização aleatória podia parecer saudável durante anos, para depois começar a apresentar dispositivos duplicados, falhas no novo registo e análises ruidosas após uma atualização de rotina dos telemóveis. A infraestrutura manteve-se igual. O modelo de identidade do cliente mudou.

Da privacidade de varrimento à identidade de ligação

A randomização de MAC inicial protegia principalmente o tráfego de sondagem (probe). Os dispositivos ocultavam a identidade enquanto procuravam redes, mas frequentemente usavam um endereço estável após a ligação. Isto continuava a afetar as análises passivas de tráfego pedestre e alguns serviços de localização, mas muitas políticas de WLAN de produção sobreviviam porque o MAC do cliente associado permanecia suficientemente previsível para o controlo de acessos.

Uma rutura operacional significativa ocorreu mais tarde, quando as principais plataformas de clientes começaram a aplicar a randomização à associação como um comportamento de privacidade predefinido. Nesse momento, o MAC deixou de ser uma âncora fiável para onboarding, aplicação de regras e relatórios. Os administradores que tinham tolerado varrimentos randomizados passaram subitamente a ter de lidar com identidades randomizadas na sessão ativa.

Essa distinção é importante. A aleatoriedade nas sondagens afetava principalmente os observadores. A aleatoriedade na associação afeta os sistemas dos quais depende todos os dias.

Os sistemas operativos também seguiram caminhos diferentes. A Apple promoveu predefinições de privacidade fortes desde cedo e continuou a aperfeiçoá-las. O Android adotou a mesma direção geral, mas o comportamento ainda varia de acordo com o fabricante, o chipset e a política de gestão. O Windows é habitualmente o mais misto, especialmente em portáteis que se movem entre SSIDs corporativos geridos e redes domésticas ou de convidados não geridas.

Comportamento de Randomização de MAC por Sistema Operativo a partir de 2026

Sistema Operativo	Comportamento Predefinido	Âmbito da Aleatorização	Notas do Administrador
iOS	Ativado por predefinição em redes WiFi modernas	Geralmente persistente por SSID	Fortes predefinições de privacidade. Os controlos legados baseados em MAC falham frequentemente, a menos que o SSID seja explicitamente gerido.
Android	Ativado por predefinição em versões modernas	Frequentemente por SSID, com alguma variação por dispositivo e política	As diferenças de fornecedor são importantes. Teste os tipos de frota Samsung, Pixel, Zebra e outros separadamente.
Windows 10 e 11	Varia consoante o perfil e a capacidade do dispositivo	Pode ser baseado em perfil, com comportamentos de rotação opcionais	Atenção aos computadores portáteis de utilização mista. Os SSIDs corporativos podem necessitar de definições geridas, enquanto os SSIDs de convidados podem permanecer adequados para a privacidade.

Por que razão o cronograma importa operacionalmente

Muitos designs empresariais ainda refletem pressupostos do período de transição. Uma equipa pode lembrar-se de que a randomização era "principalmente um problema de varrimento" e subestimar o que mudou depois de as novas versões de SO terem tornado os MACs privados parte do comportamento normal de associação. É assim que os fluxos de trabalho MAB herdados, as reservas DHCP específicas de dispositivos e os registos de convidados associados ao MAC continuam em produção muito depois de o lado do cliente ter deixado de cooperar.

Isto também faz parte de uma tendência de privacidade mais ampla, não de uma peculiaridade isolada do WiFi. O modelo de privacidade do iCloud Private Relay da Apple aponta na mesma direção. Os fornecedores de endpoints estão a reduzir os identificadores passivos em toda a infraestrutura, o que significa que as equipas de rede precisam de métodos de identidade que sobrevivam a essa mudança.

A resposta prática não é forçar a identidade permanente de hardware de volta ao design. É mover a decisão de confiança para um nível superior da pilha. O Passpoint, a integração baseada em certificados e o OpenRoaming oferecem aos administradores uma forma estável de identificar utilizadores e dispositivos sem depender de um MAC de fábrica que as plataformas modernas tratam cada vez mais como privado.

Se um design de WiFi depende de um endereço de hardware permanente para reconhecer um cliente, esse design está a ficar obsoleto. O acesso baseado em identidade oferece um caminho muito mais limpo do que tentar recuperar a visibilidade do MAC.

Como a Randomização Interrompe as Operações de Rede

A forma mais clara de descrever o impacto é esta. A aleatorização quebra o antigo atalho entre "dispositivo visto" e "dispositivo conhecido". Assim que esse atalho desaparece, várias práticas operacionais comuns desmoronam-se ao mesmo tempo.

Mais de 30% dos dispositivos móveis utilizam a randomização de MAC por predefinição, o que cria uma relação de 1 para muitos entre um dispositivo físico e os seus MACs comunicados, complicando a contagem de dispositivos únicos e perturbando a análise de dados e a personalização, de acordo com a análise da CUJO sobre o impacto nos operadores de serviços de rede.

Controlos de segurança que deixam de ser fiáveis

As primeiras vítimas são normalmente os controlos baseados em MAC:

• As ACLs de MAC perdem o sentido: um dispositivo pode apresentar um endereço diferente daquele que aprovou.
• Os fluxos de trabalho do tipo MAB tornam-se frágeis: a lista branca é apenas tão estável quanto o identificador que contém.
• As reservas de DHCP estático falham: a reserva pertence a um endereço que o cliente pode já não utilizar.
• Os mapeamentos de iPSK legados fragmentam-se: um único utilizador ou telemóvel pode parecer múltiplos pontos de extremidade.

Isto nem sempre falha de forma ruidosa. É isso que o torna operacionalmente dispendioso. As equipas deparam-se com reclamações de acesso intermitentes, desajustes de políticas ou funções de dispositivos aplicadas de forma inconsistente, sendo que a causa raiz reside uma camada abaixo do sintoma.

Dados analíticos que se tornam mais difíceis de confiar

Para os espaços, o impacto na análise é frequentemente o problema de negócio mais visível. A análise de afluência, tempo de permanência, taxa de retorno e percurso depende de alguma confiança de que as observações repetidas pertencem à mesma entidade. A aleatorização enfraquece essa confiança.

Um centro comercial pode continuar a ter um tráfego forte, mas as visitas recorrentes podem parecer fracas porque telemóveis anteriormente familiares aparecem agora com novos identificadores. Um hotel pode pensar que tem mais hóspedes novos na rede do que tem na realidade. Um centro de saúde pode ter dificuldades em distinguir claramente a mobilidade dos funcionários da atividade dos visitantes.

Se a sua equipa depende de relatórios de presença e comportamento, este guia de WiFi analytics é uma referência útil para as métricas com maior probabilidade de serem afetadas.

Problemas de experiência do utilizador que se escondem à vista de todos

Alguns dos problemas mais complexos residem no limite da autenticação:

• Os Captive Portals podem voltar a solicitar autenticação aos utilizadores inesperadamente
• Os fluxos de nova autenticação tornam-se inconsistentes entre visitas
• A resolução de problemas torna-se mais lenta porque o MAC de ontem não é o MAC de hoje
• O histórico dos dispositivos fica fragmentado nos registos de suporte técnico

As equipas de operações descrevem frequentemente isto como "WiFi instável" quando o RF está bom e a verdadeira falha reside na continuidade da identidade.

Técnicas Práticas de Deteção e Mitigação

Não é possível modernizar um parque de rede sem primeiro quantificar o problema. O objetivo imediato não é eliminar a aleatorização. É identificar onde esta está a ocorrer, quais os fluxos de trabalho que dependem de MACs estáveis e quais os SSIDs que estão mais expostos.

Comece com a deteção em ferramentas que já utiliza

A maioria das pilhas WLAN empresariais já expõe telemetria suficiente para detetar endereços de privacidade. Em Meraki, Aruba, Mist, Ruckus e plataformas semelhantes, inspecione as listas de clientes, falhas de autenticação e histórico de sessões para padrões MAC administrados localmente. Combine isso com os registos RADIUS se utilizar NAC ou motores de políticas.

Procure três coisas:

1. Clientes com o segundo dígito hexadecimal igual a 2, 6, A ou E
2. Falhas de registo repetidas associadas ao mesmo utilizador mas com MACs diferentes
3. Anomalias específicas do SSID, especialmente em redes de convidados, BYOD e residenciais partilhadas

Uma análise interna simples revela frequentemente que a randomização não está distribuída uniformemente. Os SSIDs de convidados costumam ser os primeiros a demonstrá-lo. Os SSIDs de funcionários começam a apresentar problemas quando dispositivos não geridos ou pouco geridos se ligam. Os ambientes multi-inquilino são frequentemente os mais afetados porque a rede tenta suportar dispositivos de consumo e a aplicação de políticas ao mesmo tempo.

Decidir onde o bloqueio é defensável

Muitas equipas fazem a mesma pergunta a seguir. Devemos bloquear os MACs aleatórios? A resposta honesta é que pode ser útil como um controlo temporário num conjunto restrito de casos, mas é uma estratégia fraca a longo prazo.

O bloqueio pode ajudar quando:

• Um SSID corporativo exige uma postura rigorosa de dispositivos geridos
• Precisa de preservar um fluxo de trabalho legado enquanto uma solução de substituição está a ser implementada
• Uma classe específica de dispositivos deve utilizar uma identidade fixa e conhecida por motivos de conformidade ou operacionais

O bloqueio normalmente falha quando:

• O SSID é público, voltado para convidados ou de elevada rotatividade
• Os utilizadores não compreendem facilmente como desativar a funcionalidade
• A sua equipa de suporte não está equipada para dar instruções sobre cada variante de OS
• Precisa de um acesso sem fricção, e não de mais um caminho de exceção

O compromisso é simples. O bloqueio restaura algum controlo, mas geralmente degrada a experiência do utilizador e cria custos administrativos de suporte evitáveis.

Mitigações táticas que funcionam hoje

Vale a pena utilizar mitigações a curto prazo se estas permitirem ganhar tempo para uma reformulação adequada:

• Segmente por caso de utilização: Mantenha o acesso gerido do pessoal separado do acesso de convidados e BYOD.
• Utilize MDM onde controla os dispositivos: Nos SSIDs corporativos, envie perfis de rede em vez de depender de os utilizadores alterarem manualmente as definições de privacidade.
• Elimine pressupostos dependentes de MAC: Audite as reservas DHCP, os atalhos NAC e as regras específicas de dispositivos.
• Documente fluxos de trabalho de exceção: Se um dispositivo médico, impressora ou consola necessitar de uma identidade estável, trate-o como uma exceção específica e não como o modelo predefinido.

Nenhuma dessas correções resolve o problema de identidade subjacente. Apenas impedem que este se propague a todas as áreas das operações.

Abraçar o Futuro com Redes Baseadas em Identidade

A resposta mais forte à randomização de MAC é deixar de tratar o endereço MAC como o centro da confiança. Essa é a mudança de design fundamental. As redes baseadas em identidade movem o ponto de decisão de um token de hardware mutável para algo em que a rede possa confiar: um utilizador, um certificado, um objeto de diretório, uma decisão de postura do dispositivo ou um estado de integração federado.

Porque é que o Passpoint e o OpenRoaming mudam a equação

O Passpoint e o OpenRoaming tornam-se, por isso, mais do que meras funcionalidades de conveniência. Reduzem a dependência de Captive Portals e palavras-passe partilhadas, e permitem que a rede tome decisões de confiança antes mesmo de começar o antigo fluxo de trabalho de convidados.

Isto é importante porque 72% dos dispositivos móveis no Reino Unido agora randomizam MACs por predefinição, e as redes sem o suporte adequado podem registar até 40% de falhas de autenticação no primeiro pacote. O mesmo rascunho do IETF observa que a implementação do Hotspot 2.0 com indicações de randomização ANQP pode reduzir as re-associações em 35%, razão pela qual vale a pena ler atentamente o rascunho do IETF sobre a randomização de endereços MAC para arquitetos que planeiam ambientes de convidados e residenciais.

O Passpoint altera o modelo de "quem é este MAC?" para "este dispositivo tem uma relação de integração válida para esta rede?". Essa é uma questão muito melhor.

Como é um design moderno

Uma arquitetura prática normalmente apresenta estas características:

• O acesso de convidados utiliza Passpoint ou OpenRoaming: O utilizador autentica-se uma vez e obtém conectividade encriptada a partir do primeiro pacote nas visitas de regresso.
• O acesso do pessoal utiliza identidade suportada por diretório: O Entra ID, o Google Workspace ou o Okta podem ancorar o acesso em torno da pessoa e do estado do dispositivo gerido.
• Os certificados substituem os segredos partilhados sempre que possível: Escalam melhor e sobrevivem às alterações de privacidade de forma muito mais limpa do que a lógica vinculada a MAC.
• Os dispositivos legados obtêm uma via de exceção controlada: O iPSK continua a ter lugar para impressoras, IoT e endpoints complexos, mas não deve definir todo o seu modelo de acesso.

Porque é que isto é melhor do que tentar reverter a privacidade

Pode passar meses a tentar convencer os utilizadores a desativar as funcionalidades de privacidade, a escrever artigos de base de conhecimento para cada modelo de telemóvel e a perseguir comportamentos inconsistentes após cada atualização do SO. Ou pode mudar a rede para um design que assume que os clientes vão proteger a sua identidade por predefinição.

O segundo caminho é mais sustentável. Também melhora a segurança. Palavras-passe partilhadas, Captive Portals frágeis e pesquisas de MAC sempre foram soluções de compromisso. A aleatorização apenas expôs o quão fracas essas soluções se tinham tornado.

O objetivo não é restaurar o antigo modelo de visibilidade. O objetivo é construir uma rede que já não precise dele.

Perguntas Frequentes Sobre Randomização de MAC

A randomização de MAC melhora a segurança ou apenas a privacidade

Principalmente privacidade. Ajuda a impedir a monitorização entre redes ao ocultar o endereço de hardware permanente. Não prova automaticamente que o utilizador é de confiança, que o dispositivo está em conformidade ou que a sessão é segura. É por isso que os controlos de identidade, certificado e postura ainda importam.

Devemos pedir aos utilizadores para a desativarem

Apenas em casos muito específicos. Para dispositivos geridos de funcionários num SSID corporativo, isso pode ser aceitável se a configuração for implementada através de MDM e associada a uma política clara. Para convidados, residentes ou visitantes ocasionais, pedir às pessoas para desativarem uma funcionalidade de privacidade traduz-se geralmente numa experiência fraca e num fardo para o suporte.

Porque é que as residências de estudantes e o Build-to-Rent são tão afetados

Porque esses ambientes misturam frequentemente dispositivos de consumo, padrões de onboarding herdados e elevada sensibilidade ao suporte. No Reino Unido, o Build-to-Rent e o alojamento para estudantes registaram um aumento de 31% nas reclamações de acesso WiFi, com 55% associadas a MACs randomizados que fragmentam as políticas iPSK, de acordo com este guia sobre problemas de endereços MAC randomizados.

O que funciona melhor em ambientes multi-inquilino

Separe o problema em vias diferentes. Utilize o registo baseado em identidade para residentes e funcionários, mantenha as exceções legadas sob controlo apertado e evite desenhar a arquitetura em torno da visibilidade persistente de endereços MAC. Quanto mais um site depender do iPSK como a resposta universal, mais frágil se torna à medida que as funcionalidades de privacidade do cliente se expandem.

---

Se está a repensar o acesso WiFi de convidados, funcionários ou multi-inquilino com base na identidade em vez de endereços de hardware, a Purple foi concebida para essa transição. Suporta Passpoint e OpenRoaming, integra-se com o Entra ID, Google Workspace e Okta, e ajuda a substituir palavras-passe partilhadas e a fricção do Captive Portal por um acesso seguro e sem palavra-passe que funciona em ambientes de hotelaria, retalho, saúde, transportes e residenciais.