RADIUS Authentication: How It Works

RADIUS is imperative for securely authenticating users for network access.

Approximately 54% of the US workforce is potentially able to cause an accidental internal security breach. Given that a network is only as strong as its weakest link, enterprises that conduct business online need to ensure robust network security. WPA2-Enterprise with 802.1x is the gold standard for wireless authentication, and RADIUS servers play an integral part.

RADIUS is imperative for securely authenticating users in a network access server. It also allows organizations to use unique authentication keys for each user, rather than one single pre-shared key like we use with our home Wi-Fi. Read here about how a marketing firm successfully secured its offices globally with our Cloud RADIUS.

This article covers RADIUS authentication at a high level and features an easy way to implement RADIUS in the cloud.

What is RADIUS?

Remote Authentication Dial-In User Service, or RADIUS, is a client-server protocol that secures the connection between users and clients and ensures that only approved users can access the network. It is a networking protocol that offers users a centralized means of authentication and authorization.

The earliest RADIUS was developed by Livingston Enterprises in 1991. It was designed to replace dial-in services used then so that the internet would be more accessible to the average person. Nowadays, RADIUS servers see a wide range of implementations. Some examples include CISCO ISE, our own Cloud RADIUS, and Microsoft’s NPS.

In the RADIUS authentication flow, RADIUS acts like the bouncer, with your network being the club. Users requesting access are like guests at the door. Each “guest” presents proof of their identity, which takes the form of credentials (username and password) or certificates. The RADIUS then checks that the user is valid by referencing a directory, much like how a bouncer might check a list of approved guests before letting someone in. Once verified, they send a message (ACCESS_ACCEPT) to the Wireless Controller or VPN Server, which will then open a port for the user.

RADIUS Servers are also known as AAA servers because they provide authentication, authorization, and accounting services. We’ll discuss in more detail below what each of those terms entails.


Authentication is the process of determining whether a user requesting RADIUS network access is active and approved. Authentication begins the moment a user attempts to log into the network.

Their device will request access either through the use of credentials or by presenting an X.509 digital certificate. The RADIUS server authentication, much like a bouncer, will compare the user’s information with a list of users stored in a directory or IDP (Identity Provider). Common examples of cloud  IDPs in use today include Azure AD, Okta, and Google.


Once the user has been authenticated, the next step in the process occurs is authorization.Authorization is when the RADIUS determines how much access someone on the network will be granted. The level of access is determined by the policies set by network administrators.

This step goes hand in hand with zero trust policies. A RADIUS server can be used to segment different levels of access, ensuring that each user only gains access to the resources they need to do their work.


Finally, the user is granted the level of access warranted by their role. As they access the organization’s network, the RADIUS server’s innate accounting ability comes into play.

Remember, to access the network in the first place, and the user had to present credentials or a certificate tied to their device. Because of this, network administrators are able to see exactly which devices and users are tapped into the network at all times.

Logins and user activity are all monitored and logged. If there is any unusual activity on the network, administrators can determine exactly where it came from.

The RADIUS Authentication Process

Authentication and Authorization can happen simultaneously: the RADIUS verifies the user (authenticate) and checks what network policies are assigned to the user (authorize). We’ve provided a general breakdown of the authentication process with credentials (username-password) and then with x.509 certificates

Credential Authentication

  1. The user inputs their network credentials, attempting to connect to a network. This is then forwarded to the RADIUS Server.
  2. The client (end user) sends an Access-Request message containing the authentication method and the RADIUS shared secret to the RADIUS server.
  3. The RADIUS server verifies the RADIUS client with the shared secret. Then, the RADIUS server verifies the authentication method.
    • The RADIUS server runs on TLS and can be configured to authenticate users with EAP-TLS, EAP-TTLS-PAP, or PEAP-MSCHAPv2. We’ll cover this more below.
  4. In the case of credential-based authentication, the server compares the user credentials against the user database verifying that the user is active. In the case of certificate-based authentication, it verifies the user’s client certificate against the Root Certificate Authority.
    • No matching credentials means the RADIUS server responds with an Access-Reject message.
    • After verification, the server then checks for any access policies or profiles matching the user credentials.
  5. If the server finds a matching policy, it will send an Access-Accept message back to the RADIUS client.
    • The message contains the same shared secret and a FilterID, which tells the RADIUS client which RADIUS group the user is assigned.
  6. The user is both authenticated and authorized, completing the process and granting the user network access.


Certificate Authentication

