Como Implementar SCEP para Registo Automatizado de Certificados WiFi

Este guia explica como implementar o SCEP (Simple Certificate Enrollment Protocol) para o registo automatizado de certificados WiFi em espaços empresariais. Abrange o plano arquitetónico completo - desde o design de PKI e integração de MDM até à sequência obrigatória de implementação em três etapas - e mostra aos gestores de TI e arquitetos de rede como eliminar credenciais partilhadas, automatizar a gestão do ciclo de vida dos certificados e cumprir os requisitos de PCI DSS e GDPR em escala.

📖 10 min de leitura📝 2,383 palavras🔧 2 exemplos práticos❓ 4 perguntas de prática📚 10 definições principais

Ouça este guia

Ver transcrição do podcast

INTRODUCTION AND CONTEXT - 0:00 to 1:00

Hello, and welcome to this technical briefing from Purple. Today we are unpacking SCEP, the Simple Certificate Enrollment Protocol, and how to implement it for automated WiFi certificate enrollment. If you are a network architect, an IT director, or managing infrastructure for large venues like retail chains, hospitals, or stadiums, this briefing is for you. We are cutting through the noise to discuss how to deploy EAP-TLS at scale, why SCEP is the right choice for device identity, and how you can practically deploy it in your environment. Let us get straight into it.

TECHNICAL DEEP-DIVE - 1:00 to 6:00

So, what exactly is the challenge we are solving here? In the world of enterprise WiFi security, EAP-TLS represents the gold standard. Unlike legacy methods such as PEAP or EAP-TTLS, which rely on user passwords, EAP-TLS mandates mutual certificate-based authentication. This means the client device must verify the network identity via a server certificate, and the network must verify the client identity via a unique client certificate.

Think about the vulnerability of passwords. They can be shared, phished, or stolen. In a sprawling enterprise environment, a compromised password can grant a bad actor access to your entire internal network. EAP-TLS eliminates this vector entirely. The authentication relies on X.509 certificates issued by a Public Key Infrastructure, or PKI.

But the core challenge with EAP-TLS is not the protocol itself. It is the logistics of getting unique client certificates onto thousands of devices, whether they are Windows laptops, iPads, or point-of-sale tablets. You cannot manually install certificates on thousands of devices. This is where Mobile Device Management platforms like Microsoft Intune or Jamf come into play. But how do you deliver those certificates securely?

You generally have two choices: PKCS or SCEP. Let me be absolutely clear on this. For WiFi authentication, you want SCEP. Here is why it matters. With SCEP, the MDM instructs the endpoint device to generate its own private key locally. That key stays locked in the device secure hardware. It never travels across the network. The device just sends a Certificate Signing Request to your Certificate Authority via a gateway, usually an NDES server.

Contrast that with PKCS, where the Certificate Authority generates the private key centrally and pushes it down over the network to the device. While PKCS has its place, say, for email encryption where you need key escrow, transmitting private keys over the network is a risk you do not need to take for network authentication. Keep the keys on the device. Use SCEP.

Now, let us talk implementation. If you take away one thing from this briefing, it is this rule of thumb: Trust before Authentication. You cannot just push a WiFi profile and expect it to work. There is a strict, three-step deployment sequence you must follow.

Step one: Deploy the Trusted Root Certificate. Before a device can ask for a client certificate, or trust your RADIUS server, it has to trust the issuing Certificate Authority. Push this profile first.

Step two: Configure and push the SCEP Certificate Profile. This tells the device how to talk to the SCEP gateway, what format to use for its subject name, and what the certificate is actually for. In this case, Client Authentication. You must link this profile to the Trusted Root you deployed in step one.

Step three: Deploy the 802.1X WiFi Profile. This is where you tie it all together. You specify the SSID, select WPA3-Enterprise, set the EAP type to EAP-TLS, and point it to the SCEP certificate for client authentication.

IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 6:00 to 8:00

Here is a major pitfall we see all the time. A client calls us and says, the certificates are on the device, but the WiFi profile shows an error in Intune. Almost every single time, this is a group targeting mismatch. If you assign the SCEP profile to a Users group, but assign the WiFi profile to a Devices group, the MDM cannot resolve the dependency. Match your targets exactly across all three profiles.

Let us look at a real-world scenario. Imagine a 200-room hotel. They have 150 managed iOS devices for housekeeping staff. Currently, they use a standard password network, and staff keep sharing the password with guests. It is a genuine operational headache. By migrating to WPA2-Enterprise with EAP-TLS via SCEP, the IT Director eliminates the password entirely. The iOS devices authenticate silently in the background using their certificates.

But what happens if a housekeeper loses a device, or leaves the company? Disabling their Active Directory account is not enough, because the certificate on that device is still cryptographically valid. This brings us to a critical security control: strict CRL checking. You must configure your RADIUS server to check the Certificate Revocation List. If a device goes missing, you revoke the certificate at the CA. The RADIUS server sees the revocation on the CRL and immediately blocks network access. Without strict CRL checking, your security posture is incomplete.

