Implantação de Certificado WiFi do Microsoft Intune via SCEP e PKCS

A implantação de certificado WiFi do Intune usa três perfis: um certificado raiz de confiança, um certificado de cliente SCEP ou PKCS e um perfil de WiFi 802.1X configurado para EAP-TLS. Implante-os nessa ordem, todos atribuídos ao mesmo grupo do Microsoft Entra ID. O SCEP cria a chave privada no dispositivo, enquanto o PKCS a cria de forma centralizada. Para WiFi no Windows, iOS e Android, escolha SCEP.

O que a implantação de certificado WiFi do Intune realmente faz?

O Intune fornece a cada dispositivo gerenciado seu próprio certificado de identidade e as configurações de WiFi para apresentá-lo. O dispositivo entra na sua rede de funcionários sem que ninguém precise digitar uma senha.

O mecanismo é o IEEE 802.1X, o padrão para controle de acesso à rede baseado em porta. Sob o 802.1X, o ponto de acesso mantém o dispositivo fora da rede até que um servidor de autenticação o aprove. Esse servidor é um servidor RADIUS, o serviço que seus pontos de acesso consultam antes de permitir a entrada de um dispositivo.

O método de autenticação é o EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), definido na RFC 5216. Ambos os lados comprovam sua identidade com certificados:

• O dispositivo apresenta um certificado de cliente.
• O servidor RADIUS apresenta um certificado de servidor.
• Cada lado verifica se o certificado do outro se encadeia a uma autoridade certificadora (CA) em que ele confia.

Nenhuma senha é digitada, armazenada ou exposta ao phishing.

Isso se torna mais importante a cada ano. A Microsoft documenta que o Windows Defender Credential Guard bloqueia o logon único para métodos 802.1X baseados em senha, como o PEAP-MSCHAPv2. O PEAP (Protected EAP) envia uma senha dentro de um túnel criptografado. O Credential Guard vem ativado por padrão em compilações recentes do Windows 11 Enterprise, e a Microsoft recomenda a autenticação baseada em certificado.

O Intune oferece WiFi baseado em certificado por meio de três perfis de configuração:

• Perfil de certificado de confiança. Instala sua CA raiz e qualquer CA intermediária. O dispositivo pode, então, confiar em sua própria cadeia de certificados e em seu servidor RADIUS.
• Perfil de certificado SCEP ou PKCS. Emite para cada dispositivo um certificado de cliente exclusivo.
• Perfil de WiFi. Define o SSID (o nome da rede transmitida), o tipo de segurança e o método EAP. Ele também nomeia o certificado a ser apresentado e o servidor em que se deve confiar.

Para operadores de locais físicos, este é o lado dos funcionários na rede. Laptops, dispositivos portáteis e tablets de funcionários em Hotéis, Varejo e Saúde precisam de acesso a sistemas aos quais visitantes, compradores e pacientes jamais devem ter acesso. Seu WiFi para Convidados mantém seu Captive Portal, a página de login que os visitantes veem. Os dispositivos dos funcionários se autenticam silenciosamente em um SSID e VLAN separados, um segmento de rede logicamente isolado.

SCEP ou PKCS: qual perfil de certificado você deve usar?

Ambos os perfis deixam um certificado de cliente no dispositivo. A diferença é onde a chave privada é criada.

SCEP (Simple Certificate Enrolment Protocol, RFC 8894) faz com que o dispositivo gere seu próprio par de chaves. O dispositivo envia uma solicitação de assinatura de certificado por meio de um servidor NDES (Network Device Enrolment Service) ou através do PKI em nuvem da Microsoft. A AC assina a solicitação e retorna o certificado. A chave privada nunca sai do dispositivo. No Windows, o perfil SCEP pode colocar essa chave no TPM (Trusted Platform Module), o chip de segurança de hardware.

Os perfis PKCS usam o Certificate Connector para Microsoft Intune para solicitar o certificado da sua AC. O par de chaves é criado fora do dispositivo. O Intune então entrega o certificado e a chave privada ao dispositivo de forma criptografada. Você evita a execução do NDES, mas a chave privada existiu em outro lugar além do dispositivo.

Um terceiro tipo, certificados importados PKCS, entrega certificados que você já possui. Sua função habitual é a criptografia de e-mail S/MIME, onde as chaves ficam sob custódia. É a ferramenta errada para WiFi.

	SCEP via NDES e AD CS	SCEP via PKI em nuvem da Microsoft	PKCS via conector e AD CS
