How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

Esta guía explica cómo configurar SCEP (Protocolo de inscripción de certificados simple) para la inscripción automatizada de certificados WiFi empresariales, abarcando toda la arquitectura desde PKI y NDES hasta la implementación de perfiles MDM y la validación RADIUS. Está dirigida a gerentes de TI, arquitectos de red y directores de tecnología (CTO) en hoteles, cadenas de retail, estadios, centros de conferencias y organizaciones del sector público que necesitan ir más allá de 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 coexiste junto con su red de personal autenticada por certificados.

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

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

Puntos 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 sucursales o un gran centro de conferencias, depender de claves precompartidas para el WiFi del personal representa 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 (Protocolo de autenticación extensible - Seguridad de la capa de transporte) elimina por completo ese riesgo. Cada dispositivo demuestra su identidad de forma criptográfica antes de que el punto de acceso le conceda acceso a la red.

El desafío es la distribución. Implementar manualmente certificados de cliente únicos en miles de dispositivos Windows, iOS y Android no es viable. SCEP (Protocolo de inscripción de certificados simple), formalizado como RFC 8894 por la IETF en 2020, resuelve esto. Automatiza el proceso de solicitud, emisión e instalación de certificados digitales en dispositivos administrados a través de su plataforma MDM, sin ninguna interacción del usuario.

Esta guía cubre toda la arquitectura: qué hace SCEP, cómo se integra con Microsoft Intune, Jamf y otras plataformas MDM, la secuencia exacta de implementación en la que la mayoría de los equipos se equivocan y los errores operativos que causan interrupciones. También cubrimos dos escenarios de implementación del mundo real en hotelería y retail, y explicamos dónde encaja la plataforma de Guest WiFi de Purple junto con su red de personal autenticada por certificados.

Escuche el podcast informativo complementario:

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

Qué hace realmente SCEP

SCEP no es un reemplazo para su Infraestructura de clave pública (PKI). Es la capa de inscripción automatizada que se ejecuta sobre 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 manualmente una CSR e instalar el certificado.

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. Ese modelo de autenticación mutua elimina el robo de credenciales y protege contra ataques de gemelo malvado (evil twin), donde un atacante monta un punto de acceso falso para recopilar nombres de usuario y contraseñas.

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

El flujo de inscripción de SCEP, paso a paso

La cadena de inscripción completa funciona de la siguiente manera. Su plataforma MDM (Microsoft Intune, Jamf u otro MDM) envía una carga útil (payload) de SCEP a un dispositivo administrado. Esa carga útil contiene dos cosas: la URL de SCEP que apunta a su servidor NDES (Servicio de inscripción de dispositivos de red) o puerta de enlace SCEP en la nube, y una contraseña de desafío o secreto compartido.

El dispositivo genera su propio par de claves pública y privada de forma local. 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. Luego, el dispositivo crea una Solicitud de firma de certificado (CSR) y la envía a la puerta de enlace SCEP. La puerta de enlace valida la contraseña de desafío, reenvía la CSR a su Autoridad 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 contra su cadena de confianza de la CA, verifica la Lista de revocación de certificados (CRL) para confirmar que el certificado no haya sido revocado y, si todo está en orden, envía un mensaje de Access-Accept al punto de acceso. El dispositivo 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 (Estándares de criptografía de clave pública). La diferencia arquitectónica es significativa.

