How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Este guia explica como configurar o SCEP (Simple Certificate Enrollment Protocol) para a inscrição automatizada de certificados WiFi empresariais, cobrindo toda a arquitetura desde a PKI e NDES até à implementação de perfis MDM e validação RADIUS. Destina-se a gestores de TI, arquitetos de rede e CTOs em hotéis, cadeias de retalho, estádios, centros de conferências e organizações do setor público que precisam de ir além das chaves pré-partilhadas e implementar uma autenticação 802.1X EAP-TLS escalável e baseada em identidade. A plataforma de sobreposição na nuvem e agnóstica de hardware da Purple integra-se diretamente com esta arquitetura, fornecendo a camada de WiFi para convidados e BYOD que funciona em paralelo com a sua rede de funcionários autenticada por certificado.

📖 10 min de leitura📝 2,282 palavras🔧 2 exemplos práticos❓ 3 perguntas de prática📚 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 espaços empresariais - quer se trate de um hotel de 200 quartos, de uma cadeia de retalho com 50 localizações ou de um grande centro de conferências - depender de chaves pré-partilhadas para o WiFi dos funcionários é um risco de segurança e um estrangulamento operacional. Uma única palavra-passe divulgada expõe toda a rede. A autenticação baseada em certificados via IEEE 802.1X e EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina totalmente esse risco. Cada dispositivo prova a sua identidade de forma criptográfica antes de o ponto de acesso lhe conceder acesso à rede.

O desafio é a distribuição. Implementar manualmente certificados de cliente exclusivos em milhares de dispositivos Windows, iOS e Android não é viável. O SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 pelo IETF in 2020, resolve este problema. Automatiza o processo de solicitação, emissão e instalação de certificados digitais em dispositivos geridos através da sua plataforma MDM - sem qualquer interação do utilizador.

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

Ouça o podcast informativo complementar:

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

O que o SCEP realmente faz

O SCEP não substitui a sua Infraestrutura de Chaves Públicas (PKI). É a camada de inscrição automatizada que se baseia nela. A sua PKI - normalmente uma hierarquia de dois níveis com uma CA raiz offline e uma CA emissora online - continua a ser 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 certificados.

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 como 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 "evil twin", em que um atacante cria um ponto de acesso falso para recolher nomes de utilizador e palavras-passe.

Para uma análise detalhada do handshake EAP-TLS, consulte o nosso guia sobre Autenticação de Certificados WiFi: Acesso Seguro à Rede .

O fluxo de inscrição SCEP, passo a passo

A cadeia de inscrição completa funciona da seguinte forma. A sua plataforma MDM - Microsoft Intune, Jamf ou outro MDM - envia um payload SCEP para um dispositivo gerido. Esse payload contém duas coisas: o URL do SCEP que aponta para o seu servidor NDES (Network Device Enrollment Service) ou gateway SCEP na nuvem, e uma palavra-passe de desafio ou segredo partilhado.

O dispositivo gera localmente o seu próprio par de chaves pública e privada. 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 cria então um Pedido de Assinatura de Certificado (CSR) e envia-o para o gateway SCEP. O gateway valida a palavra-passe de desafio, encaminha o CSR para a sua Autoridade de Certificação (CA), e a CA assina-o e devolve o certificado público ao dispositivo.

A partir desse momento, quando o dispositivo se liga ao seu SSID WiFi, 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 Access-Accept para o ponto de acesso. O dispositivo está na rede. Todo o processo é invisível para o utilizador.

SCEP vs. PKCS: qual utilizar para WiFi

As plataformas MDM como o Intune suportam dois mecanismos de entrega de certificados: SCEP e PKCS (Public Key Cryptography Standards). A diferença arquitetural é significativa.

Com o SCEP, a chave privada é gerada no dispositivo e nunca sai dele. Com o PKCS, a Autoridade de Certificação gera a chave pública e privada centralmente, e o conector de certificados envia o par de chaves para o dispositivo através da rede. Isso significa que a chave privada é transmitida, o que introduz uma superfície de ataque teórica.

