Come implementare SCEP per l'assegnazione automatizzata dei certificati WiFi

Executive summary

For venue operators running Guest WiFi across hotels, retail estates, stadiums, and conference centres, relying on pre-shared keys or basic captive portals for staff network access is a security liability. Modern network architecture demands 802.1X authentication using EAP-TLS (Extensible Authentication Protocol - Transport Layer Security), ensuring every device is cryptographically verified before it touches the network. The challenge is distribution: how do you deploy unique client certificates to thousands of Windows, iOS, and Android devices without burying your helpdesk?

The answer is SCEP - the Simple Certificate Enrolment Protocol. Formalised by the IETF as RFC 8894 in 2020, SCEP automates certificate enrolment across managed device fleets. When integrated with an MDM platform such as Microsoft Intune or Jamf, SCEP delivers zero-touch certificate provisioning: devices request, receive, and renew their own certificates without any IT intervention. The private key is generated locally on the device and never transmitted across the network - a fundamental security advantage over PKCS-based delivery.

This guide walks through the complete SCEP implementation workflow: PKI architecture, NDES gateway configuration, the mandatory three-step MDM deployment sequence, and the operational controls - particularly CRL checking and group targeting - that determine whether a rollout succeeds or stalls. Two real-world scenarios illustrate the approach in hospitality and retail environments. Purple operates across 80,000+ live venues and 350 million unique users; the patterns described here reflect what works at that scale.

Technical deep-dive

What SCEP actually does

SCEP sits between your MDM platform and your Certificate Authority (CA). It provides a standardised HTTP-based mechanism for devices to request, receive, and renew X.509 certificates without requiring a domain-joined credential or manual administrator involvement. The protocol was originally developed in the early 2000s and gained widespread adoption in enterprise MDM environments before the IETF formally published it as RFC 8894.

The six-step enrolment flow works as follows. First, the managed device connects to the SCEP gateway URL pre-configured in its MDM profile. Second, the device generates a private/public key pair locally and creates a Certificate Signing Request (CSR). Third, the SCEP gateway validates the device's authorisation using a challenge password or OTP embedded in the MDM policy. Fourth, the gateway forwards the validated CSR to the CA. Fifth, the CA signs the certificate and returns it to the gateway. Sixth, the gateway delivers the signed certificate to the device. Future renewals follow the same automated path - the device re-enrols before expiry without any user or administrator action.

SCEP vs PKCS: the decision that matters

Microsoft Intune and most MDM platforms support two certificate delivery mechanisms: SCEP and PKCS. The distinction is architectural, not cosmetic.

With SCEP, the private key is generated on the device and stays there. The CA never sees it. The device's TPM (on Windows) or Secure Enclave (on iOS/macOS) protects the key at the hardware level. With PKCS, the CA generates the key pair centrally and transmits it to the device over the network. The CA retains a copy, enabling key escrow - which is useful for S/MIME email encryption but introduces unnecessary risk for network authentication.

For 802.1X WiFi authentication, use SCEP. The private key never leaves the device. That is the rule.

802.1X and EAP-TLS: the authentication framework

IEEE 802.1X is the port-based network access control standard that underpins enterprise WiFi security. It defines three roles: the supplicant (the client device), the authenticator (the access point - Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet), and the authentication server (a RADIUS server such as Microsoft NPS, FreeRADIUS, or Cisco ISE).

EAP-TLS is the most secure EAP method for 802.1X. Both sides present certificates: the RADIUS server presents its certificate to the client, and the client presents its SCEP-provisioned certificate to the RADIUS server. Neither side can impersonate the other without a valid, non-revoked certificate from the trusted CA hierarchy. This mutual authentication model eliminates credential theft, Evil Twin attacks, and rogue access point risks in a single architectural decision.

EAP-TLS satisfies PCI DSS 4.0 Requirement 8.6 for multi-factor authentication at the network layer. It is required for WPA3 Enterprise 192-bit (Suite B) deployments. For any wireless network in scope for cardholder data processing - retail point-of-sale, hotel front desk, stadium ticketing - EAP-TLS is the correct choice.

For a deeper look at secure WiFi architecture and how certificate-based authentication fits within a broader security posture, see our essential guide.

Implementation guide

The deployment sequence is non-negotiable. Intune and Jamf resolve profile dependencies in order: the WiFi profile depends on the SCEP profile, which depends on the Trusted Root profile. Deploy them out of sequence and the WiFi profile will fail to apply.

Step 1: Design your PKI