Onde a chave privada é criada	No dispositivo	No dispositivo	Fora do dispositivo, depois entregue
Autoridade certificadora	Sua AC corporativa do Active Directory Certificate Services (AD CS)	ACs hospedadas pela Microsoft ou sua própria raiz	Sua AC corporativa do AD CS
Servidores locais operados por você	AC, servidor NDES, Certificate Connector	Nenhum	AC, Certificate Connector
Componente voltado para a internet	URL do NDES, publicada por meio do proxy de aplicativo do Microsoft Entra ID	Nenhum: a Microsoft hospeda o ponto de extremidade SCEP	Nenhum: o conector faz apenas conexões de saída
Licença extra	Nenhuma além do Windows Server	Add-on do PKI em nuvem ou Microsoft Intune Suite	Nenhuma além do Windows Server
Esforço de configuração	Mais alto: AC, NDES, conector e publicação de proxy	Mais baixo: ACs criadas no centro de administração do Intune	Médio: AC e conector, sem NDES
A quem se destina	Ambientes com AD CS que desejam chaves mantidas no dispositivo	Ambientes focados em nuvem sem PKI local	Ambientes com AD CS que não podem publicar o ponto de extremidade NDES

Para WiFi, escolha SCEP, a menos que não possa atender às suas necessidades de infraestrutura. Uma chave que nunca sai do dispositivo não pode ser copiada de um servidor ou interceptada em trânsito. Escolha o PKI em nuvem da Microsoft se você não tiver uma PKI local e não quiser construir uma. Escolha PKCS se você executa o AD CS, mas não pode publicar um ponto de extremidade NDES para a internet.

O que você precisa antes de implantar certificados WiFi com o Intune?

Confirme cada item antes de criar um único perfil. A maioria das implantações malsucedidas se deve a uma lacuna nesta lista.

• Licenciamento. Cada pessoa precisa de uma licença do Intune. O Intune está incluído no Microsoft 365 E3, E5 e Business Premium, e no Enterprise Mobility + Security E3 e E5.
• Dispositivos inscritos. Dispositivos Windows são ingressados no Microsoft Entra ID, frequentemente por meio do Windows Autopilot. Dispositivos iOS e iPadOS são inscritos por meio da inscrição automatizada de dispositivos do Apple Business Manager. Dispositivos Android usam o Android Enterprise. A Microsoft encerrou o gerenciamento de administrador de dispositivos para aparelhos com Google Mobile Services, portanto, planeje o uso do Android Enterprise.
• Uma autoridade certificadora. Isso significa uma CA empresarial do AD CS, Microsoft Cloud PKI ou uma CA de terceiros compatível com o Intune.
• Um modelo de certificado. No AD CS, publique um modelo com o uso estendido de chave Client Authentication.
• Infraestrutura de conectores. O SCEP no AD CS precisa de um servidor NDES e do Certificate Connector for Microsoft Intune. O PKCS precisa apenas do conector.
• Um servidor RADIUS compatível com EAP-TLS. Seu certificado de servidor deve se encadear a uma raiz que você implantará. Registre o nome exato contido nesse certificado, pois o perfil de WiFi precisará dele.
• Revogação acessível. Seu servidor RADIUS deve alcançar a lista de revogação de certificados (CRL) ou um respondedor OCSP (Online Certificate Status Protocol). Se não conseguir, a autenticação falhará.
• SSIDs empresariais. Seus pontos de acesso devem transmitir um SSID WPA2-Enterprise ou WPA3-Enterprise apontado para o seu servidor RADIUS. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet oferecem suporte a 802.1X.
• Grupos do Entra ID. Crie um grupo piloto e um grupo de produção. Decida agora se eles conterão pessoas ou dispositivos.
• Uma rede de bootstrap. Um dispositivo precisa de acesso à internet para coletar seu certificado antes de poder se conectar ao SSID 802.1X. Forneça acesso cabeado, dados móveis ou um SSID de integração isolado. Operadores de trens que fornecem tablets para a tripulação de bordo devem configurá-los no depósito, antes que os tablets entrem em trânsito.

Como configurar certificados de WiFi SCEP ou PKCS no Intune?

