Enterprise WiFi authentication without Active Directory or an on-prem server

This guide explains how to deploy secure WPA2/3-Enterprise WiFi authentication without an on-premises Active Directory, Windows NPS, or RADIUS server. It covers the protocol mismatch between cloud identity providers and 802.1X, the case for EAP-TLS over PEAP-MSCHAPv2, and how to deploy cloud RADIUS with MDM-issued certificates against Microsoft Entra ID, Okta, or Google Workspace. Written for IT leads at cloud-first and Mac/Chromebook-heavy organisations that are ready to retire on-premises infrastructure.

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

Listen to this guide

View podcast transcript

Hello and welcome to this technical briefing. Today we are tackling a very specific, very common architectural headache: how to run enterprise WiFi authentication when you have moved to the cloud and no longer have an on-premises Active Directory or a Windows NPS server.

If you are an IT manager, a network architect, or a CTO at a cloud-first organisation, you have probably hit this wall. You have migrated your identity to Microsoft Entra ID, Okta, or Google Workspace. Everything is SaaS. But your Cisco, Aruba, or Meraki access points still expect a RADIUS server. And historically, that RADIUS server was a Windows Server running Network Policy Server, or NPS, talking to a domain controller.

So, how do you bridge that gap without spinning up new virtual machines just for WiFi? Let us dive into the technical details.

The core issue here is a protocol mismatch. Entra ID and Okta speak modern web protocols: SAML, OIDC, and OAuth2. Your access points speak RADIUS. Microsoft does not provide a native RADIUS endpoint for Entra ID. You cannot just point your Meraki dashboard at Azure and expect it to work.

Historically, organisations used PEAP-MSCHAPv2 for WiFi. Users typed in their username and password, and the RADIUS server checked that against an NTLM hash stored in Active Directory. Here is the critical failure point: Microsoft Entra ID does not store NTLM hashes. So even if you put a cloud RADIUS server in front of Entra ID, it cannot validate a PEAP password challenge.

To fix this, you have to change the authentication method. You have to move to EAP-TLS.

EAP-TLS uses digital certificates instead of passwords. The device presents an X.509 certificate to the RADIUS server. The RADIUS server checks if that certificate was signed by a trusted Certificate Authority. Because there is no password involved, the RADIUS server does not need an NTLM hash store. It just needs to validate the certificate and check the user's group membership to assign the right VLAN.

This is where the modern architecture comes together. You use a cloud RADIUS service - like Purple - to act as the authentication server. You use your Mobile Device Management platform, like Microsoft Intune or Jamf, to act as the delivery mechanism.

The MDM uses a protocol called SCEP, the Simple Certificate Enrollment Protocol, to silently push device certificates to your managed laptops and phones. The user does nothing. The device connects to the WiFi, presents the certificate to Purple's cloud RADIUS, Purple validates it, checks Entra ID or Okta for the user's group, and tells the access point to drop them onto the correct VLAN.

Let us talk about implementation recommendations and pitfalls.

The biggest recommendation is to embrace SCIM provisioning. Do not rely on periodic directory syncs. SCIM, which stands for System for Cross-domain Identity Management, ensures that when HR disables an employee in Entra ID, that signal is pushed to the cloud RADIUS instantly. Their WiFi access stops the same second their email access stops. That is a significant security improvement.

A common pitfall is certificate lifecycle management. If you issue certificates that expire in one year, you must ensure your MDM is configured to auto-renew them at the ten-month mark. If a certificate expires, the device falls off the network silently, and you will receive a support ticket.

Another pitfall is firewall configuration. Your access points need to reach the cloud RADIUS endpoints. Make sure your outbound rules allow UDP port 1812, or ideally TCP port 2083 if your access points support RadSec, which encrypts the RADIUS traffic over the internet.

Let us do a rapid-fire question and answer session based on the most common questions we see.

Question one: Can I authenticate WiFi against Entra ID directly?
Answer: No. Entra ID does not speak RADIUS. You need a cloud RADIUS service in the middle.

Question two: Do I still need Windows NPS?
Answer: No. A cloud RADIUS service completely replaces NPS. You can decommission those Windows Servers.

