Cómo implementar SCEP para la inscripción automatizada de certificados WiFi

Esta guía explica cómo implementar SCEP (Simple Certificate Enrollment Protocol) para la inscripción automatizada de certificados WiFi en entornos empresariales. Cubre el diseño arquitectónico completo, desde el diseño de PKI y la integración de MDM hasta la secuencia de implementación obligatoria de tres pasos, y muestra a los administradores de TI y arquitectos de red cómo eliminar las credenciales compartidas, automatizar la gestión del ciclo de vida de los certificados y cumplir con los requisitos de PCI DSS y GDPR a escala.

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

Escucha esta guía

Ver transcripción del podcast

INTRODUCTION AND CONTEXT - 0:00 to 1:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Puntos clave

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

Resumen ejecutivo

Para los operadores de establecimientos que ofrecen Guest WiFi en hoteles, tiendas minoristas, estadios y centros de conferencias, depender de claves precompartidas o Captive Portals básicos para el acceso a la red del personal es un riesgo de seguridad. La arquitectura de red moderna exige autenticación 802.1X mediante EAP-TLS (Protocolo de Autenticación Extensible - Seguridad de la Capa de Transporte), lo que garantiza que cada dispositivo se verifique criptográficamente antes de conectarse a la red. El desafío es la distribución: ¿cómo implementar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar a su mesa de ayuda?

La respuesta es SCEP: el Protocolo de Inscripción de Certificados Simple. Formalizado por el IETF como RFC 8894 en 2020, SCEP automatiza la inscripción de certificados en flotas de dispositivos administrados. Al integrarse con una plataforma MDM como Microsoft Intune o Jamf, SCEP ofrece un aprovisionamiento de certificados sin intervención (zero-touch): los dispositivos solicitan, reciben y renuevan sus propios certificados sin ninguna intervención de TI. La clave privada se genera localmente en el dispositivo y nunca se transmite a través de la red, una ventaja de seguridad fundamental sobre la entrega basada en PKCS.

Esta guía detalla el flujo de trabajo completo de la implementación de SCEP: la arquitectura de PKI, la configuración de la puerta de enlace NDES, la secuencia obligatoria de implementación de MDM de tres pasos y los controles operativos (en particular, la verificación de CRL y la segmentación de grupos) que determinan si una implementación tiene éxito o se estanca. Dos escenarios del mundo real ilustran este enfoque en entornos de hotelería y comercio minorista. Purple opera en más de 80,000 establecimientos activos y cuenta con 350 millones de usuarios únicos; los patrones descritos aquí reflejan lo que funciona a esa escala.

Análisis técnico profundo

Qué hace realmente SCEP

SCEP se ubica entre su plataforma MDM y su Autoridad de Certificación (CA). Proporciona un mecanismo estandarizado basado en HTTP para que los dispositivos soliciten, reciban y renueven certificados X.509 sin requerir una credencial unida al dominio ni la intervención manual del administrador. El protocolo se desarrolló originalmente a principios de la década de 2000 y obtuvo una adopción generalizada en entornos MDM empresariales antes de que el IETF lo publicara formalmente como RFC 8894.

El flujo de inscripción de seis pasos funciona de la siguiente manera. Primero, el dispositivo administrado se conecta a la URL de la puerta de enlace SCEP preconfigurada en su perfil de MDM. Segundo, el dispositivo genera un par de claves privada/pública localmente y crea una Solicitud de Firma de Certificado (CSR). Tercero, la puerta de enlace SCEP valida la autorización del dispositivo mediante una contraseña de desafío o OTP integrada en la política de MDM. Cuarto, la puerta de enlace reenvía la CSR validada a la CA. Quinto, la CA firma el certificado y lo devuelve a la puerta de enlace. Sexto, la puerta de enlace entrega el certificado firmado al dispositivo. Las renovaciones futuras siguen la misma ruta automatizada: el dispositivo se vuelve a inscribir antes de su vencimiento sin ninguna acción por parte del usuario o del administrador.

SCEP vs. PKCS: la decisión que importa

Microsoft Intune y la mayoría de las plataformas MDM admiten dos mecanismos de entrega de certificados: SCEP y PKCS. La distinción es arquitectónica, no cosmética.

