How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para o registro automatizado de certificados WiFi corporativos, cobrindo toda a arquitetura, desde a PKI e o NDES até a implantação de perfis de MDM e validação RADIUS. Destina-se a gerentes de TI, arquitetos de rede e CTOs de hotéis, redes de varejo, estádios, centros de convenções e organizações do setor público que precisam ir além das chaves pré-compartilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição em nuvem e independente de hardware da Purple integra-se diretamente a essa arquitetura, fornecendo a camada de WiFi para convidados e BYOD que funciona em paralelo com a rede de funcionários autenticada por certificado.

📖 10 min de leitura📝 2,282 palavras🔧 2 exemplos práticos❓ 3 questões práticas📚 9 definições principais

Ouça este guia

Ver transcrição do podcast

Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network. Whether that is a university campus, a multi-site hotel group, or a large public sector estate, the challenges are identical.

We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them.

This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map.

Let us get into it.

First principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalised by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine.

In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS, Extensible Authentication Protocol with Transport Layer Security, which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks, where an attacker spins up a rogue access point to harvest credentials.

Here is how the full chain works. A managed device, a student laptop, a staff phone, a hotel point-of-sale terminal, needs to join the corporate wireless network. Your MDM platform, which might be Microsoft Intune or Jamf, pushes a SCEP payload to that device. The payload contains two things: the SCEP URL, which points to your NDES server or cloud SCEP gateway, and a challenge password or shared secret.

The device generates its own public and private key pair locally. This is critical. The private key never leaves the device. It is generated on-device, stored in the secure enclave or TPM, and is never transmitted across the network. The device then creates a Certificate Signing Request, a CSR, and sends it to the SCEP gateway. The gateway validates the challenge, forwards the CSR to your Certificate Authority, and the CA signs it and returns the public certificate to the device.

From that point on, when the device connects to your WiFi SSID, it presents that certificate to the RADIUS server. The RADIUS server validates the certificate against your CA trust chain, checks the Certificate Revocation List to confirm the cert has not been revoked, and if everything checks out, sends an accept message to the access point. The device is on the network. The whole process is invisible to the user.

Now, let us talk about where SCEP sits relative to the alternative, which is PKCS. PKCS, Public Key Cryptography Standards, is the other certificate delivery method supported by platforms like Intune. With PKCS, the CA generates both the public and private key centrally, and the certificate connector pushes the key pair down to the device. That means the private key travels over the network, which introduces a theoretical attack surface. PKCS is fine for use cases like S/MIME email encryption where key escrow is actually desirable. For WiFi authentication, SCEP is the right choice. The private key stays on the device, full stop.

Now, the hardware layer. SCEP and EAP-TLS are vendor-neutral standards, which means they work across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Your RADIUS configuration, whether that is Windows NPS, FreeRADIUS, or a cloud RADIUS service, is where you define the certificate validation policy and, critically, where you configure dynamic VLAN assignment.

Dynamic VLANs are how you segment the network by identity. A student device gets VLAN 20 for internet access only. A faculty device gets VLAN 10 for access to internal research systems. A facilities management device gets VLAN 30 for access to building management systems. All of this is driven by the certificate attributes and the RADIUS policy, with no manual intervention per device.

For identity provider integration, SCEP certificate attributes, specifically the Subject Alternative Name, can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. That ties the certificate to a specific identity, which means when you disable an account in Entra ID and the MDM unenrols the device, the certificate is revoked and WiFi access is cut automatically. That is the revocation story that pre-shared keys simply cannot tell.

Right, let us talk about the deployment sequence, because this is where most teams trip up.

The sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Intune and Jamf both enforce profile dependencies. If your WiFi profile references a SCEP certificate that has not yet been deployed to the device, the WiFi profile will fail with a cryptic error that looks like a misconfiguration but is actually just a timing issue.

The second pitfall is group targeting. All three profiles, Trusted Root, SCEP, and WiFi, must be deployed to the exact same Azure AD or Jamf group. If the SCEP profile targets a user group and the WiFi profile targets a device group, Intune cannot resolve the dependency and the WiFi profile will show as Not Applicable. This catches teams out constantly.

