Wi-Fi para licitações públicas é a contratação, via edital, de uma plataforma que autentica, controla e registra o acesso à rede sem fio de órgãos e instituições públicas. Os editais mais recentes pedem gestão em nuvem com captive portal, SSO via SAML, vouchers, políticas por perfil e logs auditáveis. Tudo isso deve funcionar sobre os access points e firewalls que o órgão já possui.
Os editais de Wi-Fi mudaram de patamar. Há poucos anos, o objeto era “fornecer internet sem fio”. Hoje, os termos de referência de universidades, autarquias, tribunais e redes de ensino pedem governança de identidade, criptografia no rádio, políticas de sessão e trilha de auditoria completa.
Essa evolução é positiva, mas cria um problema novo. Os requisitos passaram a misturar camadas diferentes da rede: parte depende da plataforma de autenticação, parte do access point e parte da integração entre os dois.
Quando essa separação não fica clara, o edital pede a coisa certa ao fornecedor errado. Os licitantes prometem o que não controlam, e a prova de conceito vira disputa de interpretação.
Este guia organiza esses requisitos por camada e termina com um checklist de avaliação. Ele serve ao gestor de TI que redige o termo de referência e a quem avalia as propostas recebidas.
O que é Wi-Fi para licitações públicas e o que mudou no edital
Wi-Fi para licitações públicas é o processo de contratação, regido pela Lei 14.133/2021, de soluções que entregam e governam o acesso à rede sem fio em órgãos e instituições públicas. No contexto atual, isso significa contratar menos “sinal” e mais controle: quem acessa, como se autentica e o que fica registrado.
A Nova Lei de Licitações reforçou a fase de planejamento. O Estudo Técnico Preliminar (ETP) justifica a necessidade, e o termo de referência descreve o objeto com precisão suficiente para comparar propostas. Soluções de gestão de Wi-Fi em nuvem costumam ser enquadradas como serviço comum, o que abre caminho para o pregão eletrônico.
Entidades do Sistema S seguem regulamentos próprios de contratação, mas os requisitos técnicos de Wi-Fi que aparecem nos seus editais são praticamente os mesmos.
A diferença entre um edital antigo e um edital atual aparece nos requisitos:
- Antes: quantidade de pontos de acesso, velocidade do link e uma senha compartilhada por rede.
- Agora: plataforma SaaS com gestão centralizada por unidade, site, prédio, SSID e grupo de APs.
- Agora: autenticação federada para servidores e docentes, vouchers para visitantes e autocadastro com minimização de dados.
- Agora: padrões de segurança de rádio como WPA3 e Enhanced Open (OWE).
- Agora: logs com campos mínimos definidos, política de retenção e exportação para auditoria.
- Agora: compatibilidade com a infraestrutura existente, sem aquisição obrigatória de hardware.
Essa última exigência é decisiva. Ela transforma a contratação em uma camada de software que precisa conversar com equipamentos já instalados, muitas vezes de fabricantes diferentes em cada unidade.
Outro ponto recorrente é a capacidade mínima, como 300 usuários simultâneos por unidade. Em uma plataforma de hotspot em nuvem, a escalabilidade da autenticação raramente é o gargalo. O limite real costuma estar na capacidade de rádio dos APs e no link de cada unidade. Um bom termo de referência deixa essa distinção explícita.
Termo de referência de Wi-Fi: como organizar os requisitos
O termo de referência de Wi-Fi é o documento que descreve o objeto, os requisitos técnicos mínimos e os critérios de aceitação da solução contratada. Para a rede sem fio, isso significa converter uma necessidade de governança em requisitos objetivos, que possam ser testados e comprovados.
Os editais mais bem estruturados que analisamos seguem uma divisão em oito blocos:
- Arquitetura e escopo: modelo SaaS, abrangência de unidades e capacidade mínima.
- Autenticação e identidade: SSO, voucher, autocadastro e aceite de termos.
- Segurança Wi-Fi: WPA2/WPA3, modo de transição e OWE para redes abertas.
- Segmentação e políticas: banda, sessão, horários, isolamento e VLAN.
- Gestão de APs: grupos lógicos com regras e portais distintos.
- Logs e auditoria: campos, retenção, exportação e correlação de eventos.
- Portal e experiência: identidade visual, idiomas, redirecionamento e pesquisas.
- Integração e operação: compatibilidade com o parque existente e relatórios.
Três boas práticas evitam impugnações e aditivos depois da assinatura.
A primeira é usar parâmetros mensuráveis. “Timeout configurável” é vago. “Idle Timeout configurável entre 5 e 120 minutos” pode ser verificado na prova de conceito.
A segunda é separar o que é obrigatório do que é desejável. Hotspot 2.0/Passpoint, por exemplo, depende de dispositivos compatíveis. Por isso costuma aparecer como item desejável, e com razão.
A terceira é não direcionar a fabricante. Exigir um recurso proprietário sem justificativa técnica restringe a competitividade e costuma gerar questionamento. O caminho mais seguro é exigir o padrão, como SAML 2.0, RADIUS ou IEEE 802.11u, e não a marca.
Vale ainda indicar no termo de referência qual camada responde por cada requisito. É exatamente aí que a maioria dos editais tropeça, como mostra a tabela mais adiante.
Autenticação no edital: SAML, voucher e autocadastro com LGPD
Autenticação no edital de Wi-Fi é o conjunto de métodos que a solução deve oferecer para identificar cada perfil de usuário antes de liberar a rede. Em órgãos e instituições públicas, isso significa ter métodos diferentes para servidores, visitantes e público em geral, cada um com seu nível de exigência.
Os editais recentes convergem para quatro métodos:
- SSO via SAML 2.0 para perfis internos: colaboradores, docentes e servidores entram com a conta institucional, geralmente vinculada ao Microsoft Entra ID (antigo Azure AD). O requisito mais valioso é a restrição por grupos, que libera o SSID administrativo só para quem pertence a ele.
- Voucher para visitantes, eventos e fornecedores: códigos temporários com validade configurável por tempo e perfil. O QR Code opcional agiliza credenciamentos.
- Autocadastro com e-mail: campos configuráveis e validação opcional por e-mail ou SMS.
- Aceite de termos de uso e política de privacidade: o consentimento, quando aplicável, precisa ficar registrado junto ao log de acesso.
O SAML resolve um problema antigo do setor público: a senha de Wi-Fi que circula em grupos de mensagem e nunca é trocada. Com SSO, quando um servidor é desligado no diretório, o acesso à rede termina junto, sem ação manual da equipe de TI.
O voucher cumpre o papel oposto. Ele dá acesso rápido e rastreável a quem não tem conta institucional, sem abrir a rede interna.
O ponto de atenção é o autocadastro. A LGPD estabelece o princípio da necessidade: coletar apenas o dado indispensável para a finalidade. Por isso os editais passaram a exigir “minimização de dados”. Pedir CPF, endereço e data de nascimento para liberar Wi-Fi em uma biblioteca dificilmente se justifica.
Para órgãos públicos, vale considerar também o login via Gov.br. Ele usa uma identidade já verificada pelo Governo Federal e dispensa cadastro paralelo de dados pessoais. Os demais métodos de autenticação entram conforme o perfil de público de cada unidade.
Plataforma ou equipamento: quem cumpre cada requisito do edital
Os requisitos de um edital de Wi-Fi se distribuem em três camadas: a plataforma de autenticação, o equipamento de rede (AP, controladora ou firewall) e a integração entre eles, normalmente feita via RADIUS. Para quem redige ou avalia o edital, isso significa saber a quem cobrar cada item.
| Requisito do edital | Camada responsável | Como é entregue | O que verificar na PoC |
|---|
| SSO via SAML 2.0 com restrição por grupo | Plataforma | Integração com o provedor de identidade | Login institucional e bloqueio de quem está fora do grupo |
| Voucher e autocadastro | Plataforma | Fluxos do captive portal | Geração, validade e expiração do código |
| WPA2/WPA3 em modo de transição | AP ou controladora | Configuração do SSID | Suporte no firmware dos modelos instalados |
| Enhanced Open (OWE) | AP ou controladora | Criptografia no rádio (RFC 8110) | Modo de transição OWE e convivência com o captive portal |
| Hotspot 2.0/Passpoint | AP e plataforma | IEEE 802.11u com perfil e RADIUS | Modelos e dispositivos compatíveis |
| Limite de banda por perfil | Integração | Atributos RADIUS específicos de cada fabricante | Se o AP aplica o limite recebido |
| VLAN por perfil | Integração | Atributos RADIUS de túnel (RFC 3580) | Se a controladora troca a VLAN após o login |
| Isolamento de clientes | AP ou controladora | Configuração do SSID | Teste entre dois dispositivos na mesma rede |
| Session e Idle Timeout | Integração | Atributos Session-Timeout e Idle-Timeout (RFC 2865) | Reautenticação ao fim do tempo |
| Revogação de sessão ativa | Integração | Disconnect-Message ou CoA (RFC 5176) | Derrubada imediata do dispositivo |
| Logs de sessão | Plataforma e equipamento | Accounting RADIUS (início, fim, IP, MAC) | Exportação com todos os campos exigidos |
A leitura da tabela traz uma conclusão importante. Um edital que exige OWE “da plataforma de autenticação” está cobrando o fornecedor errado. OWE criptografa o tráfego no ar e é um recurso do rádio. O captive portal identifica quem está do outro lado. As duas camadas se complementam.
O mesmo vale para WPA3 e isolamento de clientes. A plataforma deve operar em redes que usam esses recursos, mas quem os implementa é o equipamento.
Já os itens de integração dependem do protocolo RADIUS e do suporte de cada fabricante. Por isso, na avaliação, a lista de equipamentos homologados do licitante pesa tanto quanto a lista de funcionalidades.
O Hotspot 2.0 é o único item que exige as duas pontas ao mesmo tempo: o AP anuncia a rede compatível, e a plataforma autentica o perfil do usuário.
Sessão, timeout e revogação: o controle que a auditoria exige
Políticas de sessão são as regras que definem por quanto tempo uma autenticação continua válida e em que situações ela precisa ser renovada. Em ambientes públicos com dispositivos compartilhados, como laboratórios, totens e salas de aula, isso significa garantir que o próximo usuário não herde a identidade do anterior.
Os editais mais maduros detalham quatro controles:
- Idle Timeout: encerra a sessão após um período sem tráfego. Uma faixa comum é de 5 a 120 minutos.
- Session Timeout: força a desconexão ao atingir o tempo máximo, mesmo com uso ativo. Uma faixa comum é de 1 a 24 horas.
- Reautenticação obrigatória: ao fim de qualquer timeout ou desconexão administrativa, o usuário passa de novo pelo portal. Autenticação persistente por prazo indeterminado fica vedada.
- Revogação manual: o administrador encerra sessões por unidade, SSID, usuário, identificador ou dispositivo, com efeito imediato.
A revogação é o item que mais separa soluções maduras de soluções improvisadas. Ela é útil em incidentes de segurança, em solicitações de auditoria e na troca de operador de um computador compartilhado.
Há também um detalhe técnico que costuma passar despercebido: o MAC aleatório. iOS e Android usam, por padrão, endereços privados por rede, que podem mudar com o tempo. Isso afeta reconexões automáticas baseadas em MAC address e a correlação de logs de um mesmo aparelho.
Por esse motivo, o log precisa associar o MAC a um identificador de usuário, e não apenas ao dispositivo. A reconexão por MAC continua útil para a experiência, desde que limitada por um tempo de sessão definido.
Somados às janelas de horário por perfil, como a rede de alunos disponível só no turno letivo, esses controles transformam a política de acesso em algo documentável. É isso que o auditor vai pedir.
Logs de acesso em licitações: o que registrar e por quanto tempo
Logs de acesso são os registros que associam cada conexão à rede a um usuário, um dispositivo, um horário e um local. Em licitações públicas, isso significa ter uma trilha capaz de responder com precisão a uma auditoria ou a uma solicitação formal de autoridade competente.
Os campos mínimos que os editais recentes exigem são:
- Usuário ou identificador do acesso.
- Data e hora de início e de fim da sessão.
- Endereço IP atribuído e MAC do dispositivo.
- SSID, unidade e método de autenticação.
Os editais mais criteriosos vão além e pedem a correlação de eventos: expiração, reconexão, revogação manual e nova autenticação. Sem isso, um laboratório com 40 computadores compartilhados vira uma trilha ilegível.
Sobre retenção, o Marco Civil da Internet determina que provedores de conexão guardem registros de conexão por 1 ano. Esse prazo costuma ser a referência adotada pelas instituições, e a política final cabe à governança de cada órgão.
Existe uma armadilha técnica que quase nenhum edital menciona: o NAT. O IP registrado no log de acesso é, na maioria das redes, um endereço privado. Uma solicitação judicial chega com IP público, data, hora e, muitas vezes, porta de origem.
Para responder, é preciso cruzar o log da plataforma com o log de tradução NAT do firewall. Um bom termo de referência pede que os horários estejam sincronizados via NTP entre as camadas e que a exportação permita esse cruzamento.
Também vale lembrar que o próprio log é dado pessoal. Ele precisa ficar em ambiente seguro, com controle de quem consulta, e ser exportável em CSV, JSON ou via API para auditoria e integração com ferramentas de monitoramento.
Captive portal institucional: personalização sem virar vitrine
O captive portal institucional é a página de autenticação exibida antes da liberação da rede, personalizada com a identidade do órgão. No contexto público, isso significa comunicar com o cidadão sem transformar o acesso à internet em moeda de troca.
Um captive portal alinhado aos editais atuais contempla:
- Layout customizável: cores, tipografia, logomarca, imagens de fundo e mensagens.
- Responsividade: adaptação a celulares, tablets e desktops.
- Multilíngue: no mínimo português, inglês e espanhol, essencial em universidades e eventos.
- Redirecionamento pós-login: por perfil de usuário ou por SSID.
- Conteúdo multimídia institucional: imagens, vídeos e campanhas educativas, de forma não obstrutiva.
- Pesquisas configuráveis: satisfação, NPS ou enquetes, com resultados exportáveis.
- Links múltiplos em tela única: redes sociais, avisos e documentos, sem redirecionamento externo.
- Portais independentes: um por unidade ou SSID, com gestão centralizada.
O requisito mais importante dessa lista também é o mais discreto. Recursos de comunicação devem ser opcionais e nunca condicionar a autenticação. Assistir a um vídeo não pode ser pré-requisito para navegar em uma rede pública.
Isso protege a instituição de questionamentos e mantém o foco no que o edital realmente contrata: acesso controlado.
Há também uma limitação técnica a considerar. iOS e Android abrem o portal em um mini navegador de detecção, com recursos reduzidos. Portais pesados, com scripts de terceiros ou fluxos longos, falham justamente nesse ambiente.
Entre os tipos de captive portal usados em ambientes corporativos e institucionais, o padrão que funciona é sempre o mesmo: página leve, servida em HTTPS e com poucos passos até a navegação.
Checklist para avaliar propostas e a prova de conceito
A prova de conceito (PoC) é a etapa em que o licitante demonstra, em ambiente real ou controlado, que a solução cumpre os requisitos do edital. A Lei 14.133/2021 admite essa exigência quando prevista no edital. Na prática, isso significa transformar cada requisito em um teste com evidência registrada.
Checklist técnico sugerido para a PoC:
- Login via SAML 2.0 com o provedor de identidade do órgão, bloqueando usuário fora do grupo autorizado.
- Geração de voucher com validade curta e confirmação da expiração.
- Autocadastro com campos mínimos e aceite de termos registrado no log.
- Idle Timeout e Session Timeout disparando nova autenticação.
- Revogação manual de uma sessão ativa, com derrubada imediata.
- Troca de VLAN por perfil após o login, quando o ambiente suportar.
- Limite de banda aplicado a um perfil de teste.
- Exportação de log com todos os campos exigidos.
- Portal em três idiomas, testado em celular Android e iOS.
- Operação sobre os APs e firewalls existentes, sem troca de hardware.
- Relatórios de usuários conectados, consumo por SSID ou unidade e tentativas de autenticação.
Dois cuidados tornam a avaliação mais justa.
O primeiro é testar nos modelos de equipamento que o órgão realmente usa. Uma PoC em laboratório com AP diferente do parque instalado não prova compatibilidade.
O segundo é tratar a capacidade de usuários simultâneos com precisão. A plataforma em nuvem precisa escalar a autenticação, enquanto a capacidade de rádio de cada unidade depende do projeto de APs. Separar as duas coisas evita reprovar uma solução por um limite que não é dela.
Registrar cada teste com captura de tela, horário e log exportado transforma a PoC em evidência documental. Isso facilita o parecer técnico e reduz o espaço para recursos de outros licitantes.
Glossário técnico para editais públicos de Wi-Fi
- Termo de referência (TR): documento que descreve o objeto, os requisitos técnicos e os critérios de aceitação da contratação.
- Estudo Técnico Preliminar (ETP): análise que justifica a necessidade e a solução escolhida antes do edital.
- Prova de conceito (PoC): demonstração prática de que a solução atende aos requisitos exigidos.
- Captive portal: página de autenticação exibida antes de liberar o acesso à rede Wi-Fi.
- SAML 2.0: padrão de autenticação federada que permite o login único com a conta institucional.
- Voucher: código temporário de acesso, com validade configurável.
- WPA3: padrão atual de segurança Wi-Fi, com criptografia mais robusta que o WPA2.
- Enhanced Open (OWE): criptografia individual por dispositivo em redes abertas, sem senha.
- Hotspot 2.0/Passpoint: padrão IEEE 802.11u para conexão automática e segura em dispositivos compatíveis.
- RADIUS: protocolo que autentica usuários e transmite políticas de sessão entre a plataforma e o equipamento.
- Client isolation: recurso que impede dispositivos da mesma rede de se comunicarem entre si.
- Idle Timeout: tempo máximo de inatividade antes de encerrar a sessão.
- Session Timeout: tempo máximo total de uma sessão, independentemente do uso.
Esses termos aparecem com frequência crescente nos termos de referência de Wi-Fi. Conhecê-los ajuda o gestor a escrever requisitos precisos e o avaliador a identificar respostas genéricas.
Uma proposta que responde “atende” a todos os itens, sem indicar como cada um é entregue nem qual camada é responsável, merece atenção redobrada na análise técnica.
Como o WiFeed atende aos requisitos dos editais de Wi-Fi
O WiFeed é uma plataforma de controle de acesso, autenticação e segurança para redes Wi-Fi corporativas e institucionais, que opera em nuvem sobre a infraestrutura existente. No contexto de editais públicos, isso significa cobrir os blocos de autenticação, políticas, portal e auditoria a partir de um único painel.
Na prática, a equipe de TI centraliza:
- Mais de 15 métodos de autenticação: SSO via SAML com 2FA, Active Directory, Google Workspace, LDAP, login via Gov.br, voucher, formulário customizado e aprovação por responsável.
- Políticas por perfil e SSID: tempo de sessão, janelas de horário, banda, conexões simultâneas, limite de reconexões, troca de VLAN e bloqueio ou liberação por MAC.
- Gestão por grupos de locais: regras e portais distintos por unidade, prédio ou área, sem configuração ponto a ponto.
- Logs e relatórios de auditoria: quem acessou, quando e de onde, com termos de uso e consentimento registrados, além de API pública e webhooks para integração.
- Compatibilidade multifabricante: homologação com mais de 20 fabricantes, como Cisco, Fortinet, Aruba, Ruckus, Huawei, Intelbras, Ubiquiti e MikroTik.
A arquitetura se apoia em servidor RADIUS na nuvem, sem servidores locais em cada unidade. Segundo a WiFeed, os dados ficam hospedados na Oracle Cloud Brasil, com 99,9% de uptime mensal garantido. Os cenários de implantação mais comuns já estão documentados.
Para quem está avaliando fornecedores, a página de fornecedor de hotspot para órgãos públicos reúne os recursos específicos para governo e o canal de contato do time comercial.
Perguntas frequentes sobre Wi-Fi para licitações públicas
1- O que deve constar no termo de referência de Wi-Fi? No mínimo: arquitetura em nuvem, métodos de autenticação por perfil, políticas de sessão e segmentação, campos e retenção de logs, requisitos do captive portal e compatibilidade com a infraestrutura existente. Indicar a camada responsável por cada item evita impugnações.
2- Plataforma de gestão de Wi-Fi pode ser contratada por pregão eletrônico? Em geral, sim. Soluções SaaS de autenticação e gestão de Wi-Fi têm padrões de desempenho e qualidade que podem ser descritos objetivamente, o que costuma enquadrá-las como serviço comum. A decisão final sobre a modalidade é do órgão, com base no ETP.
3- É preciso trocar os access points para atender a um edital de Wi-Fi? Normalmente não. A maioria dos editais recentes exige compatibilidade com a infraestrutura existente. Plataformas homologadas com múltiplos fabricantes aplicam autenticação e políticas sobre os APs e firewalls já instalados, salvo necessidade técnica comprovada.
4- Por quanto tempo um órgão público deve guardar os logs do Wi-Fi? O Marco Civil da Internet prevê 1 ano de guarda de registros de conexão para provedores de conexão, e esse prazo costuma servir de referência. A política definitiva deve ser formalizada pela governança do órgão, considerando também a LGPD.
5- Qual a diferença entre WPA3 e Enhanced Open em um edital? O WPA3 protege redes com senha ou autenticação corporativa. O Enhanced Open (OWE) criptografa redes abertas, sem senha, e dificulta a captura passiva de tráfego. Ambos são recursos do equipamento de rede e funcionam em conjunto com o captive portal.
Se você está redigindo um termo de referência ou preparando a avaliação técnica de propostas, vale ver na prática como cada requisito do edital se traduz em configuração. Agende uma demonstração do WiFeed e confira autenticação via SAML, vouchers, políticas de sessão e logs auditáveis rodando sobre a sua rede atual.
