What is RADIUS? The Complete Guide for IT Professionals

A RADIUS server (Remote Authentication Dial-In User Service) is a networking protocol server that provides centralized authentication, authorization, and accounting (AAA) for users and devices connecting to a network. It verifies credentials against a directory, then grants or denies access based on policies. RADIUS is the standard behind WPA2-Enterprise WiFi, VPN, and wired 802.1X authentication.

What is RADIUS?

RADIUS (Remote Authentication Dial-In User Service) is a networking protocol that provides centralized Authentication, Authorization, and Accounting (AAA) for users and devices connecting to a network. It is the industry standard for controlling who gets access to WiFi networks, VPNs, wired Ethernet ports, and other network resources.

When a user tries to connect to a WiFi network secured with WPA-Enterprise, or logs into a VPN, the network equipment doesn't make the access decision on its own. Instead, it asks a RADIUS server whether to allow or deny the connection. This centralized model means you can manage authentication policies from one place, regardless of how many access points, switches, or VPN concentrators you operate.

History and Evolution of RADIUS

RADIUS was developed in 1991 by Livingston Enterprises to authenticate dial-up modem connections for the Merit Network, which operated the NSFnet backbone. At the time, Internet service providers needed a way to verify username/password combinations from thousands of modem ports across distributed points of presence.

The protocol proved so effective that the IETF standardized it in RFC 2058 (1997) and later updated it to RFC 2865 (2000), which remains the authoritative specification. Accounting was defined separately in RFC 2866.

Key Milestones

• 1991: RADIUS created for dial-up authentication at Merit Network
• 1997: IETF publishes RFC 2058, formalizing the protocol
• 2000: RFC 2865/2866 published as the definitive RADIUS standard
• 2004: EAP support added (RFC 3579), enabling 802.1X and WPA-Enterprise
• 2012: RadSec (RADIUS over TLS) standardized in RFC 6614 for encrypted transport
• 2020s: Cloud RADIUS services emerge, eliminating on-premise server requirements

Despite its age, RADIUS has proved remarkably adaptable. The core protocol is simple and extensible, which has allowed it to evolve from dial-up authentication to securing modern WiFi, VPN, and IoT networks without requiring protocol redesign.

How RADIUS Authentication Works

RADIUS authentication follows a three-party model involving a supplicant (the user or device), an authenticator (the network device), and the RADIUS server (the authentication authority).

The Authentication Flow

1. Connection request: A user or device (the supplicant) attempts to connect to the network -- for example, associating with a WPA-Enterprise WiFi network or initiating a VPN session
2. Authenticator forwards request: The network device (access point, switch, or VPN gateway) acts as a RADIUS client and sends an Access-Request packet to the RADIUS server, containing the user's credentials and connection metadata
3. RADIUS server validates: The RADIUS server checks the credentials against its user database. This could be a local database, an LDAP directory like Active Directory, a SAML identity provider, or a certificate authority
4. Challenge (optional): For EAP-based authentication, the server may issue Access-Challenge packets to perform multi-step authentication (certificate validation, MFA, etc.)
5. Access decision: The RADIUS server responds with either an Access-Accept (granting access with specific policies) or an Access-Reject (denying access)
6. Policy enforcement: If accepted, the response includes RADIUS attributes that tell the authenticator how to configure the connection -- which VLAN to assign, bandwidth limits, session timeouts, and other policies

Shared Secrets

Communication between the authenticator and the RADIUS server is protected by a shared secret -- a password known to both parties but never transmitted over the network. This shared secret is used to encrypt the user's password within the Access-Request packet and to generate the response authenticator field, which proves the response came from the legitimate RADIUS server.

RADIUS Packet Types

The RADIUS protocol defines several packet types, each serving a specific function in the AAA process:

Packet Type	Code	Purpose
Access-Request	1	Sent by the authenticator to request authentication for a user/device
Access-Accept	2	Sent by the RADIUS server to grant access, includes policy attributes
Access-Reject	3	Sent by the RADIUS server to deny access
Access-Challenge	11	Sent by the server to request additional information (used in EAP exchanges)
Accounting-Request	4	Sent by the authenticator to report session start, stop, or interim updates
Accounting-Response	5	Sent by the server to acknowledge the accounting record

The Access-Challenge packet is particularly important for modern authentication. When using EAP methods like EAP-TLS (certificate-based) or PEAP (username/password over TLS tunnel), the authentication process involves multiple round-trip exchanges between the supplicant and the RADIUS server, with each step carried in Access-Challenge and Access-Request packets.

RADIUS Attributes and Vendor-Specific Attributes (VSAs)