O PKCS é adequado para casos de utilização em que é necessária a custódia de chaves (key escrow), como a encriptação de e-mail S/MIME. Para a 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	Através da rede
Servidor NDES necessário	Sim (ou gateway na 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 normas neutras em termos de fornecedor. Funcionam em pontos de acesso Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A sua configuração RADIUS - seja Windows NPS, FreeRADIUS ou um serviço RADIUS na nuvem - é onde define a política de validação de certificados e a atribuição dinâmica de VLAN.

A atribuição dinâmica de VLAN é a forma como vou segmentar 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 isto é 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 com a segmentação de rede baseada em identidade, consulte a nossa visão geral da plataforma de analytics.

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

Configurar com sucesso o SCEP para WiFi empresarial requer uma adesão estrita a uma sequência de implementação específica. As plataformas MDM impõem dependências de perfil: um perfil de WiFi que referencie um certificado SCEP não pode ser aplicado até que esse certificado exista no dispositivo. Violar esta sequência é a causa mais comum de falhas de implementação.

A sequência é: Trusted Root primeiro, perfil SCEP em segundo, perfil WiFi em terceiro. Esta ordem é inegociável.

Passo 1: implementar o perfil de Certificado Trusted Root

Antes que qualquer dispositivo possa solicitar um certificado de cliente ou confiar no seu servidor RADIUS, ele deve confiar na Autoridade de Certificação (CA) emissora. Exporte o seu certificado Root CA - e quaisquer certificados Intermediate CA - como ficheiros .cer. No seu centro de administração MDM, crie um perfil de Certificado de Confiança (Trusted Certificate), carregue o ficheiro .cer e implemente-o no seu grupo de dispositivos de destino.

Se tiver uma hierarquia PKI de dois níveis (recomendado), precisa de implementar tanto o certificado root CA como os certificados da CA emissora como perfis de Trusted Certificate separados, ou como uma cadeia num único perfil, dependendo da sua plataforma MDM.

Passo 2: configurar o perfil de Certificado SCEP

Assim que a confiança estiver estabelecida, configure o perfil SCEP para instruir os dispositivos sobre como obter o 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 baseada no utilizador, CN={{UserPrincipalName}} é o padrão. Para autenticação de dispositivos (dispositivos partilhados, IoT, terminais POS), utilize CN={{AAD_Device_ID}}. Defina a Utilização de chave (Key usage) para Assinatura digital (Digital signature) e Cifragem de chave (Key encipherment). Defina a Utilização de Chave Alargada (Extended Key Usage) para Autenticação de Cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2). Associe este perfil ao perfil de certificado Trusted Root criado no Passo 1. Forneça o URL externo do seu servidor NDES.

Especificamente para o Microsoft Intune, o servidor NDES deve ser publicado através do Azure AD Application Proxy para permitir que os dispositivos remotos se registem antes de chegarem ao local. Não exponha o NDES diretamente à internet.

Passo 3: implementar o perfil de WiFi 802.1X

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

Integração com fornecedor de identidade

Os atributos do certificado SCEP - especificamente o Subject Alternative Name (SAN) - podem conter o nome principal do utilizador do Microsoft Entra ID, Okta ou Google Workspace. Isto associa o certificado a uma identidade específica. Quando desativa uma conta no Entra ID e o MDM anula o registo do dispositivo, o certificado é revogado e o acesso ao WiFi é cortado automaticamente. Essa revogação automatizada é a história de segurança que as chaves pré-partilhadas (pre-shared keys) 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 o nosso guia dedicado.

Melhores práticas e padrões da indústria

Posicionamento do servidor NDES

O servidor NDES deve estar acessível a partir da internet para que os dispositivos se possam registar antes de chegarem ao local. Publique o URL do NDES através do Azure AD Application Proxy. Isto fornece um acesso remoto seguro sem abrir portas de entrada na firewall e permite-lhe aplicar políticas de Acesso Condicional ao fluxo de registo. Nunca exponha o NDES diretamente à internet.

Para redes com mais de 500 dispositivos geridos, considere um gateway SCEP na cloud em vez de um NDES local (on-premises). Os gateways na cloud eliminam o ponto único de falha do NDES, escalam horizontalmente e, normalmente, integram-se diretamente com serviços RADIUS na cloud.

Disponibilidade da CRL

O seu servidor RADIUS verifica a Lista de Revogação de Certificados (CRL) sempre que um dispositivo se autentica. Se o seu Ponto de Distribuição de CRL (CDP) estiver indisponível - porque um servidor está em baixo ou o URL mudou - a autenticação falha para todos os dispositivos na rede em simultâneo. Configure o seu servidor NPS ou RADIUS para impor uma verificação estrita de CRL e torne os 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 titulares de cartões. O EAP-TLS com certificados provisionados por SCEP satisfaz este requisito para redes sem fios em ambientes de Retalho e Hotelaria .

