How to Configure SCEP for Automated Enterprise WiFi Certificate Enrollment

This guide explains how to configure SCEP (Simple Certificate Enrollment Protocol) for automated enterprise WiFi certificate enrolment, covering the full architecture from PKI and NDES through to MDM profile deployment and RADIUS validation. It is aimed at IT managers, network architects, and CTOs at hotels, retail chains, stadiums, conference centres, and public-sector organisations who need to move beyond pre-shared keys and implement scalable, identity-based 802.1X EAP-TLS authentication. Purple's hardware-agnostic, cloud overlay platform integrates directly with this architecture, providing the guest and BYOD WiFi layer that sits alongside your certificate-authenticated staff network.

📖 10 min read📝 2,282 words🔧 2 worked examples❓ 3 practice questions📚 9 key definitions

Listen to this guide

View podcast transcript

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.

Key Takeaways

✓SCEP (RFC 8894) automates certificate enrolment 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.

Executive summary

For enterprise venues - whether a 200-room hotel, a 50-site retail chain, or a major conference centre - relying on pre-shared keys for staff WiFi is a security liability and an operational bottleneck. A single leaked password exposes the entire network. Certificate-based authentication via IEEE 802.1X and EAP-TLS (Extensible Authentication Protocol - Transport Layer Security) eliminates that risk entirely. Every device proves its identity cryptographically before the access point grants it network access.

The challenge is distribution. Deploying unique client certificates to thousands of Windows, iOS, and Android devices manually is not viable. SCEP (Simple Certificate Enrollment Protocol), formalised as RFC 8894 by the IETF in 2020, solves this. It automates the process of requesting, issuing, and installing digital certificates on managed devices via your MDM platform - without any user interaction.

This guide covers the full architecture: what SCEP does, how it integrates with Microsoft Intune, Jamf, and other MDM platforms, the exact deployment sequence that most teams get wrong, and the operational pitfalls that cause outages. We also cover two real-world implementation scenarios from hospitality and retail, and explain where Purple's Guest WiFi platform fits alongside your certificate-authenticated staff network.

Listen to the companion podcast briefing:

Technical deep-dive: SCEP, PKI, and 802.1X

What SCEP actually does

SCEP is not a replacement for your Public Key Infrastructure (PKI). It is the automated enrolment layer that sits on top of it. Your PKI - typically a two-tier hierarchy with an offline root CA and an online issuing CA - remains the trust anchor. SCEP automates the step where a device requests a certificate from that CA, removing the need for manual CSR generation and certificate installation.

In the context of WiFi authentication, the target protocol is EAP-TLS. This is the 802.1X authentication method that requires both the client device and the RADIUS server to present valid X.509 certificates. Neither side trusts the other without cryptographic proof. That mutual authentication model eliminates credential theft and protects against evil twin attacks, where an attacker spins up a rogue access point to harvest usernames and passwords.

For a detailed breakdown of the EAP-TLS handshake, see our guide on WiFi Certificate Authentication: Secure Network Access .

The SCEP enrollment flow, step by step

The full enrollment chain works as follows. Your MDM platform - Microsoft Intune, Jamf, or another MDM - pushes a SCEP payload to a managed device. That payload contains two things: the SCEP URL pointing to your NDES (Network Device Enrollment Service) 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 the critical security property of SCEP: the private key is generated on-device, stored in the secure enclave or TPM chip, and never transmitted across the network. The device then creates a Certificate Signing Request (CSR) and sends it to the SCEP gateway. The gateway validates the challenge password, 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 (CRL) to confirm the certificate has not been revoked, and if everything checks out, sends an Access-Accept message to the access point. The device is on the network. The entire process is invisible to the user.

SCEP vs. PKCS: which to use for WiFi

MDM platforms like Intune support two certificate delivery mechanisms: SCEP and PKCS (Public Key Cryptography Standards). The architectural difference is significant.

With SCEP, the private key is generated on the device and never leaves it. With PKCS, the Certificate Authority generates both the public and private key centrally, and the certificate connector pushes the key pair down to the device over the network. That means the private key is transmitted, which introduces a theoretical attack surface.

PKCS is appropriate for use cases where key escrow is required, such as S/MIME email encryption. For WiFi authentication, SCEP is the correct choice. The private key stays on the device.

Property	SCEP	PKCS
Private key generation	On-device (TPM/Secure Enclave)	Centralised (CA)
Private key transmission	Never	Over network
NDES server required	Yes (or cloud gateway)	No
Recommended for WiFi	Yes	No
Recommended for S/MIME	No	Yes

Hardware compatibility

SCEP and EAP-TLS are vendor-neutral standards. They work across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Your RADIUS configuration - whether Windows NPS, FreeRADIUS, or a cloud RADIUS service - is where you define certificate validation policy and dynamic VLAN assignment.