RADIUS packets carry attributes -- key-value pairs that communicate information between the authenticator and the RADIUS server. Attributes are how RADIUS delivers both identity data (who is authenticating) and policy data (what access they should receive).

Common Standard Attributes

• User-Name (1): The identity being authenticated
• User-Password (2): Encrypted password for PAP authentication
• NAS-IP-Address (4): IP address of the network device making the request
• NAS-Port (5): Physical or logical port the user is connecting through
• Service-Type (6): Type of service requested (login, framed, etc.)
• Framed-IP-Address (8): IP address to assign to the user
• Filter-Id (11): Name of a filter list to apply
• Session-Timeout (27): Maximum session duration in seconds
• Tunnel-Type (64): Used for VLAN assignment
• Tunnel-Private-Group-Id (81): VLAN ID to assign
• EAP-Message (79): Encapsulates EAP protocol data

Vendor-Specific Attributes (VSAs)

RADIUS was designed to be extensible through Vendor-Specific Attributes (attribute type 26). VSAs allow equipment manufacturers to define custom attributes for their specific features. For example, Cisco uses VSAs to assign users to specific access control lists, while Aruba uses them for role-based access policies.

VSAs are identified by a vendor ID (assigned by IANA) and a vendor-specific attribute number. The RADIUS server must be configured to send the appropriate VSAs based on the target equipment manufacturer.

RADIUS vs LDAP: When to Use Which

RADIUS and LDAP are often mentioned together, but they serve fundamentally different purposes. Understanding the distinction is critical for designing network authentication correctly.

Aspect	RADIUS	LDAP
Primary function	Network access authentication (AAA)	Directory services (user/group storage and lookup)
Protocol type	Authentication protocol	Directory access protocol
802.1X support	Native -- designed for 802.1X	Not supported directly
EAP support	Full EAP framework support	No EAP capability
Policy delivery	Returns VLAN, ACL, bandwidth policies	Returns user data only
Accounting	Built-in session accounting	No accounting capability
Network device support	Universal -- all enterprise equipment	Limited -- few network devices query LDAP
Typical role	Front-end authentication decision	Back-end identity source

In practice, RADIUS and LDAP work together. The RADIUS server handles the network access protocol (communicating with access points and switches), then queries LDAP (such as Active Directory or Azure AD) as the back-end identity source to validate credentials. LDAP answers "does this user exist and is their password correct?" while RADIUS handles everything else -- the network protocol, policy delivery, and session accounting.

RADIUS vs TACACS+: Differences and Use Cases

RADIUS and TACACS+ are both AAA protocols, but they are designed for different purposes and operate differently at a technical level.

Aspect	RADIUS	TACACS+
Primary use case	Network access (WiFi, VPN, wired NAC)	Device administration (router/switch CLI access)
Transport	UDP (ports 1812/1813)	TCP (port 49)
Encryption	Password field only	Entire packet body
AAA separation	Authentication + authorization combined	Separates authentication, authorization, and accounting
Standards	Open IETF standard (RFC 2865)	Originally Cisco proprietary (now RFC 8907)
802.1X / EAP	Full support	Not supported
Command authorization	Not supported	Per-command authorization
Multi-vendor support	Universal	Primarily Cisco and select vendors

RADIUS vs Diameter: The Next Generation

Diameter was developed as a successor to RADIUS, addressing several protocol limitations. The name is a play on RADIUS -- a diameter is twice the radius.

Aspect	RADIUS	Diameter
Transport	UDP (unreliable)	TCP or SCTP (reliable)
Architecture	Client-server only	Peer-to-peer (server can initiate requests)
Failover	Application-level only	Built-in failover and redirect
Attribute size	Limited to 253 bytes per attribute	Up to 16 MB per attribute
Security	Shared secret (MD5-based)	IPsec or TLS required
Primary adoption	Enterprise WiFi, VPN, wired NAC	Mobile/telecom (LTE, 5G, IMS)

Despite Diameter's technical advantages, RADIUS remains dominant for enterprise network access. Diameter found its primary adoption in the telecom industry (LTE/4G, 5G, IMS) rather than replacing RADIUS in enterprise environments. Enterprise access points, switches, and VPN gateways universally support RADIUS, and the transition cost to Diameter would be enormous with minimal practical benefit for most use cases.

For enterprise IT teams, investing in RADIUS remains the correct choice. The protocol's extension mechanisms (RadSec for TLS transport, new EAP methods, cloud RADIUS services) have addressed many of the original limitations without requiring a protocol change.

Common RADIUS Use Cases

WiFi Authentication (802.1X / WPA-Enterprise)