Before you touch an MDM console, design your certificate hierarchy. A two-tier PKI is standard: an offline root CA and an online issuing CA. The root CA's private key is the master trust anchor for your entire certificate infrastructure - keep it air-gapped. The issuing CA handles day-to-day certificate issuance and publishes the Certificate Revocation List (CRL) and OCSP responder.

For most enterprise venue deployments, Microsoft Active Directory Certificate Services (AD CS) running on Windows Server provides the issuing CA. Cloud-hosted PKI services from providers such as SCEPman or SecureW2 eliminate the on-premises infrastructure requirement entirely and are worth evaluating for distributed estate deployments across hotel groups, retail chains, or multi-site public-sector organisations.

Step 2: Deploy the NDES server (or cloud SCEP gateway)

NDES (Network Device Enrolment Service) is the Microsoft Windows Server role that acts as the SCEP gateway between your MDM and your CA. Key configuration requirements:

• Publish the NDES URL externally via Azure AD Application Proxy (or equivalent reverse proxy). This allows remote devices to enrol before they arrive on-site, without opening inbound firewall ports.
• The NDES service account requires Read and Enrol permissions on the CA certificate template.
• Configure the certificate template with Key Usage set to Digital Signature and Key Encipherment, and Extended Key Usage set to Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
• Set an appropriate certificate validity period. One year is standard for client certificates; two years is acceptable for device certificates in stable fleets.

If you prefer to avoid on-premises NDES infrastructure, cloud SCEP gateways integrate directly with Intune and your CA via API, removing the IIS dependency entirely.

Step 3: Deploy the Trusted Root Certificate profile

In your MDM platform, create a Trusted Certificate profile and upload your Root CA certificate (and any Intermediate CA certificates) as .cer files. Deploy this profile to your target device groups before any other certificate or WiFi profiles. Without this step, devices cannot validate the RADIUS server's certificate during the EAP-TLS handshake, and they cannot trust the issuing CA when requesting their own SCEP certificate.

Rule of thumb: Always target the same Azure AD group (either Users or Devices) across all three related profiles. A mismatch here is the single most common cause of WiFi profile deployment failures.

Step 4: Configure the SCEP Certificate profile

Create a SCEP certificate configuration profile in your MDM:

• Subject name format: For user-driven authentication, use CN={{UserPrincipalName}}. For device authentication (recommended for shared devices and IoT), use CN={{AAD_Device_ID}}.
• Key usage: Digital Signature, Key Encipherment.
• Extended key usage: Client Authentication (OID: 1.3.6.1.5.5.7.3.2).
• SCEP server URL: The externally published NDES URL.
• Root certificate: Link to the Trusted Root profile from Step 3.
• Certificate validity period: Match the template configured on the CA.

Step 5: Deploy the 802.1X WiFi profile

Create a WiFi configuration profile:

• SSID: Enter the network name exactly as broadcast by your access points.
• Security type: WPA2-Enterprise or WPA3-Enterprise.
• EAP type: EAP-TLS.
• Client authentication certificate: Select the SCEP certificate profile from Step 4.
• Server validation: Specify the Trusted Root certificate from Step 3 and enter the expected RADIUS server name. This prevents devices from connecting to rogue access points presenting fraudulent certificates.

Best practices

Enforce strict CRL checking on your RADIUS server

Certificate revocation is the operational control that closes the gap between disabling an account and blocking network access. When a device is lost, stolen, or an employee leaves, disable the AD account and revoke the certificate at the CA. Your RADIUS server must be configured to check the CRL on every authentication attempt. If the CRL is unavailable - because the CDP (CRL Distribution Point) is unreachable - most RADIUS servers default to failing open, which is a security risk. Ensure your CDPs are highly available and that your RADIUS server is configured to fail closed if the CRL cannot be fetched.

For real-time revocation, configure OCSP (Online Certificate Status Protocol) in addition to CRL. OCSP provides per-certificate status responses without requiring the RADIUS server to download and parse the entire CRL.

Use device certificates for shared and IoT devices

For shared devices - hotel housekeeping tablets, retail POS terminals, stadium access control readers - use device certificates rather than user certificates. Device certificates are tied to the machine identity, not a user account. This means the device authenticates regardless of which user is logged in, and revocation is tied to the device record rather than an employee's departure.

For retail deployments, device certificates on POS hardware also satisfy the PCI DSS requirement for network-layer device identity without introducing user-credential complexity at the point of sale.

Automate certificate renewal

SCEP supports automatic renewal: the MDM instructs the device to re-enrol before the 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 Enrol permissions on the CA certificate template, or firewall URL filtering is blocking SCEP query strings.

Fix: Verify the connector account has Read and Enrol 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 enrolment 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 .