Dynamic VLAN assignment is how you segment the network by device identity. A staff device gets VLAN 10 with access to internal systems. A contractor device gets VLAN 20 with internet access only. A point-of-sale terminal gets VLAN 30 with access to payment processing systems only. All of this is driven by certificate attributes and RADIUS policy, with no manual intervention per device.

For more on how WiFi Analytics integrates with identity-based network segmentation, see our analytics platform overview.

Implementation guide: the deployment sequence

Successfully configuring SCEP for enterprise WiFi requires strict adherence to a specific deployment sequence. MDM platforms enforce profile dependencies: a WiFi profile that references a SCEP certificate cannot apply until that certificate exists on the device. Violating this sequence is the most common cause of deployment failures.

The sequence is: Trusted Root first, SCEP profile second, WiFi profile third. This order is non-negotiable.

Step 1: deploy the Trusted Root Certificate profile

Before any device can request a client certificate or trust your RADIUS server, it must trust the issuing Certificate Authority. Export your Root CA certificate - and any Intermediate CA certificates - as .cer files. In your MDM admin centre, create a Trusted Certificate profile, upload the .cer file, and deploy it to your target device group.

If you have a two-tier PKI hierarchy (recommended), you need to deploy both the root CA and the issuing CA certificates as separate Trusted Certificate profiles, or as a chain in a single profile, depending on your MDM platform.

Step 2: configure the SCEP Certificate profile

Once trust is established, configure the SCEP profile to instruct devices on how to obtain their client certificate.

Create a new configuration profile and select the SCEP certificate profile type. Configure the Subject name format. For user-driven authentication, CN={{UserPrincipalName}} is standard. For device authentication (shared devices, IoT, POS terminals), use CN={{AAD_Device_ID}}. Set Key usage to Digital signature and Key encipherment. Set Extended Key Usage to Client Authentication (OID: 1.3.6.1.5.5.7.3.2). Link this profile to the Trusted Root certificate profile created in Step 1. Provide the external URL of your NDES server.

For Microsoft Intune specifically, the NDES server must be published via Azure AD Application Proxy to allow remote devices to enrol before arriving on-site. Do not expose NDES directly to the internet.

Step 3: deploy the 802.1X WiFi profile

The final step is pushing the WiFi configuration that ties the certificates to the network SSID. Create a Wi-Fi configuration profile. Enter the Network name (SSID) exactly as it is broadcast by your access points. Select WPA2-Enterprise or WPA3-Enterprise as the security type. Set the EAP type to EAP-TLS. In the authentication settings, select the SCEP certificate profile created in Step 2 as the client authentication certificate. Specify the Trusted Root certificate for server validation - this ensures the device only connects to your legitimate RADIUS server and not a rogue access point.

Identity provider integration

SCEP certificate attributes - specifically the Subject Alternative Name (SAN) - can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. This ties the certificate to a specific identity. 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 automated revocation is the security story that pre-shared keys cannot match.

For more on EAP Method WiFi: A Guide to Secure Network Access , including PEAP-MSCHAPv2 migration paths, see our dedicated guide.

Best practices and industry standards

NDES server placement

The NDES server must be accessible from the internet so that devices can enrol before arriving on-site. Publish the NDES URL via Azure AD Application Proxy. This provides secure remote access without opening inbound firewall ports and allows you to apply Conditional Access policies to the enrolment flow. Never expose NDES directly to the internet.

For networks with more than 500 managed 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.

CRL availability

Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point (CDP) is unavailable - because a server is down or the URL has changed - authentication fails for every device on the network simultaneously. Configure your NPS or RADIUS server to enforce strict CRL checking, and make your CRL endpoints highly available. Test revocation before going live.

PCI DSS 4.0 Requirement 8.6 mandates multi-factor authentication at the network layer for cardholder data environments. EAP-TLS with SCEP-provisioned certificates satisfies this requirement for wireless networks in Retail and Hospitality environments.

WPA3 compatibility

EAP-TLS is fully compatible with WPA3-Enterprise. WPA3-Enterprise with the 192-bit security suite (Suite B) mandates EAP-TLS and is the combination recommended by the Wi-Fi Alliance for government, financial, and healthcare networks. If you are deploying in Healthcare or Transport environments with strict compliance requirements, WPA3-Enterprise with EAP-TLS is the correct target architecture.

BYOD and guest WiFi

SCEP requires MDM enrolment to push the certificate payload. It does not cover unmanaged BYOD devices or guests. For those use cases, you need a separate SSID with a captive portal and identity verification. Purple's platform handles that layer cleanly, sitting alongside your certificate-authenticated staff network. Our Guest WiFi platform supports conscious-choice opt-ins, first-party data capture, and integration with Microsoft Entra ID, Okta, and Google Workspace for identity verification.