Question three: How do cloud-only companies secure staff WiFi?
Answer: By using their MDM to push certificates and authenticating via EAP-TLS against a cloud RADIUS provider.

Question four: What happens to WiFi access when an employee leaves?
Answer: With SCIM provisioning, their access is revoked the moment their account is disabled in the identity provider. No manual intervention required.

To summarise, moving your WiFi authentication to the cloud is the logical next step after moving your identity to the cloud. By deploying cloud RADIUS and EAP-TLS, you eliminate on-premises servers, you remove passwords from the equation, and you tie network access directly to the user's cloud identity. It is more secure, it is easier to manage, and it is highly available by default.

Purple operates cloud RADIUS across 80,000 plus venues globally, with 99.999 percent uptime and native integrations with Microsoft Entra ID, Okta, and Google Workspace. You can be live on your existing Cisco Meraki, HPE Aruba, Ruckus, or Juniper Mist access points in under an hour.

Thank you for listening to this technical briefing. For more detailed deployment guides and to see a live demonstration, visit purple dot ai.

Key Takeaways

✓Microsoft Entra ID, Okta, and Google Workspace do not speak RADIUS. You need a cloud RADIUS service to bridge the gap between access points and cloud identity providers.
✓PEAP-MSCHAPv2 fails in cloud-only environments because cloud identity providers do not store the NTLM password hashes that RADIUS requires for validation.
✓EAP-TLS replaces passwords with MDM-issued X.509 certificates, providing phishing-resistant authentication with no credential to steal.
✓MDM platforms like Microsoft Intune and Jamf Pro deliver certificates silently via SCEP, eliminating manual onboarding and replacing the on-premises Certificate Authority.
✓SCIM provisioning ensures WiFi access is revoked within seconds of an employee being disabled in the identity provider - not hours later after an LDAP sync.
✓Cloud RADIUS removes the need to run Windows NPS servers, eliminating OS patching, high-availability design, and the dependency on on-premises Active Directory.
✓Purple operates cloud RADIUS across 80,000+ venues with 99.999% uptime, supporting Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points.

📚 Part of our core series: Enterprise WiFi security and authentication: the complete guide →

Executive summary

Most organisations have moved their identity to the cloud. Microsoft Entra ID, Okta, and Google Workspace now manage users, groups, and access policies for email, SaaS apps, and device management. But enterprise WiFi has not kept pace. Access points still expect a RADIUS server, and that RADIUS server has historically been Windows Network Policy Server (NPS) connected to an on-premises Active Directory domain controller.

This mismatch forces IT teams to maintain redundant on-premises infrastructure purely to keep the WiFi running. The solution is cloud RADIUS: a fully managed authentication service that speaks RADIUS to your access points and speaks OAuth2, SCIM, and SAML to your cloud identity provider. Pair it with EAP-TLS certificate delivery via your MDM, and you have a complete 802.1X deployment with no on-premises servers, no OS patching, and instant access revocation tied directly to your cloud directory.

Purple operates cloud RADIUS across 80,000+ venues globally, with 99.999% uptime (Purple internal data, 2024) and native integrations with Microsoft Entra ID, Okta, and Google Workspace. You can be live on your existing Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, or Fortinet access points in under an hour.

Technical deep-dive

The protocol mismatch at the heart of the problem

The fundamental challenge is that cloud identity providers and WiFi access points speak entirely different languages. Microsoft Entra ID (formerly Azure AD) authenticates users via SAML, OIDC, and OAuth2 - the protocols that browsers and SaaS apps use. WiFi access points use RADIUS (Remote Authentication Dial-In User Service, RFC 2865), a UDP-based protocol designed in the 1990s for dial-up and VPN. Microsoft has never shipped a native RADIUS endpoint for Entra ID. You cannot point a Meraki or Aruba access point directly at Azure and expect 802.1X to work.

This is the wall that every cloud-first IT team hits when they try to secure Staff WiFi with WPA2-Enterprise or WPA3-Enterprise. Something has to bridge the gap between the access point and the cloud identity provider. That something is cloud RADIUS.

Why PEAP-MSCHAPv2 fails without Active Directory

Historically, 802.1X deployments relied on PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2). The user typed their username and password, the access point forwarded the request to the RADIUS server, and the RADIUS server validated the password against an NTLM hash stored in Active Directory.