Con SCEP, la clave privada se genera en el dispositivo y permanece allí. La CA nunca la ve. El TPM del dispositivo (en Windows) o el Secure Enclave (en iOS/macOS) protege la clave a nivel de hardware. Con PKCS, la CA genera el par de claves de forma centralizada y lo transmite al dispositivo a través de la red. La CA conserva una copia, lo que permite el depósito de claves (key escrow), lo cual es útil para el cifrado de correo electrónico S/MIME pero introduce un riesgo innecesario para la autenticación de red.

Para la autenticación WiFi 802.1X, use SCEP. La clave privada nunca sale del dispositivo. Esa es la regla.

Criterio	SCEP	PKCS
Clave privada generada en	Dispositivo	CA (centralizado)
Clave privada transmitida por red	Nunca	Sí
Admite TPM / Secure Enclave	Sí	No
Recomendado para autenticación WiFi	Sí	No
Recomendado para cifrado de correo (S/MIME)	No	Sí
Depósito de claves (key escrow) posible	No	Sí

802.1X y EAP-TLS: el marco de autenticación

IEEE 802.1X es el estándar de control de acceso a la red basado en puertos que sustenta la seguridad WiFi empresarial. Define tres roles: el suplicante (el dispositivo cliente), el autenticador (el punto de acceso: Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme o Fortinet) y el servidor de autenticación (un servidor RADIUS como Microsoft NPS, FreeRADIUS o Cisco ISE).

EAP-TLS es el método EAP más seguro para 802.1X. Ambas partes presentan certificados: el servidor RADIUS presenta su certificado al cliente, y el cliente presenta su certificado aprovisionado por SCEP al servidor RADIUS. Ninguna de las partes puede suplantar a la otra sin un certificado válido y no revocado de la jerarquía de CA de confianza. Este modelo de autenticación mutua elimina el robo de credenciales, los ataques de gemelo malvado (Evil Twin) y los riesgos de puntos de acceso no autorizados en una sola decisión arquitectónica.

EAP-TLS cumple con el requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Es obligatorio para implementaciones de WPA3 Enterprise de 192 bits (Suite B). Para cualquier red inalámbrica dentro del alcance del procesamiento de datos de titulares de tarjetas: comercio minorista punto de venta, recepción de hotel, venta de boletos en estadios: EAP-TLS es la opción correcta.

Para analizar más a fondo la arquitectura de WiFi seguro y cómo la autenticación basada en certificados se integra en una postura de seguridad más amplia, consulte nuestra guía esencial.

Guía de implementación

La secuencia de implementación no es negociable. Intune y Jamf resuelven las dependencias de los perfiles en orden: el perfil de WiFi depende del perfil SCEP, que a su vez depende del perfil Trusted Root. Si los implementa fuera de secuencia, el perfil de WiFi no se aplicará.

Paso 1: Diseñe su PKI

Antes de tocar una consola MDM, diseñe su jerarquía de certificados. Una PKI de dos niveles es el estándar: una CA raíz fuera de línea (offline) y una CA emisora en línea (online). La clave privada de la CA raíz es el ancla de confianza maestra para toda su infraestructura de certificados; manténgala aislada de la red (air-gapped). La CA emisora se encarga de la emisión diaria de certificados y publica la Lista de revocación de certificados (CRL) y el respondedor OCSP.

Para la mayoría de las implementaciones en recintos empresariales, Microsoft Active Directory Certificate Services (AD CS) ejecutado en Windows Server proporciona la CA emisora. Los servicios de PKI alojados en la nube de proveedores como SCEPman o SecureW2 eliminan por completo el requisito de infraestructura local y vale la pena evaluarlos para implementaciones en propiedades distribuidas en grupos hoteleros, cadenas de retail u organizaciones del sector público con múltiples sedes.

Paso 2: Implemente el servidor NDES (o la puerta de enlace SCEP en la nube)

NDES (Network Device Enrollment Service) es el rol de Microsoft Windows Server que actúa como la puerta de enlace SCEP entre su MDM y su CA. Requisitos clave de configuración:

Publique la URL de NDES externamente a través de Azure AD Application Proxy (o un proxy inverso equivalente). Esto permite que los dispositivos remotos se registren antes de llegar al sitio, sin abrir puertos de firewall entrantes.
La cuenta de servicio de NDES requiere permisos de Lectura e Inscripción (Read and Enroll) en la plantilla de certificado de la CA.
Configure la plantilla de certificado con el Uso de clave (Key Usage) establecido en Firma digital (Digital Signature) y Cifrado de clave (Key Encipherment), y el Uso de clave extendido (Extended Key Usage) establecido en Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
Establezca un período de validez de certificado adecuado. Un año es el estándar para certificados de cliente; dos años es aceptable para certificados de dispositivos en flotas estables.

