Skip to main content
English (US)

How to set up a RADIUS server for WiFi authentication: Step-by-step 802.1X guide

Configure FreeRADIUS, Windows Server NPS, and Cloud RADIUS for enterprise 802.1X WiFi authentication. Step-by-step guide covering shared secrets, EAP-TLS certificates, dynamic VLAN assignment, and Microsoft Entra ID integration.

By Iain JewittPublished
📖 8 min read1,563 words2 worked examples3 practice questions5 key definitions

Video overview

Listen to this guide

View podcast transcript
Welcome to Purple's Technical Briefing. Today we are tackling a critical infrastructure decision for any enterprise IT leader: how to set up a RADIUS server for WiFi authentication. If you are managing a large-scale deployment — whether that is a hotel chain, a retail network, or a sprawling university campus — relying on a simple pre-shared key is a significant security risk. We need 802.1X, and that means we need RADIUS. Let's start with the context. RADIUS, or Remote Authentication Dial-In User Service, acts as the gatekeeper for your network. When a device tries to connect to a WiFi access point, the access point acts as an authenticator and forwards the credentials to the RADIUS server. The server checks those credentials against a directory — like Active Directory or an LDAP database — and then returns an accept or reject message. It is the foundation of enterprise WiFi security, and it is the mechanism that allows you to enforce granular access policies at scale. Now let's move into the technical deep-dive. The first major architectural decision you will face is choosing between an on-premise RADIUS server and a cloud-hosted solution. Historically, on-premise solutions like Microsoft's Network Policy Server, or NPS, or the open-source FreeRADIUS were the standard. They offer complete control over the infrastructure and do not rely on an external internet connection for authentication. However, they require dedicated hardware, ongoing maintenance, and manual configuration of redundancy. If you have a single data centre and a well-staffed IT team, this is a perfectly valid approach. On the other hand, cloud RADIUS solutions have become increasingly popular, especially for distributed environments like retail chains or hospitality venues. Cloud RADIUS abstracts the hardware management entirely, offers built-in high availability, and integrates seamlessly with cloud identity providers like Azure Active Directory or Okta. The trade-off is that authentication requires a reliable internet connection, and there is an ongoing subscription cost. For a venue operator running fifty or a hundred locations, the operational savings from not deploying and maintaining on-premise servers at each site will almost certainly outweigh that cost. When deploying RADIUS, the Extensible Authentication Protocol — EAP — is the critical piece. It defines how the client and server negotiate and perform the authentication. EAP-TLS is the gold standard for security because it uses digital certificates on both the client and the server, eliminating the need for passwords entirely. This means even if an attacker captures the authentication exchange, there are no credentials to steal. However, deploying client certificates can be administratively heavy. You need a Public Key Infrastructure and an MDM solution to push certificates to every device. PEAP-MSCHAPv2 is the most common alternative. It uses a server-side certificate to establish an encrypted TLS tunnel, inside of which the user authenticates with a username and password. This is significantly easier to deploy than EAP-TLS because you only need to manage one certificate — the server's. However, and this is critical — if clients are not strictly configured to validate the server's certificate, they are vulnerable to rogue access points. An attacker can stand up a fake access point, present a fraudulent certificate, and capture credentials. This is not a theoretical attack. It is a well-documented real-world threat. Let's talk implementation recommendations and pitfalls. The first recommendation is to enforce strict certificate validation on every client device. Use Group Policy Objects for Windows devices and MDM profiles — whether that is Intune, Jamf, or another solution — for macOS and mobile devices. The profile must specify exactly which Certificate Authority to trust and what the expected server name is. Do not leave this to the end user to configure manually. The second recommendation is to implement dynamic VLAN assignment. Instead of putting all authenticated users on the same flat network, configure the RADIUS server to instruct the access point to place the user on a specific VLAN based on their group membership in the directory. This is essential for segmenting corporate devices from BYOD or guest devices. A staff member in the finance team should be on a different network segment than a contractor visiting for the day. The third recommendation concerns guest access. For venues that need to provide WiFi to visitors — hotels, retail stores, conference centres — integrating your RADIUS infrastructure with a captive portal solution like Purple's Guest WiFi platform is a powerful combination. Staff and corporate devices authenticate silently via 802.1X, while guests are directed to a branded portal for authentication. Purple's platform then captures first-party data and provides analytics on visitor behaviour, turning your network from a cost centre into a business intelligence asset. Now for a rapid-fire question and answer session. First question: Do I need a dedicated server for RADIUS? For on-premise deployments, yes, it is highly recommended to run it on a dedicated virtual machine rather than sharing resources with a domain controller. Authentication is a latency-sensitive operation, and resource contention can cause intermittent failures that are very difficult to diagnose. Second question: Can RADIUS handle authentication for headless devices like printers or IoT sensors? Yes, through MAC Authentication Bypass, or MAB. This allows devices without 802.1X capabilities to be authenticated based on their MAC address. However, because MAC addresses are easily spoofed, MAB-authenticated devices should always be placed on a highly restricted VLAN. Third question: How do I handle RADIUS server redundancy? Always deploy at least two RADIUS servers — a primary and a secondary. Configure all access points to fail over to the secondary if the primary becomes unreachable. For cloud RADIUS, this redundancy is typically built in and managed by the provider. To summarise the key takeaways from today's briefing. Pre-shared keys are not acceptable for enterprise WiFi. Implement 802.1X. Choose your deployment model — on-premise or cloud — based on your IT resources, the number of locations you are managing, and your existing identity infrastructure. If you are distributed and cloud-first, cloud RADIUS is almost certainly the right answer. Enforce strict certificate validation on clients. This is non-negotiable. Use dynamic VLAN assignment to segment your network. And finally, consider how your authentication infrastructure can integrate with broader platforms to deliver business value beyond simply controlling access. For further reading, we recommend exploring Purple's guides on configuring 802.1X WiFi authentication and securing your network with strong DNS policies. Thank you for listening.

