無需 Active Directory 或地端伺服器的企業級 WiFi 驗證

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.

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.

Related reading: Enterprise WiFi Security: A Complete Guide for 2026 - OpenWrt Custom Firmware Integration with Purple WiFi