How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Esta guía explica cómo configurar SCEP (Simple Certificate Enrollment Protocol) para el registro automatizado de certificados WiFi empresariales, abarcando toda la arquitectura desde PKI y NDES hasta el despliegue de perfiles MDM y la validación RADIUS. Está dirigida a responsables de TI, arquitectos de red y directores de tecnología (CTO) de hoteles, cadenas de retail, estadios, centros de conferencias y organizaciones del sector público que necesitan dejar atrás las claves precompartidas e implementar una autenticación 802.1X EAP-TLS escalable y basada en la identidad. La plataforma de superposición en la nube e independiente del hardware de Purple se integra directamente con esta arquitectura, proporcionando la capa de WiFi para invitados y BYOD que funciona en paralelo con la red de personal autenticada mediante certificados.

📖 10 min de lectura📝 2,282 palabras🔧 2 ejemplos prácticos❓ 3 preguntas de práctica📚 9 definiciones clave

Escuchar esta guía

Ver transcripción del 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.

Conclusiones clave

✓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.

Resumen ejecutivo

Para los establecimientos empresariales —ya sea un hotel de 200 habitaciones, una cadena de retail con 50 centros o un gran centro de conferencias—, depender de claves precompartidas para el WiFi del personal es un riesgo de seguridad y un cuello de botella operativo. Una sola contraseña filtrada expone a toda la red. La autenticación basada en certificados a través de IEEE 802.1X y EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) elimina por completo ese riesgo. Cada dispositivo demuestra su identidad criptográficamente antes de que el punto de acceso le conceda acceso a la red.

El desafío es la distribución. Desplegar manualmente certificados de cliente únicos en miles de dispositivos Windows, iOS y Android no es viable. SCEP (Simple Certificate Enrollment Protocol), formalizado como RFC 8894 por el IETF en 2020, resuelve este problema. Automatiza el proceso de solicitud, emisión e instalación de certificados digitales en dispositivos gestionados a través de su plataforma MDM, sin necesidad de interacción por parte del usuario.

Esta guía abarca toda la arquitectura: qué hace SCEP, cómo se integra con Microsoft Intune, Jamf y otras plataformas MDM, la secuencia exacta de despliegue en la que la mayoría de los equipos se equivocan y los fallos operativos que causan interrupciones del servicio. También analizamos dos escenarios de implementación reales en los sectores de hostelería y retail, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto a su red de personal autenticada mediante certificados.

Escuche el podcast informativo complementario:

Análisis técnico detallado: SCEP, PKI y 802.1X

Qué hace realmente SCEP

SCEP no sustituye a su infraestructura de clave pública (PKI). Es la capa de registro automatizada que se superpone a ella. Su PKI —normalmente una jerarquía de dos niveles con una CA raíz fuera de línea y una CA emisora en línea— sigue siendo el ancla de confianza. SCEP automatiza el paso en el que un dispositivo solicita un certificado a esa CA, eliminando la necesidad de generar CSR e instalar certificados de forma manual.

En el contexto de la autenticación WiFi, el protocolo de destino es EAP-TLS. Este es el método de autenticación 802.1X que requiere que tanto el dispositivo cliente como el servidor RADIUS presenten certificados X.509 válidos. Ninguna de las partes confía en la otra sin una prueba criptográfica. Este modelo de autenticación mutua elimina el robo de credenciales y protege contra los ataques de tipo "evil twin" (gemelo malvado), en los que un atacante levanta un punto de acceso falso para recopilar nombres de usuario y contraseñas.

Para obtener un desglose detallado del handshake EAP-TLS, consulte nuestra guía sobre Autenticación de certificados WiFi: acceso seguro a la red .

El flujo de registro SCEP, paso a paso

La cadena de registro completa funciona de la siguiente manera. Su plataforma MDM (Microsoft Intune, Jamf u otro MDM) envía un payload SCEP a un dispositivo gestionado. Ese payload contiene dos elementos: la URL de SCEP que apunta a su servidor NDES (Network Device Enrollment Service) o pasarela SCEP en la nube, y una contraseña de desafío o secreto compartido.

