Most wireless LAN tenders are scored on coverage maps and throughput, and the security questions get a single line about "WPA3 support". That leaves the decisions that actually decide your exposure untested: whether 6 GHz and Wi-Fi 7 clients will run without legacy modes, how the platform hands identity to your RADIUS and NAC stack, how rogue and evil twin access points are found, and who can log in to the cloud controller that now runs every site. This vendor-neutral buyer's guide gives network and security teams the requirements, evaluation criteria, vendor questions and proof of concept steps for choosing an enterprise WLAN platform. For day-to-day configuration once you have bought, see the Wi-Fi Security Guide.
Key takeaways
- Buy for WPA3-only operation. The 6 GHz band does not permit WPA2, and Wi-Fi 7 features such as multi-link operation depend on WPA3, GCMP-256, Protected Management Frames and Beacon Protection, so test those modes rather than accepting a datasheet tick.
- The controller is the crown jewel. A cloud management console or on-premises controller can reconfigure every access point at once; score its administrator authentication, role model, API keys and audit logs as hard requirements.
- Identity integration decides the outcome. 802.1X with EAP-TLS, RADIUS Change of Authorization, RadSec and clean NAC hand-off matter more than any single radio feature.
- Wireless intrusion prevention needs evidence. Ask how rogue, neighbour and evil twin access points are classified, how many sensors are needed, and what containment is legal and safe in your sites.
- Run a proof of concept with your own clients. Old scanners, medical devices and headless IoT are where WPA3 transition and certificate plans fail.
Define requirements
Write requirements before you meet vendors, and separate security requirements from radio performance. Start from an inventory of SSIDs, security modes, EAP methods and client models, then decide what the new platform must support on day one and what it must support within the contract term.
- Security modes: WPA3-Enterprise on corporate SSIDs, with 192-bit mode (GCMP-256 with the Suite B 192-bit AKM) if you handle classified or highly sensitive data; WPA3-Personal with SAE Hash-to-Element (H2E) for any pre-shared key SSID; Wi-Fi Enhanced Open (OWE) for guest. The Wi-Fi Alliance states that PMF is required for all new certified devices and that WPA3 networks require PMF.
- Bands and generations: which sites need 6 GHz and Wi-Fi 7 (320 MHz channels, multi-link operation) now, and how long 2.4 GHz legacy clients must be tolerated, on an isolated SSID with an end date.
- Identity and access: your RADIUS servers, certificate authority, MDM, NAC and identity provider; whether you need per-user or per-device VLAN and role assignment, dynamic ACLs and posture checks.
- Management model: cloud managed, on-premises controller, or both; data residency for telemetry; air-gapped or regulated sites that cannot depend on a cloud console.
- Monitoring: wireless intrusion detection and prevention (WIDS/WIPS) coverage per site, SIEM export format and retention, and who in the SOC owns wireless alerts. See the Wireless intrusion detection guide.
- Machine identities: API keys and service accounts the platform will use to talk to NAC, ticketing, SIEM and automation, and how those are scoped and rotated.
Capability areas
| Capability area | What good looks like | What to verify |
|---|---|---|
| WPA3 and 6 GHz | WPA3-only SSIDs on 6 GHz with H2E; OWE guest without transition mode in 6 GHz; Wi-Fi 7 profiles with GCMP-256, PMF and Beacon Protection | Which client types lose multi-link operation when CCMP-128 is allowed for compatibility; how transition modes are scoped per band |
| 802.1X and NAC integration | EAP-TLS (including TLS 1.3 per RFC 9190), RADIUS CoA and Disconnect (RFC 5176, UDP 3799), RadSec (RFC 6614), standard attributes for VLAN and role | Interoperability with your NAC and RADIUS servers, fail-open or fail-closed behaviour when RADIUS is unreachable |
| WIDS and WIPS | Dedicated or time-sliced sensors scanning all channels including DFS and 6 GHz; rogue classification by wired-side correlation; evil twin and deauthentication detection | Sensor density per site, false positive rate, containment controls and logging |
| Controller and cloud security | SSO with phishing-resistant MFA, granular roles scoped by site, immutable audit log of configuration changes and sign-ins, signed firmware | Break-glass process, local admin accounts on APs and switches, vendor support access |
| APIs and automation | Scoped, expiring API keys or OAuth clients per integration, per-key audit trail, rate limits | Whether one key can change every site; how keys are revoked |
| Segmentation | Role-based policy that follows the user or device, client isolation on guest and IoT SSIDs | Policy enforcement point (AP, controller or switch) and how it is audited |
| Vulnerability and patch handling | Published vulnerability disclosure policy, CVE records with CWE data, staged firmware rollout and rollback | Patch cadence history and time from disclosure to fixed firmware |
Evaluation criteria
Weight the criteria to your risk. A hospital with thousands of headless devices will weight client compatibility and NAC higher; a multi-site retailer will weight cloud controller security and automation higher.
| Criterion | Suggested weight | Evidence to request |
|---|---|---|
| Security mode support (WPA3, 192-bit, H2E, OWE, Beacon Protection) | 20% | Configuration guide pages and a live demonstration on your test clients |
| Identity and NAC interoperability | 20% | Tested integration with your RADIUS, NAC and MDM; CoA round trip in the PoC |
| Management plane security | 20% | Admin authentication options, role matrix, audit log sample, API key model |
| WIDS/WIPS effectiveness | 15% | Detection of a planted rogue and a spoofed SSID in the PoC, alert sample in your SIEM |
| Logging and SOC integration | 10% | Syslog or API export format, event list, retention, time synchronisation |
| Vendor security practice | 10% | Vulnerability disclosure policy, advisory history, firmware signing, secure by design commitments |
| Operational fit | 5% | Staged rollout, rollback, change approval workflow |
Map the selected platform to your control framework while you score: NIST SP 800-53 AC-18 Wireless Access and AC-18(1) Authentication and Encryption, SI-4(14) Wireless Intrusion Detection, SC-40 Wireless Link Protection and IA-3 Device Identification and Authentication; NIST CSF 2.0 PR.AA-01 and PR.PS-01. NIST SP 800-153 remains the baseline guidance for securing WLANs. On the threat side, MITRE ATT&CK lists Wi-Fi Networks (T1669) as an initial access technique and Evil Twin (T1557.004) under adversary-in-the-middle.
Questions to ask vendors
- Show a WPA3-only SSID on 6 GHz with H2E, then show what our oldest supported client sees on the same site. Which settings would you change to keep it connected, and what security does that remove?
- For Wi-Fi 7, which cipher and AKM combinations do you enforce, and which do you relax for compatibility? Is Beacon Protection on by default?
- How do you implement 192-bit WPA3-Enterprise, and which access point models and deployment modes do not support it?
- Demonstrate a RADIUS Change of Authorization moving a device from a quarantine role to a full-access role. What happens to connected clients if every RADIUS server is unreachable?
- Do you support RADIUS over TLS, and what is your plan for removing MD5 from RADIUS as described in RFC 9765 (RADIUS/1.1)?
- How does your WIPS tell a rogue access point plugged into our network from a neighbour's? How many sensors per site do you assume for that claim?
- Which administrator sign-in methods are supported, can we enforce SSO and phishing-resistant MFA for every account including your support staff, and can roles be limited to a single site?
- How are API keys issued, scoped, expired and logged? Can a key be read-only, site-scoped, and revoked without breaking other integrations?
- What exactly is in the audit log: configuration diffs, sign-ins, API calls, support sessions? How long is it retained and how is it exported?
- How is firmware signed and verified on the access point, and how do we stage and roll back a release?
- Where is telemetry such as client MAC addresses, usernames and location data stored, and for how long?
Red flags
- WPA3 described as supported but only demonstrated in transition mode, or 6 GHz shown with WPA2 clients "working".
- Shared default credentials on access points or controllers, or a local admin account that cannot be disabled.
- No way to enforce MFA on the cloud console, or vendor support access that bypasses your identity provider and is not logged.
- One organisation-wide API key with full write access and no expiry.
- WIPS claims with no stated sensor density, and automatic containment enabled by default without legal review.
- No published vulnerability disclosure policy or no CVE records for past firmware flaws.
- Audit logs that record "configuration changed" without who, what and from where.
Proof of concept
- Build a lab or pilot site with your real client mix: corporate laptops, phones, scanners, printers, medical or OT devices and a 6 GHz capable client.
- Configure WPA3-Enterprise with EAP-TLS against your RADIUS and certificate authority, a WPA3-Personal H2E SSID and an OWE guest SSID; record which clients fail and why.
- Test NAC: posture failure, CoA to quarantine, CoA back to full access, and behaviour with RADIUS offline.
- Plant a rogue access point on the wired network and broadcast a spoofed corporate SSID nearby; measure time to detect, classification accuracy and alert delivery to your SIEM.
- Test the management plane: SSO and MFA enforcement, a site-scoped role, a read-only API key, revocation of a key, and an exported audit log showing each change.
- Run a firmware upgrade and rollback on a subset of access points and confirm configuration integrity.
- Score results against the evaluation table and keep the evidence for the contract and for audit.
For rollout after selection, the 802.1X and EAP-TLS Enterprise Wi-Fi Guide covers certificate profiles and supplicant settings, and the Top 10 Wireless Network Security Risks page is a useful threat checklist for the acceptance test.
How NHI Mgmt Group can help
We provide independent advice on network access, machine identity and management plane security, including review of requirements and proof of concept plans. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Wi-Fi Security Guide · 802.1X and EAP-TLS Enterprise Wi-Fi Guide · Wireless intrusion detection · Wireless Penetration Testing Guide