RAPID-FIRE Q&A - 8:00 to 9:00

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

Question one: Is EAP-TLS required for WPA3 Enterprise? While WPA3 Enterprise supports other methods, EAP-TLS is strongly recommended and is required if you are implementing the WPA3 Enterprise 192-bit security suite, often called Suite B.

Question two: Can we use public certificates for clients? No. You must use a private internal CA for client certificates. Public CAs are for public-facing web servers. Your internal RADIUS server needs to trust your specific internal Root CA to validate your corporate devices.

Question three: How does this fit with OpenRoaming? OpenRoaming relies on Passpoint and 802.1X. Purple acts as a free identity provider for services like OpenRoaming under the Connect licence, facilitating seamless, secure roaming across venues using underlying certificate and identity frameworks.

SUMMARY AND NEXT STEPS - 9:00 to 10:00

To wrap up, transitioning to automated SCEP certificate deployment delivers real, measurable returns. You will see a 70 to 80 percent reduction in WiFi-related helpdesk tickets, because users are not getting locked out or typing passwords incorrectly. More importantly, you eliminate the risk of credential harvesting, ensuring you meet compliance frameworks like PCI DSS and GDPR.

Automating enterprise WiFi security is not just about locking things down. It is about making the secure path the easiest path for your users. Your next steps: audit your current 802.1X deployment. If you are still relying on passwords, design your PKI and plan the migration to EAP-TLS with SCEP. Check whether your RADIUS server is enforcing strict CRL or OCSP checking. And verify that your three deployment profiles all target the same group.

Thank you for listening to this technical briefing from Purple. For more detailed deployment guides and to understand how our analytics and identity platforms can integrate with your secure networks, visit purple dot ai.

Principais Conclusões

✓SCEP (RFC 8894) automates X.509 certificate enrollment for managed devices. The private key is generated locally on the device and never transmitted over the network - this is the core security advantage over PKCS.
✓For 802.1X EAP-TLS WiFi authentication, always use SCEP. Reserve PKCS for use cases requiring key escrow, such as S/MIME email encryption.
✓The deployment sequence is non-negotiable: Trusted Root Certificate first, then SCEP Certificate Profile, then 802.1X WiFi Profile. All three profiles must target the exact same Azure AD group.
✓Strict CRL or OCSP checking on the RADIUS server is mandatory. Disabling an AD account does not revoke a certificate. Revoke at the CA and ensure the RADIUS server acts on it.
✓EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer and is required for WPA3 Enterprise 192-bit (Suite B) deployments.
✓Organisations migrating from password-based WiFi to EAP-TLS with SCEP typically report a 70-80% reduction in WiFi-related helpdesk tickets (Purple internal data, 2024).
✓For distributed estates (hotel groups, retail chains, multi-site public-sector), cloud-hosted SCEP gateways and managed PKI services eliminate the on-premises NDES infrastructure requirement without compromising security.

Resumo executivo

Para os operadores de espaços que gerem Guest WiFi em hotéis, superfícies comerciais, estádios e centros de conferências, depender de chaves pré-partilhadas ou de Captive Portals básicos para o acesso à rede dos funcionários é um risco de segurança. A arquitetura de rede moderna exige autenticação 802.1X utilizando EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), garantindo que cada dispositivo é verificado criptograficamente antes de aceder à rede. O desafio é a distribuição: como implementar certificados de cliente únicos em milhares de dispositivos Windows, iOS e Android sem sobrecarregar o suporte técnico?

A resposta é o SCEP - o Simple Certificate Enrollment Protocol. Formalizado pelo IETF como RFC 8894 em 2020, o SCEP automatiza o registo de certificados em frotas de dispositivos geridos. Quando integrado com uma plataforma de MDM como o Microsoft Intune ou o Jamf, o SCEP oferece aprovisionamento de certificados zero-touch: os dispositivos solicitam, recebem e renovam os seus próprios certificados sem qualquer intervenção de TI. A chave privada é gerada localmente no dispositivo e nunca é transmitida pela rede - uma vantagem de segurança fundamental em relação à entrega baseada em PKCS.

Este guia detalha todo o fluxo de trabalho de implementação do SCEP: arquitetura de PKI, configuração do gateway NDES, a sequência obrigatória de implementação de MDM em três etapas e os controlos operacionais - particularmente a verificação de CRL e a segmentação de grupos - que determinam se uma implementação é bem-sucedida ou se falha. Dois cenários do mundo real ilustram esta abordagem em ambientes de hotelaria e retalho. A Purple opera em mais de 80 000 espaços ativos e conta com 350 milhões de utilizadores únicos; os padrões aqui descritos refletem o que funciona a essa escala.