Microsoft Entra ID does not store NTLM hashes. This is not a configuration gap - it is a deliberate architectural decision. Entra ID is a modern cloud identity provider, not a domain controller. Consequently, a RADIUS server pointed at Entra ID cannot validate a PEAP-MSCHAPv2 challenge. The only way to make PEAP work with Entra ID is to deploy Entra Domain Services, a paid managed Active Directory that synchronises from Entra ID, and then run NPS against that. This reintroduces most of what you were trying to eliminate: Windows Server VMs, OS patching, NTLM hash storage, and manual certificate management.

EAP-TLS: the right answer for cloud-first organisations

EAP-TLS (Extensible Authentication Protocol-Transport Layer Security, RFC 5216) replaces passwords with X.509 digital certificates. The device presents a certificate to the RADIUS server. The RADIUS server validates the certificate against a trusted Certificate Authority (CA). Because there is no password in the exchange, the RADIUS server does not need an NTLM hash store. It needs only to trust the CA and to check the user's group membership in the identity provider to apply the correct VLAN and access policy.

EAP-TLS is phishing-resistant by design. There is no credential to steal. It satisfies CISA guidance on phishing-resistant multi-factor authentication and aligns with PCI DSS requirements for strong authentication on networks that handle cardholder data. It is the authentication method recommended by IEEE 802.1X for managed device fleets.

Cloud-first 802.1X authentication architecture: devices authenticate via EAP-TLS through Purple's cloud RADIUS, which validates certificates and applies group-based policy from Entra ID, Okta, or Google Workspace.

How MDM replaces the on-premises CA

In a traditional 802.1X deployment, certificates were issued by an on-premises Certificate Authority running Active Directory Certificate Services (AD CS). In a cloud-first deployment, the MDM takes over this role using SCEP (Simple Certificate Enrollment Protocol). Microsoft Intune, Jamf Pro, and other MDM platforms can request certificates from a cloud-hosted CA and push them silently to managed devices.

The flow works as follows. The IT administrator creates a SCEP certificate profile in the MDM, scoped to the device groups that require WiFi access. The MDM pushes the certificate to Windows, macOS, iOS, iPadOS, Android Enterprise, and ChromeOS devices automatically. The user sees nothing. The certificate is bound to the device identity in the MDM and renews automatically before expiry. When the device connects to the WiFi, it presents the certificate to the cloud RADIUS server, which validates it against the CA and applies the correct network policy.

For organisations using Microsoft Intune, Microsoft Cloud PKI provides a fully managed CA that integrates directly with Intune SCEP profiles, eliminating the need for an on-premises NDES (Network Device Enrollment Service) server. For Jamf-managed Mac and iOS fleets, Jamf's built-in CA or a third-party cloud CA serves the same purpose.

SCIM and instant access revocation

One of the most operationally important aspects of cloud RADIUS is SCIM (System for Cross-domain Identity Management) provisioning. SCIM is an open standard that pushes identity changes from the source of truth - your cloud identity provider - to dependent systems in real time. When an employee is disabled in Entra ID or Okta, SCIM pushes that change to the cloud RADIUS service immediately. The next time the device attempts to authenticate, the RADIUS server returns Access-Reject. With a short session timeout configured on the access point, the device is removed from the network within minutes of the account being disabled.

This is a material security improvement over shared PSK networks, where the only way to revoke access is to change the password across every device, and over legacy RADIUS deployments that rely on periodic LDAP syncs with a window of hours or days.

RadSec: securing RADIUS traffic over the internet

Traditional RADIUS uses UDP and provides only basic message authentication. When your RADIUS server is in the same data centre as your access points, this is acceptable. When your RADIUS server is a cloud service, the authentication traffic traverses the public internet. RadSec (RADIUS over TLS, RFC 6614) encrypts the RADIUS exchange using TLS, providing confidentiality and integrity for authentication traffic. Purple supports RadSec natively, with IPsec fallback for access points that do not yet support RadSec.

Implementation guide

Deploying cloud RADIUS with EAP-TLS requires four coordinated steps. A pilot SSID can be live in under an hour if Entra ID and an MDM are already in place.