A documentação do Intune da Microsoft contém as etapas detalhadas campo a campo para cada plataforma. A sequência e as decisões abaixo são o que determinam o sucesso. Crie um conjunto de perfis por plataforma: Windows, iOS/iPadOS e Android Enterprise.

Etapa 1: implantar o perfil de certificado raiz confiável

Exporte seu certificado de CA raiz como um arquivo .cer. Crie um perfil de certificado confiável que o contenha. Cada perfil de certificado confiável contém um certificado, portanto, crie perfis separados para a raiz e para cada CA intermediária.

No Windows, envie a raiz para o repositório de raiz do computador e as intermediárias para o repositório intermediário. Se uma CA diferente assinou o certificado do seu servidor RADIUS, implante essa raiz também. Sem ela, os dispositivos não poderão validar o servidor.

Etapa 2: implantar o perfil de certificado SCEP ou PKCS

Comece pelo tipo de certificado, pois ele direciona todo o restante.

• Certificados de dispositivo são adequados para dispositivos portáteis compartilhados, quiosques e notebooks que precisam se conectar na tela de login do Windows. Use um nome de assunto construído a partir do identificador do dispositivo, como CN={{AAD_Device_ID}}.
• Certificados baseados em pessoas são adequados para telefones e notebooks atribuídos a um membro da equipe. Use CN={{UserPrincipalName}} no assunto. Adicione o mesmo valor como um nome alternativo do assunto (SAN), pois muitos servidores RADIUS leem a identidade a partir dali.

Em seguida, defina os campos restantes:

• Uso da chave: assinatura digital e criptografia de chave.
• Uso estendido da chave: Autenticação do Cliente, OID 1.3.6.1.5.5.7.3.2.
• Tamanho da chave: mínimo de 2048 bits.
• Validade: não superior ao permitido pelo modelo da sua CA.
• Limite de renovação: o padrão da Microsoft é 20% do tempo de vida restante do certificado.
• Certificado raiz: selecione o perfil de certificado de confiança da etapa 1.
• Armazenamento de chaves no Windows: escolha a opção TPM para chaves com suporte de hardware.

Para SCEP, insira a URL NDES externa ou a URI SCEP da sua Cloud PKI. Para PKCS, insira o nome da CA e o nome do modelo.

Se você usa o Microsoft NPS (Network Policy Server) com identidades híbridas, leia o KB5014754 da Microsoft sobre mapeamento forte de certificados. A Microsoft documenta uma URI de nome alternativo do assunto que carrega o identificador de segurança local exatamente para este caso.

Etapa 3: implantar o perfil de WiFi 802.1X

Crie um perfil de WiFi corporativo com estas configurações:

• Insira o SSID exatamente como seus pontos de acesso o transmitem.
• Defina o tipo de segurança como WPA2-Enterprise ou WPA3-Enterprise, onde seus pontos de acesso e a plataforma suportem.
• Defina o tipo de EAP como EAP-TLS.
• Insira os nomes dos servidores de certificados que correspondam ao nome no certificado do seu servidor RADIUS. Isso impede que os dispositivos forneçam sua identidade a um ponto de acesso não autorizado.
• Selecione o perfil da etapa 1 como o certificado raiz para validação do servidor.
• Selecione o perfil da etapa 2 como o certificado de autenticação do cliente.

O que muda no Windows, iOS e Android?

• O Windows conecta com um certificado de dispositivo antes que qualquer pessoa faça login. Um certificado baseado em pessoa conecta apenas após o login, o que interrompe o primeiro login em notebooks compartilhados.
• O iOS e iPadOS confiam no servidor RADIUS correspondendo aos nomes dos servidores de certificados que você insere. Uma divergência gera uma falha de confiança, não um fallback silencioso.
• O Android Enterprise exige um nome de domínio de servidor RADIUS e um certificado raiz para validação. As versões recentes do Android removeram a opção de ignorar a validação do servidor.

O que acontece quando um novo dispositivo é registrado?

Esta é a sequência de implantação de certificados em um dispositivo recém-registrado:

1. O dispositivo se registra e entra no seu grupo do Microsoft Entra ID atribuído.
2. O Intune entrega os perfis raiz e intermediários de confiança.
3. O dispositivo solicita seu certificado de cliente. No SCEP, ele gera um par de chaves e envia uma solicitação de assinatura com um desafio único. O conector valida esse desafio com o Intune antes que a CA emita qualquer coisa. No PKCS, o conector solicita o certificado e o Intune o entrega.
4. O dispositivo relata o certificado instalado ao Intune.
5. O perfil de WiFi, que depende de ambos os perfis de certificado, é aplicado.
6. O dispositivo apresenta seu certificado ao SSID. O RADIUS valida a cadeia, verifica a revogação e aceita o dispositivo. Ele pode então atribuir uma VLAN por meio de atributos RADIUS.
7. O Intune renova o certificado quando ele atinge o limite de renovação. O Intune o revoga quando você aposenta ou limpa o dispositivo, desde que o conector tenha direitos de revogação na CA.

Como verificar se os certificados WiFi do Intune estão funcionando?

Teste com um piloto de 10 a 20 dispositivos por plataforma antes de expandir as atribuições. Verifique quatro locais.

1. Status do perfil do Intune. Cada um dos três perfis deve relatar Sucesso para cada dispositivo piloto. Um status de Pendente, Erro ou Não aplicável em qualquer um deles bloqueia o perfil WiFi.
2. O próprio dispositivo. No Windows, abra o repositório de certificados pessoais e confirme a finalidade de Autenticação do Cliente e a sua CA emissora. No iOS e Android, confirme se o certificado e o perfil WiFi aparecem no perfil de gerenciamento e nas credenciais do perfil de trabalho.
3. Logs do RADIUS. Procure por autenticações EAP-TLS bem-sucedidas com o nome de assunto esperado. No NPS, a ID de evento 6272 registra o acesso concedido e a 6273 registra o acesso negado, com um código de motivo.
4. Logs do conector e NDES. O Certificate Connector grava no log de eventos do Windows. As solicitações do NDES aparecem nos logs do IIS.

Em seguida, teste a revogação intencionalmente. Aposente um dispositivo piloto no Intune e confirme se o certificado é exibido como revogado na CA. Publique a CRL e confirme se o RADIUS nega a próxima autenticação.

O que dá errado com os perfis WiFi do Intune e como corrigir?

O perfil WiFi mostra Erro ou Não aplicável

Os certificados chegaram, mas o perfil WiFi falhou. A causa comum é o direcionamento de grupos mistos. Por exemplo, o perfil SCEP é atribuído a um grupo de pessoas, enquanto o perfil WiFi é direcionado a um grupo de dispositivos. O Intune não consegue resolver a dependência. A solução é atribuir todos os três perfis ao mesmo grupo, ou pelo menos ao mesmo tipo de grupo.

O certificado SCEP nunca chega

Os logs do NDES IIS mostram respostas HTTP 403 ou 500. Verifique se a conta de serviço do conector possui permissões de Leitura e Inscrição no modelo de certificado. Verifique se o seu firewall, proxy reverso ou proxy de aplicativo não está removendo strings de consulta SCEP, como operation=GetCACaps. Em seguida, confirme se o URL externo do NDES é resolvido de fora da sua rede.

O dispositivo possui um certificado, mas o RADIUS o rejeita

Trabalhe em quatro causas na ordem:

1. Os nomes dos servidores de certificado no perfil WiFi não correspondem ao certificado do servidor RADIUS.
2. O servidor RADIUS não confia na CA que emitiu o certificado do cliente.
3. O servidor RADIUS não consegue baixar uma CRL atual.
4. A aplicação do mapeamento forte do NPS sob a KB5014754 rejeita certificados sem um mapeamento forte.

O código de motivo do NPS indica a causa correta.

As verificações de revogação causam uma interrupção

Se o ponto de distribuição CRL ficar offline ou a CRL expirar, servidores RADIUS estritos rejeitam todos os certificados. Publique CRLs em um local HTTP de alta disponibilidade que seu servidor RADIUS possa alcançar. Monitore o horário da próxima atualização da CRL.

Dispositivos continuam se conectando à rede antiga

Um perfil PEAP ou chave pré-compartilhada legado ainda no dispositivo tem prioridade. Remova o perfil antigo pelo Intune assim que o novo relatar sucesso e, em seguida, desative o SSID antigo.

Como funciona o WiFi baseado em certificado do Intune em um local real?

Os dois cenários abaixo são exemplos práticos construídos com base no comportamento documentado da Microsoft. Eles descrevem tipos de locais, não implantações específicas.

Um grupo de 12 hotéis aposentando uma senha de equipe compartilhada