Third: NDES server accessibility. Your NDES server needs to be reachable from the internet so that devices can enrol before they arrive on-site. The right way to do this is via Azure AD Application Proxy, not by punching a hole in your firewall. App Proxy gives you secure remote access without inbound ports and lets you apply Conditional Access policies to the enrolment flow.

Fourth: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point is unavailable, because a server is down, or the URL has changed, authentication fails for every device on the network simultaneously. That is a campus-wide outage. Make your CRL endpoints highly available, and test revocation before you go live.

For large networks, anything above 500 devices, consider a cloud SCEP gateway rather than on-premises NDES. Cloud gateways eliminate the NDES single point of failure, scale horizontally, and typically integrate directly with cloud RADIUS services, removing another infrastructure dependency.

Let us tackle a few rapid-fire questions we often hear from CTOs.

Can SCEP handle BYOD devices that are not MDM-enrolled? Not directly. SCEP requires MDM enrolment to push the certificate payload. For unmanaged BYOD, you need a different approach, either a self-service onboarding portal, or a separate SSID using a captive portal with identity verification. Purple handles that guest and BYOD layer cleanly, sitting alongside your certificate-authenticated staff network.

What about iOS and Android? Both platforms support SCEP natively. iOS has supported SCEP since iOS 4. Android Enterprise supports SCEP through Intune and other MDMs. The configuration is slightly different per platform but the underlying protocol is identical.

Does EAP-TLS work with WPA3? Yes. WPA3-Enterprise mandates 192-bit security mode for sensitive environments, and EAP-TLS is fully compatible. In fact, WPA3-Enterprise with EAP-TLS is the combination recommended by the Wi-Fi Alliance for government and financial networks.

To bring this together. SCEP certificate WiFi authentication is the right architecture for any network with more than 50 managed devices. It eliminates shared credentials, gives you per-device identity, enables dynamic VLAN segmentation, and integrates directly with your identity provider for automated revocation. The deployment sequence, Trusted Root, then SCEP profile, then WiFi profile, is fixed. Group targeting must be consistent. CRL availability is not optional.

For higher education specifically, the combination of SCEP for staff and faculty devices, alongside a separate guest WiFi layer for students on personal devices, gives you both security and a great user experience without compromise.

If you want to go deeper, Purple's guide on enterprise WiFi authentication covers the cloud-native path. And if you are thinking about what happens when an employee leaves, our guide on revoking WiFi access walks through the full revocation workflow.

Thanks for listening. I am from the Purple technical team, and we will see you in the next briefing.

Principais conclusões

✓SCEP (RFC 8894) automates certificate enrollment for managed devices - the private key is generated on-device and never transmitted, making it the correct choice for WiFi authentication over PKCS.
✓The deployment sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Violating this order causes profile dependency failures.
✓All three MDM profiles (Trusted Root, SCEP, WiFi) must target the exact same directory group. Cross-group targeting is the most common cause of deployment failures.
✓NDES should be published via Azure AD Application Proxy, not exposed directly to the internet. For networks above 500 devices, a cloud SCEP gateway eliminates the NDES single point of failure.
✓CRL Distribution Point availability is a network-critical dependency. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication simultaneously.
✓EAP-TLS with SCEP-provisioned certificates satisfies PCI DSS 4.0 Requirement 8.6 for wireless networks in cardholder data environments and is required for WPA3-Enterprise 192-bit (Suite B).
✓SCEP covers managed devices only. Unmanaged BYOD and guest devices require a separate SSID with captive portal and identity verification - Purple's platform handles this layer alongside your certificate-authenticated staff network.

Resumo executivo

Para locais corporativos — seja um hotel de 200 quartos, uma rede de varejo com 50 unidades ou um grande centro de convenções —, depender de chaves pré-compartilhadas para o WiFi dos funcionários é um risco de segurança e um gargalo operacional. Uma única senha vazada expõe toda a rede. A autenticação baseada em certificado via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo comprova sua identidade criptograficamente antes que o ponto de acesso conceda acesso à rede.

O desafio é a distribuição. Implantar certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android manualmente não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pela IETF em 2020, resolve isso. Ele automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos gerenciados por meio de sua plataforma MDM — sem qualquer interação do usuário.