Si prefiere evitar la infraestructura NDES local, las puertas de enlace SCEP en la nube se integran directamente con Intune y su CA a través de una API, eliminando por completo la dependencia de IIS.

Paso 3: Implemente el perfil de Certificado Trusted Root

En su plataforma MDM, cree un perfil de Certificado de confianza (Trusted Certificate) y cargue su certificado de CA raíz (y cualquier certificado de CA intermedia) como archivos .cer. Implemente este perfil en sus grupos de dispositivos de destino antes de cualquier otro perfil de certificado o de WiFi. Sin este paso, los dispositivos no podrán validar el certificado del servidor RADIUS durante el saludo (handshake) EAP-TLS, y no podrán confiar en la CA emisora al solicitar su propio certificado SCEP.

Regla general: Diríjase siempre al mismo grupo de Azure AD (ya sea de Usuarios o de Dispositivos) en los tres perfiles relacionados. Una discrepancia aquí es la causa más común de fallas en la implementación de perfiles de WiFi.

Paso 4: Configure el perfil de Certificado SCEP

Cree un perfil de configuración de certificado SCEP en su MDM:

Formato del nombre de sujeto (Subject name format): Para la autenticación basada en el usuario, use CN={{UserPrincipalName}}. Para la autenticación de dispositivos (recomendada para dispositivos compartidos e IoT), use CN={{AAD_Device_ID}}.
Uso de clave (Key usage): Firma digital (Digital Signature), Cifrado de clave (Key Encipherment).
Uso de clave extendido (Extended key usage): Autenticación de cliente (Client Authentication) (OID: 1.3.6.1.5.5.7.3.2).
URL del servidor SCEP: La URL de NDES publicada externamente.
Certificado raíz (Root certificate): Vincule al perfil Trusted Root del Paso 3.
Período de validez del certificado: Debe coincidir con la plantilla configurada en la CA.

Paso 5: Implemente el perfil de WiFi 802.1X

Cree un perfil de configuración de WiFi:

SSID: Ingrese el nombre de la red exactamente como lo transmiten sus puntos de acceso.
Tipo de seguridad: WPA2-Enterprise o WPA3-Enterprise.
Tipo de EAP: EAP-TLS.
Certificado de autenticación de cliente: Seleccione el perfil de certificado SCEP del Paso 4.
Validación del servidor: Especifique el certificado Trusted Root del Paso 3 e ingrese el nombre esperado del servidor RADIUS. Esto evita que los dispositivos se conecten a puntos de acceso no autorizados que presenten certificados fraudulentos.

Mejores prácticas

Aplique una verificación estricta de CRL en su servidor RADIUS

La revocación de certificados es el control operativo que cierra la brecha entre deshabilitar una cuenta y bloquear el acceso a la red. Cuando un dispositivo se pierde, se roba o un empleado se va, deshabilite la cuenta de AD y revoque el certificado en la CA. Su servidor RADIUS debe estar configurado para verificar la CRL en cada intento de autenticación. Si la CRL no está disponible (porque el CDP [Punto de distribución de CRL] es inaccesible), la mayoría de los servidores RADIUS fallan de forma abierta de manera predeterminada (fail open), lo que representa un riesgo de seguridad. Asegúrese de que sus CDP tengan una alta disponibilidad y que su servidor RADIUS esté configurado para fallar de forma cerrada (fail closed) si no se puede obtener la CRL.

Para la revocación en tiempo real, configure OCSP (Online Certificate Status Protocol) además de la CRL. OCSP proporciona respuestas de estado por certificado sin requerir que el servidor RADIUS descargue y analice toda la CRL.

Utilice certificados de dispositivo para dispositivos compartidos e IoT

Para dispositivos compartidos (tabletas de limpieza de hoteles, terminales POS de retail, lectores de control de acceso en estadios), use certificados de dispositivo en lugar de certificados de usuario. Los certificados de dispositivo están vinculados a la identidad de la máquina, no a una cuenta de usuario. Esto significa que el dispositivo se autentica independientemente de qué usuario haya iniciado sesión, y la revocación está vinculada al registro del dispositivo en lugar de a la salida de un empleado.