Part of our core series: Enterprise WiFi Security Guide →

Interactive Network Tool

RADIUS Server Setup & 802.1X Architecture Configurator

Model your enterprise RADIUS deployment: configure Identity Provider sync, EAP authentication methods, dynamic VLAN attributes, and firewall ports.

Architectural Blueprint

Cloud-Native 802.1X Architecture

Security & ComplianceMaximum Enterprise Security (A+)
Est. Admin Overhead9 hrs/year
Network Protocol & Ports: RadSec (TCP 2083 with TLS) & UDP 1812/1813
RadSec TLS Support: Yes (Encrypted RADIUS over TLS)
BlastRADIUS (CVE-2024-3596) Hardening: Protected (Message-Authenticator)
Dynamic VLAN Attributes: Tunnel-Type=13, Tunnel-Medium-Type=6, Tunnel-Private-Group-ID

Architecture Insight: Eliminate shared PSKs by pushing device certificates via Microsoft Intune or Jamf. EAP-TLS with Cloud RADIUS removes local server maintenance while enforcing strict role-based VLAN segmentation.

Executive summary

How to set up a RADIUS server for WiFi authentication: Step-by-step 802.1X guide

Enterprise wireless networks require centralized identity management, role-based segmentation, and strong cryptographic protection. Relying on shared Pre-Shared Keys (PSKs) exposes organizations to credential leaks, unauthorized device access, and administrative nightmares whenever an employee leaves.

Setting up a RADIUS (Remote Authentication Dial-In User Service) server enables IEEE 802.1X enterprise authentication. Every connecting device and user authenticates individually against a central directory - such as Microsoft Entra ID, Google Workspace, Okta, or on-premises Active Directory.

This technical guide provides step-by-step deployment instructions for configuring a RADIUS server for enterprise WiFi. We cover Linux FreeRADIUS configuration, Windows Server Network Policy Server (NPS) setup, modern Cloud RADIUS architectures, dynamic VLAN assignment, and BlastRADIUS security hardening.

802.1X & RADIUS architecture overview

The IEEE 802.1X framework divides network access into three distinct entities:

  1. The Supplicant: The client endpoint (laptop, smartphone, or tablet) running 802.1X client software that presents identity credentials.
  2. The Authenticator: The wireless access point (AP) or Wireless LAN Controller (WLC) that controls physical access to the network and relays authentication messages.
  3. The Authentication Server: The RADIUS server that validates credentials against an identity directory and returns network authorization policies.