Análise técnica aprofundada

O que o SCEP realmente faz

O SCEP posiciona-se entre a sua plataforma de MDM e a sua Autoridade de Certificação (CA). Fornece um mecanismo padronizado baseado em HTTP para os dispositivos solicitarem, receberem e renovarem certificados X.509 sem necessitarem de uma credencial associada ao domínio ou de envolvimento manual do administrador. O protocolo foi originalmente desenvolvido no início dos anos 2000 e obteve uma adoção generalizada em ambientes de MDM empresariais antes de o IETF o publicar formalmente como RFC 8894.

O fluxo de registo em seis etapas funciona da seguinte forma. Primeiro, o dispositivo gerido liga-se ao URL do gateway SCEP pré-configurado no seu perfil de MDM. Segundo, o dispositivo gera localmente um par de chaves privada/pública e cria um Pedido de Assinatura de Certificado (CSR). Terceiro, o gateway SCEP valida a autorização do dispositivo utilizando uma palavra-passe de desafio ou OTP incorporada na política de MDM. Quarto, o gateway encaminha o CSR validado para a CA. Quinto, a CA assina o certificado e devolve-o ao gateway. Sexto, o gateway entrega o certificado assinado ao dispositivo. As renovações futuras seguem o mesmo caminho automatizado - o dispositivo volta a registar-se antes da expiração, sem qualquer ação do utilizador ou do administrador.

SCEP vs PKCS: a decisão que importa

O Microsoft Intune e a maioria das plataformas de MDM suportam dois mecanismos de entrega de certificados: SCEP e PKCS. A distinção é arquitetónica, não cosmética.

Com o SCEP, a chave privada é gerada no dispositivo e permanece lá. A CA nunca a vê. O TPM do dispositivo (em Windows) ou o Secure Enclave (em iOS/macOS) protege a chave ao nível do hardware. Com o PKCS, a CA gera o par de chaves centralmente e transmite-o para o dispositivo através da rede. A CA retém uma cópia, permitindo a custódia de chaves (key escrow) - o que é útil para a encriptação de e-mail S/MIME, mas introduz riscos desnecessários para a autenticação de rede.

Para autenticação WiFi 802.1X, utilize o SCEP. A chave privada nunca sai do dispositivo. Essa é a regra.

Critério	SCEP	PKCS
Chave privada gerada em	Dispositivo	CA (centralmente)
Chave privada transmitida pela rede	Nunca	Sim
Suporta TPM / Secure Enclave	Sim	Não
Recomendado para autenticação WiFi	Sim	Não
Recomendado para encriptação de e-mail (S/MIME)	Não	Sim
Custódia de chaves (key escrow) possível	Não	Sim

802.1X e EAP-TLS: a estrutura de autenticação

O IEEE 802.1X é o padrão de controlo de acesso à rede baseado em portas que sustenta a segurança WiFi empresarial. Define três funções: o suplicante (o dispositivo cliente), o autenticador (o ponto de acesso - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme ou Fortinet) e o servidor de autenticação (um servidor RADIUS como o Microsoft NPS, FreeRADIUS ou Cisco ISE).

O EAP-TLS é o método EAP mais seguro para 802.1X. Ambos os lados apresentam certificados: o servidor RADIUS apresenta o seu certificado ao cliente, e o cliente apresenta o seu certificado aprovisionado por SCEP ao servidor RADIUS. Nenhum dos lados pode fazer-se passar pelo outro sem um certificado válido e não revogado da hierarquia de CA fidedigna. Este modelo de autenticação mútua elimina o roubo de credenciais, ataques Evil Twin e riscos de pontos de acesso não autorizados numa única decisão arquitetónica.

O EAP-TLS cumpre o Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. É obrigatório para implementações WPA3 Enterprise de 192 bits (Suite B). Para qualquer rede sem fios abrangida pelo processamento de dados de titulares de cartões - retalho ponto de venda, receção de hotel, bilheteira de estádio - o EAP-TLS é a escolha correta.

Para uma análise mais aprofundada da arquitetura de WiFi seguro e de como a autenticação baseada em certificados se enquadra numa postura de segurança mais ampla, consulte o nosso guia essencial.

Guia de implementação

A sequência de implementação é não negociável. O Intune e o Jamf resolvem as dependências de perfil por ordem: o perfil de WiFi depende do perfil SCEP, que depende do perfil Trusted Root. Se os implementar fora de sequência, a aplicação do perfil de WiFi irá falhar.

Passo 1: Desenhe a sua PKI

Antes de tocar numa consola MDM, desenhe a sua hierarquia de certificados. Uma PKI de dois níveis é o padrão: uma CA raiz offline e uma CA emissora online. A chave privada da CA raiz é a âncora de confiança mestre para toda a sua infraestrutura de certificados - mantenha-a isolada (air-gapped). A CA emissora lida com a emissão diária de certificados e publica a Lista de Revogação de Certificados (CRL) e o respondedor OCSP.