Certificate authentication comes in a few flavors, but here we talk about mutual authentication – a type of certificate authentication between clients and servers. This is what it looks like when you attempt to connect to Wi-Fi using a digital certificate for RADIUS server authentication:

  1. The client device attempts to connect to a familiar access point; the user enters no credentials as certificates are communicated and authenticated without end user interaction.
  2. The TLS handshake between client and server occurs. First, the server sends its own certificate with public key (for server certificate validation).
  3. The client ensures the certificate is valid using its matching private key and confirming the Certificate Authority (CA) that signed the server certificate is listed in its trusted root store.
  4. The client responds to the server by sending its own certificate and public key. The server confirms validity in the same manner, and authenticates the client for access to the network.
  5. At this point, the RADIUS server authorizes access to specific resources (parts of the network) based on policy rules configured in the directory or on the certificates themselves!


Certificates serve as a better user/device identifier because user information can be stored on the certificates and admins can use certificates to manage privileged access levels. SecureW2 provides a Cloud RADIUS server that allows you to authenticate your certificates and also check user, group, and device information in your Identity Provider (IDP) at the moment of authentication.
In addition, you can deny or allow network access (or send custom RADIUS attributes) based on Time of Day, NAS-ID, User Roles, and much more with our Network Policies.



In order to answer this question, it’s important to understand on a basic level what UDP and TCP are. UDP (User Datagram Protocol) and TCP (Transmission Control Protocol) are both ways of sending data packets over the internet.


The main difference between them is whether they require a connection between sender and receiver or not before sending the packets. UDP, as a connectionless protocol, does not require this connection before sending the data. TCP does require a connection.


There are advantages and disadvantages to either protocol. TCP, for example, is incredibly consistent and ensures all the sender’s data reaches the receiver. However, it needs more bandwidth as a result of the connection it requires, making it slower.UDP is faster than TCP. One drawback to the protocol is that it is not as reliable as TCP, so data packets may become lost along the way.


By default, RADIUS transports using UDP. But in 2012, the Internet Engineering Task Force (IEFT), an organization that develops Internet Protocol standards, released RFC 6613, allowing RADIUS to use TCP protocol for TLS. While UDP’s connectionless protocol may seem like a security risk, organizations that authenticate with EAP-TLS are protected.




Yes, RADIUS can use the LDAP protocol to communicate with servers designed for LDAP communication. Active Directory (AD) is a widely-used platform that uses LDAP for authentication purposes. However, AD is notorious for its lack of flexibility when it comes to cloud computing services. Luckily, SecureW2’s Cloud RADIUS makes it easy for AD-domain admins to bridge the gap from on-prem to cloud.


LDAP is not the only protocol RADIUS can use to communicate with directories. SAML is another protocol that RADIUS is capable of using. Let’s take a look at the differences between the two.


RADIUS Authentication: LDAP vs SAML


The biggest difference between LDAP and SAML is that LDAP is designed to communicate with on-prem servers while SAML communicates with cloud-based servers and applications. With businesses increasingly moving their computing to the cloud, this makes SAML the only long-term solution.


Azure AD, where Microsoft’s cloud directory is located, primarily supports SAML authentication, as do other cloud directories like Google and Okta. SecureW2’s Cloud RADIUS can be configured with either SAML or LDAP, which means it can seamlessly integrate with your on-prem or cloud network – or even a hybrid environment.


What is the Default RADIUS Authentication Port?


By default, the RADIUS server uses UDP 1812 for authentication and authorization and 1813 for accounting as defined by the IETF, but can also use 1645 and 1646.


How 802.1X Protocols Make RADIUS Secure

The authentication protocol your network uses determines the security strength of your RADIUS. As stated before, the three most common protocols organizations use for 802.1x are:

  • PEAP-MSCHAPv2 (credentials)
  • EAP-TTLS-PAP (credentials)
  •  EAP-TLS (certificates)

Authenticating with x.509 certificates is the most secure form of authentication since certificates are themselves encrypted with asymmetric cryptography, protecting the input information from malicious actors even if the certificate falls into their hands. On the other hand, credentials are only protected by the authentication protocol’s communication standards (which is just the icing on the cake in the case of certificates).

SecureW2 has recently innovated new features for RADIUS encryption that further enhance its security and usability. The new Dynamic Cloud RADIUS by SecureW2 is the industry’s first passwordless authentication solution for cloud directories like Okta, Google, and Azure.