+---------------+        EAP over LAN (EAPoL)        +-------------------+
|  Supplicant   | <================================> |   Authenticator   |
| (Client Device)|                                    | (AP / Controller) |
+---------------+                                    +-------------------+
                                                               ||
                                                               || RADIUS Protocol
                                                               || (UDP 1812 / TCP 2083)
                                                               \/
                                                     +-------------------+
                                                     |   RADIUS Server   |
                                                     |  (FreeRADIUS/NPS) |
                                                     +-------------------+
                                                               ||
                                                               || Identity Lookup
                                                               \/
                                                     +-------------------+
                                                     | Identity Provider |
                                                     | (Entra ID / LDAP) |
                                                     +-------------------+

RADIUS communication flow

  1. Association: The client associates with the enterprise SSID (WPA2-Enterprise or WPA3-Enterprise).
  2. EAP initiation: The AP blocks all data traffic and sends an EAP-Request/Identity frame to the client.
  3. Identity response: The client responds with an EAP-Response/Identity frame.
  4. RADIUS encapsulation: The AP encapsulates the EAP payload into a RADIUS Access-Request packet and forwards it to the RADIUS server.
  5. EAP negotiation: The client and RADIUS server negotiate the cryptographic authentication method (such as EAP-TLS or PEAP).
  6. Authorization & Access-Accept: Upon successful validation, the RADIUS server issues a RADIUS Access-Accept packet containing the Pairwise Master Key (PMK) and optional dynamic VLAN assignment attributes.
  7. Port open: The AP unblocks the virtual port and initiates the 4-way handshake to encrypt wireless traffic over the air.

For deeper architectural concepts, explore our Enterprise WiFi Security Guide and Captive Portal Guide.

Step-by-step setup: FreeRADIUS on Linux

FreeRADIUS is the world open-source RADIUS suite standard. Below is the configuration sequence for Ubuntu 24.04 LTS / Debian 12.

Step 1: Install FreeRADIUS packages

sudo apt update
sudo apt install -y freeradius freeradius-utils freeradius-ldap ssl-cert

Step 2: Define Network Access Server (NAS) clients

Edit /etc/freeradius/3.0/clients.conf to authorize your wireless access points and configure a shared secret:

client enterprise_wlan {
  ipaddr: 192.168.10.0/24
  secret: Str0ngSh@redSecr3t2026!
  shortname: branch-aps
  nas_type: other
  require_message_authenticator: yes
}

Note: Always enforce RFC 2869 Message-Authenticator attributes to defend against BlastRADIUS forgery attacks.

Step 3: Configure EAP authentication modules

Open /etc/freeradius/3.0/mods-available/eap and configure the default EAP method:

eap {
  default_eap_type: tls
  timer_expire: 60
  ignore_unknown_eap_types: no
  cisco_accounting_username_bug: no
  max_sessions: 4096

  tls-config tls-common {
    certdir: ${confdir}/certs
    cadir: ${confdir}/certs
    private_key_file: ${certdir}/radius-server.key
    certificate_file: ${certdir}/radius-server.crt
    ca_file: ${cadir}/ca.crt
    cipher_list: HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH
    tls_min_version: 1.2
  }
}

Step 4: Test in debug mode

Before running as a system service, stop the daemon and start in foreground debug mode:

sudo systemctl stop freeradius
sudo freeradius -X

Test local authentication using radtest:

radtest testuser Password123 127.0.0.1 0 testing123

A successful response returns Received Access-Accept Id 1.

Step-by-step setup: Windows Server NPS

Microsoft Network Policy Server (NPS) is the built-in RADIUS server role for Windows Server environments connected to Active Directory Domain Services (AD DS).

+-------------------------------------------------------------------------+
|                  Windows Server Network Policy Server                   |
|                                                                         |
|  [RADIUS Clients (AP / WLC)] ---> [Connection Request Policies]         |
|                                                  |                      |
|                                                  v                      |
|  [Active Directory DS / PKI] <--- [Network Policies (VLAN / EAP-TLS)]   |
+-------------------------------------------------------------------------+

Step 1: Install Network Policy and Access Services

Open PowerShell as Administrator:

Install-WindowsFeature NPAS -IncludeManagementTools
Register-ActiveDirectoryServer -Server nps01.corp.local

