TL;DR / Key Takeaways
- Enterprise WiFi security is identity-first. A device joining the network proves it belongs to a known user or asset, against an identity provider, before traffic is allowed.
- The three credible authentication models in 2026: WPA3 Enterprise with EAP-TLS (managed workforce), iPSK (IoT and contractors), captive portal with RADIUS (guests). Shared pre-shared keys do not belong in any of them.
- Cloud RADIUS replaces on-prem Windows NPS for most organisations. The exceptions are estates where authentication has to survive WAN failure - distributed retail, remote sites, ships, aircraft.
- The identity provider is the source of truth. Entra ID, Okta, and Google Workspace integrations are first-class; SCIM-driven group sync drives VLAN, ACL, and role assignment at the access point.
- The compliance story (PCI DSS 4.0, HIPAA, ISO 27001:2022, NIST 800-153) is satisfied by the same control set. Build the stack once; pass every audit that asks about wireless.
Most enterprise WiFi networks are still running on a credential model designed when employees worked from one building and IoT meant a wired printer. A single pre-shared key, shared across the workforce, rotated at variable intervals, written on a whiteboard near reception.
That model has been obsolete for a decade. Hybrid working, BYOD, contractor density, and the long parade of IoT make a shared password an unmanaged credential by definition. The leaver risk alone is enough to retire it; PCI DSS 4.0 and ISO 27001:2022 are now explicit that wireless authentication is in scope.
This guide is the technical and operational reference for what replaces the shared password. 802.1X and EAP-TLS for managed devices, iPSK for IoT and contractors, captive portal for guests, and a cloud RADIUS layer that ties all three back to your identity provider. Aimed at IT directors, security architects, and the network engineers who run the deployments.
The four properties of secure enterprise WiFi
A wireless network qualifies as enterprise-grade if it does four things. Networks that do three of them are common; networks that do all four are rare and worth working towards.
Identity-bound authentication
Every device that joins the network is tied to a known user or known asset, authenticated against your directory. No shared credentials, no anonymous joins.
Transmission encryption
WPA3 Enterprise as a minimum. AES-256, forward secrecy, protected management frames (802.11w) on. Transitional WPA2 fallback only where unavoidable.
Authorisation past join
Authentication grants network access; authorisation decides what that access is. Dynamic VLAN, ACL, or SGT assigned from RADIUS attributes - not flat-L2 trust after the password.
Auditable revocation
When a user leaves, when a device is lost, when a contract ends, network access stops within minutes. JML automation, certificate revocation, iPSK rotation - whichever the model is.
The six authentication models
Most organisations end up running two or three of these in parallel: one for managed workforce devices, one for IoT and contractors, one for guests. Mapping the right method to the right population is the first decision.
WPA3 Enterprise
Current standard. 192-bit suite-B mode for sensitive environments. Forward secrecy by default. The destination for any new enterprise SSID.
EAP-TLS
Certificate-based, passwordless. The most secure method available; the one auditors prefer; the one with the highest user-experience score once provisioning is automated.
iPSK
Per-identity pre-shared key, looked up via RADIUS. No supplicant configuration. Per-identity isolation and revocation. Right answer where 802.1X is impractical.
PEAP-MSCHAPv2
Username and password tunnelled inside TLS. Widely deployed, but only safe with strict server-certificate validation on every supplicant. Plan to retire.
Captive portal + RADIUS
Authenticated guest WiFi. Identity comes through a portal sign-in, RADIUS records the session for accounting and policy. The right answer for visitors, not for staff.
Passpoint / OpenRoaming
Device-level certificate trust to a federated identity provider; joining is automatic. The future of public and large-venue WiFi; complementary to the above.
RADIUS: cloud or on-prem?
Every authentication model above runs through a RADIUS layer. RADIUS is the protocol; what changes between vendors and deployment models is where the RADIUS server sits and how it talks to your identity provider.
The dominant on-prem implementations - Microsoft Network Policy Server (NPS) and FreeRADIUS - were designed for an era when authentication latency over a leased line was tolerable and the identity provider was a domain controller in the same rack. Both still run a lot of corporate WiFi. Neither is a comfortable place to be in 2026.
Cloud RADIUS replaces the server-in-the-rack model with a managed service: anycast or multi-region active-active, sub-50ms authentication latency to anywhere, native connectors into Entra ID, Okta, and Google Workspace, automated certificate handling for EAP-TLS. The trade-off is that the WAN now sits between the access point and the auth server.
For most mid-market and a growing share of large-enterprise estates, the trade-off is worth taking. The exceptions are estates where authentication has to survive WAN failure: distributed retail with poor backhaul, remote industrial sites, ships, aircraft. There, on-prem RADIUS or a hybrid local-with-cloud-failover model still has a job. See Purple RADIUS-as-a-Service.
NPS to cloud RADIUS migration
- Export current NPS policy set; translate to the cloud-RADIUS policy model.
- Stand up cloud RADIUS in parallel, bound to the same identity provider.
- Migrate one SSID at a time, or one site at a time. Watch the auth-latency dashboards.
- Switch back-up routes from NPS to local-fallback (if used) before retiring NPS.
- Decommission NPS once the rollback window has closed.
The first three weeks are the entire risk. Plan a long quiet-period rollback option.
Identity provider integration
The identity provider is the source of truth. Group membership, employment status, device posture, and conditional-access policy all live there. The RADIUS layer is the bridge between the access point and the IdP; the value of the integration is what the IdP can decide about each authentication attempt.
Purple integrates natively with:
SCIM provisioning is the operational layer that makes the integration useful. When HR marks a leaver, SCIM propagates the change to the IdP, the IdP propagates to RADIUS, and the user’s WiFi access is removed within minutes. This is the JML automation that ISO 27001 auditors look for; it is also what saves the helpdesk from doing it manually.
Conditional Access (Entra ID) and equivalent policy engines apply at the WiFi join moment. Device posture (compliant, healthy, managed), location, and risk score are all available signals. Used well, they let you enforce “managed corporate devices only on this SSID” without writing a single ACL.
BYOD onboarding and the zero-trust LAN
Personal devices are the second-biggest population on most enterprise WiFi networks. Getting them onto WPA2/3 Enterprise without a helpdesk ticket is the difference between a workable security policy and one that gets routed around.
The pattern that scales is self-service certificate issuance through an onboarding portal. The user signs in with their corporate credentials, the portal generates a per-device certificate, the device installs it via a provisioning profile (iOS, macOS), Group Policy / Intune (Windows, Android), or MDM (corporate-managed devices). The certificate is bound to the user and the device, has a short lifetime, and auto-renews while the user remains an employee.
The zero-trust framing applies here. The WiFi join is the first authentication moment, not the only one. Device posture, network segmentation past the SSID, and continuous verification are the rest of the model. A modern WiFi stack contributes to a zero-trust LAN without needing to be marketed as such; the principles are identity-first authentication, micro-segmentation by role, and explicit-deny defaults. See WPA2 and WPA3 Enterprise and Staff WiFi.
Compliance and audit evidence
Wireless authentication has moved from “supporting control” to “in-scope, explicit” across all four major frameworks. The good news is the same stack satisfies all four; the bad news is the evidence has to be available on demand.
PCI DSS 4.0
Wireless requirements: 4.2.1 (strong cryptography), 11.2 (rogue-AP detection), 8.3 (unique user IDs - no shared passwords on the CDE WLAN). 802.1X with EAP-TLS is the cleanest control.
Reference ›HIPAA Security Rule
§164.312(a)(1) unique user identification, §164.312(b) audit controls, §164.312(d) person or entity authentication. Certificate-based WiFi maps to all three.
Reference ›ISO 27001:2022
Annex A.5.16 identity management, A.8.5 secure authentication, A.5.18 access rights. JML-tied WiFi access with audit trail is the evidence auditors look for.
Reference ›NIST 800-153
Wireless LAN security guidelines. Authentication, transmission encryption, monitoring, configuration management. The reference for US federal and most regulated industries.
Reference ›The three pieces of evidence that auditors ask for, in order: a current access log showing who has WiFi access and on what authentication method; a sample of leaver records demonstrating that access was removed within the documented SLA; and a configuration export of the RADIUS policy showing how each population is segregated. A WiFi stack that cannot produce these in minutes is not audit-ready, regardless of how secure it actually is.
Hardware compatibility
The authentication layer should be hardware-agnostic. Purple’s enterprise security stack runs on the access points you already own.
Every current-generation enterprise access point supports the relevant standards: WPA3 Enterprise, EAP-TLS (RFC 5216), RADIUS (RFC 2865), and dynamic VLAN assignment via vendor-specific attributes. Older equipment (pre-Wave 2 802.11ac) may not; check before committing to an EAP-TLS rollout on it.
How to evaluate an enterprise WiFi security platform
An eight-item checklist for procurement, security, and network teams.
Direct authentication against Entra ID, Okta, or Google Workspace - not a brittle LDAP shim. SCIM-driven group sync.
SCEP / EST / Intune for issuance. Auto-renewal at 30 days, auto-revocation on leaver event. Manual cert handling does not scale past ~200 devices.
Anycast or multi-region active-active. Authentication latency under 50ms. Survives WAN events without bringing the WLAN down.
RADIUS VSAs that drive VLAN, ACL, or SGT. Authorisation must do real work; identity alone is not enough.
Even if not deployed today, the platform should be Passpoint-capable. The transition is starting.
Every join attempt, every failure reason, every policy decision. ISO 27001 and SOC 2 evidence in the dashboard, not a CSV export.
Works with Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet. The authentication layer should outlive the AP refresh.
Parallel-run support during NPS or legacy-RADIUS replacement. Cutover by SSID or by site, not all at once.
Frequently asked questions
What is enterprise WiFi security?
+
Enterprise WiFi security is the umbrella term for the standards, protocols, and operational practices that protect a wireless network used by employees, contractors, and managed devices. The defining difference from consumer WiFi is identity: each user or device is authenticated against a directory rather than sharing a single password.
What is the difference between WPA2 Personal and WPA2 Enterprise?
+
WPA2 Personal uses a single pre-shared key (PSK) - the office WiFi password everyone shares. WPA2 Enterprise uses 802.1X to authenticate each user or device against a RADIUS server backed by your identity provider. WPA3 is the current standard; WPA3 Enterprise replaces the older PSK fallback weaknesses and adds 192-bit suite-B mode for sensitive environments.
What is 802.1X?
+
802.1X is the IEEE port-based network access control standard. A supplicant (the device) authenticates to an authenticator (the access point) which passes credentials to an authentication server (RADIUS). It works the same way on wired and wireless, but enterprise WiFi is where most organisations meet it. EAP-TLS, PEAP, and EAP-TTLS are the methods that run inside the 802.1X envelope.
Is EAP-TLS the same as passwordless WiFi?
+
In practice, yes. EAP-TLS uses a per-user or per-device certificate instead of a password. The user never types a credential; the device presents its certificate to the network and is authenticated against the issuing CA. Most "passwordless WiFi" products are EAP-TLS with managed certificate issuance bolted on top.
Should we still use PEAP?
+
Only with caveats. PEAP-MSCHAPv2 is still widely deployed but has known weaknesses: if the supplicant skips server-certificate validation (a common misconfiguration), a rogue AP can capture credentials and brute-force them offline. PEAP is acceptable as a stopgap during EAP-TLS migration; it should not be a long-term destination for a security-conscious organisation.
What is cloud RADIUS?
+
A managed RADIUS authentication service hosted by a vendor, with the access points connecting over the public internet (TLS-protected, hardened). It replaces the operational burden of running Windows NPS or FreeRADIUS on-premises. The right answer for most mid-market and a growing share of large-enterprise estates; the wrong answer where you need authentication to survive WAN failure.
How do I integrate WiFi with Entra ID, Okta, or Google Workspace?
+
Through a RADIUS layer that speaks to the IdP. For Entra ID, that's typically a cloud RADIUS service authenticating against Entra ID via the OpenID Connect or modern Microsoft Graph integration, plus Intune-issued certificates for EAP-TLS. Okta and Google Workspace follow the same pattern with their respective directory APIs.
What is iPSK and how is it different from 802.1X?
+
iPSK (Identity Pre-Shared Key) issues a unique pre-shared key per user or device, looked up at the access point through RADIUS. It's simpler to deploy than 802.1X (no supplicant configuration on every device) but provides per-identity isolation. iPSK is the right authentication for IoT devices, contractor BYOD, and multi-tenant residential WiFi; 802.1X with EAP-TLS is the right authentication for managed workforce devices.
Does WiFi security have to be part of a zero-trust programme?
+
WiFi authentication is the LAN equivalent of the identity-first principle in zero trust. A modern WiFi stack contributes: identity verification at network join, device posture as a continuous signal, micro-segmentation past the SSID via dynamic VLAN assignment, and revocation tied to the JML process. Calling it 'zero trust' isn't necessary; getting these four right is.
How does this satisfy HIPAA, PCI DSS, and ISO 27001?
+
HIPAA technical safeguards require unique user identification and audit controls; certificate-based WiFi gives you both natively. PCI DSS 4.0 requires authentication for any wireless access to the cardholder data environment and prohibits shared accounts; 802.1X with EAP-TLS is the cleanest path. ISO 27001:2022 Annex A.5.16 (identity management) and A.8.5 (secure authentication) are both addressable with the same stack. We have a full control-mapping cluster post linked from this pillar.