Step 1: Connect cloud RADIUS to your identity provider

Connect Purple to your identity provider via OAuth2 admin consent (for Entra ID) or API token (for Okta and Google Workspace). This authorises Purple to read users, groups, and group memberships from the directory. Configure SCIM provisioning to push user state changes to Purple in real time. No service principal credentials are stored on disk. Group changes propagate on the next authentication event, not on a sync schedule.

Step 2: Configure your MDM and SCEP profile

In Microsoft Intune, create a Trusted Certificate Profile for the CA root, then create a SCEP certificate profile pointing at the Purple-managed CA. Scope both profiles to the device groups that require WiFi access. For Jamf, configure a SCEP payload in a configuration profile. The MDM pushes the certificates silently. Verify certificate delivery in the MDM compliance dashboard before proceeding.

Step 3: Define network policies in the cloud RADIUS dashboard

Create RADIUS policies that map identity provider groups to specific VLANs and access controls. For example, map the Entra ID group "Staff-Finance" to VLAN 20 with full internet access, and map "Staff-Contractors" to VLAN 30 with time-limited access that expires automatically. Purple's dashboard applies these policies at the point of authentication, with no firewall changes required.

Step 4: Update access point configuration

Update the SSID configuration on your access points to use WPA2-Enterprise or WPA3-Enterprise with 802.1X. Enter the Purple cloud RADIUS primary and secondary endpoint hostnames or IP addresses, along with the shared secret. Configure the access points to use dynamic VLAN assignment based on the RADIUS attributes returned by Purple. Test with a single SSID on a subset of access points before rolling out across the estate.

Cloud RADIUS vs on-premises RADIUS: a direct comparison across deployment time, Active Directory dependency, high availability, OS patching, identity integration, and certificate lifecycle management.

Best practices

These recommendations reflect IEEE 802.1X standards, PCI DSS v4.0 requirements, and operational experience across Purple's 80,000+ venue estate.

Mandate EAP-TLS for managed devices. Passwords are susceptible to phishing and credential stuffing. Certificates provide cryptographic proof of identity and device compliance. EAP-TLS is the only 802.1X method that is phishing-resistant by design.

Use SCIM for instant revocation. Periodic LDAP syncs leave a window where a terminated employee retains network access. SCIM ensures access is revoked the moment the account is disabled in the identity provider.

Deploy multi-region RADIUS. Configure your access points with at least two RADIUS endpoints in different geographic regions. Purple provides active-active multi-region failover by default, with failover completing in seconds.

Segment traffic with dynamic VLANs. Use identity provider group memberships to assign users to specific VLANs dynamically. This isolates sensitive traffic and limits the blast radius of a compromised device without requiring manual firewall changes.

Enable RadSec. If your access points support RadSec, enable it to encrypt authentication traffic between the access point and the cloud RADIUS server. This is particularly important for branch offices and venues where the access point is on an untrusted network segment.

Monitor certificate lifecycle. Set MDM auto-renewal to trigger at 80% of the certificate lifetime. For a one-year certificate, renewal begins at the 10-month mark. Alert on devices that fail to renew before the certificate expires.

For a broader treatment of enterprise WiFi security standards and frameworks, see our Enterprise WiFi Security: A Complete Guide for 2026 .

Troubleshooting and risk mitigation

Transitioning to cloud RADIUS introduces new dependencies. Prepare for these common failure modes before they affect production.

Certificate expiration. If a device certificate expires before the MDM renews it, the device fails authentication silently. The user sees a connection error with no explanation. Mitigate by configuring MDM auto-renewal at 80% of certificate lifetime and monitoring the MDM compliance dashboard for devices with expiring certificates.

MDM sync failures. A device that falls out of MDM compliance or fails to check in may not receive a renewed certificate. Implement compliance policies that flag unhealthy devices and alert administrators before the certificate expires.

Firewall blocking RADIUS traffic. The access points must reach the cloud RADIUS endpoints on UDP port 1812 (authentication) and UDP port 1813 (accounting), or TCP port 2083 for RadSec. Outbound firewall rules at branch offices frequently block these ports. Test reachability from the access point management VLAN before deployment.

