Toda vez que um colaborador digita a senha do Wi-Fi corporativo, existe um risco embutido que o EAP-TLS foi criado para eliminar. Senhas circulam em grupos de WhatsApp, ficam anotadas em post-its e sobrevivem a demissões que ninguém lembrou de revogar.
O EAP-TLS resolve esse problema pela raiz. Em vez de validar quem sabe uma senha, a rede passa a validar quem possui uma chave privada única, vinculada a um certificado digital emitido por uma autoridade confiável.
Neste guia, você vai entender como funciona a autenticação por certificado, quando ela faz sentido para sua operação, como ela se compara a outros métodos e o que muda no dia a dia do time de TI ao adotá-la.
O que é o EAP-TLS
EAP-TLS é a sigla para Extensible Authentication Protocol – Transport Layer Security, um método de autenticação definido na RFC 5216. Ele opera dentro do framework de autenticação 802.1X.
Vale uma distinção importante: EAP-TLS não é um tipo de certificado, é o protocolo de autenticação. O certificado usado é um certificado digital X.509 comum, o mesmo formato usado em HTTPS.
O EAP-TLS é quem define como esse certificado é apresentado e validado durante a conexão Wi-Fi. Por isso, “certificado digital para autenticação EAP-TLS” é o termo tecnicamente mais correto, embora “certificado EAP-TLS” também circule como forma abreviada no mercado.
Cada certificado contém a identidade do dispositivo, uma chave pública e a assinatura da autoridade certificadora (CA) que o emitiu. A chave privada correspondente nunca sai do dispositivo.
Isso é diferente de qualquer método baseado em senha: não há segredo compartilhado circulando na conexão, então não há nada para um invasor capturar numa rede clonada.
Como funciona a autenticação por certificado na prática
O EAP-TLS reaproveita a estrutura do 802.1X, então o dispositivo (suplicante), o access point (autenticador) e o servidor RADIUS (autenticação) continuam com os mesmos papéis. O que muda é o conteúdo da troca.
O fluxo resumido funciona assim:
- O dispositivo tenta se conectar e o access point solicita sua identidade.
- O cliente responde, muitas vezes com uma identidade anônima para não expor dados em texto claro.
- O RADIUS inicia o handshake TLS e envia seu próprio certificado de servidor.
- O dispositivo valida esse certificado e envia o seu, assinado pela CA da empresa.
- Ambos os lados derivam uma chave de sessão, e o RADIUS libera o acesso.
Um detalhe pouco comentado é a eficiência dessa troca. O EAP-TLS costuma completar a autenticação em bem menos mensagens do que métodos baseados em senha como o PEAP-MSCHAPv2. Em ambientes com centenas de dispositivos reconectando ao mesmo tempo, como abertura de loja ou troca de turno em um hospital, essa diferença aparece no tempo de resposta da rede.
O WPA3-Enterprise no modo de 192 bits, inclusive, exige o uso de EAP-TLS. Não é uma opção entre outras, é requisito do padrão para quem busca esse nível de segurança.
Diferença entre EAP-TLS, PEAP e EAP-TTLS: comparativo direto
Antes de decidir qual método adotar, vale colocar as opções lado a lado. Essa é a dúvida mais comum entre equipes que ainda usam senha compartilhada ou PEAP e avaliam migrar.
| Critério | Senha (PSK/MSCHAPv2) | PEAP | EAP-TLS |
|---|
| Autenticação mútua | Não | Parcial (só servidor) | Sim (cliente e servidor) |
| Resistência a phishing de credencial | Baixa | Média | Alta |
| Complexidade de implantação | Baixa | Média | Alta (requer PKI) |
| Revogação individual de acesso | Difícil | Possível | Imediata via lista de revogação |
| Exigido para WPA3-Enterprise 192 bits | Não | Não | Sim |
| Escalabilidade multi-dispositivo | Limitada | Boa | Excelente |
EAP-TLS vs PEAP: qual a diferença
O PEAP (Protected EAP) nasceu de uma parceria entre Cisco, Microsoft e RSA para adicionar uma camada de proteção a métodos EAP mais simples. Na prática quase toda implementação usa PEAP-MSCHAPv2, muito comum em ambientes Active Directory.
O servidor se autentica com certificado, mas o cliente ainda usa usuário e senha dentro do túnel TLS. O ponto fraco está no método interno: o MSCHAPv2 usa um hash comprometido publicamente desde 2012, quebrável em menos de um dia. Se o usuário ignora um alerta de certificado inválido numa rede clonada, essa senha pode ser capturada. O EAP-TLS elimina esse vetor por completo, já que não existe senha para roubar.
EAP-TLS vs EAP-TTLS: qual a diferença
O EAP-TTLS também abre um túnel TLS autenticado pelo certificado do servidor, mas sem exigir certificado do lado do cliente. Dentro desse túnel, a credencial trafega por métodos mais simples, como PAP.
Isso reduz a complexidade de implantação, já que não é preciso emitir e gerenciar certificado para cada dispositivo. Mas cria uma dependência crítica: se o dispositivo não validar corretamente o certificado do servidor, a credencial fica exposta dentro de um túnel comprometido. O EAP-TLS remove essa dependência ao exigir certificado dos dois lados desde o início.
A contrapartida do EAP-TLS é a complexidade de implantação. Distribuir e gerenciar certificados em centenas de dispositivos manualmente não escala, o que exige ferramentas de MDM para automatizar o provisionamento.
O que é necessário para implementar EAP-TLS
Antes de planejar as fases, vale confirmar se a base mínima de infraestrutura já existe na empresa:
- Servidor RADIUS (AAA): para validar as credenciais e liberar o acesso.
- Diretório de usuários: Active Directory, Google Workspace ou LDAP, para vincular certificados a identidades reais.
- Access points compatíveis com 802.1X: praticamente qualquer equipamento corporativo recente atende esse requisito.
- PKI: para emitir, distribuir e revogar os certificados, seja uma CA interna ou uma gerenciada em nuvem.
A ausência de PKI costuma ser o maior gargalo. Diferente do RADIUS e do diretório, que a maioria das empresas de médio e grande porte já tem, montar uma PKI do zero exige planejamento específico, e é normalmente aí que o projeto de EAP-TLS emperra ou é postergado.
Roteiro de implantação em 5 fases
Adotar EAP-TLS não precisa ser um projeto de um ano. Para uma equipe de TI enxuta, o caminho costuma seguir esta ordem:
- Fase 1, infraestrutura de certificados: definir a autoridade certificadora, seja uma CA interna (via Active Directory) ou uma CA gerenciada em nuvem.
- Fase 2, servidor de autenticação: configurar o RADIUS para validar EAP-TLS, seja local ou via RADIUS na nuvem.
- Fase 3, provisionamento de dispositivos: distribuir certificados via MDM para notebooks e celulares corporativos, priorizando os grupos com maior risco primeiro.
- Fase 4, configuração dos access points: habilitar 802.1X/EAP-TLS nos SSIDs corporativos, mantendo um SSID de transição para dispositivos ainda não migrados.
- Fase 5, política de revogação e monitoramento: definir o processo de revogação imediata em caso de perda de dispositivo ou desligamento de colaborador, com logs centralizados.
Migrações graduais, por unidade ou por grupo de usuários, reduzem o risco de indisponibilidade e dão tempo para a equipe validar compatibilidade com os equipamentos já instalados.
Onde o EAP-TLS faz mais diferença
Nem toda empresa precisa de EAP-TLS no dia um. Mas alguns cenários tornam o investimento praticamente obrigatório:
- Saúde: hospitais e clínicas que trafegam dados de pacientes protegidos por LGPD, com múltiplos dispositivos conectados simultaneamente.
- Varejo multi-loja: redes com dezenas de unidades, onde a gestão centralizada de acesso reduz chamados de suporte.
- Educação: escolas e universidades que precisam diferenciar o acesso entre alunos, professores e visitantes, mantendo conformidade com LGPD e Marco Civil.
- Bancos e cooperativas: instituições financeiras, onde a rastreabilidade de cada acesso é exigência regulatória, não opcional.
- Ambientes com BYOD e IoT: onde controlar cada dispositivo individualmente importa mais do que controlar cada usuário.
Em ambientes multi-unidade, o ganho não é só criptográfico. É a diferença entre a TI depender de uma senha compartilhada, que qualquer pessoa pode repassar, e ter controle individual sobre quem está de fato conectado à rede interna de cada loja ou filial, com revogação imediata quando necessário.
Modos de falha mais comuns
Migrar para certificado traz um novo tipo de chamado técnico. Vale a equipe já conhecer os sintomas mais frequentes:
| Sintoma | Causa provável | Como resolver |
|---|
| Dispositivo não conecta após instalação do certificado | Certificado emitido sem a extensão de uso “autenticação de cliente” | Reemitir o certificado com o perfil correto de uso estendido |
| Conexão cai após alguns minutos | Certificado do servidor RADIUS expirado ou não confiável no dispositivo | Renovar o certificado do servidor e redistribuir a CA raiz nos dispositivos |
| Usuário desligado ainda acessa a rede | Certificado não revogado no momento do desligamento | Automatizar a revogação como parte do processo de offboarding |
| Falha intermitente em dispositivos IoT | Provisionamento manual sem suporte a MDM | Usar um fluxo de provisionamento automatizado compatível com dispositivos headless |
| Erro de “certificado não confiável” em dispositivo novo | CA raiz da empresa não instalada no dispositivo | Incluir a distribuição da CA raiz no processo padrão de configuração de novos equipamentos |
O que isso significa para o orçamento de TI
A comparação mais direta não é “certificado custa mais que senha”. É o custo de não ter controle quando algo dá errado. A LGPD prevê multas que podem chegar a 2% do faturamento da empresa no Brasil, limitadas a R$ 50 milhões por infração, além do custo de reputação de um vazamento de dados via rede Wi-Fi mal controlada.
Com EAP-TLS, a empresa ganha três ativos que pesam diretamente nessa conta: rastreabilidade completa de quem acessou o quê e quando, revogação imediata de acesso individual sem impactar o restante da rede, e eliminação do vetor de phishing de credencial que é hoje uma das portas de entrada mais comuns em incidentes corporativos.
Isso não elimina a necessidade de outras camadas de segurança, mas fecha uma das brechas mais exploradas e mais baratas de corrigir preventivamente.
Glossário rápido
- X.509: padrão internacional que define a estrutura de um certificado digital.
- PKI: infraestrutura de chave pública responsável por emitir, distribuir e revogar certificados.
- CA (autoridade certificadora): entidade que assina e garante a validade de um certificado.
- CRL: lista de certificados revogados, consultada pelo servidor para negar acesso a certificados inválidos.
- MDM: ferramenta de gestão de dispositivos usada para distribuir certificados em escala.
- SCEP: protocolo usado para provisionar certificados automaticamente em dispositivos gerenciados.
- RadSec: camada de segurança que criptografa a comunicação com o servidor RADIUS, usada como transporte em implementações de EAP-TLS baseadas em nuvem.
Perguntas frequentes
1- O que é EAP-TLS? É o método de autenticação 802.1X que usa certificados digitais X.509 para comprovar a identidade de dispositivos na rede, eliminando o uso de senha como credencial de acesso.
2- EAP-TLS é um tipo de certificado? Não. EAP-TLS é o protocolo de autenticação, não o certificado em si. O certificado usado é um certificado digital X.509 comum, e o EAP-TLS define como ele é apresentado e validado durante a conexão à rede Wi-Fi.
3- EAP-TLS é mais seguro que PEAP? Sim. O EAP-TLS exige autenticação mútua com certificado nos dois lados, enquanto o PEAP ainda depende de senha do lado do cliente, mantendo um vetor de phishing que o EAP-TLS elimina.
4- É obrigatório ter um servidor RADIUS para usar EAP-TLS? Sim. O servidor RADIUS valida o certificado apresentado pelo dispositivo e decide se libera o acesso à rede, seguindo o padrão 802.1X.
5- EAP-TLS funciona com dispositivos IoT? Funciona, mas exige um fluxo de provisionamento automatizado, já que dispositivos headless não têm interface para instalar o certificado manualmente.
6- O WiFeed suporta autenticação baseada em certificado? Sim. O módulo Wi-Fi Pass do WiFeed suporta EAP-TLS e EAP-TTLS nativamente, com emissão e revogação de certificado via painel e transporte protegido por RadSec até o servidor RADIUS.
Já é cliente WiFeed? Siga o passo a passo completo de configuração do Wi-Fi Pass com EAP-TLS na central de ajuda.
Como o WiFeed simplifica a autenticação por certificado
O WiFeed centraliza mais de 15 métodos de autenticação, incluindo SSO com 2FA, integração via SAML e LDAP, e é homologado com mais de 20 fabricantes de access points, incluindo Mikrotik, Intelbras e TP-Link, o que evita retrabalho de integração equipamento por equipamento.
Isso significa que, ao adotar controle de acesso baseado em certificado ou combinar com outros métodos robustos, sua equipe não perde tempo reconfigurando a infraestrutura já existente. As regras por perfil, VLAN e conexões simultâneas, junto com os relatórios de auditoria, ficam em um único painel, já alinhados com LGPD e Marco Civil da Internet.
Clientes que padronizaram a autenticação com o WiFeed registram redução de até 87% no tempo de gestão de Wi-Fi e queda de 91% nas reclamações relacionadas à rede.
Se sua equipe está avaliando migrar de senha para um modelo de autenticação mais robusto, vale entender primeiro onde estão os gargalos da sua rede atual. Agende uma demonstração do WiFeed e veja como centralizar autenticação, políticas por perfil e conformidade em uma única plataforma.