Este guia aborda toda a arquitetura: o que o SCEP faz, como ele se integra ao Microsoft Intune, Jamf e outras plataformas MDM, a sequência exata de implantação que a maioria das equipes erra e as armadilhas operacionais que causam interrupções. Também abordamos dois cenários de implementação do mundo real nos setores de hotelaria e varejo, e explicamos onde a plataforma WiFi para convidados da Purple se encaixa ao lado de sua rede de funcionários autenticada por certificado.

Ouça o podcast complementar informativo:

Análise técnica detalhada: SCEP, PKI e 802.1X

O que o SCEP realmente faz

O SCEP não substitui sua Infraestrutura de Chaves Públicas (PKI). Ele é a camada de registro automatizada que opera sobre ela. Sua PKI — normalmente uma hierarquia de duas camadas com uma CA raiz offline e uma CA emissora online — continua sendo a âncora de confiança. O SCEP automatiza a etapa em que um dispositivo solicita um certificado a essa CA, eliminando a necessidade de geração manual de CSR e instalação de certificado.

No contexto da autenticação WiFi, o protocolo de destino é o EAP-TLS. Este é o método de autenticação 802.1X que exige que tanto o dispositivo cliente quanto o servidor RADIUS apresentem certificados X.509 válidos. Nenhum dos lados confia no outro sem prova criptográfica. Esse modelo de autenticação mútua elimina o roubo de credenciais e protege contra ataques de "evil twin" (gêmeo malvado), em que um invasor cria um ponto de acesso falso para coletar nomes de usuário e senhas.

Para uma análise detalhada do handshake EAP-TLS, consulte nosso guia sobre Autenticação de certificado WiFi: acesso seguro à rede .

O fluxo de registro do SCEP, passo a passo

A cadeia de registro completa funciona da seguinte forma. Sua plataforma MDM — Microsoft Intune, Jamf ou outro MDM — envia um payload SCEP para um dispositivo gerenciado. Esse payload contém duas coisas: a URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP em nuvem, e uma senha de desafio ou segredo compartilhado.

O dispositivo gera seu próprio par de chaves pública e privada localmente. Esta é a propriedade de segurança crítica do SCEP: a chave privada é gerada no dispositivo, armazenada no enclave seguro ou chip TPM, e nunca é transmitida pela rede. O dispositivo então cria uma Solicitação de Assinatura de Certificado (CSR) e a envia para o gateway SCEP.

O gateway valida a senha de desafio, encaminha a CSR para sua Autoridade Certificadora (CA), e a CA a assina e retorna o certificado público para o dispositivo.

A partir desse momento, quando o dispositivo se conecta ao seu SSID WiFi, ele apresenta esse certificado ao servidor RADIUS. O servidor RADIUS valida o certificado em relação à cadeia de confiança da sua CA, verifica a Lista de Revogação de Certificados (CRL) para confirmar que o certificado não foi revogado e, se tudo estiver correto, envia uma mensagem de Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o usuário.

SCEP vs. PKCS: qual usar para WiFi

Plataformas MDM como o Intune oferecem suporte a dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetônica é significativa.

Com o SCEP, la chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade Certificadora gera as chaves pública e privada de forma centralizada, e o conector de certificados envia o par de chaves para o dispositivo pela rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é apropriado para casos de uso em que a custódia de chaves é necessária, como a criptografia de e-mail S/MIME. Para autenticação WiFi, o SCEP é a escolha correta. A chave privada permanece no dispositivo.

Propriedade	SCEP	PKCS
Geração de chave privada	No dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmissão de chave privada	Nunca	Pela rede
Servidor NDES necessário	Sim (ou gateway em nuvem)	Não
Recomendado para WiFi	Sim	Não
Recomendado para S/MIME	Não	Sim

Compatibilidade de hardware

O SCEP e o EAP-TLS são padrões independentes de fornecedor. Eles funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. Sua configuração do RADIUS — seja Windows NPS, FreeRADIUS ou um serviço RADIUS em nuvem — é onde você define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é como vou segmente a rede por identidade do dispositivo. Um dispositivo de funcionário recebe a VLAN 10 com acesso a sistemas internos. Um dispositivo de prestador de serviços recebe a VLAN 20 apenas com acesso à internet. Um terminal de ponto de venda recebe a VLAN 30 apenas com acesso a sistemas de processamento de pagamentos. Tudo isso é impulsionado por atributos de certificado e política RADIUS, sem intervenção manual por dispositivo.