Para a maioria das implementações em recintos empresariais, o Microsoft Active Directory Certificate Services (AD CS) executado em Windows Server fornece a CA emissora. Os serviços de PKI alojados na nuvem de fornecedores como o SCEPman ou o SecureW2 eliminam totalmente o requisito de infraestrutura local e vale a pena avaliá-los para implementações distribuídas em grupos hoteleiros, cadeias de retalho ou organizações do setor público com vários locais.

Passo 2: Implementar o servidor NDES (ou gateway SCEP na nuvem)

O NDES (Network Device Enrollment Service) é a função do Microsoft Windows Server que atua como o gateway SCEP entre o seu MDM e a sua CA. Requisitos de configuração principais:

Publique o URL do NDES externamente através do Azure AD Application Proxy (ou proxy inverso equivalente). Isto permite que os dispositivos remotos se registem antes de chegarem ao local, sem abrir portas de firewall de entrada.
A conta de serviço NDES requer permissões de Leitura e Registo (Read and Enroll) no modelo de certificado da CA.
Configure o modelo de certificado com a Utilização de Chave (Key Usage) definida para Assinatura Digital (Digital Signature) e Cifragem de Chave (Key Encipherment), e a Utilização de Chave Alargada (Extended Key Usage) definida para Autenticação de Cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
Defina um período de validade de certificado adequado. Um ano é o padrão para certificados de cliente; dois anos é aceitável para certificados de dispositivo em frotas estáveis.

Se preferir evitar a infraestrutura NDES local, os gateways SCEP na nuvem integram-se diretamente com o Intune e a sua CA via API, removendo totalmente a dependência do IIS.

Passo 3: Implementar o perfil de Certificado de Raiz Fidedigna (Trusted Root)

Na sua plataforma MDM, crie um perfil de Certificado Fidedigno (Trusted Certificate) e carregue o seu certificado de CA Raiz (e quaisquer certificados de CA Intermédia) como ficheiros .cer. Implemente este perfil nos seus grupos de dispositivos de destino antes de qualquer outro perfil de certificado ou de WiFi. Sem este passo, os dispositivos não conseguem validar o certificado do servidor RADIUS durante o handshake EAP-TLS e não podem confiar na CA emissora ao solicitar o seu próprio certificado SCEP.

Regra de ouro: Direcione sempre o mesmo grupo do Azure AD (Utilizadores ou Dispositivos) nos três perfis relacionados. Uma incompatibilidade aqui é a causa individual mais comum de falhas na implementação de perfis de WiFi.

Passo 4: Configurar o perfil de Certificado SCEP

Crie um perfil de configuração de certificado SCEP no seu MDM:

Formato do nome do requerente (Subject name format): Para autenticação baseada no utilizador, utilize CN={{UserPrincipalName}}. Para autenticação de dispositivo (recomendado para dispositivos partilhados e IoT), utilize CN={{AAD_Device_ID}}.
Utilização de chave (Key usage): Digital Signature, Key Encipherment.
Utilização de chave alargada (Extended key usage): Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
URL do servidor SCEP: O URL do NDES publicado externamente.
Certificado raiz: Associe ao perfil Trusted Root do Passo 3.
Período de validade do certificado: Deve corresponder ao modelo configurado na CA.

Passo 5: Implementar o perfil de WiFi 802.1X

Crie um perfil de configuração de WiFi:

SSID: Introduza o nome da rede exatamente como é transmitido pelos seus pontos de acesso.
Tipo de segurança: WPA2-Enterprise ou WPA3-Enterprise.
Tipo de EAP: EAP-TLS.
Certificado de autenticação de cliente: Selecione o perfil de certificado SCEP do Passo 4.
Validação do servidor: Especifique o certificado Trusted Root do Passo 3 e introduza o nome do servidor RADIUS esperado. Isto evita que os dispositivos se liguem a pontos de acesso fraudulentos que apresentem certificados falsos.

Melhores práticas

Impor uma verificação rigorosa de CRL no seu servidor RADIUS

A revogação de certificados é o controlo operacional que elimina o intervalo entre desativar uma conta e bloquear o acesso à rede. Quando um dispositivo é perdido, roubado ou um funcionário sai da empresa, desative a conta AD e revogue o certificado na CA. O seu servidor RADIUS deve estar configurado para verificar a CRL em cada tentativa de autenticação. Se a CRL estiver indisponível - porque o CDP (CRL Distribution Point) está inacessível - a maioria dos servidores RADIUS falha por omissão permitindo o acesso (fail open), o que constitui um risco de segurança. Certifique-se de que os seus CDPs estão altamente disponíveis e que o seu servidor RADIUS está configurado para bloquear o acesso (fail closed) se a CRL não puder ser obtida.