Step 2: Register RADIUS clients (access points)

  1. Open Network Policy Server (nps.msc).
  2. Expand RADIUS Clients and Servers > Right-click RADIUS Clients > New.
  3. Enter Friendly Name: Cisco-Catalyst-AP-Cluster.
  4. Enter IP Address or Subnet CIDR (e.g. 10.50.0.0/24).
  5. Generate and enter a strong Shared Secret (minimum 24 alphanumeric characters).

Step 3: Create network policy for WiFi authentication

  1. Under Policies > Network Policies, right-click and select New.
  2. Policy Name: Staff-WiFi-802.1X-Policy. Type of network access server: Unspecified.
  3. Conditions:
    • Add Windows Groups: CORP\WiFi-Authorised-Users
    • Add NAS-Port-Type: Wireless - IEEE 802.11 or Wireless - Other
  4. Access Permission: Select Access granted.
  5. Authentication Methods:
    • Deselect less secure methods.
    • Under EAP Types, add Microsoft: Smart Card or other certificate (EAP-TLS).
    • Edit the method and select the issued RADIUS Server Certificate from your Active Directory Certificate Services (AD CS) Enterprise CA.
  6. Constraints: Set Idle Timeout to 30 minutes and Session Timeout to 8 hours.

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.

Cloud RADIUS: Modern zero-trust architecture

Traditional on-premises RADIUS servers present major operational challenges:

  • High server licensing and patching overhead.
  • No native authentication APIs for cloud identity directories like Microsoft Entra ID or Google Workspace.
  • Vulnerability to WAN outages across branch offices.

Modern enterprise networks deploy Cloud RADIUS to centralize authentication with zero on-premises server footprint.

Feature Legacy Windows NPS / FreeRADIUS Cloud RADIUS Architecture
Directory Integration On-premises LDAP / Kerberos Native Microsoft Entra ID, Google Workspace, Okta
Transport Security Unencrypted UDP 1812/1813 RadSec (RFC 6614) TLS over TCP 2083
Certificate Automation Manual SCEP / NDES setup Automated Intune & Jamf PKI Connectors
High Availability Manual active-passive failover Multi-region global Anycast redundancy
Maintenance Operating system patching & OS licensing Managed cloud service with continuous updates

To model your architecture, explore our Multi-Tenant WiFi Guide and Staff WiFi Solutions.

Dynamic VLAN assignment configuration

Dynamic VLAN Assignment (defined under RFC 2868 and RFC 3580) allows a single enterprise SSID to dynamically segment users into distinct network subnets based on their directory group membership.

                          [Enterprise Staff SSID]
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
        [VLAN 10: Exec]       [VLAN 20: Engineering]  [VLAN 30: Contractors]
        (10.10.10.0/24)        (10.10.20.0/24)        (10.10.30.0/24)

Standard RADIUS attributes required

When the RADIUS server validates credentials, it appends these attributes to the Access-Accept response:

Tunnel-Type = 13 (VLAN)
Tunnel-Medium-Type = 6 (802 - includes all 802 media plus Ethernet canonical format)
Tunnel-Private-Group-ID = 20 (or VLAN Name "CORP_ENG")

FreeRADIUS dynamic VLAN mapping example

In /etc/freeradius/3.0/users:

DEFAULT Group == "Engineering-Team"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "20"

DEFAULT Group == "Contractors"
  Tunnel-Type: 13
  Tunnel-Medium-Type: 6
  Tunnel-Private-Group-ID: "30"

Network firewall rules & port configuration

Ensure network firewalls permit communication between access points and RADIUS servers:

Protocol Port Number Description Source Destination
UDP 1812 RADIUS Authentication (RFC 2865) Access Points / WLC RADIUS Server
UDP 1813 RADIUS Accounting (RFC 2866) Access Points / WLC RADIUS Server
TCP 2083 RadSec - RADIUS over TLS (RFC 6614) Access Points / WLC Cloud RADIUS
UDP 1645 / 1646 Legacy RADIUS Auth / Acct (Deprecated) Legacy NAS Devices RADIUS Server

Security hardening & BlastRADIUS mitigation

Mitigating BlastRADIUS (CVE-2024-3596)

In July 2024, researchers disclosed BlastRADIUS, an MD5 collision vulnerability in the RADIUS protocol that allows an attacker positioned between the access point and RADIUS server to forge Access-Accept responses.