Con SCEP, la clave privada se genera en el dispositivo y nunca sale de él. Con PKCS, la Autoridad 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 donde 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
Requiere servidor NDES	Sí (o puerta de enlace 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 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. Una 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 de 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 nuestra descripción general de la plataforma de analítica.

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 ese certificado exista en el dispositivo. Violar esta secuencia es la causa más común de fallas en el despliegue.

La secuencia es: primero la Raíz de Confianza (Trusted Root), segundo el perfil SCEP, tercero el perfil de 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, cargue el archivo .cer y despliéguelo en su grupo de dispositivos de destino.

Si tiene una jerarquía PKI de dos niveles (recomendado), debe 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 solo 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, CN={{UserPrincipalName}} es el estándar. Para la autenticación de dispositivos (dispositivos compartidos, IoT, terminales POS), use CN={{AAD_Device_ID}}. Establezca el uso de clave (Key usage) en Firma digital y Cifrado de clave (Key encipherment). Establezca el Uso de clave extendido (Extended Key Usage) en Autenticación de cliente (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 al sitio. No exponga NDES directamente a internet.

Paso 3: desplegar el perfil de WiFi 802.1X

El paso final es enviar la configuración de WiFi que vincula los certificados al SSID de la red. Cree un perfil de configuración de Wi-Fi. Ingrese 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 la configuración de autenticación, seleccione el perfil de certificado SCEP creado en el Paso 2 como el certificado de autenticación de cliente. Especifique el certificado de Raíz de Confianza 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 deshabilita una cuenta en Entra ID y el MDM desvincula el dispositivo, el certificado se revoca y el acceso a 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.

Mejores prácticas y estándares de la industria

Ubicación del servidor NDES

El servidor NDES debe ser accesible desde internet para que los dispositivos puedan registrarse antes de llegar al sitio. Publique la URL de NDES a través de Azure AD Application Proxy. Esto proporciona un acceso remoto seguro sin abrir puertos de firewall entrantes 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 administrados, considere una puerta de enlace SCEP en la nube en lugar de un NDES local. Las puertas de enlace en la nube eliminan el punto único de falla de NDES, se escalan horizontalmente y, por lo general, se integran directamente con los servicios RADIUS en la nube.

Disponibilidad de CRL

Su servidor RADIUS verifica 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 verificación estricta de CRL y asegúrese de que sus endpoints de CRL tengan 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 con este requisito para redes inalámbricas en entornos de Retail y Hospitalidad .

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 de atención médica. Si está realizando un despliegue en entornos de Sector salud o Transporte con requisitos de cumplimiento estrictos, WPA3-Enterprise con EAP-TLS es la arquitectura de destino correcta.

BYOD y WiFi de invitadosiFi

SCEP requiere el registro en el MDM para enviar la carga útil del certificado. No cubre dispositivos BYOD no administrados ni invitados. Para esos casos de uso, necesita un SSID independiente con un Captive Portal y verificación de identidad. La plataforma de Purple maneja esa capa de manera limpia, coexistiendo con su red de personal autenticada por certificado. Nuestra plataforma de Guest WiFi admite opciones de consentimiento consciente (opt-in), captura de datos de primera mano 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

El perfil de WiFi no se aplica

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

Causa raíz: Desajuste 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 de Raíz de confianza, SCEP y WiFi se dirijan exactamente al mismo grupo de directorio.

Errores NDES 403 Forbidden

Síntoma: Los dispositivos no logran recuperar el certificado SCEP. Los registros de NDES IIS 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 firewall está bloqueando los parámetros de la cadena de consulta SCEP.

Solución: Verifique que la cuenta del conector tenga permisos de Lectura e Inscripción en la plantilla de la CA. Revise los registros del firewall para asegurarse de que las URL que contienen ?operation=GetCACaps no estén bloqueadas.

Falla 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á disponible. El servidor RADIUS no puede confirmar que los certificados sean válidos y se bloquea por seguridad (fails closed).

Solución: Configure el monitoreo y las alertas de la CRL. Publique las CRL con un período de validez significativamente mayor que el intervalo de publicación. Pruebe la accesibilidad de la CDP desde el servidor RADIUS antes de la puesta en marcha.

La expiración de certificados causa fallas silenciosas

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

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

Solución: Configure la renovación de certificados para que se active al 80% de la vida útil del certificado. Monitoree los informes de estado de registro de MDM para dispositivos con errores de certificado. Establezca períodos de validez de certificados adecuados para el ciclo de renovación de sus dispositivos, normalmente de uno a dos años para endpoints administrados.

ROI e impacto empresarial

La transición a la autenticación por certificado 802.1X basada en SCEP ofrece retornos medibles en seguridad, operaciones y cumplimiento.

Reducción de tickets de soporte: El WiFi basado en contraseñas genera un volumen significativo de tickets de soporte: expiraciones de contraseñas, bloqueos de cuentas y errores de escritura. La autenticación basada en certificados es invisible para el usuario. Las organizaciones suelen ver una reducción del 70 al 80% en el volumen de soporte relacionado con WiFi después de la migración.

Postura de seguridad: EAP-TLS elimina el robo de credenciales y los ataques Man-in-the-Middle. Esto respalda directamente el cumplimiento de PCI DSS 4.0 para redes de retail y hospitalidad, y los requisitos del Artículo 32 de GDPR para medidas de seguridad técnica adecuadas.

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

Segmentación de red: La asignación dinámica de VLAN a través de atributos de certificado RADIUS le brinda una segmentación de red aplicada criptográficamente. Los dispositivos llegan al segmento de red correcto según las propiedades del certificado, no por la selección de SSID o el filtrado de direcciones MAC, ambos fácilmente vulnerables.

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 de 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 personal autenticada por certificado y nuestra capa de guest WiFi funcionen 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 implementación de red segura, consulte nuestra guía de análisis.

Referencias

[1] RFC 8894: Simple Certificate Enrollment Protocol - IETF [2] Configure infrastructure to support SCEP with Intune - Microsoft Learn [3] PCI DSS Wireless Guidelines - PCI Security Standards Council

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 resueltos

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: Una guía para ubicaciones remotas y marítimas

Esta guía detalla cómo omitir el hardware nativo de Starlink e integrar un Captive Portal administrado en la nube utilizando equipos de enrutamiento empresariales. Aprenderá cómo superar la limitación de CGNAT, aplicar la segmentación de VLAN, administrar las restricciones 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 de WiFi para hoteles de nivel empresarial, enfocándose en la segmentación de VLAN, la integración de PMS para la gestión automatizada de sesiones y la optimización de Captive Portal para la captura de datos de conformidad con el GDPR.

Mejores prácticas de Captive Portal: Diseñando para una alta conversión y cumplimiento

Esta guía técnica ofrece a los gerentes de TI, arquitectos de red y directores de operaciones de establecimientos un plan completo para implementar captive portals que equilibren la seguridad de la red con una alta conversión de usuarios. Cubre toda la arquitectura, desde la segmentación de VLAN y la autenticación RADIUS hasta el diseño de consentimiento conforme a GDPR y la selección del método de autenticación. Basada en la experiencia operativa de Purple en más de 80,000 establecimientos y 440 millones de inicios de sesión en 2024, cada recomendación se fundamenta en datos reales de implementación.