It can reference the directory for user attributes or roles and make runtime-level policy decisions, reducing reliance on static certificates for group policy and user segmentation. Want to know more about Dynamic Cloud RADIUS? Click here.

RADIUS Authentication Protocols


TTLS-PAP is a credential-based authentication protocol with its main draw being the encrypted tunnel when a client and server connect. While encrypting a tunnel is well and good, many cyber attacks, most notably the man-in-the-middle attack, can just impersonate a server or client and connect with its victim, rendering the encrypted tunnel useless.

Furthermore, EAP-TTLS-PAP sends user credentials using CLEARTEXT, meaning those credentials aren’t encrypted, and malicious actors can obtain login credentials. If the network authenticates with a password shared among the office, the entire network is vulnerable to data theft.


PEAP-MSCHAPv2 is a Microsoft protocol and thus the authentication method was designed to be used for Windows and AD-Domain environments. Just like TTLS-PAP, PEAP is a credential-based authentication method, and again, just like TTLS-PAP, PEAP suffers from a glaring vulnerability. There is a well-known weakness in PEAP’s encryption method, which can be exploited, and the network is still at risk for credential theft.


EAP-TLS is the only certificate-based authentication protocol and is widely known for its strong security measures. Digital certificates are cryptographic keys and encrypt user information. Networks configured for EAP-TLS mean that both clients and servers are equipped with certificates to more easily identify approved users and automatically grant them network access.

Furthermore, EAP-TLS completely eliminates the risk of over-the-air credential theft, and it provides much higher assurance levels that the person connecting to the network actually is who they say they are.

Authenticating with Cloud RADIUS and Digital Certificates

radius authentication

If you want to use EAP-TLS, you will need a PKI. A Public Key Infrastructure (PKI) enables organizations to issue and manage x.509 digital certificates that can encrypt connections between end-user devices and RADIUS servers. Certificates are encrypted themselves, so even if a malicious actor could obtain one, they wouldn’t be able to authenticate. On the contrary, other personal identifiers can be intercepted and used to fake identities – such as the recent case of purchased Slack cookies being used to infiltrate Electronic Arts.

Certificates are incredibly user-friendly, automatically connecting approved devices to a network without input (like remembering passwords) from the user. Network segmentation is also improved as admins can more efficiently categorize users based on their role in the company.

SecureW2’s Cloud RADIUS and managed PKI were designed to be extremely easy for organizations to use together. As a result, it’s simple for organizations to secure their RADIUS authentication with EAP-TLS. It gives organizations a one-stop-shop to set up WPA2-Enterprise and 802.1x EAP-TLS for secure wireless authentication.

The Benefits of Cloud RADIUS

It’s easy to see why using a RADIUS server is a wise move. However, setting an on-prem RADIUS server up takes time, money, and other resources. So, how can you weave a RADIUS server into your infrastructure in the most economical way possible?

The answer lies in the cloud. Implementing a cloud-based RADIUS, like SecureW2’s Cloud RADIUS, offers you the benefits of a RADIUS server at a fraction of the cost. 

There are many compelling reasons to integrate our Cloud RADIUS server with your current infrastructure. The first is how it can be seamlessly integrated into any cloud infrastructure such as Azure AD, Okta, or Google. 

Another benefit of our Cloud RADIUS is the way it enhances policy enforcement. When users attempt to authenticate against the RADIUS server (for Wi-Fi, VPN, or Application Access), the RADIUS will compare their information with what’s currently in your directory and apply the correct access policy. That way, no one has unfettered access to resources they don’t need.

Securely Authenticate Users with SecureW2’s Cloud RADIUS

RADIUS is a key security feature for WPA2-Enterprise and 802.1x. Networks can configure secure authentication for Wi-Fi, desktop login, VPN, email, and more using RADIUS. SecureW2’s Cloud RADIUS makes the process of X.509 certificate implementation super easy because Cloud RADIUS comes with SecureW2’s turnkey PKI. In a matter of hours, network admins can integrate their networks to set up RADIUS authentication.

SecureW2 is the only vendor in the industry that provides organizations with a cloud-based RADIUS server, full-suite PKI services, and everything you need to implement them.  Click here to check out the pricing for the solutions we can offer to any type of business.


Sam Metzler

Sam (aka Slammin Salmon, Street Hustler Sam, Samilstilskin) is a copywriter within the marketing team and a man of many nicknames. He has a degree in Marketing from the University of North Texas with previous experience in mortgage marketing and financial services.

Related Post