Situação. Um grupo de 12 hotéis, cada um com cerca de 200 quartos, executa um SSID de equipe em uma chave pré-compartilhada. A chave é compartilhada por 840 dispositivos: PCs da recepção, iPhones da governança e coletores Android em alimentos e bebidas. A rede está conectada ao ambiente de dados de portadores de cartão. O requisito 2.3.2 do PCI-DSS v4.0 exige, portanto, que a chave mude sempre que alguém que a conhece saia da empresa. Com a rotatividade da equipe de atendimento, cada rotação deixa dispositivos isolados até que alguém insira a chave novamente.

O que foi feito. A equipe implanta o SCEP por meio do NDES, publicado com o proxy de aplicativo do Microsoft Entra ID. Os PCs da recepção recebem certificados de dispositivo para que se conectem na tela de login. Os telefones recebem certificados baseados na pessoa. Um piloto de 20 dispositivos é executado em um hotel por duas semanas. Depois disso, um hotel faz a migração a cada semana, com o SSID antigo funcionando em paralelo.

Resultado mensurável. Após 12 semanas, todos os 840 dispositivos se autenticam com EAP-TLS e o SSID com chave pré-compartilhada é desligado. O número de chaves compartilhadas para rotação cai de uma em 12 locais para zero. O acesso de um ex-colaborador agora termina quando seu dispositivo é desativado e a CRL é republicada, e não na próxima rotação de chave.

Uma rede de varejo de 150 lojas com coletores compartilhados

Situação. Cada loja opera quatro coletores Android compartilhados e dois notebooks Windows de retaguarda, totalizando 900 dispositivos. Os coletores passam de funcionário para funcionário a cada turno, portanto, certificados baseados na pessoa não fazem sentido. O serviço RADIUS em nuvem da rede não consegue alcançar uma CRL publicada apenas na rede interna.

O que foi feito. A rede inscreve os coletores como dispositivos dedicados Android Enterprise e emite certificados de dispositivo por meio do SCEP. Um perfil de WiFi por plataforma atende a todas as lojas, pois o SSID é idêntico em todos os lugares. A CRL passa para um ponto de distribuição HTTP acessível pela internet.

Resultado mensurável. Nenhum coletor compartilhado carrega uma senha de WiFi. A equipe da loja para de pedir a chave após cada alteração. Um coletor perdido é bloqueado ao ser desativado no Intune, e seu certificado falha na próxima autenticação assim que a CRL for atualizada.

Quanto custa a implantação de certificado WiFi do Intune e qual é o retorno?

Quanto custa

• Licenças. A maioria das empresas já possui o Intune por meio do Microsoft 365 ou Enterprise Mobility + Security, portanto, não há novo custo por usuário.
• Servidores. AD CS, NDES e NPS são funções do Windows Server que não exigem licença separada além do próprio Windows Server.
• PKI na nuvem. A Microsoft Cloud PKI é um add-on pago, também incluído no Microsoft Intune Suite. Pondere seu custo em relação à construção e manutenção de uma CA e NDES locais.
• Esforço. O trabalho está concentrado no design da PKI, na publicação do NDES e no piloto. Os três perfis levam horas, não semanas.

O que você ganha com isso

• Sem chaves de WiFi compartilhadas. Isso elimina a rotação de chaves que o requisito 2.3.2 do PCI-DSS impõe às redes sem fio conectadas ao ambiente de dados do portador do cartão.
• Acesso de desligados que você pode revogar. Desativar um dispositivo no Intune pode revogar seu certificado, para que o acesso ao WiFi acompanhe seu processo de admissão, movimentação e desligamento de funcionários (JML).
• Compatibilidade com o Credential Guard. O EAP-TLS continua funcionando nos casos em que o Windows bloqueia o single sign-on 802.1X baseado em senha.
• Nenhuma credencial para sofrer phishing. Um certificado vinculado a um TPM não pode ser digitado em uma página de login falsa.
• Sem expiração de senha. Os certificados são renovados automaticamente antes de expirarem, eliminando as redefinições de senha como causa de chamados de suporte do WiFi.

Planeje o tratamento do GDPR desde o início. Os titulares de certificados que contêm o nome de login de um funcionário são dados pessoais em seus logs do RADIUS. Defina um período de retenção e restrinja o acesso a esses logs.