Para revogação em tempo real, configure o OCSP (Online Certificate Status Protocol) além da CRL. O OCSP fornece respostas de estado por certificado sem exigir que o servidor RADIUS transfira e analise toda a CRL.

Utilizar certificados de dispositivo para dispositivos partilhados e IoT

Para dispositivos partilhados - tablets de limpeza de hotéis, terminais POS de retalho, leitores de controlo de acessos de estádios - utilize certificados de dispositivo em vez de certificados de utilizador. Os certificados de dispositivo estão associados à identidade da máquina, não a uma conta de utilizador. Isto significa que o dispositivo se autentica independentemente do utilizador que iniciou sessão, e a revogação está associada ao registo do dispositivo em vez de à saída de um funcionário.

Para implementações de retalho , os certificados de dispositivo em hardware POS também cumprem o requisito PCI DSS para a identidade do dispositivo na camada de rede, sem introduzir a complexidade das credenciais de utilizador no ponto de venda.

Automatizar a renovação de certificados

O SCEP suporta a renovação automática: o MDM instrui o dispositivo a registar-se novamente antes que o certificado expire. Configure o seu perfil SCEP para acionar a renovação a 20% do período de validade restante do certificado. Para um certificado de um ano, a renovação começa aproximadamente 73 dias antes da expiração. Esta janela oferece tempo suficiente para resolver quaisquer falhas de renovação antes que o certificado expire e os dispositivos percam o acesso à rede.

Os certificados expirados que causam falhas de autenticação em massa são o incidente operacional mais comum em implementações 802.1X. A renovação automatizada via SCEP elimina totalmente este risco.

Segmentar redes por atributo de certificado

Os servidores RADIUS podem ler atributos de certificados - Subject, SAN ou OIDs personalizados - e utilizá-los para atribuir dispositivos a VLANs de forma dinâmica. Um tablet de limpeza com um certificado emitido a partir do modelo HousekeepingDevices entra na VLAN de limpeza. Um terminal POS com um certificado do modelo RetailPOS entra na VLAN de âmbito PCI. Trata-se de uma segmentação de rede imposta criptograficamente - muito mais fiável do que as abordagens baseadas em SSID ou baseadas em MAC.

Para operadores de hotelaria que executam Guest WiFi juntamente com Staff WiFi na mesma infraestrutura física, a atribuição de VLAN através de atributos de certificado garante que os convidados e os funcionários estejam sempre em segmentos de rede separados, independentemente do SSID ao qual um dispositivo se liga.

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

Perfil de WiFi mostra 'Erro' ou 'Não Aplicável' no Intune

Causa raiz: Incompatibilidade de segmentação de grupo. O perfil SCEP está atribuído a um grupo diferente do perfil de WiFi. O Intune não consegue resolver a dependência do certificado.

Correção: Audite os três perfis (Trusted Root, SCEP, WiFi). Certifique-se de que estão todos atribuídos exatamente ao mesmo grupo do Azure AD. Se estiver a implementar para Utilizadores, os três perfis devem ter como destino um grupo de Utilizadores. Se estiver a implementar para Dispositivos, os três devem ter como destino um grupo de Dispositivos.

NDES devolve erros HTTP 403

Causa raiz: A conta de serviço do Intune Certificate Connector não tem permissões de Leitura ou Inscrição (Read ou Enroll) no modelo de certificado da CA, ou a filtragem de URL do firewall está a bloquear as query strings do SCEP.

Correção: Verifique se a conta do conector tem permissões de Leitura e Inscrição no modelo na consola da CA. Verifique os registos do firewall para pedidos bloqueados que contenham ?operation=GetCACaps ou ?operation=PKIOperation. Estas query strings devem passar sem modificações.

Os dispositivos não conseguem renovar os certificados antes da expiração

Causa raiz: A janela de renovação do SCEP é demasiado curta ou o servidor NDES está inacessível no momento da renovação.

Correção: Defina o limite de renovação para 20% da validade do certificado. Certifique-se de que o URL do NDES é publicado através de um reverse proxy de alta disponibilidade. Monitorize os registos IIS do NDES para falhas de pedidos de renovação e emita alertas proativamente.

O RADIUS rejeita certificados válidos

Causa raiz: O arquivo de CA fidedignas do servidor RADIUS não inclui o certificado da CA emissora, ou a CRL está desatualizada.

Correção: Importe a cadeia de CA completa (Root CA + Issuing CA) para o arquivo fidedigno do servidor RADIUS. Verifique se a CRL está a ser obtida com sucesso e se o URL do CDP está acessível a partir do servidor RADIUS. Verifique o carimbo de data/hora da próxima atualização da CRL - se já tiver passado, a CA precisa de publicar uma nova CRL.