Para implementaciones de retail , los certificados de dispositivo en el hardware de POS también cumplen con el requisito de PCI DSS para la identidad del dispositivo a nivel de red, sin introducir la complejidad de las credenciales de usuario en el punto de venta.

Automatice la renovación de certificados

SCEP admite la renovación automática: el MDM le indica al dispositivo que se vuelva a registrar antes de que certificado expire. Configure su perfil SCEP para activar la renovación al 20% del periodo de validez restante del certificado. Para un certificado de un año, la renovación comienza aproximadamente 73 días antes del vencimiento. Este intervalo proporciona suficiente tiempo para resolver cualquier fallo de renovación antes de que el certificado expire y los dispositivos pierdan el acceso a la red.

Los certificados vencidos que causan fallos de autenticación masivos son el incidente operativo más común en las implementaciones de 802.1X. La renovación automatizada a través de SCEP elimina este riesgo por completo.

Segmentar redes por atributo de certificado

Los servidores RADIUS pueden leer los atributos de los certificados (Subject, SAN u OID personalizados) y utilizarlos para asignar dispositivos a VLAN de forma dinámica. Una tableta de limpieza con un certificado emitido desde la plantilla HousekeepingDevices se asigna a la VLAN de limpieza. Una terminal POS con un certificado de la plantilla RetailPOS se asigna a la VLAN con alcance PCI. Esta es una segmentación de red aplicada criptográficamente, mucho más confiable que los enfoques basados en SSID o en MAC.

Para los operadores de hospitalidad que ejecutan WiFi para invitados junto con WiFi para el personal en la misma infraestructura física, la asignación de VLAN a través de atributos de certificado garantiza que los invitados y el personal estén siempre en segmentos de red separados, independientemente del SSID al que se conecte un dispositivo.

Resolución de problemas y mitigación de riesgos

El perfil de WiFi muestra 'Error' o 'No aplicable' en Intune

Causa raíz: Desajuste en la asignación de grupos. El perfil SCEP está asignado a un grupo diferente al del perfil de WiFi. Intune no puede resolver la dependencia del certificado.

Solución: Audite los tres perfiles (Trusted Root, SCEP, WiFi). Asegúrese de que todos estén asignados exactamente al mismo grupo de Azure AD. Si está realizando la implementación para Usuarios, los tres perfiles deben dirigirse a un grupo de Usuarios. Si la realiza para Dispositivos, los tres deben dirigirse a un grupo de Dispositivos.

NDES devuelve errores HTTP 403

Causa raíz: La cuenta de servicio de Intune Certificate Connector carece de permisos de lectura (Read) o inscripción (Enroll) en la plantilla de certificado de la CA, o el filtrado de URL del firewall está bloqueando las cadenas de consulta SCEP.

Solución: Verifique que la cuenta del conector tenga permisos de lectura (Read) e inscripción (Enroll) en la plantilla en la consola de la CA. Revise los registros del firewall para detectar solicitudes bloqueadas que contengan ?operation=GetCACaps o ?operation=PKIOperation. Estas cadenas de consulta deben pasar sin modificaciones.

Los dispositivos no renuevan los certificados antes de su vencimiento

Causa raíz: El intervalo de renovación de SCEP es demasiado corto o el servidor NDES no está accesible al momento de la renovación.

Solución: Establezca el límite de renovación al 20% de la validez del certificado. Asegúrese de que la URL de NDES se publique a través de un proxy inverso de alta disponibilidad. Monitoree los registros de IIS de NDES para detectar fallos en las solicitudes de renovación y genere alertas proactivas al respecto.

RADIUS rechaza certificados válidos

Causa raíz: El almacén de CA de confianza del servidor RADIUS no incluye el certificado de la CA emisora, o la CRL está desactualizada.

Solución: Importe la cadena de CA completa (Root CA + Issuing CA) en el almacén de confianza del servidor RADIUS. Verifique que la CRL se esté obteniendo correctamente y que la URL de CDP sea accesible desde el servidor RADIUS. Compruebe la marca de tiempo de la próxima actualización de la CRL; si ya pasó, la CA debe publicar una nueva CRL.

Para consideraciones más amplias sobre el rendimiento de la red junto con la seguridad, consulte nuestra guía de gestión de ancho de banda .