Para saber mais sobre como o WiFi Analytics se integra à segmentação de rede baseada em identidade, consulte a visão geral da nossa plataforma de análise.

Guia de implementação: a sequência de implantação

A configuração bem-sucedida do SCEP para WiFi corporativo exige a adesão estrita a uma sequência de implantação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que faz referência a um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. A violação dessa sequência é a causa mais comum de falhas de implantação.

A sequência é: Raiz Confiável primeiro, perfil SCEP em segundo, perfil de WiFi em terceiro. Essa ordem é inegociável.

Passo 1: implantar o perfil de Certificado de Raiz Confiável

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade Certificadora emissora. Exporte seu certificado de CA Raiz - e quaisquer certificados de CA Intermediária - como arquivos .cer. No seu centro de administração MDM, crie um perfil de Certificado Confiável, faça o upload do arquivo .cer e implante-o no seu grupo de dispositivos de destino.

Se você tiver uma hierarquia PKI de duas camadas (recomendado), precisará implantar os certificados da CA raiz e da CA emissora como perfis de Certificado Confiável separados, ou como uma cadeia em um único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

Assim que a confiança for estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter seu certificado de cliente.

Crie um novo perfil de configuração e selecione o tipo de perfil de certificado SCEP. Configure o formato do nome do Assunto (Subject name). Para autenticação orientada ao usuário, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivo (dispositivos compartilhados, IoT, terminais de PDV), use CN={{AAD_Device_ID}}. Defina o Uso da chave (Key usage) como Assinatura digital (Digital signature) e Criptografia de chave (Key encipherment). Defina o Uso estendido de chave (Extended Key Usage) como Autenticação de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil ao perfil de certificado de Raiz Confiável criado no Passo 1. Forneça a URL externa do seu servidor NDES.

Especificamente para o Microsoft Intune, o servidor NDES deve ser publicado por meio do Proxy de Aplicativo do Azure AD para permitir que dispositivos remotos se registrem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implantar o perfil de WiFi 802.1X

O passo final é enviar a configuração de WiFi que vincula os certificados ao SSID da rede. Crie um perfil de configuração de Wi-Fi. Insira o Nome da rede (SSID) exatamente como ele é transmitido pelos seus pontos de acesso. Selecione WPA2-Enterprise ou WPA3-Enterprise como o tipo de segurança. Defina o tipo de EAP como EAP-TLS. Nas configurações de autenticação, selecione o perfil de certificado SCEP criado no Passo 2 como o certificado de autenticação do cliente. Especifique o certificado de Raiz Confiável para validação do servidor — isso garante que o dispositivo se conecte apenas ao seu servidor RADIUS legítimo e não a um ponto de acesso invasor.

Integração com provedor de identidade

Os atributos do certificado SCEP — especificamente o Nome Alternativo do Assunto (SAN) — podem conter o nome principal do usuário do Microsoft Entra ID, Okta ou Google Workspace. Isso vincula o certificado a uma identidade específica. Quando você desativa uma conta no Entra ID e o MDM desregistra o dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é o diferencial de segurança que as chaves pré-compartilhadas (PSKs) não conseguem igualar.

Para saber mais sobre EAP Method WiFi: A Guide to Secure Network Access , incluindo caminhos de migração PEAP-MSCHAPv2, consulte nosso guia dedicado.

Melhores práticas e padrões do setor

Posicionamento do servidor NDES

O servidor NDES deve estar acessível pela internet para que os dispositivos possam se registrar antes de chegarem ao local. Publique a URL do NDES por meio do Proxy de Aplicativo do Azure AD. Isso fornece acesso remoto seguro sem abrir portas de entrada no firewall e permite aplicar políticas de Acesso Condicional ao fluxo de registro. Nunca exponha o NDES diretamente à internet.

Para redes com mais de 500 dispositivos gerenciados, considere um gateway SCEP em nuvem em vez do NDES local. Os gateways em nuvem eliminam o ponto único de falha do NDES, escalam horizontalmente e geralmente se integram diretamente com serviços RADIUS em nuvem.

Disponibilidade de CRL

Seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) toda vez que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível — porque um servidor está fora do ar ou a URL mudou — a autenticação falhará para todos os dispositivos na rede simultaneamente. Configure seu servidor NPS ou RADIUS para impor uma verificação estrita de CRL e torne seus endpoints de CRL altamente disponíveis. Teste a revogação antes de entrar em produção.

O Requisito 8.6 do PCI DSS 4.0 exige autenticação multifator na camada de rede para ambientes de dados de portadores de cartão. O EAP-TLS com certificados provisionados por SCEP atende a esse requisito para redes sem fio em ambientes de Varejo e Hospitalidade .

Compatibilidade com WPA3

O EAP-TLS é totalmente compatível com o WPA3-Enterprise. O WPA3-Enterprise com a suíte de segurança de 192 bits (Suite B) exige o EAP-TLS e é a combinação recomendada pela Wi-Fi Alliance para redes governamentais, financeiras e de saúde. Se você estiver implantando em ambientes de Saúde ou Transporte com requisitos de conformidade estritos, o WPA3-Enterprise com EAP-TLS é a arquitetura de destino correta.

BYOD e W de convidadosiFi

SCEP exige o registro no MDM para enviar o payload do certificado. Ele não abrange dispositivos BYOD não gerenciados ou convidados. Para esses casos de uso, você precisa de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple gerencia essa camada de forma limpa, operando paralelamente à rede de funcionários autenticada por certificado. Nossa plataforma de Guest WiFi oferece suporte a opt-ins de escolha consciente, captura de dados primários (first-party) e integração com o Microsoft Entra ID, Okta e Google Workspace para verificação de identidade.

Solução de problemas e mitigação de riscos

Falha ao aplicar o perfil de WiFi

Sintoma: O dispositivo recebe os certificados Trusted Root e SCEP, mas o perfil de WiFi aparece como Erro ou Não Aplicável no MDM.

Causa raiz: Incompatibilidade de direcionamento de grupo. Se o perfil SCEP direcionar a um grupo de Usuários e o perfil de WiFi direcionar a um grupo de Dispositivos, o MDM não conseguirá resolver a dependência.

Correção: Audite suas atribuições. Certifique-se de que os perfis Trusted Root, SCEP e WiFi direcionem exatamente para o mesmo grupo de diretório.

Erros NDES 403 Forbidden

Sintoma: Os dispositivos não conseguem recuperar o certificado SCEP. Os logs do NDES IIS mostram erros HTTP 403.

Causa raiz: A conta de serviço do MDM Certificate Connector não possui permissões de Leitura e Inscrição (Read and Enroll) no modelo de certificado, ou o filtro de URL do firewall está bloqueando os parâmetros de query string do SCEP.

Correção: Verifique se a conta do conector possui permissões de Leitura e Inscrição no modelo de CA. Verifique os logs do firewall para garantir que as URLs que contêm ?operation=GetCACaps não estejam bloqueadas.

Falha de autenticação em massa após expiração da CRL

Sintoma: Todos os dispositivos na rede falham ao se autenticar simultaneamente.

Causa raiz: A CRL expirou ou a URL do CDP está inacessível. O servidor RADIUS não consegue confirmar se os certificados são válidos e falha no modo fechado (fails closed).

Correção: Configure o monitoramento e alertas de CRL. Publique CRLs com um período de validade significativamente maior do que o intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do go-live.

Expiração de certificado causando falhas silenciosas

Sintoma: Dispositivos individuais falham intermitentemente ao se conectar, sem um padrão claro.

Causa raiz: Os certificados do cliente expiraram e o MDM não os renovou com sucesso.

Correção: Configure a renovação do certificado para ser acionada em 80% do tempo de vida do certificado. Monitore os relatórios de status de registro do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificado adequados ao seu ciclo de atualização de dispositivos — normalmente de um a dois anos para endpoints gerenciados.

ROI e impacto nos negócios

A transição para a autenticação por certificado 802.1X baseada em SCEP oferece retornos mensuráveis em segurança, operações e conformidade.

Redução de chamados no helpdesk: O WiFi baseado em senha gera um volume significativo de chamados de suporte — expiração de senhas, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o usuário. As organizações geralmente observam uma redução de 70% a 80% no volume de chamados de helpdesk relacionados ao WiFi após a migração.