El dispositivo genera localmente su propio par de claves pública y privada. Esta es la propiedad de seguridad crítica de SCEP: la clave privada se genera en el dispositivo, se almacena en el enclave seguro o chip TPM y nunca se transmite a través de la red. A continuación, el dispositivo crea una solicitud de firma de certificado (CSR) y la envía a la pasarela SCEP. La pasarela valida la contraseña de desafío, reenvía la CSR a su entidad de certificación (CA), y la CA la firma y devuelve el certificado público al dispositivo.

A partir de ese momento, cuando el dispositivo se conecta a su SSID de WiFi, presenta ese certificado al servidor RADIUS. El servidor RADIUS valida el certificado frente a su cadena de confianza de la CA, comprueba la lista de revocación de certificados (CRL) para confirmar que el certificado no ha sido revocado y, si todo es correcto, envía un mensaje de Access-Accept al punto de acceso. El dispositivo ya está en la red. Todo el proceso es invisible para el usuario.

SCEP frente a PKCS: cuál utilizar para WiFi

Las plataformas MDM como Intune admiten dos mecanismos de entrega de certificados: SCEP y PKCS (Public Key Cryptography Standards). La diferencia arquitectónica es significativa.

Con SCEP, la clave privada se genera en el dispositivo y nunca sale de él. Con PKCS, la entidad de certificación genera tanto la clave pública como la privada de forma centralizada, y el conector de certificados envía el par de claves al dispositivo a través de la red. Esto significa que la clave privada se transmite, lo que introduce una superficie de ataque teórica.

PKCS es adecuado para casos de uso en los que se requiere el depósito de claves (key escrow), como el cifrado de correo electrónico S/MIME. Para la autenticación WiFi, SCEP es la opción correcta. La clave privada permanece en el dispositivo.

Propiedad	SCEP	PKCS
Generación de clave privada	En el dispositivo (TPM/Secure Enclave)	Centralizada (CA)
Transmisión de clave privada	Nunca	A través de la red
Servidor NDES requerido	Sí (o pasarela en la nube)	No
Recomendado para WiFi	Sí	No
Recomendado para S/MIME	No	Sí

Compatibilidad de hardware

SCEP y EAP-TLS son estándares independientes del proveedor. Funcionan en puntos de acceso de Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet. Su configuración de RADIUS —ya sea Windows NPS, FreeRADIUS o un servicio RADIUS en la nube— es donde define la política de validación de certificados y la asignación dinámica de VLAN.

La asignación dinámica de VLAN es cómo ssegmenta la red por identidad de dispositivo. Un dispositivo del personal obtiene la VLAN 10 con acceso a los sistemas internos. Un dispositivo de contratista obtiene la VLAN 20 solo con acceso a internet. Un terminal de punto de venta obtiene la VLAN 30 solo con acceso a los sistemas de procesamiento de pagos. Todo esto se gestiona mediante atributos de certificado y políticas RADIUS, sin intervención manual por dispositivo.

Para obtener más información sobre cómo WiFi Analytics se integra con la segmentación de red basada en la identidad, consulte la descripción general de nuestra plataforma de análisis.

Guía de implementación: la secuencia de despliegue

Configurar correctamente SCEP para WiFi empresarial requiere el cumplimiento estricto de una secuencia de despliegue específica. Las plataformas MDM imponen dependencias de perfil: un perfil de WiFi que hace referencia a un certificado SCEP no se puede aplicar hasta que dicho certificado exista en el dispositivo. No respetar esta secuencia es la causa más común de fallos en el despliegue.

La secuencia es: primero la raíz de confianza (Trusted Root), segundo el perfil SCEP y tercero el perfil WiFi. Este orden no es negociable.

Paso 1: desplegar el perfil de certificado de raíz de confianza (Trusted Root)

