Cómo implementar SCEP para el registro automatizado de certificados WiFi

Resumen ejecutivo

Para los operadores de recintos que ofrecen Guest WiFi en hoteles, establecimientos comerciales, estadios y centros de conferencias, depender de claves precompartidas o de Captive Portal 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 acceder a la red. El desafío es la distribución: ¿cómo desplegar certificados de cliente únicos en miles de dispositivos Windows, iOS y Android sin saturar al servicio de soporte técnico?

La respuesta es SCEP: el Protocolo simple de registro de certificados. Formalizado por el IETF como RFC 8894 en 2020, SCEP automatiza el registro de certificados en flotas de dispositivos gestionados. Cuando se integra con una plataforma MDM como Microsoft Intune o Jamf, SCEP ofrece un aprovisionamiento de certificados sin intervención: 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 distribución basada en PKCS.

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

Análisis técnico detallado

Qué hace realmente SCEP

SCEP se sitúa 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 necesidad de una credencial unida al dominio ni de la intervención manual de un administrador. El protocolo se desarrolló originalmente a principios de la década de 2000 y logró una adopción generalizada en entornos MDM empresariales antes de que el IETF lo publicara formalmente como RFC 8894.

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

SCEP frente a PKCS: la decisión clave

Microsoft Intune y la mayoría de las plataformas MDM admiten dos mecanismos de distribución de certificados: SCEP y PKCS. La distinción es arquitectónica, no esté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) protegen 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), algo útil para el cifrado de correo electrónico S/MIME pero que introduce un riesgo innecesario para la autenticación de red.

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

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 provisto 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 tipo 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 despliegues 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 entradas en estadios: EAP-TLS es la opción correcta.

Para analizar en profundidad la arquitectura de WiFi seguro y cómo la autenticación basada en certificados se integra en un marco de seguridad más amplio, consulte nuestra guía esencial.

Guía de implementación

La secuencia de despliegue 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 de raíz de confianza (Trusted Root). Si los despliega fuera de orden, 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. Lo estándar es una PKI de dos niveles: 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 los despliegues 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 despliegues distribuidos en grupos hoteleros, cadenas de retail u organizaciones del sector público con múltiples sedes.

Paso 2: Despliegue el servidor NDES (o la pasarela SCEP en la nube)