SCIM provisioning failures. If the SCIM connection between the identity provider and Purple is interrupted, user state changes will not propagate. Monitor SCIM sync status in both the identity provider and the Purple dashboard. Configure alerting for sync failures.

Legacy devices without certificate support. IoT devices, printers, and older hardware may not support EAP-TLS. For these devices, use iPSK (individual pre-shared keys) rather than a shared PSK. Purple supports iPSK natively, assigning a unique key per device and placing each device on the correct VLAN without requiring 802.1X supplicant support.

ROI and business impact

Migrating from on-premises RADIUS to cloud RADIUS delivers measurable value across infrastructure, operations, and security.

Dimension	On-premises NPS	Cloud RADIUS (Purple)
Infrastructure cost	Windows Server licences, VM compute, storage	Per-AP subscription, no server hardware
Time to deploy	Days to weeks	Under one hour
High availability	Manual - two servers plus replication	Multi-region active-active, default
OS patching	Monthly, your team	Vendor-managed
WiFi helpdesk tickets	High - password resets, manual onboarding	Down 80% (Purple customer data)
Access revocation	Hours to days via LDAP sync	Seconds via SCIM

IT teams using Purple's Staff WiFi typically see WiFi support tickets drop by 80% (Purple internal data, 2024), driven by the elimination of password resets and manual device onboarding. Certificate-based authentication also satisfies PCI DSS requirement 8.3 for strong authentication and ISO 27001 control A.9.4 for system and application access control, reducing the audit burden on your security team.

For organisations in retail and hospitality , the ability to manage Staff WiFi and Guest WiFi from a single cloud dashboard - with a unified identity layer - reduces operational complexity across multi-site estates. For transport operators and healthcare providers, the instant revocation capability and full audit trail satisfy regulatory requirements without additional tooling.

Purple's WiFi Analytics layer adds occupancy and hybrid working data on top of the authentication infrastructure, turning Staff WiFi from a cost centre into a source of operational intelligence.

Key Definitions

802.1X

An IEEE standard (IEEE 802.1X-2020) for port-based network access control. It requires devices to authenticate before the access point grants network access, using an EAP exchange mediated by a RADIUS server.

IT teams use 802.1X to ensure only authorised users and devices connect to the corporate network. It provides per-user encryption, per-session keys, and a full audit trail of every connection event.

RADIUS

Remote Authentication Dial-In User Service (RFC 2865). A networking protocol that provides centralised Authentication, Authorization, and Accounting (AAA) management for network access.

Access points forward every connection request to the RADIUS server, which decides whether to admit the device and which VLAN to assign it to. Cloud RADIUS replaces on-premises NPS or FreeRADIUS servers.

EAP-TLS

Extensible Authentication Protocol-Transport Layer Security (RFC 5216). An 802.1X authentication method that uses mutual X.509 certificate exchange instead of passwords.

EAP-TLS is the gold standard for managed device fleets. It is phishing-resistant, requires no password hash store, and is the only 802.1X method that satisfies CISA phishing-resistant MFA guidance.

PEAP-MSCHAPv2

Protected Extensible Authentication Protocol with Microsoft Challenge Handshake Authentication Protocol version 2. A legacy 802.1X method that validates passwords against NTLM hashes stored in Active Directory.

PEAP-MSCHAPv2 fails in cloud-only environments because Entra ID does not store NTLM hashes. Organisations migrating from on-premises AD must replace PEAP with EAP-TLS.

SCEP

Simple Certificate Enrollment Protocol. A protocol used by MDM platforms to request and install digital certificates on devices automatically, without user interaction.

IT teams use SCEP with Intune or Jamf to silently provision WiFi certificates to employee devices. SCEP replaces the on-premises NDES (Network Device Enrollment Service) server in cloud-first deployments.

SCIM

System for Cross-domain Identity Management (RFC 7644). An open standard that automates the real-time exchange of user identity information between IT systems.

SCIM ensures that when an employee is disabled in Entra ID or Okta, that change is pushed to the cloud RADIUS service immediately, revoking WiFi access within seconds rather than hours.

NPS

Network Policy Server. Microsoft's RADIUS implementation, typically run on Windows Server as part of an on-premises Active Directory environment.