Postura de segurança: O EAP-TLS elimina o roubo de credenciais e ataques de Man-in-the-Middle. Isso apoia diretamente a conformidade com o PCI DSS 4.0 para redes de varejo e hospitalidade, além dos requisitos do Artigo 32 do GDPR para medidas de segurança técnica adequadas.

Revogação automatizada: Quando um funcionário sai da empresa, a desativação de sua conta no Microsoft Entra ID aciona a revogação automática do certificado e o cancelamento do registro no MDM. O acesso ao WiFi é interrompido sem qualquer intervenção manual da equipe de rede.

Segmentação de rede: A atribuição dinâmica de VLAN por meio de atributos de certificado RADIUS oferece uma segmentação de rede aplicada criptograficamente. Os dispositivos entram no segmento de rede correto com base nas propriedades do certificado, e não na seleção de SSID ou filtragem de endereço MAC — ambos facilmente burlados.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. Nossa sobreposição de nuvem independente de hardware integra-se com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet — para que a rede de funcionários autenticada por certificado e nossa camada de WiFi para convidados funcionem na mesma infraestrutura.

Para saber mais sobre como a Análise Comportamental: Insights para Redes WiFi pode complementar sua implantação de rede segura, consulte nosso guia de análise.

Referências

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configurar infraestrutura para dar suporte ao SCEP com o Intune - Microsoft Learn [3] Diretrizes de Redes Sem Fio do PCI DSS - PCI Security Standards Council

Definições principais

SCEP (Simple Certificate Enrollment Protocol)

A protocol formalised in RFC 8894 that allows managed devices to automatically request and receive X.509 digital certificates from a Certificate Authority via HTTP, using a shared challenge password for initial authentication. The private key is generated on the device and never transmitted.

The standard mechanism used by MDM platforms like Microsoft Intune and Jamf to deploy WiFi authentication certificates to managed endpoints at scale.

EAP-TLS (Extensible Authentication Protocol - Transport Layer Security)

The most secure 802.1X authentication method, requiring both the client device and the RADIUS server to present valid X.509 certificates. Mutual authentication means neither side trusts the other without cryptographic proof.

The target authentication protocol for enterprise WiFi. Mandated or strongly recommended by PCI DSS 4.0, WPA3-Enterprise 192-bit (Suite B), and HIPAA for wireless networks handling sensitive data.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as a Registration Authority (RA) between SCEP-enabled devices and a Certificate Authority. It validates challenge passwords and forwards CSRs to the CA on behalf of devices that lack domain credentials.

Required infrastructure for SCEP deployment with Microsoft Intune. Should be published via Azure AD Application Proxy rather than exposed directly to the internet.

PKI (Public Key Infrastructure)

The hierarchy of Certificate Authorities, policies, and procedures used to issue, manage, and revoke digital certificates. A two-tier PKI consists of an offline root CA (the master trust anchor) and an online issuing CA (which handles day-to-day certificate issuance).

The non-negotiable prerequisite for EAP-TLS and SCEP deployment. The root CA should be kept air-gapped; its private key is the foundation of your entire certificate trust chain.

CSR (Certificate Signing Request)

A message generated by a device containing its public key and identity information, sent to a Certificate Authority to request a signed digital certificate. In SCEP, the CSR is generated on-device and wrapped in a PKCS envelope before transmission.

Generated automatically by the device during the SCEP enrollment flow. The private key used to sign the CSR never leaves the device.

CRL (Certificate Revocation List)

A list published by the Certificate Authority containing the serial numbers of certificates that have been revoked before their expiration date. RADIUS servers check the CRL on every authentication attempt to ensure revoked certificates cannot access the network.

CRL Distribution Point (CDP) availability is critical. If the RADIUS server cannot reach the CRL, it fails closed and denies all authentication - causing a network-wide outage.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised Authentication, Authorisation, and Accounting (AAA) for network access. In 802.1X WiFi, the RADIUS server validates client certificates, checks the CRL, and returns an Access-Accept or Access-Reject message to the access point.

The authentication server in the 802.1X supplicant-authenticator-server model. Common implementations include Windows NPS, FreeRADIUS, and cloud RADIUS services.

Dynamic VLAN assignment

A RADIUS feature that places an authenticated device on a specific VLAN based on certificate attributes or directory group membership, rather than relying on SSID selection or MAC address filtering. Enforces network segmentation by device identity.