Para considerações mais amplas sobre o desempenho da rede, juntamente com a segurança, consulte o nosso guia de gestão de largura de banda .

ROI e impacto comercial

O caso de negócio para a inscrição de certificados baseada em SCEP é simples. O WiFi baseado em palavra-passe gera um volume previsível de pedidos de suporte: expirações de palavras-passe, bloqueios, partilha de credenciais de funcionários com convidados e fricção na integração de novos colaboradores. A autenticação baseada em certificados é invisível para o utilizador final. Os dispositivos ligam-se automaticamente. Não existem palavras-passe para expirar, partilhar ou esquecer.

As organizações que migram de WiFi baseado em palavra-passe para EAP-TLS com SCEP reportam tipicamente uma redução de 70-80% nos pedidos de suporte relacionados com WiFi (dados internos da Purple, 2024, com base em implementações em propriedades de hotelaria e retalho). A poupança no suporte técnico por si só justifica frequentemente o custo de implementação logo no primeiro ano.

O impacto na conformidade é igualmente concreto. O EAP-TLS cumpre o Requisito 8.6 do PCI DSS 4.0 para autenticação multifator na camada de rede. Para ambientes de saúde , alinha-se com os requisitos de salvaguarda técnica da HIPAA para acesso a redes sem fios. Para organizações do setor público, apoia os requisitos de certificação Cyber Essentials Plus do NCSC para controlo de acesso à rede.

Para operadores de transportes - concessões ferroviárias, operadores aeroportuários, redes de autocarros - a autenticação baseada em certificados nos dispositivos dos funcionários garante que as redes operacionais que transportam dados críticos de segurança sejam isoladas do WiFi dos passageiros e protegidas contra ataques baseados em credenciais.

A plataforma WiFi Analytics da Purple integra-se com redes protegidas por 802.1X para fornecer insights de dados primários (first-party) sem comprometer a postura de segurança da infraestrutura subjacente. Os 29 mil milhões de pontos de dados recolhidos na rede da Purple demonstram que a segurança e a análise são objetivos complementares e não concorrentes.

Para gestão de feedback e experiência juntamente com a sua implementação de rede segura, consulte o nosso manual de feedback do local .

Definições Principais

SCEP (Simple Certificate Enrollment Protocol)

An IETF-standardised protocol (RFC 8894) that automates X.509 certificate enrollment for managed devices. The device generates its own private key locally and sends only a Certificate Signing Request to the CA via a gateway. The private key never leaves the device.

IT teams encounter SCEP when configuring MDM platforms (Intune, Jamf) to deploy WiFi authentication certificates at scale. It is the recommended mechanism for 802.1X EAP-TLS deployments because the private key is hardware-protected on the endpoint.

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

The most secure 802.1X authentication method. Both the client device and the RADIUS server present X.509 certificates. Neither side can authenticate without a valid, non-revoked certificate from the trusted CA hierarchy.

EAP-TLS is the target authentication protocol that SCEP certificate deployment enables. It satisfies PCI DSS 4.0 Requirement 8.6 and is required for WPA3 Enterprise 192-bit (Suite B) deployments.

PKCS (Public Key Cryptography Standards)

A certificate delivery mechanism where the CA generates both the public and private key pair centrally and transmits them to the endpoint. The CA retains a copy of the private key, enabling key escrow.

IT teams choose between SCEP and PKCS when configuring certificate profiles in Intune. PKCS is appropriate for S/MIME email encryption where key escrow is required. It is not recommended for WiFi authentication because the private key is transmitted over the network.

NDES (Network Device Enrollment Service)

A Microsoft Windows Server role that acts as the SCEP gateway between an MDM platform and a Certificate Authority. It validates device enrollment requests and forwards CSRs to the CA.

NDES is a required infrastructure component for on-premises SCEP deployments with Microsoft Intune. It must be published externally via an application proxy to allow remote devices to enroll. Cloud SCEP gateways are an alternative that eliminates the on-premises NDES dependency.

CRL (Certificate Revocation List)

A list published by the CA containing the serial numbers of certificates that have been revoked before their expiry date. RADIUS servers check the CRL to ensure devices with revoked certificates cannot authenticate.

CRL checking is the operational control that enforces certificate revocation. IT teams must configure their RADIUS server to check the CRL on every authentication attempt and ensure the CRL Distribution Point (CDP) is highly available.

802.1X

An IEEE standard for port-based network access control. It defines the three-party authentication framework (supplicant, authenticator, authentication server) used in enterprise WiFi and wired networks.

802.1X is the framework within which EAP-TLS and SCEP operate. IT teams encounter it when configuring WPA2-Enterprise or WPA3-Enterprise SSIDs and when setting up RADIUS server policies.

RADIUS (Remote Authentication Dial-In User Service)

A networking protocol that provides centralised authentication, authorisation, and accounting (AAA) for network access. In 802.1X deployments, the RADIUS server validates client certificates and enforces VLAN assignment policies.