NDES (Network Device Enrollment Service) es el rol de Microsoft Windows Server que actúa como pasarela 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 a las instalaciones, sin abrir puertos de entrada en el cortafuegos.
• La cuenta de servicio de NDES requiere permisos de lectura y registro (Read y 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 lo estándar para certificados de cliente; dos años es aceptable para certificados de dispositivo en flotas estables.

Si prefiere evitar la infraestructura NDES local, las pasarelas 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: Despliegue el perfil de certificado de raíz de confianza (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. Despliegue 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 de oro: 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 fallos en el despliegue 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 del sujeto (Subject name format): Para la autenticación basada en el usuario, use "CN={{UserPrincipalName}}". Para la autenticación de dispositivos (recomendado para dispositivos compartidos e IoT), use "CN={{AAD_Device_ID}}".
• Uso de clave (Key usage): Digital Signature, Key Encipherment.
• Uso de clave extendido (Extended key usage): 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: Enlace al perfil de raíz de confianza (Trusted Root) del Paso 3.
• Período de validez del certificado: Debe coincidir con la plantilla configurada en la CA.

Paso 5: Despliegue el perfil de WiFi 802.1X

Cree un perfil de configuración de WiFi:

• SSID: Introduzca 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 de raíz de confianza (Trusted Root) del Paso 3 e introduzca el nombre del servidor RADIUS esperado. Esto evita que los dispositivos se conecten a puntos de acceso no autorizados que presenten certificados fraudulentos.

Buenas prácticas

Aplique una comprobación estricta de la CRL en su servidor RADIUS

La revocación de certificados es el control operativo que cierra la brecha entre la desactivación de una cuenta y el bloqueo del acceso a la red. Cuando un dispositivo se pierde, se roba o un empleado se marcha, desactive la cuenta de AD y revoque el certificado en la CA. Su servidor RADIUS debe estar configurado para comprobar 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 en modo abierto (fail open) de forma predeterminada, lo que representa un riesgo de seguridad. Asegúrese de que sus CDP tengan una alta disponibilidad y de que su servidor RADIUS esté configurado para fallar en modo cerrado (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 necesidad de que el servidor RADIUS descargue y analice toda la CRL.

Utilice certificados de dispositivo para dispositivos compartidos e IoT

Para dispositivos compartidos (tabletas del servicio de limpieza de hoteles, terminales de punto de venta [POS] de retail, lectores de control de acceso a estadios), utilice 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 despliegues 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 indica al dispositivo que vuelva a registrarse antes de que el certificate expires. Configure your SCEP profile to trigger renewal at 20% of the certificate's remaining validity period. For a one-year certificate, renewal begins approximately 73 days before expiry. This window provides enough time to resolve any renewal failures before the certificate expires and devices lose network access.

Expired certificates causing mass authentication failures are the most common operational incident in 802.1X deployments. Automated renewal via SCEP eliminates this risk entirely.

Segment networks by certificate attribute

RADIUS servers can read certificate attributes - Subject, SAN, or custom OIDs - and use them to assign devices to VLANs dynamically. A housekeeping tablet with a certificate issued from the HousekeepingDevices template lands on the housekeeping VLAN. A POS terminal with a certificate from the RetailPOS template lands on the PCI-scoped VLAN. This is cryptographically enforced network segmentation - far more reliable than SSID-based or MAC-based approaches.

For hospitality operators running Guest WiFi alongside Staff WiFi on the same physical infrastructure, VLAN assignment via certificate attributes ensures guests and staff are always on separate network segments, regardless of which SSID a device connects to.

Troubleshooting & risk mitigation

WiFi profile shows 'Error' or 'Not Applicable' in Intune

Root cause: Group targeting mismatch. The SCEP profile is assigned to a different group than the WiFi profile. Intune cannot resolve the certificate dependency.

Fix: Audit all three profiles (Trusted Root, SCEP, WiFi). Ensure they are all assigned to the exact same Azure AD group. If you are deploying to Users, all three profiles must target a Users group. If deploying to Devices, all three must target a Devices group.

NDES returns HTTP 403 errors

Root cause: The Intune Certificate Connector service account lacks Read or Enroll permissions on the CA certificate template, or firewall URL filtering is blocking SCEP query strings.

Fix: Verify the connector account has Read and Enroll permissions on the template in the CA console. Check firewall logs for blocked requests containing ?operation=GetCACaps or ?operation=PKIOperation. These query strings must pass through without modification.

Devices fail to renew certificates before expiry

Root cause: The SCEP renewal window is too short, or the NDES server is unreachable at the time of renewal.

Fix: Set the renewal threshold to 20% of certificate validity. Ensure the NDES URL is published via a highly available reverse proxy. Monitor NDES IIS logs for renewal request failures and alert on them proactively.

RADIUS rejects valid certificates

Root cause: The RADIUS server's trusted CA store does not include the issuing CA certificate, or the CRL is stale.

Fix: Import the full CA chain (Root CA + Issuing CA) into the RADIUS server's trusted store. Verify the CRL is being fetched successfully and that the CDP URL is reachable from the RADIUS server. Check the CRL's next-update timestamp - if it has passed, the CA needs to publish a new CRL.

For broader network performance considerations alongside security, see our bandwidth management guide .

ROI & business impact

The business case for SCEP-based certificate enrollment is straightforward. Password-based WiFi generates a predictable volume of helpdesk tickets: password expirations, lockouts, staff sharing credentials with guests, and onboarding friction for new starters. Certificate-based authentication is invisible to the end user. Devices connect automatically. There are no passwords to expire, share, or forget.

Organisations that migrate from password-based WiFi to EAP-TLS with SCEP typically report a 70-80% reduction in WiFi-related helpdesk tickets (Purple internal data, 2024, based on deployments across hospitality and retail estates). The helpdesk saving alone often justifies the implementation cost within the first year.

The compliance impact is equally concrete. EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer. For healthcare environments, it aligns with HIPAA technical safeguard requirements for wireless network access. For public-sector organisations, it supports NCSC Cyber Essentials Plus certification requirements for network access control.

For transport operators - rail franchises, airport operators, bus networks - certificate-based authentication on staff devices ensures that operational networks carrying safety-critical data are isolated from passenger WiFi and protected against credential-based attacks.

Purple's WiFi Analytics platform integrates with 802.1X-secured networks to deliver first-party data insights without compromising the security posture of the underlying infrastructure. The 29 billion data points collected across Purple's network demonstrate that security and analytics are complementary, not competing, objectives.

For feedback and experience management alongside your secure network deployment, see our venue feedback playbook .