ROI e impacto comercial

El caso de negocio para el registro de certificados basado en SCEP es sencillo. El WiFi basado en contraseñas genera un volumen predecible de tickets de soporte: vencimientos de contraseñas, bloqueos de cuentas, personal que comparte credenciales con invitados y fricción en la incorporación de nuevos empleados. La autenticación basada en certificados es invisible para el usuario final. Los dispositivos se conectan automáticamente. No hay contraseñas que venzan, se compartan o se olviden.

Las organizaciones que migran de WiFi basado en contraseñas a EAP-TLS con SCEP suelen reportar una reducción del 70-80% en los tickets de soporte relacionados con WiFi (datos internos de Purple, 2024, basados en implementaciones en propiedades de hospitalidad y comercio minorista). El ahorro en soporte técnico por sí solo suele justificar el costo de implementación dentro del primer año.

El impacto en el cumplimiento es igualmente concreto. EAP-TLS cumple con el Requisito 8.6 de PCI DSS 4.0 para la autenticación multifactor en la capa de red. Para entornos de atención médica , se alinea con los requisitos de salvaguardas técnicas de HIPAA para el acceso a redes inalámbricas. Para las organizaciones del sector público, respalda los requisitos de certificación Cyber Essentials Plus de la NCSC para el control de acceso a la red.

Para los operadores de transporte (concesiones ferroviarias, operadores aeroportuarios, redes de autobuses), la autenticación basada en certificados en los dispositivos del personal garantiza que las redes operativas que transportan datos críticos para la seguridad estén aisladas del WiFi para pasajeros y protegidas contra ataques basados en credenciales.

La plataforma WiFi Analytics de Purple se integra con redes protegidas por 802.1X para ofrecer información de datos de primera mano sin comprometer la postura de seguridad de la infraestructura subyacente. Los 29 mil millones de puntos de datos recopilados a través de la red de Purple demuestran que la seguridad y la analítica son objetivos complementarios, no opuestos.

Para la gestión de comentarios y experiencias junto con la implementación de su red segura, consulte nuestro manual de recopilación de comentarios en establecimientos .

Definiciones clave

SCEP (Simple Certificate Enrollment Protocol)

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

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

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

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

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

PKCS (Public Key Cryptography Standards)

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

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

NDES (Network Device Enrollment Service)

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

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

CRL (Certificate Revocation List)

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

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

802.1X

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

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

RADIUS (Remote Authentication Dial-In User Service)

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

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

CSR (Certificate Signing Request)

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

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

PKI (Public Key Infrastructure)

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

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

VLAN (Virtual Local Area Network)

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

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

Ejemplos resueltos

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

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

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

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

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

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

Preguntas de práctica

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

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

Ver respuesta modelo

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

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

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

Ver respuesta modelo

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

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

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

Ver respuesta modelo

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

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

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

Ver respuesta modelo

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

Continúe leyendo esta serie

La guía empresarial de SCEP: Implementación de Simple Certificate Enrollment Protocol para la seguridad automatizada de WiFi en campus

Esta guía de referencia técnica proporciona un diseño arquitectónico definitivo y una estrategia de implementación paso a paso para la implementación de certificados de WiFi empresariales mediante SCEP. Cubre las diferencias críticas entre SCEP y PKCS, la secuencia de implementación exacta requerida para el éxito y estrategias de mitigación de riesgos del mundo real para líderes de TI.

¿Por qué no se conecta mi WiFi de invitados? Resolución de problemas de Captive Portal

Esta guía de referencia técnica autorizada explica la mecánica subyacente de la detección de Captive Portal y detalla los seis modos de falla principales que impiden que el WiFi de invitados se conecte. Proporciona a los gerentes de TI y arquitectos de red un marco de trabajo práctico para la resolución de problemas para resolver conflictos de redirección HTTP, DNS y desafíos de aleatorización de direcciones MAC.

GDPR y Guest WiFi: Guía de cumplimiento para profesionales de marketing de recintos y TI

Esta guía proporciona a los gerentes de TI y operadores de recintos un marco práctico para garantizar que los servicios de Guest WiFi cumplan plenamente con el GDPR. Cubre la arquitectura técnica, la mecánica de consentimiento, la retención de datos y cómo transformar el cumplimiento en un activo seguro de datos de primera mano.