The RADIUS server is the authentication decision point in every 802.1X deployment. Common implementations include Microsoft NPS, FreeRADIUS, and Cisco ISE. It must be configured with the trusted CA chain and strict CRL or OCSP checking.

CSR (Certificate Signing Request)

A block of encoded text generated by a device that contains the device's public key and identity information. The device sends the CSR to the CA (via the SCEP gateway) to request a signed certificate. The corresponding private key is generated and retained on the device.

The CSR is the core artifact in the SCEP enrollment flow. IT teams configure the CSR format (subject name, key usage, EKU) in the SCEP certificate profile within their MDM platform.

PKI (Public Key Infrastructure)

The combination of hardware, software, policies, and procedures required to create, manage, distribute, and revoke digital certificates. A standard enterprise PKI consists of an offline root CA and an online issuing CA.

PKI is the prerequisite for any EAP-TLS deployment. IT teams must design and deploy a two-tier CA hierarchy before configuring SCEP. Cloud-hosted PKI services reduce the infrastructure burden for distributed estate deployments.

VLAN (Virtual Local Area Network)

A logical network segment that isolates traffic at Layer 2. In 802.1X deployments, RADIUS servers assign devices to VLANs dynamically based on certificate attributes, user identity, or policy.

VLAN assignment via RADIUS is the mechanism that enforces network segmentation in enterprise WiFi. IT teams use it to separate POS devices onto PCI-scoped VLANs, guest devices onto internet-only VLANs, and staff devices onto corporate VLANs - all from a single physical infrastructure.

Exemplos Práticos

A 200-room Premier Inn property needs to deploy secure WiFi for 150 iOS housekeeping devices. Staff are currently sharing a WPA2-Personal password with guests, creating a compliance and operational risk. The IT Director needs to eliminate the shared password without disrupting daily operations.

The IT Director implements a Jamf-driven SCEP deployment in three phases. Phase one: the Root CA certificate is pushed to all 150 iOS devices via a Jamf Trusted Certificate profile, targeting the 'Housekeeping Devices' smart group. Phase two: a SCEP certificate profile is deployed, directing devices to an Azure AD App Proxy-published NDES server. The subject name uses CN={{SERIALNUMBER}} to tie the certificate to the device hardware. Phase three: a WPA2-Enterprise WiFi profile is pushed, specifying EAP-TLS and linking to the SCEP certificate. Devices authenticate silently. The shared password SSID is decommissioned. The RADIUS server is configured with strict CRL checking and VLAN assignment: housekeeping devices land on VLAN 20 (operations), guest devices on VLAN 10 (internet-only).

Comentário do Examinador: The key design decisions here are device certificates (not user certificates) for shared hardware, and VLAN assignment via certificate attributes rather than SSID. This means a device that somehow connects to the guest SSID still lands on the correct VLAN. The CRL checking configuration is non-negotiable: when a housekeeper leaves, the device certificate is revoked at the CA, and the RADIUS server blocks access within the CRL refresh interval - typically 15 minutes with OCSP, or up to one hour with CRL.

A retail chain with 500 locations needs to secure corporate WiFi for Windows POS tablets running payment processing software. PCI DSS 4.0 compliance requires multi-factor authentication at the network layer. The current WPA2-Personal setup fails the PCI DSS Requirement 8.6 assessment.

The network architect deploys EAP-TLS via Microsoft Intune and SCEP across all 500 locations. The deployment uses device certificates with CN={{AAD_Device_ID}} as the subject name, tying each certificate to the Intune device record. The three-profile sequence (Trusted Root, SCEP, WiFi) is deployed to the 'POS Devices' Azure AD group - the same group across all three profiles. The RADIUS server assigns POS devices to a dedicated PCI-scoped VLAN (VLAN 100) based on the certificate's issuing template. The CRL is published to a highly available CDN-hosted endpoint with a four-hour validity window. OCSP is enabled for real-time revocation checking. The deployment is validated against PCI DSS 4.0 Requirement 8.6 by the QSA.

Comentário do Examinador: The PCI DSS alignment is achieved by the combination of EAP-TLS (something you have - the certificate) and the device identity bound to the Intune record (something you are - the enrolled managed device). The VLAN assignment via certificate template ensures POS devices are always on the PCI-scoped network segment, regardless of physical location across the 500-site estate. The CDN-hosted CRL endpoint is a critical reliability decision: if the CRL is unreachable, authentication fails, causing a site-wide outage. High availability for the CRL is as important as high availability for the RADIUS server itself.

Perguntas de Prática

Q1. You have deployed Trusted Root and SCEP certificate profiles to the 'All Staff' user group in Intune. You then deploy the WiFi profile to the 'Corporate Devices' device group. Devices receive the certificates but the WiFi profile shows 'Error' in the Intune console. What is the most likely cause, and how do you fix it?

