What Is RADIUS Authentication? WiFi Network Access Control Explained
Key Takeaways: RADIUS (Remote Authentication Dial-In User Service) is a networking protocol that handles authentication, authorization, and accounting (AAA) for devices connecting to a network. In WiFi marketing, RADIUS is the back-end system that decides whether a guest device gets internet access after captive portal login, enforces session policies (time limits, bandwidth caps), and logs detailed session data (connect/disconnect times, bytes transferred, session duration). Every cloud-managed captive portal uses RADIUS or a RADIUS-like protocol under the hood, even if the reseller never interacts with it directly.
RADIUS is the protocol that makes captive portals work. When a guest taps "Connect" on a captive portal, it's the RADIUS server that flips the switch — authorizing that specific device to access the internet and recording every detail of the session until the guest disconnects.
The protocol was invented in 1991 by Livingston Enterprises for dial-up internet authentication. It's defined in RFC 2865 (authentication) and RFC 2866 (accounting). Three decades later, it remains the dominant protocol for network access control in enterprise and commercial WiFi deployments.
You don't need to configure RADIUS servers to sell WiFi marketing. Cloud platforms handle this entirely. But understanding RADIUS helps you speak the language of network administrators, troubleshoot connection issues, and explain the data model behind guest WiFi analytics.
How RADIUS authentication works
The three-party model
RADIUS operates with three participants:
- •Supplicant — the guest's device (phone, laptop, tablet)
- •NAS (Network Access Server) — the access point or wireless controller
- •RADIUS server — the authentication and accounting engine
The authentication flow
Guest Device → Access Point → RADIUS Server → Decision → Access Point → Guest Device
- •Guest connects to SSID and completes the captive portal login
- •The portal platform sends an Access-Request to the RADIUS server, containing the guest's MAC address, the NAS identifier (AP), and authentication credentials
- •RADIUS server validates the credentials against its database
- •RADIUS returns either Access-Accept (with optional authorization attributes) or Access-Reject
- •On Accept, the AP adds the device MAC to its allowlist and grants internet access
- •RADIUS attributes in the Accept message can include session timeout, bandwidth limits, VLAN assignment, and idle timeout
RADIUS attributes that matter for WiFi marketing
| Attribute | Description | Marketing Use |
|---|---|---|
| Calling-Station-Id | Guest device MAC address | Device identification, return visit tracking |
| Called-Station-Id | AP MAC address | Location mapping (which AP = which zone) |
| NAS-IP-Address | AP or controller IP | Site identification in multi-location deployments |
| Session-Timeout | Max session length in seconds | Free tier limits (e.g., 60 min free, then re-auth) |
| Idle-Timeout | Disconnect after X seconds idle | Clean up inactive sessions |
| WISPr-Bandwidth-Max-Down | Download speed limit (bps) | Tiered access (free = slow, paid = fast) |
| WISPr-Bandwidth-Max-Up | Upload speed limit (bps) | Same as above |
| Reply-Message | Text sent back to the NAS | Post-auth redirect URL or welcome message |
| Acct-Session-Id | Unique session identifier | Session-level analytics tracking |
RADIUS accounting: where the analytics data lives
Authentication decides yes or no. Accounting records everything that happens after.
The accounting flow
Once a guest is authenticated, the AP sends RADIUS accounting packets at three points:
- •Accounting-Start — sent when the session begins (device is online)
- •Accounting-Interim-Update — sent periodically (every 5-15 minutes) with running totals
- •Accounting-Stop — sent when the session ends (device disconnects or times out)
What accounting records contain
Each accounting record (stored in a radacct database table) includes:
| Field | Description | Analytics Value |
|---|---|---|
acctsessionid | Unique session ID | Session-level tracking |
username | Guest identifier (email, MAC) | Identity linkage |
callingstationid | Device MAC | Device recognition |
calledstationid | AP MAC + SSID | Location + network |
acctstarttime | Session start timestamp | Visit timing |
acctstoptime | Session end timestamp | Visit duration |
acctsessiontime | Total seconds online | Dwell time |
acctinputoctets | Bytes uploaded | Engagement proxy |
acctoutputoctets | Bytes downloaded | Engagement proxy |
acctterminatecause | Why the session ended | User behavior signal |
nasipaddress | AP IP address | Site identification |
framedipaddress | IP assigned to device | Network forensics |
This is the richest session-level dataset in WiFi marketing. Every metric in your analytics dashboard — dwell time, session count, bandwidth usage, peak hours — derives from RADIUS accounting data.
Terminate cause codes
The acctterminatecause field tells you why a session ended:
| Code | Meaning | Insight |
|---|---|---|
| User-Request | Guest disconnected voluntarily | Normal departure |
| Session-Timeout | Time limit reached | May indicate user wanted more time |
| Idle-Timeout | No activity for X minutes | Device left venue or went to sleep |
| Admin-Reset | Reseller or AP forced disconnect | Manual intervention |
| NAS-Reboot | AP restarted | Infrastructure event |
| Lost-Carrier | Signal lost | Guest moved out of range |
A high percentage of "Session-Timeout" disconnects might mean the venue's time limit is too aggressive. A spike in "Lost-Carrier" might indicate an AP coverage gap. This is operational intelligence that resellers can use to optimize the guest experience.
RADIUS in the cloud WiFi marketing stack
How platforms abstract RADIUS
Modern WiFi marketing platforms run RADIUS as a managed service. The reseller never touches a RADIUS configuration file. Instead:
- •Reseller configures the portal (login methods, branding, policies)
- •Platform generates RADIUS shared secrets and server IPs
- •Reseller enters those values into the AP's controller (Meraki, UniFi, Aruba, etc.)
- •AP sends RADIUS traffic to the platform's RADIUS server
- •Platform handles authentication, authorization, and accounting automatically
The 2-minute device integration wizard on platforms like MyWiFi handles steps 2-4 automatically for supported hardware vendors.
RADIUS vs. WISPr vs. API authentication
| Method | Protocol | Where Used |
|---|---|---|
| RADIUS | UDP, ports 1812/1813 | Universal — works with all enterprise APs |
| WISPr | HTTP-based XML | Legacy hotspot controllers |
| Controller API | REST/JSON | Meraki ExCap, UniFi Hotspot API |
| Cloud redirect | HTTPS redirect | CDN-hosted portals with callback |
RADIUS remains the most universal method. It works with any AP that supports 802.1X or external RADIUS (which is essentially all commercial hardware). Controller-specific APIs offer tighter integration but lock you to one vendor's ecosystem.
RADIUS deployment patterns
Pattern 1: Cloud RADIUS (most common for resellers)
The platform provider hosts RADIUS servers in the cloud. The AP sends RADIUS traffic over the internet to the cloud server. This is the standard model for multi-site, multi-vendor deployments.
Pros: Zero on-site infrastructure, works everywhere, centralized management. Cons: Requires internet connectivity for auth (no offline fallback), minor latency (50-200ms).
Pattern 2: On-premise RADIUS
A physical or virtual RADIUS server at the venue. Common in large enterprise deployments (hospitals, universities, airports) where latency, security, or regulatory requirements demand local processing.
Pros: Sub-10ms auth latency, works without internet, full data sovereignty. Cons: Hardware/VM cost per site, local maintenance, doesn't scale for multi-site resellers.
Pattern 3: Hybrid RADIUS
Cloud RADIUS for authentication with local caching. If the internet connection drops, the AP falls back to cached authorization. Common in deployments where connectivity is unreliable (events, remote locations, ships).
RADIUS security considerations
Shared secret management
RADIUS uses a shared secret (password) between the AP and the RADIUS server to encrypt authentication packets. If the shared secret is compromised, an attacker can forge authentication responses.
Best practices:
- •Use unique shared secrets per AP or per site (not one secret for all APs)
- •Minimum 16 characters, random alphanumeric
- •Rotate secrets annually or when staff with access leave
- •Cloud platforms handle this automatically — each AP integration generates a unique secret
RadSec (RADIUS over TLS)
Standard RADIUS uses UDP with MD5-based encryption — functional but not modern cryptography. RadSec (RFC 6614) wraps RADIUS in TLS, providing certificate-based authentication and encrypted transport. Enterprise APs from Cisco, Aruba, and Juniper support RadSec.
For resellers, RadSec matters when clients in regulated industries (healthcare, finance) require encrypted authentication traffic. Most cloud WiFi platforms support RadSec for enterprise-tier deployments.
MAC authentication bypass (MAB)
Some deployments use MAB — authenticating devices by MAC address alone, without user interaction. This is used for IoT devices, printers, and known equipment. MAB is not suitable for guest WiFi marketing (no data capture) but is relevant when resellers manage mixed networks with both guest and device segments.
RADIUS data and analytics
Building analytics from radacct
The RADIUS accounting table (radacct) is the foundation of WiFi analytics. Here's how platform-level metrics map to RADIUS fields:
| Dashboard Metric | RADIUS Source |
|---|---|
| Total sessions | COUNT of radacct records |
| Unique visitors | COUNT DISTINCT callingstationid |
| Average dwell time | AVG(acctsessiontime) |
| Total data transferred | SUM(acctinputoctets + acctoutputoctets) |
| Peak hours | GROUP BY HOUR(acctstarttime) |
| New vs. returning | First-seen vs. subsequent callingstationid |
| Location breakdown | GROUP BY calledstationid |
Session-level intelligence
RADIUS data enables granular analysis that aggregate foot traffic systems can't match:
- •Exact session duration per guest (not an estimate — precise to the second)
- •Bandwidth per session (heavy users vs. light users)
- •Time-of-day patterns (when specific guests typically visit)
- •Multi-AP movement (guest roaming between zones during a single visit)
This data feeds into marketing automation triggers. "Guest who spent 2+ hours and transferred 500MB+ data" is a different segment than "guest who connected for 10 minutes and barely used the network."
Frequently asked questions
Do resellers need to manage RADIUS servers?
No. Cloud WiFi marketing platforms run managed RADIUS infrastructure. The reseller configures portals and policies through a web dashboard. RADIUS configuration (server addresses, shared secrets, ports) is auto-generated during the AP integration process.
Does RADIUS work with all access points?
Virtually all commercial and enterprise access points support external RADIUS authentication. Consumer-grade routers generally don't. The hardware compatibility page lists specific vendor integration methods — most use RADIUS as the underlying protocol.
What's the difference between RADIUS and 802.1X?
802.1X is the IEEE standard for port-based network access control. RADIUS is the protocol that 802.1X uses to communicate authentication decisions. 802.1X defines the framework; RADIUS provides the transport. In the WiFi marketing context, 802.1X/RADIUS handles the back-end while the captive portal handles the front-end user experience.
Can RADIUS data be exported?
Yes. RADIUS accounting data is available via API on enterprise-tier plans. Resellers can pull session-level data for custom analytics, integration with business intelligence tools, or synchronization with CRM systems. Standard-tier plans expose this data through the platform's analytics dashboard.
How does RADIUS handle returning guests?
When a guest returns, the platform recognizes their device MAC (Calling-Station-Id) from previous sessions. The portal can auto-authenticate returning guests (using a stored MAC allowlist with a configurable expiry) or present a "Welcome Back" simplified login. The returning guest's new session generates a fresh radacct record, linked to their historical profile.
Bottom line
RADIUS is the invisible protocol that makes WiFi marketing work. It authenticates guests, enforces session policies, and records the granular session data that powers analytics dashboards and automation triggers.
Resellers don't manage RADIUS directly — cloud platforms abstract it completely. But understanding the protocol helps you troubleshoot connection issues, explain the data model to technical clients, and appreciate why WiFi analytics produces richer data than any other foot traffic technology.
The session accounting data flowing through RADIUS is the raw material for guest WiFi analytics. Every metric, every automation trigger, every report your clients see is built on RADIUS accounting records.
Get started with a free trial — the RADIUS infrastructure is managed for you from day one.