A Remote Authentication Dial-In User Service (RADIUS) server, or RADIUS authentication server, could be the missing piece of the puzzle for your organization’s network authentication. RADIUS is a type of authentication that functions like a virtual guard. It is increasingly used in industries and organizations internationally due its triple function of authentication, authorization, and accounting.
Every time a user or device attempts to access a protected resource, they need to prove they have the right to access that resource through the process of authentication. Wired and wireless networks are the same; they’re more secure when authentication is used to verify exactly who’s accessing them. For that purpose, new authentication protocols are being introduced and old ones are improved constantly, such as the RADIUS protocol.
In this article, we’ll explain everything you need to understand about what a RADIUS server is, what it does, how it works, and how it can benefit your wired and wireless security.
What is a RADIUS Server?
A Remote Authentication Dial-In User Service (RADIUS) server is a network access server (NAS) that grants or denies users and devices access to networks, whether wired, wireless, or virtual private networks (VPNs). Before responding to an access request, the server cross-references credentials or certificates against a trusted directory of approved users and their access levels.
If you’re unfamiliar with the concept, the easiest way to imagine where a RADIUS server fits into your network is to picture a bouncer at the door to a club. When someone tries to access the network, it confirms they should have access first by checking their credentials or certificate through the RADIUS authentication process.
Sometimes, a RADIUS authentication server is also referred to as an AAA server, which stands for Authentication, Authorization, and Accounting.
Components of RADIUS Authentication
RADIUS authentication requires a few things in order to occur:
- A RADIUS server, which receives user connection requests
- A directory of user/device information, also called an Identity Provider or IDP, for the RADIUS to reference
- A RADIUS client, which sends access requests to the server
RADIUS networking servers are so efficient at controlling network access because they don’t perform too many tasks at once. RADIUS protocol focuses on authentication, authorization, and accounting – not storing user information in advance. This is why it needs a directory to reference once it receives an access request. Commonly, an Identity Provider such as Active Directory, Azure AD/Entra ID, Google, or Okta is used to verify the information behind each access request.
How Does RADIUS Server Authentication and Authorization Work?
Imagining a RADIUS authentication server as a guard at a door gives you a high-level overview of how RADIUS authentication works. But it’s a bit more complicated than that, and there are steps involved in the process depending on the authentication protocol your network supports.
In our experience, three common wireless authentication protocols we see are the following:
- Extensible Authentication Protocol-Transport Layer Security (EAP-TLS)
- Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MSCHAPv2)
- Extensible Authentication Protocol-Tunneled Transport Layer Security-Password Authentication Protocol (EAP-TTLS/PAP)
| WPA2 & WPA3 Enterprise Common Protocols | Level of Encryption | Authentication Speed | Directory Support | Credentials |
|---|---|---|---|---|
| EAP-TLS | Public–Private Key Cryptography | Fast – 12 steps | Universal | Passwordless |
| PEAP-MSCHAPv2 | Bad encryption (MD4, compromised since 1995) | Slow – 22 steps | Active directory | Passwords |
| EAP-TTLS/PAP | No credential encryption | Slowest – 25 steps | Active directory | Passwords |
No matter which protocol you use, RADIUS networking pairs authentication and authorization together for streamlined but secure access.
However, each protocol dictates a different set of standards for the authentication and authorization process, including what the user/device provides to verify their identity. You can break down authentication with these protocols into two different categories: authentication via credentials (username/password) and authentication via digital certificates (passwordless).
Credential-Based RADIUS Authentication and Authorization
PEAP-MSCHAPv2 and EAP-TTLS/PAP are both credential-based authentication protocols. But a RADIUS server doesn’t store login information. It needs a directory of some kind to check the credentials and policies related to those credentials at the time of authentication.
All communication between the client and server is protected with a shared secret: a security key or password that’s never transmitted over the network, maintaining privacy and security.
Generally, credential-based authentication and authorization follow these steps:
- User Sends Authentication Request: The end-user/device submits an authentication request to the Network Access Server (NAS) with their username and encrypted password.
- NAS Delivers Access Request to RADIUS Server: The NAS transmits this request to the designated RADIUS server.
- Server Analyzes Request: The RADIUS authentication server receives the request, reads the shared secret, and verifies that the user’s username and password exist in the user database — commonly an Identity Provider.
- RADIUS Server Responds: Based on the results of the verification, the RADIUS returns an ACCESS_ACCEPT to authenticate the user, an ACCESS_CHALLENGE to request more details, or an ACCESS_REJECT message to the NAS.
- (If ACCESS_ACCEPT) Client Receives Authorization: Once authenticated, the client receives the ACCESS_ACCEPT message authorizing connection. This message contains a shared secret and Filter ID attribute authorizing access to a specific RADIUS group (a collection of users with the same access controls, e.g., Sales, Finance, HR).
- (IF ACCESS_ACCEPT) User Gains Access: With their access request authenticated and authorized, the user can access the client and network.
This may seem like a complex process, but it all happens quickly; authentication and authorization is nearly instantaneous.
Certificate-Based RADIUS Authentication and Authorization
RADIUS authentication with certificates (EAP-TLS) looks different. Digital certificates contain quite a bit more information in their templates than a typical username/password does, giving the RADIUS server and any administrator reviewing records like RADIUS event logs a lot more context.
The process looks like this:
- NAS Sends the Certificate: The device presents its certificate to the NAS, which forwards the request to the RADIUS authentication server.
- Server Runs Expiration Check: The RADIUS networking server starts by checking that the certificate isn’t expired.
- Server Cross-Checks CRL: Next, the RADIUS server checks the Certificate Revocation List (CRL) to determine that the certificate hasn’t been revoked.
- Server Authenticates and Authorizes User: If the certificate hasn’t been revoked, the RADIUS can confirm the user’s status in your directory and grant access. But if the certificate has been revoked, the server will reject the request.
Cloud RADIUS was designed to integrate with all major Security Assertion Markup Language (SAML) Identity Providers. At the time of authentication, it can actively communicate with Azure AD/Entra ID, Google, Okta, or OneLogin to determine that a user still exists in the directory and which network access policies should be applied to them. With Real-Time Intelligence, Cloud RADIUS can even apply policy updates immediately. This means that, even if someone is removed from the organization in the middle of the day, their network access can be revoked once you update the information in your directory.
How Does RADIUS Server Accounting Work?
After authentication and authorization, RADIUS clients send user and device data to the server for storage. Admins can use this data for audits, reporting, billing, and network monitoring or other security management activities.
Network administrators can use RADIUS accounting features with or without authentication and authorization.
There are 3 main steps to RADIUS accounting:
- Accounting Start: When an authorized user accesses the network, the RADIUS client sends a RADIUS accounting request packet, also known as an Accounting Start, to the RADIUS server. The packet includes the user’s network address, MAC address, access point, credentials, and unique session identifier. On receipt of the Start packet, the RADIUS server sends an Accounting Response.
- Interim Updates: As the session continues, the client may send new accounting request packets with updated information about data usage, session duration, and more. The server sends responses accordingly.
- Accounting Stop: When a user logs off or their access is revoked, the RADIUS client sends a final accounting request packet called the Accounting Stop. It shares the session duration, data accessed, bytes, starting and interim packets, and why the user disconnected. The server confirms receipt of the Accounting Stop packet and stores the details for future use.
RADIUS authenticates all accounting conversations between clients and servers, while password encryption prevents bad actors from intercepting user credentials.
RADIUS accounting helps network administrators monitor individual usage and overall trends, improve forecasting and resource allocation, bill users for data usage, and spot unusual network activity to maintain security.
What is a RADIUS Server Used For?
Network administrators use AAA RADIUS servers for diverse needs, spanning:
- General Network Access: Before granting access, RADIUS authentication servers verify a user’s identity by confirming their credentials or certificate along with their unique access levels.
- Intranets: Company intranets need ironclad verification to prevent unauthorized access. RADIUS servers authenticate the user and device, authorize or reject access, and keep accounts of user activity.
- Virtual Private Networks (VPNs): RADIUS servers can regulate local network usage and secure remote access to VPNs, maintaining sensitive network security.
- Wireless Networks (Wi-Fi): Private Wi-Fi network protection is another application for RADIUS authentication servers. It works with popular authentication methods such as the 802.1X protocol. Most private Wi-Fi requires credentials, but the shared secret between server and client keeps those credentials secure.
- Internet Service Providers (ISPs): ISPs for both home and corporate use rely on RADIUS networking to regulate wired and wireless network security.
Network Accounting: Not all authentication methods provide accounting services, but RADIUS does. This lets network administrators monitor, record, track, and identify anomalies in network usage. It’s also ideal for usage-based billing.
Authentication, Authorization, & Accounting in RADIUS Servers
While all RADIUS AAA functions occur on the same server, each have their own uses within the RADIUS protocol.
Authentication
We’ve established that RADIUS servers take user credentials or certificates and process access request messages. This is called authentication. During the authentication process, the RADIUS server will reply to an access request message with either an access accept message or access reject message.
Authorization
Authentication determines whether or not someone should be allowed access to the remote network. The level of authorization someone has determines exactly how much access they have to specific resources on the network.
For example, someone working in an HR department for an organization may have access to different information and applications than someone working in the finance department. This means that they have varied levels of authorization.
We often see our customers use the RADIUS networking protocol to segment categories of users into their own unique VLANs. By doing so, they can ensure various types of users have their own strict requirements, such as limiting bandwidth for particular users or preventing access to certain resources with RADIUS security.
Accounting
The job isn’t complete after the RADIUS server authenticates a device or user. This is where accounting comes into play.
Although it will vary by the RADIUS provider in question and what the RADIUS server supports, accounting generally produces records of authentication. These records can be used for a variety of purposes but typically are used for monitoring access and for audits.
As an example, let’s look at the information contained in a SecureW2 JoinNow Cloud RADIUS event log. Cloud RADIUS event logs contain extremely detailed information tied to the device’s certificate, such as:
- The region the device authenticated from
- The time of authentication
- The MAC address of the device
Administrators can also use this information to troubleshoot when there are connectivity issues.
Types of RADIUS Servers
There are two main types, or modes, of RADIUS protocol servers:
- Synchronous Authentication Mode: A user requests access; the client and server communicate to authenticate the user’s credentials and either grant access or reject the request.
- Asynchronous Authentication Mode: A user requests access; RADIUS security authenticates the credentials and responds with a challenge for the user — usually a code, as in multi-factor authentication (MFA). Based on the user’s response to the challenge, the server will approve or reject the access request.
Admins can configure RADIUS authentication servers to either mode; the choice just depends on your needs.
Synchronous authentication is sufficient for most use cases. Asynchronous authentication can provide an additional layer of security for industries with highly sensitive data and strict regulatory requirements, such as finance and healthcare.
What is RADIUS Protocol? A Brief History
The concept of RADIUS networking was born in the first half of the 90’s, during the internet’s early days. Merit Network, a nonprofit organization that provides networking services to various entities, requested a solution that condensed their authentication, authorization, and accounting systems.
In response, another company called Livingston Enterprises drafted the first version of the RADIUS protocol or Remote Authentication Dial-In User Service.
Initially, the RADIUS protocol only supported credential-based authentication, but it has changed over time to support authentication methods such as digital certificates. This keeps it relevant within the scope of the ever-changing cybersecurity industry. Today, it is part of IEEE 802 and Internet Engineering Task Force (IETF) standards.
Benefits and Challenges of RADIUS Server Security
Benefits of RADIUS
- Reliable Authentication, Authorization, Accounting (AAA): AAA is the primary function of RADIUS; it’s a trusted all-in-one solution for network security management.
- Continuous Trust Verification: RADIUS server logins require consistent authentication and authorization. If admins revoke authorization at any time, unauthorized users will immediately lose access.
- Centralized Authentication Management: RADIUS and the IDPs it references provide one clear source for credential and certificate management.
- Role-Based Access Controls: Personalize access levels by department or role to keep sensitive data secure.
- Scalability: RADIUS is extremely flexible, scaling with you as your organization grows. It can accommodate heavy traffic without failure.
Challenges of RADIUS
- Potential On-Premise Costs: Unless you choose a cloud RADIUS server, you need to purchase, manage, and maintain on-premise hardware.
- Complex Network Infrastructure: One of the benefits of RADIUS is that it’s highly customizable. That means RADIUS authentication server configuration can be difficult to set up and maintain on your own.
- Security Vulnerabilities: As with any network access protocol, RADIUS requires regular monitoring and updates to avoid cybersecurity threats.
- Security Expertise: To set up RADIUS security, you need skilled IT experts. This requires experienced in-house personnel and/or a trusted service provider to configure RADIUS server settings and access levels.
- Reliability: RADIUS uses UDP, which is connectionless — not TCP (Transmission Control Protocol), which is connection-based. While UDP is faster, it may be less reliable and consistent. Using EAP-TLS authentication with RADIUS is the best defense.
On-Premise RADIUS Server or Cloud-Based RADIUS Server?
Some organizations want to add a RADIUS server to their security, but are uncertain whether they should build and manage their own on-premise or use a cloud-based, managed RADIUS authentication server like Cloud RADIUS. There are advantages to either method, and it’s important to consider these before making your decision.
On-Premise RADIUS Server
The main benefit offered by an on-premise RADIUS server is that your organization has total control over everything that goes into it. For some organizations with IT teams that have experience with RADIUS servers, this is an enticing benefit.
However, there are many drawbacks to consider, as well, when building and managing your own RADIUS architecture.
To start with, consider the cost. Although you could theoretically put the RADIUS on any server where you have sufficient space, many organizations look at building a specific physical server for this purpose. Aside from hardware, that means it needs sufficient, secure space in your office somewhere.
This cost increases exponentially if you have multiple office locations. Suddenly, you’re not just establishing one RADIUS — you’re setting up one for each individual location.
There’s also the cost of maintaining a server. Regular patches and maintenance need to be performed, which requires time and effort from your IT team. This time and effort grows if they have little experience with RADIUS servers. Misconfiguration, which is possible with less experienced teams, can cause major security issues and setbacks.
Setting aside staffing and hardware requirements, there’s also the possibility of localized disasters temporarily taking your RADIUS down. Fires, earthquakes, and other types of inclement weather can potentially damage your RADIUS server or take it offline temporarily. This can prevent employees from connecting to your network, dropping productivity and increasing frustrations.
Cloud-Based Managed RADIUS Service
A cloud-based and managed RADIUS authentication server counters all the points we addressed in the previous section.
The same cost considerations no longer apply. You don’t need to build the RADIUS yourself or manage maintenance and patching. All of those things are done for you, allowing you to deploy the security of RADIUS authentication quickly.
Furthermore, since it’s native to the cloud, you don’t need to duplicate the RADIUS at every single office location. This makes solutions like Cloud RADIUS infinitely scalable. With server locations globally available, Cloud RADIUS also enjoys low latency — faster authentication leads to faster connections.
You also no longer need to address physical security. Your IT team doesn’t need to add another server and the space for it. While this might be a small consideration, it’s still an important point, especially when you factor in the redundancy of a Cloud RADIUS service that isn’t taken down by local conditions.
Integrating Cloud RADIUS with Your Identity Infrastructure
Cloud RADIUS was designed to integrate with your current infrastructure so you don’t have to make any major changes or upgrades. It can integrate with all major SAML Identity Providers and even Microsoft’s Active Directory.
The configuration process for this varies depending on which IDP you want to integrate with. If you’re doing EAP-TLS, however, the general infrastructure you need to set up with as follows:
- Tie your PKI to your IDP.
- Tie the Cloud RADIUS infrastructure to your IDP.
- Tie your Device Management platform to the SecureW2 PKI if you’re leveraging our PKI services.
We have more detailed RADIUS configuration guides that provide the configuration steps. If you’d like to learn more about integrating Cloud RADIUS with Azure AD/Entra ID, Okta, or Google Workspace, you can click on any of the links provided here.
Deploy RADIUS Security in Minutes with Cloud RADIUS
Deploying RADIUS security doesn’t need to be difficult, costly, and a headache to maintain. With comprehensive Cloud RADIUS features, you can leverage the strength of RADIUS server authentication quickly at all of your locations.
Plus, because it’s a managed service, you can rely on the expertise of our knowledgeable engineers without hiring a whole new team. We have experience integrating with all kinds of infrastructure and deploying as quickly as you need us to. We’re an award-winning platform for a reason.
If you’d like to learn more about how flexible Cloud RADIUS can be, reach out to us today for a free demo.
FAQs About RADIUS Servers
Are RADIUS Servers Still Used? Is RADIUS Authentication Still Used?
Yes, RADIUS servers are still widely used in 2025, and remain a foundational component of network access control in enterprises, educational institutions, ISPs, and government organizations worldwide.
Despite being a protocol that dates back to the early 1990s, RADIUS has proven remarkably resilient. Its longevity stems from deep integration across network infrastructure: routers, switches, firewalls, VPN gateways, and wireless access points all support RADIUS natively. Replacing it would require significant infrastructure overhauls that most organizations have little incentive to undertake.
Is RADIUS Authentication Still Used?
RADIUS authentication remains the dominant method for controlling network-level access in several key scenarios:
- Corporate VPNs: RADIUS is the standard backend authentication service for most enterprise VPN solutions.
- WPA2/WPA3 Enterprise Wi-Fi: The 802.1X authentication standard that secures enterprise wireless networks relies directly on RADIUS.
- Network Device Administration: IT teams use RADIUS (often alongside TACACS+) to authenticate administrators logging into routers, switches, and firewalls.
- ISP and Telecom Networks: Internet service providers use RADIUS for subscriber authentication and session accounting at massive scale.
Why RADIUS Hasn't Been Replaced
While newer protocols like OAuth 2.0 and SAML have taken over application-layer authentication, no single successor has displaced RADIUS at the network layer. Its AAA framework (Authentication, Authorization, and Accounting) is deeply embedded in the IEEE 802.1X standard, and most modern network hardware ships with RADIUS support out of the box.
RADIUS is evolving. RadSec (RADIUS over TLS) addresses one of the oldest criticisms of the protocol, reliance on UDP and weak transport security, by tunneling RADIUS traffic over encrypted TLS connections, extending its relevance into modern continuous trust architectures.
What is the Difference Between RADIUS Clients and RADIUS Servers?
A RADIUS client is the device transmitting access request messages to the RADIUS server. It’s important to note that the RADIUS client is not the end-user’s individual device. The term RADIUS client specifically refers to a network access server, which can mean wireless access points, VPNs, or an 802.1X switch.
One way to imagine a RADIUS client and RADIUS authentication server is to picture the way mail is sent. You, as the writer of a letter, are a user. The mail truck is the RADIUS client, delivering your letter to the post office. The post office is the RADIUS server, verifying the letter is formatted appropriately (authenticated).
How Does RADIUS Work in Wi-Fi Authentication?
A RADIUS server can be used to authenticate users and devices so they can use network resources. We see them most often used for wired and wireless authentication, but some organizations also use RADIUS server authentication to secure access to Virtual Private Networks (VPNs).
In Wi-Fi authentication, the process varies depending on the protocol you’re using. We generally recommend EAP-TLS, as it is more secure than alternatives like PEAP-MSCHAPv2, which rely on credentials that can be easily stolen or shared. In EAP-TLS, the user authenticates to the RADIUS authentication server with a certificate containing a detailed template with their information.
However, the RADIUS server also verifies itself through a process called server certificate validation, in which it proves it is the correct authentication server by furnishing its own certificate to the device. This mutual authentication is an integral part of EAP-TLS and what makes it so ironclad.
How Does a RADIUS Server Work for VPN Authentication?
Organizations with a remote workforce often look to VPNs to allow employees to securely access company resources from outside the office. The process is similar to what happens for Wi-Fi authentication with some caveats.
If you’re looking to do certificate-based RADIUS authentication with your VPN, you’ll need to verify that your VPN supports both certificate-based authentication and RADIUS authentication.
Even if your VPN doesn’t technically support EAP-TLS, however, Cloud RADIUS can still often integrate with multi-factor authentication (MFA) for more secure VPN authentication. In that case, we can use an Azure MFA license with Cloud RADIUS to perform a lookup with a SAML Identity Provider such as Azure AD/Entra ID. This will trigger the Microsoft Authenticator App to authenticate the session.
Alternatively, many VPNs support certificate-based authentication but not necessarily with the addition of RADIUS. In that case, you can leverage the SecureW2 managed PKI and integrate it with your firewalls instead.
What's the Difference Between RADIUS Servers vs. Active Directory?
A RADIUS server processes requests for network access authentication, authorization, and accounting. The server compares user credentials or certificates against directories called Identity Providers (IdPs) to determine whether to accept or reject the access request.
Active Directory (AD) isn’t a server — it’s actually an IDP that stores user information. So, a RADIUS server may communicate with Active Directory (or another IDP) to verify user credentials before granting access.
What's the Difference Between RADIUS vs. LDAP?
RADIUS stands for Remote Authentication Dial-in User Service. It’s an authentication method commonly used for network access across wired, Wi-Fi, and VPN connections. Depending on your network architecture, it can be on-premise or cloud based. RADIUS can authenticate, authorize, and provide accounting support. RADIUS verifies access through credentials or digital certificates using User Datagram Protocol (UDP), encrypting passwords with shared secrets.
LDAP stands for Lightweight Directory Access Protocol. It’s also an authentication protocol, but with downsides: for example, unsecured credentials and no server certificate validation. It’s typically limited to on-premise implementation. LDAP can authorize and authenticate, but there’s no accounting. LDAP verifies access through credentials only (not certificates) using Transport Layer Security (TLS).
When it comes to LDAP vs. RADIUS, RADIUS provides more comprehensive, secure verification.
What's the Difference Between RADIUS and TACACS+?
RADIUS is an open-standard network access authentication protocol using UDP as its transport layer protocol. It combines all authentication, authorization, and accounting (AAA) processes together, supports 802.1X port-based access control, and encrypts passwords when passing information between client and server.
TACACS+ is a proprietary device administration protocol that primarily works with Cisco devices, using Transmission Control Protocol (TCP) as its transport layer. It separates AAA into distinct processes. It doesn’t support 802.1x network access control, but it encrypts all packets (not just passwords) when passing information between client and server.
When choosing TACACS+ vs. RADIUS, TACACS+ is often the preferred choice for heavily regulated industries (finance, security, defense), while RADIUS is best for organizations seeking simple integration, configuration for multiple devices and device types, and scalability.
What's the Difference Between RADIUS vs. SAML?
Both SAML and RADIUS are widely used authentication and authorization protocols, but they serve distinct use cases and operate in fundamentally different ways. Understanding the differences helps you choose the right protocol for your identity and access management (IAM) strategy.
What is SAML?
Security Assertion Markup Language (SAML) is an XML-based open standard designed for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). SAML is primarily used for web-based Single Sign-On (SSO). It allows users to authenticate once and gain access to multiple applications, which makes it a foundational element of modern enterprise identity federation.
SAML vs. RADIUS: Side-by-Side Comparison
| Feature | SAML | RADIUS |
|---|---|---|
| Primary Use Case | Web app SSO / federation | Network access control |
| Protocol Type | XML over HTTP/HTTPS | UDP-based client-server |
| Authentication Scope | Application-layer | Network-layer |
| Common Deployments | Cloud apps, SaaS, enterprise SSO | VPNs, Wi-Fi, firewalls |
| MFA Support | Yes (via IdP) | Supported (via proxy/extensions) |
| Standards Body | OASIS | IETF (RFC 2865) |
When to Use SAML vs. RADIUS
Choose SAML when your goal is federated identity and seamless SSO across cloud-based or web applications. It integrates natively with IdPs like Okta, Microsoft Entra ID (formerly Azure AD), and Google Workspace.
Choose RADIUS when you need to authenticate users at the network perimeter — such as enforcing access policies for remote workers connecting over VPN or employees joining a corporate Wi-Fi network. For organizations moving toward cloud-native infrastructure, Cloud RADIUS provides a way to bridge these network requirements with modern cloud IdPs.
In many enterprise environments, IT teams deploy SAML and RADIUS together. SAML handles application-layer authentication while RADIUS secures network-level access. This combination creates a “continuous trust” model, providing layered, defense-in-depth security across the entire infrastructure.