A Purple executa WiFi para funcionários e WiFi para visitantes lado a lado em mais de 80.000 locais ativos (dados da Purple). A plataforma é agnóstica em relação ao hardware em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. A Purple possui certificação ISO 27001. Nossas Identity-Based Networks funcionam com Microsoft Entra ID, Okta e Google Workspace, para que o acesso dos funcionários siga a mesma fonte de identidade do seu ambiente Intune. Do lado do visitante, o WiFi Analytics relata as conexões de visitantes separadamente do tráfego dos funcionários.

Perguntas frequentes

Você precisa de licenças extras para implantar certificados de WiFi pelo Intune?

Não, não para SCEP via NDES ou para PKCS. O Intune está incluído no Microsoft 365 E3, E5 e Business Premium, e no Enterprise Mobility + Security E3 e E5. O Active Directory Certificate Services e o NDES são funções do Windows Server, portanto exigem apenas seu licenciamento do Windows Server existente. A exceção é a Microsoft Cloud PKI, um add-on pago também incluído no Microsoft Intune Suite. Inclua-a no orçamento apenas se desejar evitar a execução de uma CA local.

O WiFi baseado em certificado do Intune funcionará com seus pontos de acesso existentes?

Sim, desde que seus pontos de acesso possam transmitir um SSID WPA2-Enterprise ou WPA3-Enterprise. O EAP-TLS é executado entre o dispositivo e o servidor RADIUS, e o ponto de acesso apenas o retransmite sob o IEEE 802.1X. A Purple é agnóstica em relação ao hardware e roda em Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme Networks e Fortinet. Você mantém o hardware que já possui e altera apenas as configurações de segurança do SSID.

É possível migrar do PEAP ou de uma senha compartilhada para o EAP-TLS sem tempo de inatividade?

Sim. Execute o novo SSID 802.1X ao lado do antigo ou configure seu servidor RADIUS para aceitar PEAP e EAP-TLS durante a transição. Implante os três perfis do Intune para um grupo piloto primeiro. Confirme as autenticações EAP-TLS bem-sucedidas nos seus logs do RADIUS e, em seguida, amplie a atribuição em ondas. Remova o perfil de WiFi antigo somente após o novo relatar sucesso e, então, desative o SSID antigo.

Você deve escolher SCEP ou PKCS para o WiFi da equipe?

Escolha SCEP. Com o SCEP, o dispositivo gera sua própria chave privada, que nunca o deixa, e o Windows pode armazenar essa chave no TPM. O PKCS cria a chave fora do dispositivo e a entrega. Isso remove o servidor NDES, mas amplia os locais onde a chave esteve presente. Escolha PKCS apenas quando você executa o Active Directory Certificate Services e não pode publicar o NDES, ou use o Microsoft Cloud PKI para SCEP sem o NDES.

Você ainda precisa de um servidor NDES?

Apenas para SCEP com uma CA do Active Directory Certificate Services local. O Microsoft Cloud PKI fornece um endpoint SCEP hospedado, portanto você não executa nenhum servidor NDES, conector ou CA local. Os perfis PKCS também evitam o NDES, porque o Certificate Connector for Microsoft Intune solicita certificados da sua CA por meio de conexões de saída. Autoridades certificadoras de terceiros suportadas pelo Intune também podem emitir certificados SCEP sem o NDES.

Quão rápido o acesso ao WiFi termina quando alguém sai?

Tão rápido quanto seu pipeline de revogação permitir. Quando você aposenta ou limpa um dispositivo no Intune, o Certificate Connector pode revogar seu certificado em sua CA. O acesso termina quando seu servidor RADIUS identifica essa revogação, por meio de uma CRL atualizada ou de uma verificação OCSP. Encurte o intervalo de publicação da CRL ou use OCSP se a remoção na mesma hora for importante. Desativar a conta isoladamente pode não interromper um certificado válido, a menos que o RADIUS também verifique o diretório.

O WiFi baseado em certificado ajuda com PCI-DSS e GDPR?

Sim. O requisito 2.3.2 do PCI-DSS v4.0 exige que as chaves sem fio em redes conectadas ao ambiente de dados de titulares de cartões sejam alteradas sempre que alguém que as conheça saia. Certificados por dispositivo significam que nenhuma chave compartilhada existe para ser rotacionada. Para o GDPR, trate os assuntos do certificado que contêm o nome de login de um funcionário como dados pessoais. Defina um período de retenção para os logs do RADIUS, restrinja o acesso a eles e registre o processamento.