The most common RADIUS use case today. WPA-Enterprise requires a RADIUS server to authenticate users via EAP methods such as EAP-TLS (certificates), PEAP (username/password), or TTLS. This eliminates the shared password problem of WPA-Personal and gives each user unique credentials.

VPN Authentication

RADIUS authenticates remote users connecting through VPN concentrators. This provides centralized authentication regardless of VPN vendor and enables integration with multi-factor authentication (MFA) providers through RADIUS proxy chains.

Wired Network Access Control (NAC)

Switches use 802.1X with RADIUS to authenticate devices before granting port access. This prevents unauthorized devices from connecting to the wired network and enables dynamic VLAN assignment based on user identity or device type.

IoT Device Authentication

RADIUS handles IoT devices through MAC Authentication Bypass (MAB) for devices that cannot run an 802.1X supplicant, or EAP-TLS for certificate-capable devices. The RADIUS server maintains approved device lists and assigns IoT devices to isolated VLANs.

Guest Network Access

Captive portal systems use RADIUS to authenticate guest users who have registered through self-service portals, sponsor approval workflows, or social login. RADIUS accounting tracks guest session usage for compliance and reporting.

On-Premise vs Cloud RADIUS

Organizations deploying RADIUS face a fundamental infrastructure decision: run your own RADIUS server or use a managed cloud service.

Factor	On-Premise RADIUS	Cloud RADIUS
Deployment time	Days to weeks	Minutes to hours
Server management	You maintain hardware, OS, patches	Fully managed by provider
High availability	Requires redundant servers + configuration	Built-in globally distributed HA
Scalability	Limited by server capacity	Elastic -- scales automatically
Identity integration	Manual configuration for each IdP	Native Azure AD, Google, Okta integration
Cost model	Capital expense (hardware + licensing)	Operating expense (subscription)
Multi-site	Separate server at each site or backhauled traffic	Global PoPs -- local authentication everywhere
Customization	Full control over configuration	Provider-defined feature set

Setting Up Your First RADIUS Server

Whether you choose on-premise or cloud, the general steps for deploying RADIUS authentication are:

1. Define your identity source: Decide where user accounts live -- Active Directory, Azure AD, Google Workspace, LDAP, or a local database. This determines which EAP methods and integrations you need
2. Choose your RADIUS deployment: On-premise software (FreeRADIUS, Microsoft NPS, Cisco ISE) or a cloud RADIUS service. Cloud services are faster to deploy and eliminate server maintenance
3. Configure RADIUS clients: Add each network device (access point, switch, VPN gateway) as a RADIUS client with a shared secret. For cloud RADIUS, point your equipment to the provider's server addresses
4. Define authentication policies: Configure which EAP methods to accept (EAP-TLS for certificates, PEAP for username/password), which users/groups are authorized, and what network policies to apply (VLANs, bandwidth, session limits)
5. Deploy certificates: For EAP-TLS or server certificate validation, deploy the RADIUS server certificate and configure trusted certificate authorities on client devices
6. Test with a single device: Verify authentication works with one device before rolling out to the full network. Check RADIUS logs for successful authentication and correct policy application
7. Configure accounting: Enable RADIUS accounting to track session starts, stops, and data usage. This provides audit trails for compliance and troubleshooting data for operations
8. Roll out to production: Gradually migrate network segments to RADIUS authentication, monitoring logs for failures and adjusting policies as needed

Choosing a RADIUS Solution: What to Look For

When evaluating RADIUS solutions, consider these factors based on your organization's requirements:

Identity Provider Integration

Your RADIUS solution must integrate with your existing identity system. If your organization uses Azure AD, Google Workspace, or Okta, look for native integration rather than LDAP sync adapters, which add complexity and latency.

EAP Method Support

Ensure the solution supports the EAP methods your environment requires. EAP-TLS (certificate-based) provides the strongest security. PEAP and EAP-TTLS support username/password authentication through a TLS tunnel.

High Availability

RADIUS is a critical service -- if it goes down, nobody can connect to the network. Your solution needs redundancy. For on-premise, this means multiple servers with automatic failover. Cloud services should provide multiple global points of presence with SLA guarantees.

Multi-Site Support

If your organization operates multiple locations, consider authentication latency. Cloud RADIUS with distributed points of presence provides low-latency authentication regardless of location. On-premise solutions may need local servers at each site.

Certificate Management

If you plan to use certificate-based authentication (EAP-TLS), look for integrated PKI and SCEP support. Managing certificates separately adds significant operational overhead. Solutions with built-in certificate lifecycle management simplify deployment considerably.

Monitoring and Troubleshooting

RADIUS authentication failures can be difficult to diagnose. Look for detailed logging, real-time authentication dashboards, and the ability to search and filter authentication events by user, device, or result.