Troubleshooting and risk mitigation

WiFi profile fails to apply

Symptom: The device receives the Trusted Root and SCEP certificates, but the WiFi profile shows as Error or Not Applicable in the MDM.

Root cause: Group targeting mismatch. If the SCEP profile targets a User group and the WiFi profile targets a Device group, the MDM cannot resolve the dependency.

Fix: Audit your assignments. Ensure the Trusted Root, SCEP, and WiFi profiles all target the exact same directory group.

NDES 403 Forbidden errors

Symptom: Devices fail to retrieve the SCEP certificate. NDES IIS logs show HTTP 403 errors.

Root cause: The MDM Certificate Connector service account lacks Read and Enrol permissions on the certificate template, or firewall URL filtering is blocking SCEP query string parameters.

Fix: Verify the connector account has Read and Enrol permissions on the CA template. Check firewall logs to ensure URLs containing ?operation=GetCACaps are not blocked.

Mass authentication failure after CRL expiry

Symptom: All devices on the network fail to authenticate simultaneously.

Root cause: The CRL has expired or the CDP URL is unreachable. The RADIUS server cannot confirm certificates are valid and fails closed.

Fix: Configure CRL monitoring and alerting. Publish CRLs with a validity period significantly longer than the publication interval. Test CDP reachability from the RADIUS server before go-live.

Certificate expiry causing silent failures

Symptom: Individual devices intermittently fail to connect, with no clear pattern.

Root cause: Client certificates have expired and the MDM has not successfully renewed them.

Fix: Configure certificate renewal to trigger at 80% of the certificate lifetime. Monitor MDM enrolment status reports for devices with certificate errors. Set certificate validity periods appropriate to your device refresh cycle - typically one to two years for managed endpoints.

ROI and business impact

Transitioning to SCEP-based 802.1X certificate authentication delivers measurable returns across security, operations, and compliance.

Helpdesk ticket reduction: Password-based WiFi generates a significant volume of support tickets - password expirations, lockouts, and typos. Certificate-based authentication is invisible to the user. Organisations typically see a 70-80% reduction in WiFi-related helpdesk volume after migration.

Security posture: EAP-TLS eliminates credential harvesting and Man-in-the-Middle attacks. This directly supports PCI DSS 4.0 compliance for retail and hospitality networks, and GDPR Article 32 requirements for appropriate technical security measures.

Automated revocation: When an employee leaves, disabling their account in Microsoft Entra ID triggers automatic certificate revocation and MDM unenrollment. WiFi access is cut without any manual intervention from the network team.

Network segmentation: Dynamic VLAN assignment via RADIUS certificate attributes gives you cryptographically enforced network segmentation. Devices land on the correct network segment based on certificate properties, not SSID selection or MAC address filtering - both of which are trivially bypassed.

Purple operates across 80,000+ live venues with 99.999% uptime, and our platform is ISO 27001, GDPR, CCPA, and Cyber Essentials certified. Our hardware-agnostic cloud overlay integrates with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet - so your certificate-authenticated staff network and our guest WiFi layer work from the same infrastructure.

For more on how Behavioral Analytics: Insights for WiFi Networks can complement your secure network deployment, see our analytics guide.

References

[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

Key Definitions

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 enrolment 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 expiry 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 enrol, configure, secure, and manage smartphones, tablets, and laptops. MDM platforms like Microsoft Intune and Jamf use SCEP profiles to push certificate enrolment 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.

Worked Examples

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.

Examiner's Commentary: 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 enrol 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.

Examiner's Commentary: 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.

Practice Questions

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.

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

View model answer

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.

Hint: 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?

View model answer

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?

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

View model answer

SCEP cannot be used for these devices. SCEP requires an MDM agent to receive the enrolment 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 enrolment 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 (Enrolment 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 enrolment 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.

Continue reading in this series

The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

This technical reference guide provides a definitive architectural blueprint and step-by-step implementation strategy for enterprise WiFi certificate deployment using SCEP. It covers the critical differences between SCEP and PKCS, the exact deployment sequence required for success, and real-world risk mitigation strategies for IT leaders.

The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

How to Implement SCEP for Automated WiFi Certificate Enrollment

This guide explains how to implement SCEP (Simple Certificate Enrollment Protocol) for automated WiFi certificate enrollment across enterprise venues. It covers the full architectural blueprint - from PKI design and MDM integration to the mandatory three-step deployment sequence - and shows IT managers and network architects how to eliminate shared credentials, automate certificate lifecycle management, and satisfy PCI DSS and GDPR requirements at scale.