Enables a single SSID to serve multiple device types with different network access levels. A staff device gets VLAN 10 (internal access); a contractor device gets VLAN 20 (internet only); a POS terminal gets VLAN 30 (payment systems only).

MDM (Mobile Device Management)

Software used by IT teams to enroll, configure, secure, and manage smartphones, tablets, and laptops. MDM platforms like Microsoft Intune and Jamf use SCEP profiles to push certificate enrollment instructions to managed devices without user interaction.

The prerequisite for SCEP-based certificate deployment. Devices must be MDM-enrolled before they can receive SCEP and WiFi profiles. Unmanaged BYOD devices require a separate onboarding approach.

Exemplos práticos

A 200-room Premier Inn property needs to secure its staff WiFi for point-of-sale tablets and housekeeping smartphones. They currently use a pre-shared key that has been leaked to contractors. They manage devices via Microsoft Intune and have a mix of iOS and Android devices. The property uses HPE Aruba access points.

Deploy an internal Microsoft AD CS two-tier PKI. Configure NDES on a dedicated Windows Server and publish it via Azure AD Application Proxy.
In Intune, create a Trusted Root Certificate profile containing the Root CA and Issuing CA certificates. Deploy to a 'Property Staff Devices' Azure AD group.
Create a SCEP Certificate profile in Intune pointing to the NDES external URL. Set Subject Name format to CN={{AAD_Device_ID}} since these are shared devices. Set Key Usage to Digital Signature and Key Encipherment, Extended Key Usage to Client Authentication. Deploy to 'Property Staff Devices'.
Create a Wi-Fi profile for the staff SSID, configuring WPA2-Enterprise and EAP-TLS. Select the SCEP profile for client authentication and the Root CA for server validation. Deploy to 'Property Staff Devices'.
Configure the HPE Aruba RADIUS settings to point to Windows NPS. On NPS, configure a Network Policy requiring EAP-TLS and assigning VLAN 10 for staff devices.
Once devices receive profiles and connect successfully, rotate the PSK on the old SSID and schedule its decommission.

Comentário do examinador: This approach correctly identifies that shared devices (POS, housekeeping) require device-based authentication (CN={{AAD_Device_ID}}) rather than user-based authentication, since multiple staff members use the same device. It follows the mandatory profile deployment sequence and ensures all three profiles target the same Azure AD group. Publishing NDES via App Proxy rather than direct internet exposure is the correct security posture for a hospitality environment.

A retail chain with 50 locations wants to deploy 802.1X for corporate laptops across all sites. They use Cisco Meraki access points and Microsoft Intune. They do not want to deploy and maintain on-premises NDES servers or AD CS infrastructure at each location or in their data centre.

Implement a cloud-based PKI and SCEP gateway service that integrates with Intune via the SCEP protocol. The cloud CA issues certificates; the cloud SCEP gateway handles CSR validation.
Configure the cloud RADIUS service (provided by the PKI vendor) within the Cisco Meraki dashboard under Wireless > Access Control for the corporate SSID. Set security to WPA2-Enterprise and point RADIUS to the cloud service.
In Intune, create a Trusted Root Certificate profile containing the cloud CA root certificate. Deploy to 'Corporate Laptops' device group.
Create a SCEP Certificate profile pointing to the cloud SCEP gateway URL. Set Subject Name to CN={{UserPrincipalName}} for user-based authentication. Deploy to 'Corporate Laptops'.
Create a Wi-Fi profile for the corporate SSID with EAP-TLS, referencing the SCEP profile and the cloud CA root. Deploy to 'Corporate Laptops'.
When laptops enroll in Intune, they automatically request certificates from the cloud CA via the cloud SCEP gateway. No on-premises infrastructure is required at any of the 50 locations.

Comentário do examinador: This is the optimal modern architecture for distributed retail environments. By leveraging cloud PKI and cloud RADIUS, the organisation eliminates the need to maintain complex on-premises infrastructure (NDES, AD CS, NPS) at each site. The cloud SCEP gateway scales horizontally and is inherently highly available, removing the single point of failure that on-premises NDES introduces. Cisco Meraki's cloud-managed architecture aligns well with this approach.

Questões práticas