Cloud-first organisations are retiring NPS to eliminate Windows Server VMs, OS patching, and the dependency on on-premises Active Directory. Cloud RADIUS is the direct replacement.

RadSec

RADIUS over TLS (RFC 6614). A protocol that encrypts RADIUS authentication traffic using TLS, replacing the UDP-based cleartext transport used by traditional RADIUS.

RadSec is essential when using cloud RADIUS, as authentication traffic must traverse the public internet between the access point and the cloud service. Purple supports RadSec natively.

iPSK

Individual Pre-Shared Key. A variant of WPA2-Personal that assigns a unique pre-shared key to each device, rather than a single shared key for all devices.

iPSK is used for IoT devices, printers, and other hardware that cannot support 802.1X EAP-TLS. It provides per-device accountability and VLAN assignment without requiring certificate support.

Dynamic VLAN

A network segmentation technique where the RADIUS server returns a VLAN identifier in the Access-Accept response, and the access point places the device on that VLAN automatically.

Dynamic VLANs allow IT teams to segment staff, contractors, IoT devices, and guests onto separate network segments based on identity provider group membership, without manual firewall changes.

Worked Examples

A 400-site retail chain needs to secure Staff WiFi across all locations. They run Cisco Meraki access points and use Microsoft Entra ID with Intune for device management. They currently use a shared WPA2-Personal PSK because they have no on-premises Active Directory to run NPS. A recent internal audit flagged the shared PSK as a PCI DSS compliance gap.

The chain deploys Purple's cloud RADIUS. First, they connect Purple to Entra ID via OAuth admin consent and configure SCIM provisioning. In Intune, they create a Trusted Certificate Profile for the Purple CA root and a SCEP certificate profile scoped to the 'Staff-Retail' device group. Intune silently pushes certificates to all managed point-of-sale terminals and staff tablets. In the Meraki dashboard, they update the Staff SSID to WPA2-Enterprise, enter the Purple cloud RADIUS primary and secondary endpoints, and enable dynamic VLAN assignment. When a device connects, it presents its Intune-issued certificate, Purple validates it against the CA and checks the Entra ID group, and the device is placed on VLAN 10 (staff network) or VLAN 20 (management network) based on group membership. The shared PSK is retired. Rollout across 400 sites takes one weekend, as no on-site hardware is deployed - only SSID configuration changes in Meraki.

Examiner's Commentary: This approach eliminates the shared PSK, providing per-device accountability and per-session encryption keys. Each authentication event is logged with user, device, AP, and SSID, satisfying PCI DSS requirement 10.2 for audit logs. By leveraging Intune SCEP and cloud RADIUS, the chain achieves 802.1X security without deploying any on-premises servers at any of its 400 locations. The alternative - deploying NPS VMs at each site or in a hub-and-spoke topology - would require weeks of infrastructure work and ongoing patching.

A 15,000-student university uses Google Workspace as its primary identity provider. The IT team wants to provide secure WiFi for staff and students on a BYOD estate of MacBooks, Chromebooks, and Android phones. They have no on-premises Active Directory and no appetite to run servers.

The university integrates Purple's cloud RADIUS with Google Workspace. For managed Chromebooks, they use Google Admin to push a WiFi certificate profile via SCEP, silently enrolling each device. For BYOD MacBooks and Android phones, they deploy a lightweight onboarding application that authenticates the user with their Google credentials and installs a certificate on the device in a single tap. Subsequent connections use EAP-TLS silently. Purple maps Google Workspace Organisational Units to VLANs: staff land on VLAN 10, students on VLAN 20, and guest visitors on a captive portal SSID. When a student graduates and their Google account is suspended, SCIM pushes the change to Purple and their WiFi access is revoked within minutes.

Examiner's Commentary: This solution provides secure 802.1X for a mixed managed and BYOD estate without requiring Active Directory. The onboarding application handles the certificate provisioning complexity for BYOD devices, which cannot be managed via MDM. The Google Workspace SCIM integration ensures that the WiFi estate stays aligned with the university's directory without manual intervention. This pattern is in production at the University of Sheffield, University of Leeds, and University of the Arts London, all Purple customers.

Practice Questions

