WiFi Multi-Tenant: Arquitetura e Gerenciamento
This authoritative technical reference guide provides IT managers, network architects, and venue operators with a comprehensive framework for designing, deploying, and managing multi-tenant WiFi networks across complex environments such as hotels, retail centres, stadiums, and multi-dwelling units (MDUs). It covers the critical architectural differences between single-venue and multi-tenant deployments, with a focus on tenant isolation, bandwidth management, and compliance. By leveraging Purple's enterprise WiFi intelligence platform, organisations can transform shared network infrastructure into a secure, scalable, and commercially valuable service.
🎧 Ouça este Guia
Ver Transcrição
Resumo Executivo
Este guia fornece uma análise técnica aprofundada sobre a arquitetura, o gerenciamento e o impacto nos negócios das redes WiFi multi-tenant. Ele foi desenvolvido para gerentes de TI, arquitetos de rede e operadores de locais responsáveis por fornecer conectividade sem fio segura e de alto desempenho em ambientes complexos e com vários ocupantes, como hotéis, shopping centers, estádios e propriedades residenciais gerenciadas (MDUs). Exploraremos as diferenças críticas entre implantações de local único e multi-tenant, com foco nos imperativos arquitetônicos de isolamento de locatários, gerenciamento granular de largura de banda e controle centralizado. O conteúdo vai além da teoria acadêmica para oferecer orientações práticas e acionáveis para projetar, implantar e monetizar uma infraestrutura de WiFi compartilhada, ao mesmo tempo em que mitiga riscos de segurança e garante a conformidade com padrões como PCI DSS e GDPR. Ao aproveitar uma plataforma de gerenciamento sofisticada como a Purple, os proprietários podem transformar um serviço compartilhado em um valor agregado significativo, aumentando a satisfação dos locatários, criando novas fontes de receita e obtendo insights operacionais profundos por meio de análises detalhadas.

Análise Técnica Aprofundada
A transição de uma arquitetura WiFi de ocupante único para uma multi-tenant exige uma mudança fundamental na filosofia de design de rede — de um ambiente plano e confiável para uma estrutura segmentada de zero-trust. O objetivo principal é garantir que vários locatários independentes coexistam em uma única infraestrutura física sem comprometer a segurança, o desempenho ou a privacidade. Isso é alcançado por meio de uma abordagem em camadas para isolamento e controle.
O Papel Fundamental das VLANs e da Segmentação
A base de qualquer rede multi-tenant é a Virtual Local Area Network (VLAN). Conforme definido pelo padrão IEEE 802.1Q, as VLANs permitem que um único switch de rede física seja particionado em vários domínios de broadcast logicamente separados. Na prática, isso significa que o tráfego de um locatário — por exemplo, uma loja de varejo na VLAN 10 — é completamente invisível e inacessível ao tráfego de outro locatário, como um escritório corporativo na VLAN 20, mesmo quando seus dispositivos estão conectados ao mesmo ponto de acesso físico.
Princípio Fundamental: Sem a implementação adequada de VLAN, a separação de locatários é meramente cosmética. Múltiplos SSIDs em uma única LAN plana não oferecem segurança significativa, pois todos os dispositivos permanecem no mesmo domínio de broadcast, permitindo um potencial movimento lateral por agentes mal-intencionados.