To secure your deployment:

  1. Enforce Message-Authenticator: Require the Message-Authenticator attribute (RFC 2869) on all Access-Request and Access-Accept packets.
  2. Transition to EAP-TLS: Certificate-based EAP-TLS is cryptographically immune to proxy forgery because TLS cryptographic keys are derived end-to-end between client and RADIUS server.
  3. Deploy RadSec (RFC 6614): Encapsulate RADIUS traffic inside TLS tunnels to prevent man-in-the-middle packet tampering.

Troubleshooting 802.1X authentication failures

Error Symptom Root Cause Technical Remediation
Client receives connection failure immediately Shared secret mismatch between AP and RADIUS server Verify shared secret string in AP controller and RADIUS configuration.
Authentication timeout after 10-15 seconds Firewall blocking UDP port 1812 or missing routing Verify firewall ACLs and confirm AP can ping the RADIUS server IP over the management VLAN.
RADIUS log: "Unknown CA" or "Certificate Untrusted" Client or RADIUS server missing Root CA certificate Install intermediate and root CA certificates into the client trust store and RADIUS server certificate directory.
Client authenticates but receives APIPA IP (169.254.x.x) Dynamic VLAN ID does not exist on AP switch trunk port Verify switch trunk configuration carries the target VLAN ID specified in Tunnel-Private-Group-ID.
RADIUS log: "Message-Authenticator is missing" NAS client does not support RFC 2869 or lacks firmware update Update AP controller firmware or enable Message-Authenticator enforcement on the NAS profile.

Frequently asked questions

What port does a RADIUS server use for WiFi authentication?

Standard RADIUS authentication operates on UDP port 1812, with accounting on UDP port 1813. Legacy implementations used UDP ports 1645 and 1646. Modern Cloud RADIUS deployments utilize RadSec over TCP port 2083 with TLS encryption.

Should I choose FreeRADIUS or Windows Server NPS?

Choose Windows Server NPS if your organization relies strictly on on-premises Active Directory Domain Services. Choose FreeRADIUS for high performance, open-source flexibility, and Linux environments. If your organization uses cloud identity providers like Microsoft Entra ID or Google Workspace, choose Cloud RADIUS.

How do I connect Microsoft Entra ID (Azure AD) to a RADIUS server?

Microsoft Entra ID does not support legacy on-premises LDAP or NTLM authentication protocols natively. To connect Entra ID to enterprise WiFi, deploy Cloud RADIUS paired with Microsoft Intune SCEP certificate deployment to authenticate endpoints using EAP-TLS.

Why is EAP-TLS preferred over PEAP-MSCHAPv2?

EAP-TLS uses mutual X.509 certificate authentication where both client and server validate cryptographic identities. PEAP-MSCHAPv2 relies on user passwords inside a TLS tunnel, leaving networks vulnerable to password spraying, phishing, and rogue AP credential theft.

For tailored enterprise WiFi security architecture, consult our WiFi Analytics Guide or speak to an enterprise network specialist.

Key Definitions

RADIUS (RFC 2865)

Remote Authentication Dial-In User Service. A networking client-server protocol that provides centralized Authentication, Authorization, and Accounting (AAA) management.

Functions as the authentication server validating device and user credentials submitted through wireless access points.

IEEE 802.1X

An IEEE standard for port-based Network Access Control (PNAC) providing protected authentication for devices attempting to attach to a LAN or WLAN.

Defines the encapsulation of EAP frames between the supplicant (endpoint device) and the authenticator (access point).

EAP-TLS (RFC 5216)

Extensible Authentication Protocol - Transport Layer Security. Mutual certificate-based authentication protocol where both the RADIUS server and client validate digital certificates.

The industry standard authentication method for enterprise zero-trust WiFi, eliminating passwords.

RadSec (RFC 6614)

RADIUS over TLS. A standard that encapsulates traditional UDP RADIUS packets inside secure TCP port 2083 TLS tunnels.

Secures RADIUS authentication traffic traversing untrusted public WAN links between local access points and Cloud RADIUS servers.

Dynamic VLAN Assignment (RFC 3580)

A RADIUS mechanism that returns VLAN IDs in Access-Accept responses based on user role or device posture.