Antes de que cualquier dispositivo pueda solicitar un certificado de cliente o confiar en su servidor RADIUS, debe confiar en la autoridad de certificación (CA) emisora. Exporte su certificado de CA raíz (Root CA) y cualquier certificado de CA intermedia como archivos .cer. En su centro de administración de MDM, cree un perfil de certificado de confianza (Trusted Certificate), cargue el archivo .cer y despliéguelo en su grupo de dispositivos de destino.

Si dispone de una jerarquía PKI de dos niveles (recomendado), deberá desplegar tanto el certificado de la CA raíz como el de la CA emisora como perfiles de certificado de confianza independientes, o como una cadena en un único perfil, según su plataforma MDM.

Paso 2: configurar el perfil de certificado SCEP

Una vez establecida la confianza, configure el perfil SCEP para indicar a los dispositivos cómo obtener su certificado de cliente.

Cree un nuevo perfil de configuración y seleccione el tipo de perfil de certificado SCEP. Configure el formato del nombre del sujeto (Subject name). Para la autenticación basada en el usuario, lo estándar es CN={{UserPrincipalName}}. Para la autenticación de dispositivos (dispositivos compartidos, IoT, terminales POS), utilice CN={{AAD_Device_ID}}. Establezca el uso de clave (Key usage) en Firma digital (Digital signature) y Cifrado de clave (Key encipherment). Establezca el uso de clave extendido (Extended Key Usage) en Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2). Vincule este perfil al perfil de certificado de raíz de confianza creado en el Paso 1. Proporcione la URL externa de su servidor NDES.

Específicamente para Microsoft Intune, el servidor NDES debe publicarse a través de Azure AD Application Proxy para permitir que los dispositivos remotos se registren antes de llegar a las instalaciones. No exponga NDES directamente a internet.

Paso 3: desplegar el perfil WiFi 802.1X

El último paso consiste en enviar la configuración WiFi que vincula los certificados al SSID de la red. Cree un perfil de configuración Wi-Fi. Introduzca el nombre de la red (SSID) exactamente como lo transmiten sus puntos de acceso. Seleccione WPA2-Enterprise o WPA3-Enterprise como tipo de seguridad. Establezca el tipo de EAP en EAP-TLS. En los ajustes de autenticación, seleccione el perfil de certificado SCEP creado en el Paso 2 como certificado de autenticación de cliente. Especifique el certificado de raíz de confianza (Trusted Root) para la validación del servidor; esto garantiza que el dispositivo solo se conecte a su servidor RADIUS legítimo y no a un punto de acceso no autorizado.

Integración con proveedores de identidad

Los atributos del certificado SCEP, específicamente el nombre alternativo del sujeto (SAN), pueden contener el nombre principal del usuario de Microsoft Entra ID, Okta o Google Workspace. Esto vincula el certificado a una identidad específica. Cuando se deshabilita una cuenta en Entra ID y el MDM anula el registro del dispositivo, el certificado se revoca y el acceso WiFi se corta automáticamente. Esa revocación automatizada es la ventaja de seguridad que las claves precompartidas no pueden igualar.

Para obtener más información sobre EAP Method WiFi: A Guide to Secure Network Access , incluidas las rutas de migración de PEAP-MSCHAPv2, consulte nuestra guía dedicada.

Buenas prácticas y estándares del sector

Ubicación del servidor NDES

El servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar a las instalaciones. Publique la URL de NDES a través de Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de entrada en el cortafuegos y le permite aplicar políticas de acceso condicional al flujo de registro. Nunca exponga NDES directamente a internet.

Para redes con más de 500 dispositivos gestionados, considere una pasarela SCEP en la nube en lugar de un NDES local. Las pasarelas en la nube eliminan el punto único de fallo de NDES, se escalan horizontalmente y suelen integrarse directamente con los servicios RADIUS en la nube.

Disponibilidad de la CRL

Su servidor RADIUS comprueba la lista de revocación de certificados (CRL) cada vez que un dispositivo se autentica. Si su punto de distribución de CRL (CDP) no está disponible (ya sea porque un servidor está caído o porque la URL ha cambiado), la autenticación fallará para todos los dispositivos de la red simultáneamente. Configure su servidor NPS o RADIUS para exigir una comprobación estricta de la CRL y asegúrese de que sus puntos de conexión de CRL tengan una alta disponibilidad. Pruebe la revocación antes de la puesta en marcha.