Q1. Your organisation has fully migrated from on-premises Active Directory to Microsoft Entra ID. Your current Staff WiFi uses PEAP-MSCHAPv2 against an NPS server that was joined to the old domain. After decommissioning the domain controller, staff report they can no longer connect to the WiFi. What is the root cause, and what is the correct long-term fix?

Hint: Consider what PEAP-MSCHAPv2 requires from the directory, and whether Entra ID provides it.

View model answer

The root cause is that PEAP-MSCHAPv2 requires the RADIUS server to validate the user's password against an NTLM hash stored in Active Directory. With the domain controller decommissioned, NPS has no directory to validate against. Entra ID does not store NTLM hashes, so NPS cannot be redirected to Entra ID. The correct long-term fix is to replace NPS with a cloud RADIUS service, migrate from PEAP-MSCHAPv2 to EAP-TLS, and use the MDM (Intune) to issue device certificates via SCEP. This eliminates the dependency on any on-premises directory.

Q2. You are deploying cloud RADIUS for a 200-device fleet of corporate MacBooks managed by Jamf Pro. Your identity provider is Okta. What is the most secure and operationally efficient way to provision the WiFi credentials to these devices?

Hint: Look for a method that requires no user interaction, avoids passwords, and integrates with your existing MDM.

View model answer

Configure Jamf Pro to use SCEP to silently push device certificates to the MacBooks. Create a SCEP payload in a Jamf configuration profile, pointing at the CA managed by your cloud RADIUS provider. Scope the profile to the relevant device group. Jamf will push the certificate to each MacBook automatically, with no user interaction. Configure the WiFi profile in the same configuration profile to use EAP-TLS with the SCEP-issued certificate. Connect the cloud RADIUS service to Okta via SCIM to ensure that when an employee is disabled in Okta, their WiFi access is revoked immediately.

Q3. An employee is terminated at 9am on a Monday. Their Entra ID account is disabled by HR at 9:05am. At 9:30am, a security alert shows the employee's laptop is still connected to the corporate WiFi from the car park. What configuration is missing, and how do you fix it?

Hint: How does the RADIUS server learn that the user's status has changed in the identity provider?

View model answer

The deployment is relying on periodic LDAP syncs rather than SCIM provisioning. The LDAP sync has not yet run since the account was disabled, so the cloud RADIUS service still considers the user active. The fix is to enable SCIM provisioning between Entra ID and the cloud RADIUS service. SCIM pushes user state changes in real time, so when the account is disabled in Entra ID at 9:05am, the RADIUS service receives the change immediately. The next time the device attempts to re-authenticate (controlled by the session timeout on the access point), it receives an Access-Reject. Setting a short session timeout (15 to 30 minutes) on the access point limits the maximum window between account disable and network eviction.

Q4. Your venue has 50 IoT devices - digital signage players, environmental sensors, and printers - that do not support 802.1X EAP-TLS. How do you secure these devices on the same WiFi infrastructure as your EAP-TLS staff network?

Hint: Consider what authentication method provides per-device accountability without requiring certificate support.

View model answer

Use iPSK (individual pre-shared keys) for the IoT devices. Assign a unique pre-shared key to each device in the cloud RADIUS dashboard, along with a VLAN assignment. Each device authenticates with its unique key, which the RADIUS server validates and uses to place the device on the IoT VLAN, isolated from the staff network. If a device is compromised or decommissioned, you revoke only that device's key without affecting any other device. This approach provides per-device accountability and network segmentation without requiring 802.1X supplicant support on the IoT hardware.

Continue reading in this series

How to revoke WiFi access when an employee leaves

This guide details how to revoke WiFi access when an employee leaves, replacing insecure shared passwords with per-user 802.1X certificates or iPSK. It covers automated deprovisioning via SCIM to meet ISO 27001 and SOC 2 audit requirements.

Google Workspace WiFi Authentication: Chromebook and LDAP Integration

A definitive technical reference for IT administrators deploying secure WiFi in Google Workspace environments. This guide covers 802.1X certificate deployment to managed Chromebooks via Google Admin Console, Google Secure LDAP integration as a RADIUS backend, and architecture decisions for education, media, and enterprise venues. It provides actionable implementation steps, real-world case studies, and a direct comparison of EAP methods to help teams move from vulnerable shared PSKs to robust, identity-based network access control.