Autenticação e Controle de Acesso: Além de uma Única Senha
Em um ambiente multi-tenant, uma abordagem única para autenticação é totalmente inadequada. Diferentes locatários têm requisitos de segurança muito distintos, e uma arquitetura robusta deve suportar vários métodos de autenticação simultaneamente. Para locatários corporativos ou de alta segurança, o WPA3-Enterprise com autenticação IEEE 802.1X é o padrão ouro. Ele exige que cada usuário se autentique com credenciais exclusivas — um nome de usuário e senha, ou um certificado digital — em um servidor RADIUS (Remote Authentication Dial-In User Service). Isso permite a responsabilização por usuário, registros de auditoria detalhados e atribuição dinâmica de políticas com base na identidade do usuário ou na associação a grupos.
Para redes de convidados, espaços públicos ou locatários de varejo, um Captive Portal é o mecanismo principal para a integração de usuários. Portais modernos, integrados a plataformas como a Purple, vão muito além de simples splash pages. Eles podem ser totalmente personalizados por locatário com marcas distintas, aplicar termos e condições, capturar dados de usuários para marketing de maneira compatível com o GDPR e integrar-se a logins sociais ou gateways de pagamento. Para dispositivos headless, como sensores IoT, Pre-Shared Keys (PSKs) exclusivas ou dinâmicas podem ser atribuídas para fornecer acesso dentro do segmento de rede isolado de um locatário sem exigir uma infraestrutura 802.1X completa.
| Método de Autenticação | Melhor Para | Padrão | Principal Benefício |
|---|---|---|---|
| WPA3-Enterprise + 802.1X | Locatários corporativos, serviços financeiros | IEEE 802.1X, RFC 2865 | Identidade por usuário, política dinâmica |
| Captive Portal (Enhanced Open) | WiFi para convidados, varejo, acesso público | WPA3-OWE | Integração com a marca, captura de dados |
| PSK Dinâmica | Dispositivos IoT, acesso temporário | WPA3-Personal | Implantação simples, chave por dispositivo |
Garantindo o Desempenho com QoS Granular
O isolamento de desempenho é tão crítico quanto o isolamento de segurança. Um único locatário executando um aplicativo de alta largura de banda — streaming de vídeo, grandes transferências de arquivos ou uma atualização de software — não pode ter permissão para degradar o serviço de todos os outros locatários. Isso é gerenciado por meio de políticas de Quality of Service (QoS) aplicadas na camada de rede. Uma plataforma multi-tenant sofisticada permite que os administradores definam controles precisos de largura de banda por locatário, por usuário ou até mesmo por aplicativo. A limitação de taxa restringe a largura de banda máxima de upstream e downstream disponível para o SSID de cada locatário, enquanto as garantias de largura de banda reservam uma alocação mínima para locatários de missão crítica, como um cliente corporativo hospedando um evento transmitido ao vivo. O traffic shaping refina ainda mais isso priorizando protocolos sensíveis ao tempo — VoIP, videoconferência — em relação a transferências de dados menos urgentes. Essas políticas garantem uma distribuição previsível e equitativa dos recursos de rede, o que é essencial para cumprir os Acordos de Nível de Serviço (SLAs) com os locatários.

Guia de Implantação
A implantação de uma rede WiFi multi-tenant é um processo estruturado que passa por cinco fases distintas, desde o planejamento inicial até a validação pós-implantação.
A primeira fase é a Análise de Requisitos e Perfil do Locatário. Antes que qualquer hardware seja adquirido ou configurado, conduza um processo de descoberta minucioso com cada locatário em potencial. O objetivo é entender sua postura de segurança (eles exigem 802.1X? estão sujeitos ao PCI DSS ou HIPAA?), seus requisitos de desempenho (quais são suas demandas de pico de largura de banda? eles executam aplicativos sensíveis à latência?) e suas preferências de integração (eles precisam de um Captive Portal com marca personalizada? quantos usuários simultâneos eles antecipam?). Essas informações orientam diretamente todas as decisões de design subsequentes.
A segunda fase é a Seleção de Hardware e Design de Rede. Pontos de acesso de nível corporativo e switches gerenciáveis são inegociáveis. Os pontos de acesso devem suportar múltiplos SSIDs com marcação de VLAN 802.1Q e recursos avançados de QoS. Os switches devem ser totalmente gerenciáveis, com densidade de portas suficiente e suporte para portas de acesso e tronco 802.1Q. Um gateway ou firewall de alto rendimento fica na borda da rede, gerenciando políticas de roteamento inter-VLAN e aplicando regras de segurança. Junto com a seleção de hardware, projete um esquema de endereçamento IP lógico e escalável, atribuindo um ID de VLAN exclusivo e a sub-rede IP correspondente a cada locatário, e documente esse esquema meticulosamente.
A terceira fase é a Configuração da Plataforma de Gerenciamento Centralizado. Usando a plataforma da Purple, os administradores definem perfis de locatários, criam SSIDs mapeados para suas VLANs correspondentes, configuram métodos de autenticação, estabelecem políticas de QoS e limitação de taxa, e projetam Captive Portals com a marca. Este é o núcleo operacional da implantação — o painel único a partir do qual todo o ambiente multi-tenant é governado.
A quarta fase é a Implantação Física e Lançamento em Etapas. Instale pontos de acesso e switches de acordo com o plano de RF, garantindo cobertura e capacidade adequadas para cada zona de locatário. Aplique as configurações da plataforma de gerenciamento e conduza um lançamento em etapas, ativando um locatário por vez para isolar quaisquer problemas de configuração antes que afetem o ambiente mais amplo.
A quinta e última fase é a Validação e Monitoramento Contínuo. Conduza um processo de teste rigoroso para cada locatário, verificando se o isolamento, o desempenho e a autenticação estão funcionando conforme projetado. Use ferramentas de captura de pacotes para confirmar que um dispositivo na VLAN de um locatário não pode alcançar um dispositivo na de outro. Estabeleça painéis de monitoramento contínuo e limites de alerta dentro da plataforma de gerenciamento para detectar anomalias em tempo real.