El requisito 8.6 de PCI DSS 4.0 exige la autenticación multifactor en la capa de red para entornos de datos de titulares de tarjetas. EAP-TLS con certificados provistos por SCEP cumple este requisito para redes inalámbricas en entornos de comercio minorista y hostelería .

Compatibilidad con WPA3

EAP-TLS es totalmente compatible con WPA3-Enterprise. WPA3-Enterprise con la suite de seguridad de 192 bits (Suite B) exige EAP-TLS y es la combinación recomendada por la Wi-Fi Alliance para redes gubernamentales, financieras y sanitarias. Si está realizando un despliegue en entornos de salud o transporte con requisitos de cumplimiento estrictos, WPA3-Enterprise con EAP-TLS es la arquitectura de destino correcta.

BYOD y W de invitadosiFi

SCEP requiere el registro en el MDM para enviar la carga útil del certificado. No cubre los dispositivos BYOD no gestionados ni los invitados. Para esos casos de uso, necesita un SSID independiente con un Captive Portal y verificación de identidad. La plataforma de Purple gestiona esa capa de forma limpia, coexistiendo con su red de empleados autenticada mediante certificados. Nuestra plataforma de Guest WiFi admite opciones de consentimiento consciente, captura de datos de origen e integración con Microsoft Entra ID, Okta y Google Workspace para la verificación de identidad.

Resolución de problemas y mitigación de riesgos

Error al aplicar el perfil de WiFi

Síntoma: El dispositivo recibe los certificados Trusted Root y SCEP, pero el perfil de WiFi se muestra como Error o No aplicable en el MDM.

Causa raíz: Incompatibilidad en la asignación de grupos. Si el perfil SCEP se dirige a un grupo de usuarios y el perfil de WiFi se dirige a un grupo de dispositivos, el MDM no puede resolver la dependencia.

Solución: Audite sus asignaciones. Asegúrese de que los perfiles Trusted Root, SCEP y WiFi se dirijan exactamente al mismo grupo de directorio.

Errores NDES 403 Forbidden

Síntoma: Los dispositivos no pueden recuperar el certificado SCEP. Los registros de IIS de NDES muestran errores HTTP 403.

Causa raíz: La cuenta de servicio del conector de certificados de MDM carece de permisos de lectura e inscripción (Read and Enroll) en la plantilla de certificado, o el filtrado de URL del cortafuegos está bloqueando los parámetros de la cadena de consulta de SCEP.

Solución: Verifique que la cuenta del conector tenga permisos de lectura e inscripción (Read and Enroll) en la plantilla de la CA. Revise los registros del cortafuegos para asegurarse de que no se estén bloqueando las URL que contienen ?operation=GetCACaps.

Fallo de autenticación masiva tras la expiración de la CRL

Síntoma: Todos los dispositivos de la red fallan al autenticarse simultáneamente.

Causa raíz: La CRL ha expirado o la URL de CDP no está accesible. El servidor RADIUS no puede confirmar que los certificados sean válidos y se bloquea por seguridad (fails closed).

Solución: Configure la monitorización y las alertas de la CRL. Publique las CRL con un periodo de validez significativamente superior al intervalo de publicación. Pruebe la accesibilidad de CDP desde el servidor RADIUS antes de la puesta en marcha.

La expiración de certificados causa fallos silenciosos

Síntoma: Dispositivos individuales fallan al conectarse de forma intermitente, sin un patrón claro.

Causa raíz: Los certificados de cliente han expirado y el MDM no los ha renovado correctamente.

Solución: Configure la renovación de certificados para que se active al 80 % de la vida útil del certificado. Supervise los informes de estado de registro de MDM para detectar dispositivos con errores de certificado. Establezca periodos de validez de los certificados adecuados para el ciclo de renovación de sus dispositivos (normalmente, de uno a dos años para los terminales gestionados).