Dica: Consider how Intune resolves dependencies between profiles and what happens when profiles target different group types.

Ver resposta modelo

The root cause is a group targeting mismatch. The WiFi profile depends on the SCEP profile, which depends on the Trusted Root profile. Intune cannot resolve these dependencies when the profiles target different group types (Users vs Devices). Fix: redeploy all three profiles to the same group. If the WiFi profile targets 'Corporate Devices' (a device group), the SCEP and Trusted Root profiles must also target 'Corporate Devices'. Alternatively, move all three to a user group if user-based authentication is required.

Q2. A hotel housekeeper's iPad is reported stolen. You immediately disable the housekeeper's Active Directory account. The next morning, the stolen iPad is still connecting to the hotel's WPA2-Enterprise network. Why, and what two actions do you take to prevent this?

Dica: Think about what the RADIUS server actually validates during EAP-TLS authentication, and what controls govern certificate validity.

Ver resposta modelo

Disabling the AD account does not revoke the client certificate stored on the iPad. The RADIUS server validates the certificate, not the AD account status, during EAP-TLS authentication. The two required actions are: (1) revoke the device certificate at the CA - this adds the certificate serial number to the CRL; (2) ensure the RADIUS server is configured with strict CRL checking so it fetches the updated CRL and rejects the revoked certificate on the next authentication attempt. For faster revocation, configure OCSP on the RADIUS server for real-time certificate status checks.

Q3. A retail chain is deploying 802.1X WiFi to 500 POS locations. The security architect proposes using PKCS certificate delivery instead of SCEP to avoid deploying an NDES server. The QSA reviewing the PCI DSS 4.0 assessment raises a concern. What is the concern, and what is the correct recommendation?

Dica: Consider what PCI DSS says about private key handling and what PKCS does with the private key during delivery.

Ver resposta modelo

The QSA's concern is that PKCS transmits the private key over the network from the CA to the device. PCI DSS 4.0 Requirement 3.5 requires that private keys used for authentication are protected against disclosure. Transmitting the private key over the network - even encrypted - introduces a risk that SCEP eliminates entirely. The correct recommendation is to use SCEP, where the private key is generated on the POS device and never leaves it. To avoid on-premises NDES infrastructure, the architect should evaluate a cloud SCEP gateway service that integrates directly with Intune and the CA via API.

Q4. You are designing a WiFi network for a large conference centre that hosts 50+ events per year. Staff devices need to be on a secure 802.1X network. You want to ensure that if a contractor's device is compromised, it can be isolated from the network within 15 minutes. What certificate revocation mechanism do you configure, and why?

Dica: Compare CRL and OCSP in terms of revocation latency and what determines how quickly a RADIUS server acts on a revocation.

Ver resposta modelo

Configure OCSP (Online Certificate Status Protocol) on the RADIUS server. CRL-based revocation has a latency determined by the CRL's validity period - typically one to 24 hours - meaning a revoked certificate may still authenticate until the RADIUS server fetches the next CRL. OCSP provides real-time per-certificate status responses: when a certificate is revoked at the CA, the OCSP responder immediately returns a 'revoked' status on the next query. With OCSP configured on the RADIUS server, a revoked contractor certificate is blocked on the next authentication attempt, typically within seconds. Ensure the OCSP responder is highly available - if it is unreachable and the RADIUS server is configured to fail closed, all authentications will fail.

Continue a ler esta série

O Guia Empresarial do SCEP: Implementar o Simple Certificate Enrollment Protocol para Segurança Automatizada de WiFi em Campus

Este guia de referência técnica fornece um modelo de arquitetura definitivo e uma estratégia de implementação passo a passo para a implementação de certificados de WiFi empresariais utilizando SCEP. Abrange as diferenças críticas entre SCEP e PKCS, a sequência exata de implementação necessária para o sucesso e estratégias reais de mitigação de riscos para líderes de TI.

Porque é que o meu WiFi de Convidados Não se Liga? Resolução de Problemas de Captive Portal

Este guia de referência técnica de autoridade explica o funcionamento subjacente da deteção de Captive Portal e detalha os seis principais modos de falha que impedem a ligação do WiFi de convidados. Fornece aos gestores de TI e arquitetos de rede uma estrutura prática de resolução de problemas para resolver problemas de redirecionamento HTTP, conflitos de DNS e desafios de randomização de MAC.

GDPR and Guest WiFi: Guia de Conformidade para Marketers de Espaços e TI

Este guia fornece aos gestores de TI e operadores de espaços uma estrutura prática para garantir que os serviços de Guest WiFi estão em total conformidade com o GDPR. Abrange a arquitetura técnica, mecanismos de consentimento, retenção de dados e como transformar a conformidade num ativo seguro de dados primários (first-party).