Q1. Your organisation is migrating from PEAP-MSCHAPv2 to EAP-TLS. You have successfully deployed the Trusted Root and SCEP profiles to your 'Corporate Users' Azure AD group in Intune. You deploy the WiFi profile to 'All Corporate Devices'. Users report they cannot connect and the WiFi profile shows as Not Applicable.

Dica: Check the profile dependencies and group targeting rules. Intune resolves profile dependencies based on the assigned group.

Ver resposta modelo

The issue is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which was targeted at a User group ('Corporate Users'). The WiFi profile was targeted at a Device group ('All Corporate Devices'). Intune cannot resolve the dependency across group types. The fix is to change all three profile assignments - Trusted Root, SCEP, and WiFi - to target the same group. Decide whether to use a User group or a Device group based on your authentication model (user-based vs device-based), and apply that consistently across all three profiles.

Q2. A security audit reveals that when an employee is terminated and their Microsoft Entra ID account is disabled, their corporate smartphone can still connect to the staff WiFi network for up to a week after termination.

Dica: Consider how the RADIUS server determines whether a certificate is still valid after the account is disabled. What is the mechanism for communicating revocation status?

Ver resposta modelo

The RADIUS server is not performing strict Certificate Revocation List checking, or the CRL is published infrequently. When an employee is terminated, the MDM should unenroll the device and the CA should revoke the certificate. However, if the RADIUS server is not checking the CRL on every authentication attempt - or if the CRL is only published weekly - the revoked certificate continues to be accepted. The fix involves three steps: configure the RADIUS server to enforce strict CRL checking on every authentication; configure the CA to publish the CRL at a shorter interval (daily or more frequently); and ensure the MDM is configured to trigger certificate revocation when a device is unenrolled.

Q3. You need to provide secure WiFi access for headless IoT devices (smart thermostats, digital signage players) that cannot run an MDM agent and cannot display a captive portal. Can you use SCEP for these devices, and if not, what is the recommended alternative?

Dica: Consider the prerequisites for SCEP enrollment and what alternatives exist for devices that cannot be MDM-enrolled or interact with a browser.

Ver resposta modelo

SCEP cannot be used for these devices. SCEP requires an MDM agent to receive the enrollment URL and challenge password, generate the key pair, and install the resulting certificate. Headless IoT devices that cannot run an MDM agent cannot participate in the SCEP enrollment flow. The recommended alternatives are: (1) MAC Authentication Bypass (MAB) combined with strict VLAN segmentation - the RADIUS server allows the device based on its MAC address and places it on an isolated IoT VLAN with no access to corporate systems; (2) if the device supports it, EST (Enrollment over Secure Transport, RFC 7030) can provision certificates to devices that support HTTPS but not MDM; (3) for devices with a management interface, some vendors support SCEP enrollment directly via the device firmware without requiring an MDM agent. In all cases, IoT devices should be isolated on a dedicated VLAN regardless of the authentication method used.

Continue a ler esta série

How to Set Up a Captive Portal on Starlink: A Guide for Remote & Maritime Venues

Este guia detalha como ignorar o hardware nativo do Starlink e integrar um Captive Portal gerenciado na nuvem usando equipamentos de roteamento corporativos. Você aprenderá como superar a limitação de CGNAT, aplicar a segmentação de VLAN, gerenciar restrições de largura de banda de satélite e garantir a conformidade regulatória.

Hotel Guest WiFi Management: Integrating PMS, Portals, and Brand Standards

Este guia técnico detalha como arquitetar redes WiFi de hotéis de nível empresarial, com foco na segmentação de VLAN, integração de PMS para gerenciamento automatizado de sessões e otimização de Captive Portal para captura de dados em conformidade com a GDPR.

Captive Portal Best Practices: Designing for High Conversion and Compliance

Este guia técnico oferece a gerentes de TI, arquitetos de rede e diretores de operações de locais um blueprint completo para implantar captive portals que equilibram a segurança da rede com uma alta conversão de usuários. Ele abrange toda a arquitetura, desde a segmentação de VLAN e autenticação RADIUS até o design de consentimento em conformidade com a GDPR e a seleção do método de autenticação. Extraído da experiência operacional da Purple em mais de 80.000 locais e 440 milhões de logins em 2024, cada recomendação é baseada em dados reais de implantação.