Enables a single enterprise SSID to dynamically place users onto isolated network segments.

Worked Examples

A network engineer needs to configure FreeRADIUS to authenticate wireless clients connecting through 12 Cisco Catalyst access points on subnet 10.20.0.0/24 with shared secret SecretAuthKey2026. What configuration must be placed in clients.conf?

client branch_aps { ipaddr = 10.20.0.0/24 secret = SecretAuthKey2026 nas_type = cisco require_message_authenticator = yes }

Examiner's Commentary: Defining an entire subnet scope in clients.conf simplifies access point additions. Setting require_message_authenticator = yes mitigates BlastRADIUS (CVE-2024-3596) forgery attacks.

An IT department is migrating 2,000 corporate Windows 11 laptops from Active Directory to Microsoft Entra ID and Intune. How should the RADIUS infrastructure be updated to support passwordless WiFi authentication without keeping on-premises Domain Controllers?

  1. Deploy Cloud RADIUS with native Microsoft Entra ID integration. 2. Configure Microsoft Intune SCEP or PKCS certificate profiles to automatically issue client certificates to managed laptops. 3. Configure the wireless controller to point 802.1X authentication to the Cloud RADIUS server using RadSec (TLS port 2083). 4. Enforce EAP-TLS as the primary authentication method in the Intune WiFi configuration profile.
Examiner's Commentary: Because Microsoft Entra ID does not expose native NTLM or Kerberos endpoints for legacy PEAP-MSCHAPv2, certificate-based EAP-TLS combined with Cloud RADIUS is the recommended enterprise migration path.

Practice Questions

Q1. During a wireless 802.1X rollout, client devices connect and authenticate successfully, but they receive an IP address on the default native VLAN instead of the assigned corporate VLAN. What RADIUS attributes must the server return?

Hint: Review RFC 2868 and RFC 3580 tunnel attributes.

View model answer

The RADIUS server must return three specific attributes in the Access-Accept response: 1. Tunnel-Type = 13 (VLAN), 2. Tunnel-Medium-Type = 6 (802), 3. Tunnel-Private-Group-ID = [VLAN_ID_or_Name]. The access point switch port must also be configured as a trunk port carrying that VLAN.

Q2. What is the security risk of deploying PEAP-MSCHAPv2 on BYOD networks without enforcing the RADIUS server root CA certificate on client devices?

Hint: Consider rogue access point and evil twin attacks.

View model answer

If client devices do not validate the RADIUS server certificate, an attacker can deploy a rogue access point broadcasting the same SSID. When the client connects, the rogue server captures the MS-CHAPv2 challenge-response handshake, allowing the attacker to crack the password offline with tools like asleap.

Q3. Which firewall ports must be open between an on-premises wireless access point and a Cloud RADIUS server when using RadSec versus standard RADIUS?

Hint: Compare legacy UDP ports with modern TLS-encapsulated RADIUS.

View model answer

Standard RADIUS requires outbound UDP port 1812 (Authentication) and UDP port 1813 (Accounting). RadSec requires outbound TCP port 2083 with TLS encryption, providing mutual certificate validation and eliminating plaintext UDP transmission across the public internet.

Continue reading in this series

A Network Administrator’s Guide to Configuring RADIUS Authentication for Guest WiFi

A comprehensive technical reference for network administrators on deploying RADIUS authentication for guest WiFi. Covers architecture, vendor-neutral configuration steps, security best practices, and troubleshooting common deployment failures.

Read the guide →

Implementing SCEP for Secure BYOD and 802.1X WiFi in Higher Education

This technical guide details how higher education IT teams can automate 802.1X certificate enrollment for thousands of BYOD devices using SCEP. It covers the architecture, security benefits, and practical deployment steps to replace manual onboarding with a secure, zero-touch network access model.

Read the guide →

Configuring RADIUS Authentication for Guest and Staff WiFi Networks

This technical reference guide outlines the architecture, configuration, and deployment of RADIUS authentication for enterprise guest and staff WiFi networks. It provides network architects and IT managers with the exact protocols, security standards, and troubleshooting methodologies required to build secure, scalable wireless access control systems.

Read the guide →

Got questions about your specific setup?

Our team works with venue operators, IT managers, and network engineers across 80,000 venues. Book a 20-minute call and we will show you how others like you solved it.