ROI e impacto empresarial

La transición a la autenticación mediante certificados 802.1X basada en SCEP ofrece un retorno de la inversión medible en términos de seguridad, operaciones y cumplimiento.

Reducción de incidencias en el servicio de soporte (helpdesk): El acceso a WiFi basado en contraseñas genera un volumen significativo de incidencias de soporte: expiración de contraseñas, bloqueos de cuentas y errores de escritura. La autenticación basada en certificados es invisible para el usuario. Las organizaciones suelen experimentar una reducción del 70-80 % en el volumen de incidencias de soporte relacionadas con el WiFi tras la migración.

Postura de seguridad: EAP-TLS elimina el robo de credenciales y los ataques de intermediario (Man-in-the-Middle). Esto respalda directamente el cumplimiento de PCI DSS 4.0 para redes de comercio minorista y hostelería, así como los requisitos del Artículo 32 del GDPR relativos a las medidas de seguridad técnica adecuadas.

Revocación automatizada: Cuando un empleado se marcha, la desactivación de su cuenta en Microsoft Entra ID activa la revocación automática del certificado y la baja en el MDM. El acceso a la WiFi se corta sin necesidad de intervención manual por parte del equipo de redes.

Segmentación de red: La asignación dinámica de VLAN a través de los atributos de certificado RADIUS le proporciona una segmentación de red aplicada criptográficamente. Los dispositivos se ubican en el segmento de red correcto en función de las propiedades del certificado, no de la selección del SSID o del filtrado de direcciones MAC, métodos que se pueden eludir fácilmente.

Purple opera en más de 80 000 establecimientos activos con un tiempo de actividad del 99,999 %, y nuestra plataforma cuenta con las certificaciones ISO 27001, GDPR, CCPA y Cyber Essentials. Nuestra capa superpuesta en la nube, independiente del hardware, se integra con Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme y Fortinet, de modo que su red de empleados autenticada mediante certificados y nuestra capa de WiFi para invitados funcionan desde la misma infraestructura.

Para obtener más información sobre cómo el Análisis de comportamiento: información para redes WiFi puede complementar su despliegue de red segura, consulte nuestra guía de análisis.

Referencias

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configuración de la infraestructura para admitir SCEP con Intune - Microsoft Learn [3] Directrices para redes inalámbricas de PCI DSS - PCI Security Standards Council

Definiciones clave

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.

Ejemplos prácticos

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.

Comentario del 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.

Comentario del 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.

Preguntas de práctica

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.

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

Ver respuesta 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.

Sugerencia: 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 respuesta 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?

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

Ver respuesta 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.

Continúe leyendo esta serie

Cómo configurar un Captive Portal en Starlink: guía para establecimientos remotos y marítimos

Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal gestionado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá a superar la limitación de CGNAT, aplicar la segmentación de VLAN, gestionar las limitaciones de ancho de banda satelital y garantizar el cumplimiento normativo.

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

Esta guía técnica detalla cómo diseñar redes WiFi hoteleras de nivel empresarial, centrándose en la segmentación de VLAN, la integración de PMS para la gestión automatizada de sesiones y la optimización del Captive Portal para la captura de datos de conformidad con el GDPR.

Cómo optimizar los captive portals para una máxima seguridad de red y conversión de usuarios

Esta guía proporciona un esquema técnico completo para optimizar los captive portals en entornos empresariales, abarcando la arquitectura de segmentación de red, la selección del método de autenticación, el diseño de consentimiento conforme a la GDPR y la optimización de la conversión. Está dirigida a responsables de TI, arquitectos de red y CTO de hoteles, cadenas de tiendas, estadios y organizaciones del sector público que necesitan equilibrar la seguridad de la red con la captura de datos de primera mano. Purple opera la infraestructura de captive portals en más de 80.000 establecimientos con 440 millones de inicios de sesión en 2024, y los marcos de trabajo aquí presentados reflejan esa experiencia operativa.