Compatibilidade com WPA3

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

BYOD e W de convidadosiFi

O SCEP requer a inscrição no MDM para enviar o payload do certificado. Não abrange dispositivos BYOD não geridos ou convidados. Para esses casos de utilização, precisa de um SSID separado com um Captive Portal e verificação de identidade. A plataforma da Purple lida com essa camada de forma limpa, coexistindo com a sua rede de funcionários autenticada por certificado. A nossa plataforma de Guest WiFi suporta 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.

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

Falha na aplicação do perfil de WiFi

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

Causa raiz: Incompatibilidade de segmentação de grupo. Se o perfil SCEP visar um grupo de Utilizadores e o perfil de WiFi visar um grupo de Dispositivos, o MDM não conseguirá resolver a dependência.

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

Erros NDES 403 Forbidden

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

Causa raiz: A conta de serviço do MDM Certificate Connector não tem permissões de Leitura e Inscrição no modelo de certificado, ou a filtragem de URL do firewall está a bloquear os parâmetros de consulta SCEP.

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

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

Sintoma: Todos os dispositivos na rede falham a autenticação em simultâneo.

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

Correção: Configure a monitorização e alertas de CRL. Publique CRLs com um período de validade significativamente superior ao intervalo de publicação. Teste a acessibilidade do CDP a partir do servidor RADIUS antes do lançamento (go-live).

Expiração de certificados a causar falhas silenciosas

Sintoma: Dispositivos individuais falham a ligação de forma intermitente, sem um padrão claro.

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

Correção: Configure a renovação de certificados para ser acionada a 80% do tempo de vida do certificado. Monitorize os relatórios de estado de inscrição do MDM para dispositivos com erros de certificado. Defina períodos de validade de certificados adequados ao ciclo de atualização dos seus dispositivos - normalmente um a dois anos para endpoints geridos.

ROI e impacto empresarial

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

Redução de pedidos de suporte (helpdesk): O WiFi baseado em palavra-passe gera um volume de suporte significativo - expiração de palavras-passe, bloqueios e erros de digitação. A autenticação baseada em certificado é invisível para o utilizador. As organizações registam normalmente uma redução de 70-80% no volume de suporte relacionado com WiFi após a migração.

Postura de segurança: O EAP-TLS elimina a recolha de credenciais (credential harvesting) e ataques Man-in-the-Middle. Isto apoia diretamente a conformidade com a norma PCI DSS 4.0 para redes de retalho e hotelaria, bem como os requisitos do Artigo 32.º do GDPR para medidas técnicas de segurança adequadas.

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

Segmentação de rede: A atribuição dinâmica de VLAN através de atributos de certificado RADIUS oferece-lhe uma segmentação de rede imposta 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ços MAC - ambas facilmente contornadas.

A Purple opera em mais de 80.000 locais ativos com 99,999% de tempo de atividade, e a nossa plataforma possui as certificações ISO 27001, GDPR, CCPA e Cyber Essentials. A 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 sua rede de funcionários autenticada por certificado e a nossa camada de WiFi para convidados funcionem a partir da mesma infraestrutura.

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

Referências

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - 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.

Perguntas de Prática

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 contornar o hardware nativo da Starlink e integrar um captive portal gerido na cloud utilizando equipamento de encaminhamento empresarial. Irá aprender a superar a limitação de CGNAT, impor a segmentação de VLAN, gerir as restrições de largura de banda de satélite e garantir a conformidade regulamentar.

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, focando-se na segmentação de VLAN, integração de PMS para gestão automatizada de sessões e otimização de captive portal para captura de dados em conformidade com o GDPR.

Captive Portal Best Practices: Designing for High Conversion and Compliance

Este guia técnico oferece aos gestores de TI, arquitetos de rede e diretores de operações de espaços um plano completo para implementar captive portals que equilibram a segurança da rede com uma elevada conversão de utilizadores. Abrange toda a arquitetura, desde a segmentação de VLAN e autenticação RADIUS até ao design de consentimento em conformidade com o GDPR e à seleção do método de autenticação. Baseado na experiência operacional da Purple em mais de 80.000 espaços e 440 milhões de inícios de sessão em 2024, cada recomendação é fundamentada em dados reais de implementação.