Melhores Práticas
As implantações multi-tenant mais eficazes compartilham um conjunto comum de princípios operacionais. Adotar um modelo zero-trust desde o primeiro dia é fundamental — presuma que nenhum usuário ou dispositivo é confiável por padrão e aplique autenticação e autorização rigorosas para cada conexão, independentemente de onde ela se origine na rede.
O Controle de Acesso Baseado em Funções (RBAC) é igualmente crítico. Uma plataforma de gerenciamento que suporta administração hierárquica permite que a equipe de TI do proprietário retenha direitos administrativos globais, ao mesmo tempo em que concede aos locatários individuais acesso limitado e com escopo para visualizar suas próprias análises ou gerenciar seu próprio Captive Portal. Esse modelo respeita a autonomia do locatário sem comprometer a integridade da infraestrutura compartilhada.
Auditorias regulares e verificação de conformidade devem ser programadas, não reativas. Para locatários sujeitos ao PCI DSS, mantenha logs de acesso detalhados e esteja preparado para demonstrar que os ambientes de dados do titular do cartão estão devidamente isolados. Para qualquer locatário que capture dados de usuários por meio de um Captive Portal, certifique-se de que as práticas de coleta, armazenamento e processamento de dados estejam totalmente em conformidade com o GDPR, incluindo um aviso de privacidade claro e acessível apresentado no momento da autenticação.
Por fim, automatizar a integração e o desligamento de locatários por meio das APIs da plataforma de gerenciamento reduz drasticamente a sobrecarga operacional, minimiza o risco de erro humano de configuração e garante que o acesso seja revogado de forma rápida e completa quando um locatário desocupa o local.
Solução de Problemas e Mitigação de Riscos
Mesmo redes multi-tenant bem projetadas enfrentam desafios operacionais. A tabela a seguir mapeia os modos de falha mais comuns para suas causas raízes e mitigações recomendadas.
| Sintoma | Causa Raiz Provável | Mitigação Recomendada |
|---|---|---|
| Desempenho degradado em todos os locatários | Saturação do uplink de internet primário ou gargalo no firewall | Monitore a utilização agregada da largura de banda; implemente QoS de nível superior no gateway; considere o upgrade do uplink |
| Os usuários não conseguem se autenticar em um SSID específico | PSK incorreta, credenciais 802.1X inválidas ou servidor RADIUS mal configurado | Inspecione os logs de autenticação do cliente na plataforma de gerenciamento; revise os logs de eventos do servidor RADIUS em busca de tentativas falhas |
| Tráfego inter-VLAN detectado na auditoria de segurança | Porta de tronco do switch mal configurada ou ACL de firewall excessivamente permissiva | Revise todas as configurações de porta do switch; aplique regras de firewall inter-VLAN de negação por padrão; audite as ACLs |
| Captive Portal não renderizando corretamente para um locatário | Falha na resolução de DNS ou configuração incorreta da URL do portal | Verifique as configurações de DNS para a VLAN do locatário; teste a resolução da URL do portal de dentro da sub-rede do locatário |
| Locatário relata conectividade intermitente | Interferência de RF, congestionamento de co-canal ou sobrecarga do AP | Revise os mapas de calor de RF na plataforma de gerenciamento; ajuste as atribuições de canal e a potência de transmissão; considere cobertura adicional de AP |
O maior risco em um ambiente multi-tenant é o movimento lateral — a capacidade de um dispositivo comprometido na rede de um locatário de se mover e atacar dispositivos em outro. A segmentação adequada de VLAN, combinada com regras rigorosas de firewall inter-VLAN, é o controle primário contra essa ameaça. Testes regulares de penetração dos limites de segmentação são fortemente recomendados para qualquer ambiente que hospede locatários com requisitos de segurança elevados.
ROI e Impacto nos Negócios
Uma rede WiFi multi-tenant adequadamente arquitetada não é um centro de custos; é um ativo estratégico com retornos múltiplos e quantificáveis. A oportunidade de receita mais direta é a monetização da rede — oferecendo aos locatários pacotes de largura de banda em níveis, cobrando por conectividade premium em eventos ou faturando pelo acesso a portais com marcas personalizadas e painéis de análise. Para um operador de propriedade gerenciada, isso pode converter uma despesa de capital em um fluxo de receita recorrente.
Além da monetização direta, o WiFi gerenciado de alta qualidade é um diferencial poderoso em mercados competitivos. No setor de unidades habitacionais múltiplas (MDU WiFi), uma infraestrutura de WiFi compartilhada confiável e gerenciada profissionalmente é cada vez mais um fator decisivo na aquisição e retenção de locatários. No setor de propriedades comerciais, os locatários esperam conectividade de nível corporativo como uma comodidade básica; não fornecê-la cria risco de churn.
Os ganhos de eficiência operacional do gerenciamento centralizado também são significativos. Uma única equipe de TI pode gerenciar um portfólio de propriedades — cada uma com vários locatários — a partir de um único painel, eliminando a necessidade de visitas ao local para alterações de configuração de rotina. Isso reduz as despesas operacionais e acelera os tempos de resposta.
Talvez o benefício estrategicamente mais valioso seja o insight baseado em dados. Ao agregar dados anonimizados e baseados em consentimento em todos os locatários, os proprietários obtêm inteligência inestimável sobre padrões de tráfego de pessoas, tempos de permanência de visitantes, períodos de pico de uso e utilização do espaço. Esses dados orientam decisões sobre investimento imobiliário, mix de locatários e programação operacional, entregando um retorno que vai muito além da própria rede.
Termos-Chave e Definições
Multi-Tenant WiFi
A wireless network architecture in which a single physical infrastructure — access points, switches, and uplinks — is logically partitioned to serve multiple independent organisations or user groups, each with their own isolated network segment, authentication method, and management controls.
IT teams encounter this term when managing properties with multiple occupants, such as shopping centres, hotels, office parks, or multi-dwelling units. It is the foundational concept that distinguishes enterprise venue networking from a simple shared hotspot.
VLAN (Virtual Local Area Network)
A logical network segment created within a physical switched network, as defined by the IEEE 802.1Q standard. VLANs create separate broadcast domains, ensuring that traffic on one VLAN cannot be seen or accessed by devices on another VLAN without explicit routing and firewall permission.
VLANs are the primary mechanism for tenant isolation in a multi-tenant WiFi deployment. Network architects must assign a unique VLAN ID to each tenant and ensure that all switches and access points are correctly configured to tag and carry traffic for each VLAN.
IEEE 802.1X
An IEEE standard for port-based network access control that provides an authentication framework for devices attempting to connect to a LAN or WLAN. It uses the Extensible Authentication Protocol (EAP) and requires a supplicant (the client device), an authenticator (the access point or switch), and an authentication server (typically a RADIUS server).
802.1X is the recommended authentication standard for corporate tenants and any environment requiring individual user accountability. It eliminates the security risks of shared passwords and enables dynamic policy assignment based on user identity.
RADIUS (Remote Authentication Dial-In User Service)
A networking protocol and server infrastructure that provides centralised Authentication, Authorisation, and Accounting (AAA) management for users connecting to a network. In a multi-tenant WiFi context, the RADIUS server validates user credentials for 802.1X-authenticated SSIDs and can dynamically assign users to specific VLANs based on their identity or group membership.
Network architects must plan for RADIUS server redundancy (at least two servers in an active-passive configuration) to prevent authentication failures from causing a network outage. Cloud-hosted RADIUS services are increasingly common in multi-tenant deployments.
Captive Portal
A web page that intercepts a user's initial HTTP/HTTPS request when they connect to a WiFi network, requiring them to complete an action — such as accepting terms of service, entering credentials, or providing contact information — before granting full internet access. In a multi-tenant context, each tenant can have a fully customised captive portal with their own branding and data capture requirements.
Captive portals are the primary onboarding mechanism for guest and public WiFi networks. When deploying portals that capture personal data (email addresses, social login profiles), operators must ensure compliance with GDPR, including providing a clear privacy notice and obtaining explicit consent for marketing communications.
QoS (Quality of Service)
A set of network management techniques that prioritise certain types of traffic or allocate specific bandwidth resources to defined users, applications, or network segments. In a multi-tenant WiFi deployment, QoS policies are used to enforce per-tenant bandwidth limits (rate limiting), guarantee minimum throughput for premium tenants, and prioritise latency-sensitive applications such as VoIP.
QoS configuration is essential for preventing the 'noisy neighbour' problem, where a single tenant's high-bandwidth usage degrades the experience for all other tenants on the shared infrastructure. Network architects should define QoS policies as part of the tenant onboarding process, not as a reactive measure after complaints arise.
MDU WiFi (Multi-Dwelling Unit WiFi)
A specific application of multi-tenant WiFi architecture in residential properties such as apartment blocks, student accommodation, and managed housing developments. In an MDU context, each residential unit or floor is treated as a tenant, with isolated network segments providing privacy between residents and a centralised management platform enabling the property operator to deliver a managed connectivity service.
MDU WiFi deployments have specific regulatory considerations, particularly around data privacy for residential users. Property operators must be especially careful to ensure that residents cannot see each other's network traffic, and that any data captured through the network is handled in strict compliance with GDPR.
WPA3-Enterprise
The latest generation of the Wi-Fi Protected Access enterprise security protocol, introduced by the Wi-Fi Alliance. WPA3-Enterprise mandates the use of 192-bit cryptographic strength (in its highest security mode) and eliminates the vulnerabilities present in WPA2-Enterprise, including susceptibility to PMKID attacks and dictionary attacks against captured handshakes. It is used in conjunction with IEEE 802.1X for user authentication.
Network architects should specify WPA3-Enterprise as the minimum security standard for any SSID serving corporate tenants, financial services, healthcare, or any environment with elevated data sensitivity. Legacy devices that do not support WPA3 may require a separate, isolated SSID with WPA2-Enterprise as a transitional measure.
RBAC (Role-Based Access Control)
An access control model in which permissions are assigned to roles rather than to individual users, and users are assigned to roles based on their responsibilities. In a multi-tenant WiFi management platform, RBAC enables a hierarchical administration model where property owners have global access, while individual tenants have scoped access only to their own network segment and analytics data.
RBAC is a critical governance control in any multi-tenant management platform. Without it, a tenant administrator could potentially view or modify the configurations of neighbouring tenants, creating both a security risk and a significant liability for the property operator.
Lateral Movement
A cyberattack technique in which an attacker who has compromised one device on a network uses that foothold to move horizontally across the network, accessing other devices and systems. In a multi-tenant WiFi context, inadequate VLAN segmentation or overly permissive inter-VLAN firewall rules can enable lateral movement from a compromised device in one tenant's network to devices in another tenant's network.
Preventing lateral movement is the primary security objective of tenant isolation in a multi-tenant WiFi architecture. Network architects must validate that VLAN boundaries are impermeable through regular penetration testing and that firewall rules enforce a default-deny policy for all inter-VLAN traffic.
Estudos de Caso
A 350-room full-service hotel needs to provide WiFi to four distinct groups simultaneously: hotel guests in rooms and public areas, a 1,200-capacity conference centre that hosts multiple concurrent events from different corporate clients, a ground-floor retail tenant (a coffee shop) that processes card payments, and the hotel's own back-of-house operational network used for PMS, CCTV, and POS systems. How should the network be architected to meet the security, performance, and compliance requirements of each group?
This deployment requires a minimum of four isolated network segments, each with distinct security and performance profiles. The hotel guest network (VLAN 10) should use a captive portal with WPA3-Enhanced Open, with a rate limit of 20 Mbps per device and a Purple-managed splash page for branded onboarding and GDPR-compliant data capture. The conference centre (VLAN 20) requires a more sophisticated approach: it should be sub-segmented using dynamic VLANs assigned at authentication time via 802.1X, so that delegates from Event A (VLAN 21) are isolated from delegates from Event B (VLAN 22). Each event organiser can be given a temporary admin credential in Purple to manage their own captive portal and view their own analytics. Bandwidth guarantees of 50 Mbps per event should be configured, with burst allowances up to 100 Mbps if capacity is available. The retail coffee shop (VLAN 30) processes card payments, placing it within PCI DSS scope. This segment must be strictly isolated with no inter-VLAN routing permitted under any circumstances. The POS terminals should be on a dedicated sub-VLAN (VLAN 31) with a whitelist-only firewall policy permitting traffic only to the payment processor's IP range. The back-of-house operational network (VLAN 40) should have no internet access whatsoever, operating as a fully air-gapped private LAN for internal systems. All four VLANs are configured and monitored from a single Purple dashboard, with RBAC ensuring that the conference manager can only see their own event data, the retail tenant can only see their own network, and the hotel IT team has full visibility across all segments.
A large urban shopping centre with 120 retail units across three floors wants to deploy a shared WiFi infrastructure managed centrally by the property management company. Each retail tenant should have their own branded guest WiFi for customers, their own analytics dashboard showing visitor dwell times and return visit rates, and their own bandwidth allocation. The property management company also wants to offer a premium 'anchor tenant' tier with guaranteed throughput and priority support. How should this be structured using Purple's multi-tenant platform?
The deployment begins with a hierarchical management structure in Purple. The property management company holds the top-level 'Organisation' account, with each retail tenant provisioned as a sub-account with scoped permissions. Each tenant receives a dedicated SSID mapped to a unique VLAN, with a Purple-managed captive portal fully branded with their own logo, colour scheme, and promotional messaging. The portal is configured to capture email addresses and opt-in marketing consent in compliance with GDPR, with the data flowing into the tenant's own Purple analytics dashboard. Standard tenants are allocated a 10 Mbps per-device rate limit with a 50 Mbps SSID cap, sufficient for typical retail customer browsing. Anchor tenants — large department stores or flagship brands — are provisioned on a premium tier with a 100 Mbps guaranteed bandwidth allocation, a dedicated SSID with WPA3-Enterprise for their own staff devices, and a separate guest SSID for customers. The property management company's IT team monitors the entire estate from the top-level Purple dashboard, with alerts configured for any tenant whose network utilisation exceeds 80% of their allocation (a signal to upsell to a higher tier) or drops below 10% (a signal of a potential configuration issue). Monthly analytics reports are automatically generated per tenant, showing visitor counts, dwell times, and return visit rates, which the property management company packages as a value-added service in the tenant's lease agreement.
Análise de Cenário
Q1. A university campus wants to deploy a shared WiFi infrastructure serving four groups: undergraduate students, postgraduate researchers, visiting conference delegates, and the university's own administrative staff. The research network handles sensitive grant data and must meet Cyber Essentials Plus requirements. The conference delegate network needs to be provisioned and decommissioned on a per-event basis. How would you architect the VLAN structure and authentication model to meet these requirements?
💡 Dica:Consider the compliance requirements of the research network carefully — Cyber Essentials Plus mandates specific access control and patch management requirements. Also consider how the conference network's temporary nature should influence your provisioning approach: can you use a template-based deployment model?
Mostrar Abordagem Recomendada
The architecture requires a minimum of four VLANs: VLAN 10 for undergraduate students (captive portal with social login, 10 Mbps rate limit), VLAN 20 for postgraduate researchers (WPA3-Enterprise with 802.1X, integrated with the university's Active Directory, access restricted to authorised devices via certificate-based authentication to meet Cyber Essentials Plus), VLAN 30 for conference delegates (captive portal, provisioned from a pre-built template in Purple that can be activated and deactivated on demand with a custom event SSID and branded portal), and VLAN 40 for administrative staff (WPA3-Enterprise with 802.1X, integrated with AD, with access to internal university systems via a site-to-site VPN or private routing). The research VLAN must have a default-deny firewall policy with explicit whitelist rules for required services, and all access must be logged for audit purposes. The conference VLAN template approach in Purple allows the IT team to onboard a new event in under 30 minutes without touching switch or firewall configurations.
Q2. You are the network architect for a managed office provider with 50 buildings across the UK, each hosting between 10 and 40 small business tenants. You need to design a scalable multi-tenant WiFi service that can be managed by a central IT team of five people. What management architecture and automation strategy would you recommend to make this operationally viable?
💡 Dica:With 50 buildings and up to 2,000 tenants, manual configuration is not viable. Consider how Purple's API and hierarchical management model can be used to automate tenant provisioning, and how you would structure the management hierarchy to delegate appropriate access to building managers without compromising central governance.
Mostrar Abordagem Recomendada
The solution requires a three-tier management hierarchy in Purple: the managed office provider at the top level with full administrative access, building managers at the second level with access scoped to their specific building, and individual tenants at the third level with access only to their own captive portal design and analytics dashboard. Tenant provisioning must be fully automated via Purple's API, integrated with the company's CRM or property management system. When a new tenant signs a lease, the CRM triggers an API call to Purple that creates the tenant profile, provisions the SSID, assigns the VLAN (from a pre-allocated pool per building), sets the bandwidth tier based on the contracted service level, and generates a branded captive portal from a template. When a tenant vacates, the offboarding workflow automatically deactivates the SSID and releases the VLAN back to the pool. This automation reduces the per-tenant provisioning time from hours to minutes and eliminates the risk of orphaned configurations. The central IT team's role shifts from manual configuration to policy governance, exception handling, and performance monitoring across the estate.
Q3. A stadium operator hosts 40 events per year, ranging from 20,000-capacity football matches to 5,000-capacity corporate conferences. During a football match, the primary use case is fan engagement (social media, team apps, live stats). During corporate conferences, the primary use case is business productivity (video conferencing, cloud applications). How would you configure the QoS and bandwidth management policies to optimise the network for each event type, and how would you switch between configurations efficiently?
💡 Dica:Consider that the two event types have fundamentally different traffic profiles: football matches generate massive concurrent bursts of social media uploads and streaming, while conferences require consistent, low-latency throughput for video calls. A single QoS policy cannot optimise for both. Think about how event-type templates in the management platform could solve this.
Mostrar Abordagem Recomendada
The solution is to create two distinct QoS policy templates in Purple: a 'Fan Engagement' template and a 'Corporate Conference' template. The Fan Engagement template prioritises high-throughput, burst-tolerant traffic by setting a relatively high per-device rate limit (e.g., 5 Mbps) to accommodate simultaneous social media uploads, while deprioritising or throttling streaming video to prevent any single user from consuming disproportionate bandwidth during peak moments (e.g., a goal). The Corporate Conference template inverts these priorities: it sets a lower per-device rate limit for general browsing (e.g., 2 Mbps) but implements strict QoS prioritisation for DSCP-marked video conferencing traffic (e.g., Zoom, Teams), ensuring that video calls receive consistent, low-latency throughput even under load. Switching between templates is handled through Purple's event management workflow: the operations team selects the event type when creating the event in the platform, and the appropriate QoS template is automatically applied to all relevant SSIDs. This eliminates the risk of a corporate conference running on a fan engagement QoS profile, which would result in degraded video call quality.
Principais Conclusões
- ✓Multi-tenant WiFi requires VLAN-based network segmentation as its foundational security control — multiple SSIDs without proper VLAN tagging provide no meaningful tenant isolation and create a significant security liability.
- ✓Authentication must be matched to tenant type: WPA3-Enterprise with IEEE 802.1X for corporate and regulated tenants; GDPR-compliant captive portals for guest and public access; dynamic PSKs for IoT and headless devices.
- ✓QoS and rate-limiting policies are not optional — they are essential for preventing the 'noisy neighbour' problem and for meeting SLA commitments with tenants who have contracted for specific bandwidth tiers.
- ✓Compliance requirements must be assessed per-tenant at onboarding: PCI DSS mandates strict isolation and default-deny firewall policies for any tenant processing card payments; GDPR governs all captive portal data capture.
- ✓Centralised, cloud-based management platforms like Purple are the operational enabler for multi-tenant WiFi at scale — they provide the single pane of glass for configuration, monitoring, RBAC, and analytics across an entire property portfolio.
- ✓Lateral movement prevention is the primary security benefit of proper tenant isolation — VLAN boundaries and default-deny inter-VLAN firewall rules contain the blast radius of any compromised device to a single tenant segment.
- ✓A well-architected multi-tenant WiFi network is a revenue-generating asset, not a cost centre — it enables tiered service monetisation, provides tenants with valuable visitor analytics, and is a demonstrable differentiator in competitive property markets.



