The Definitive Guide to RADIUS

The Why, What, and How of RADIUS Servers


Centralize Network Access Control

If you’re wondering why you should use the RADIUS (Remote Authentication Dial-In User Service) protocol at all, consider this: You may have myriad networking / infrastructure devices, as well as networks that many users need to access and connect to, but you have no central authentication mechanism to enable access. That’s where the RADIUS protocol comes in.

RADIUS is used to connect core user identities stored in a directory like Microsoft® Active Directory®, OpenLDAP™, a cloud directory service, or even on the RADIUS server itself to networking infrastructure. What that means is that each of your users can access the network or VPN with their own unique login information. For ops personnel, they can access networking equipment such as routers, switches, firewalls, and more. Essentially, you’re eliminating the practice of utilizing a single set of credentials, for example, the SSID and passphrase for WiFi access points, for network access across all users in your organization. You have full control over access to critical business IT infrastructure. Therefore, when you need to deprovision access, such as when an employee leaves, removing the user from your core directory effectively eliminates their access to the network, VPN, or infrastructure equipment.

The end result of utilizing RADIUS is two-fold with increases to network security and time savings. Your network gets a security boost because you gain a more granular method of managing user access to network infrastructure. You can even take it a step further by segmenting your network into VLANs and utilizing RADIUS reply attributes to place each user into a section of the network as dictated by their department, unique privileges you might want each to have, or many other attributes.

When it comes to time savings across your entire organization, simply eliminating a single user’s access rather than updating shared access credentials can be great because you no longer need to change the password for all the users in your organization; just deprovision a single user and move to the next task without interrupting anyone’s workflow.

With a little information about why RADIUS may be valuable to your network management, let’s discuss the specifics of what RADIUS actually is.

What is RADIUS?

Defining the RADIUS Protocol

The fundamentals for RADIUS are defined in its ratification as an Internet Engineering Task Force (IETF) accepted standard in 1997. The RFC (Request for Comments), which essentially outlines the standard, can be found here. That document, RFC 2058, describes the RADIUS protocol as based on a AAA framework. AAA stands for Authentication, Authorization, and Accounting.

Essentially, RADIUS is a protocol that determines whether or not a user can access a local or remote network (Authentication), establishes what sort of privileges they’re allowed on that network (Authorization), and then records the activity of the user while they’re connected to the network resource (Accounting). The beauty of RADIUS is that it centralizes these AAA functions across networking infrastructure and locations. Let’s take a look at the pieces involved in the RADIUS protocol.

RADIUS Components

Supplicant - The supplicant is generally software built-in or installed ad hoc on a user’s operating system (Windows®, macOS®, or Linux®) that passes information about a user (username, password, etc.) to a second component, the network access server (NAS), along with an Access-Request query. An Access-Request query is just that, a request for access from a client to a server to utilize a resource like a network.

NAS - In the client/server architecture, the NAS acts as the client. NAS devices can be switches, routers, VPNs, or wireless access points (WAPs) among others. The client asks the server to do work for it, which in the case of RADIUS generally means determining if a user is allowed access to a particular resource—also called authentication.

Server - This is the RADIUS server itself. It waits for requests from NAS devices. Those requests could originate from many different types of devices including VPNs, switches, routers, and WAPs among others. The benefit of RADIUS is that no matter what type of NAS you’re trying to connect to, the RADIUS server centralizes authentication to those devices. Once the server receives the access request, it either verifies the user’s identity via an onboard user database or delegates the information to an identity provider like Microsoft® Active Directory®, OpenLDAP™, or a cloud directory service. If the user is verified, they’re granted access to their requested service when the server sends back an Access-Accept message back to the NAS.

Simple enough, right? That’s the conceptual flow with RADIUS. It can get much more complex and sophisticated, and we discuss that further in the How RADIUS Works Section.

Let’s take a look at some practical examples to get an idea of how this process works in the wild.

Trends in Identity and Access Management (IAM)

RADIUS Authentication in the Office

For the first practical example, we will utilize a scenario that most of us experience at one point or another: You arrive at work and need to access the company WiFi. For the sake of argument, we will assume it’s your first day on the job and you don’t auto-login to the network. Now, in the company you worked at before, the entire office shared a single SSID (network name) and password that was written in a conspicuous place. Sometimes that password would change when an employee quit, or if IT became wary that the password may have been intercepted. Either way it would interrupt your workflow for a bit until you found the new password and updated your WiFi network settings.

In any case, at your new office, there is no shared password that everyone uses. Every employee leverages their own unique username and password combination and they input it into their networking settings. It’s all very seamless from an end-user point-of-view. But, how does it work? Well, it works because your new office has RADIUS implemented. Let’s take a look.

After selecting the network you’re attempting to connect to for the first time, you input your credentials (which are subsequently saved so you don’t need to input them every time you log on to the network). On the back end, an Access-Request to the NAS is sent (most likely a wireless access point or WAP). The NAS then sends that information to the RADIUS server. RADIUS servers have the ability to store user and password information themselves, or the server can check with a database—often either an LDAP-based OpenLDAP instance, Active Directory implementation, or even a cloud directory. If the information you’ve provided is correct, the RADIUS server sends the NAS an Access-Accept response along with any sort of parameters or restrictions regarding what you can utilize on that network.

RADIUS Authentication at School

Imagine you’re a student on a large college campus. You have a username and password for accessing your student account to access billing, register for classes, and keep up with homework. But, if your school utilizes the RADIUS protocol, then you’ll more than likely use those same credentials to log in to the student network.

Campuses are large places filled with a lot of different types of networking equipment and students. Each of those student identities—which could number into the tens of thousands— needs to be passed to the networking gear on campus so students can access class materials, turn in assignments, and more. The thing is, as you traverse from one end of campus to the other, you aren’t accessing the same WAP. Instead you’re accessing many different WAPs that each authenticate users via the central authentication protocol RADIUS.

In short, with RADIUS each student gets their own individual set of credentials to access the network. That means IT admins can protect the network from bad actors by having different networks for students, guests, and faculty to access. It’s a win for both parties.

History of RADIUS

A Brief Look Back

In the late 1980s computer networking was becoming more widespread than ever before. A nonprofit by the name of Merit Networks, which had networked Michigan universities to one another with its MichNet network, won a contract to begin work on the National Science Foundation’s NSFNET project. For those who don’t know what NSFNET was, it was a nationwide network that linked NSF-funded supercomputing centers together.1 The reasoning for this was to connect researchers, students, and resources regardless of location. Ultimately, you could think of NSFNET as a precursor to the internet we know today.

One of the requirements that the National Science Foundation set with respect to NSFNET was that there could be no proprietary dial-in servers—they had to be commercial.2 At this time, users utilized telephone lines and modems to dial-in to networks. For Merit, their proprietary servers would not work given the stipulations put in place by the National Science Foundation. So, Merit submitted a Request for Information (RFI) and was contacted about half a year later by Livingston Enterprises in 1991.3

Livingston’s proposal essentially described the first RADIUS-like server that allowed for remote authentication. Merit awarded the contract to Livingston, and Merit began installing Livingston “Portmaster” servers in its MichNet network.4 Essentially, this work enabled people from all over the state of Michigan to dial-in and remotely authenticate into the MichNet network, as well as connect to NSFNET.

So although RADIUS was proven to work for its intended purpose of remote authentication, there were some reservations about whether it was acceptable as a standard. But, as soon as RADIUS became available as an internet draft, it was widely adopted by NAS vendors. Then, due to demand for the AAA capabilities, RADIUS would go on to become a ratified standard with the RADIUS RFC (Request for Comments) 2039.5

How RADIUS Works—Early Days

In this section, we’ll provide a general overview of how RADIUS works. This will be our discussion on how RADIUS was set up to work in its early incarnation. Having an understanding of how RADIUS was utilized in the past will give you an idea of how it works now. Of course, with new advancements in technology, different methodologies (e.g. 802.1x authentication) crop up, which we will cover in the next section down.

RADIUS at the Outset

As we know, RADIUS is broken up into three parts. These parts are the:

  • Client/Supplicant: Essentially the device and user seeking access to a network.
  • NAS: Network Access Server that serves as the gateway between a user and a network.
  • RADIUS Server: Authentication server that ensures the user is allowed to access the network and what permissions they are allowed. The server can also provide accounting functions for the purposes of billing, time tracking, and device/connection details.

So, while we already have a basic understanding of RADIUS components, what are the underlying mechanisms that enable a user to authenticate into a network? We’re glad you asked.

Creating a Connection

Of the different types of protocols (Telnet, rLogin, PPP, SLIP, etc.) that a RADIUS server could authenticate users to in those days, PPP was used most often for the types of use cases we most readily recognize—authenticating a user onto a network via their credentials. Specifically, PPP, or Point-to-Point Protocol, is a framework for establishing a direct connection between two nodes—like a supplicant (i.e. the end user) and the NAS. Moving to communication from the NAS to RADIUS server, every communication between the two is authenticated via a shared secret. The shared secret is a password that is exchanged between the NAS and RADIUS server; it happens invisibly and end users never see it happen.

Data Transmission

Within the IP protocol, there is something called a transport layer. In the transport layer, data gets bundled into packets. Those packets include request types, usernames, passwords, and more. Transport can happen over both the UDP and TCP protocols. For reference, you may be familiar with the acronym TCP/IP as it is the most widely used transport protocol on the internet. RADIUS by default uses an alternative transport protocol: UDP.

The differences between TCP and UDP explain why UDP was chosen. Essentially, UDP has a much lower transmission overhead. TCP is always checking to ensure that data sent has in fact been received. If it has, it is notified. That’s more overhead. Plus, it aggressively resends data to ensure that it gets through. All these moving parts contribute to network congestion, which was a major concern for the low-bandwidth networks of the early 90s. In the case of RADIUS, it is up to the RADIUS server to ensure that the transmission was a success, not the transmission protocol.

Essentially, a chain of events occurs when an end user inputs their information into their network settings. That process is shown in the following authentication workflow graphic (with CHAP authentication used).

RADIUS Authentication

Authentication Protocols

Basically, in order to receive an Access-Accept packet from the RADIUS server (which means that the end user device can access the network), you need to enter the correct information as defined by the authentication protocol that has been put in place to protect the network. For late 90s RADIUS implementations, that could mean a few different protocols that worked with the Point-to-Point Protocol: PAP and CHAP.

What is PAP?

One of two authentication protocols used with PPP is PAP. PAP stands for Password Authentication Protocol. PAP, on the end-user side, works as we all readily understand. For example: First, the user inputs a username and password. That information is provided by the user to the client who then sends it from the NAS to the RADIUS server. Unfortunately, PAP is terribly insecure because it sends both the username and password in plaintext, meaning that anybody who has the ability to intercept packets between the NAS and RADIUS server would be able to discern the username and password easily.

What is CHAP?

CHAP stands for Challenge Handshake Authentication Protocol. It is a more secure method of authentication than PAP (although it wasn’t hard to be more secure than a clear-text password communication). CHAP eliminates the process of sending clear-text passwords and instead utilizes encryption to mask the information being transferred. It works like this.

After the user inputs their password, their supplicant will combine that password with a random string of numbers (challenge) that it received from the NAS. It then runs that combination (password and random string) through something called an MD5 hash. This basically scrambles the two together and makes them unintelligible. This is called the response. The RADIUS server receives the username, challenge, and response and looks up the password that corresponds with the username. It combines the challenge with the password in its database and hashes it. It then compares the result to see if it matches the response received. If so, the user is allowed access to the network.

The problem is, the RADIUS server needs for the password to be stored in plaintext in order to properly hash it so that it can get a result that it can accurately compare to the responses it receives. That’s a problem. Should your RADIUS server be compromised, every user’s password would be in plaintext and easy to steal. That’s why more advanced authentication protocols have since been conceived.

802.1x Authentication and RADIUS

We know that RADIUS was first designed to work with dial-in networks, but nowadays the majority of users are connecting their systems to networks via Ethernet cables to a Local Area Network (LAN) or WLAN (Wireless Local Area Network/ WiFi). These connections follow the standards as prescribed by the IEEE 802.1x RFCs. 802.1x authentication basically sets the parameters for devices and outlines three distinct components (this will look familiar):

  • Supplicant: Again, the software on a client device. Provides a user’s credentials.
  • Authenticator: Network devices that enable a client to access a network resource. Can be a wireless access point (WAP) or Ethernet switch.
  • Authentication Server: A RADIUS server is the most commonly used for 802.1x authentication, though it is not required.

Similarities to the Past

802.1x uses the Extensible Authentication Protocol (EAP) framework for moving authentication packets between two components. The main difference is that EAP can leverage many more authentication protocols than simply PAP or CHAP. This includes protocols such as EAP-TLS, EAP-TTLS, and EAP-PEAP among others. The key here is that EAP is not a protocol itself; it is a framework for establishing a request/response pattern. It is extremely flexible, which is why you see the acronyms TTLS, TLS, and PEAP attached to it.

But, before we get into those authentication methods, let’s take a quick look at how the data moves between the different components in 802.1x authentication.

802.1x Authentication

You see, there are many striking similarities between how RADIUS works for 802.1x authentication and how it worked with modems and phone lines.

More Similarities

Instead of having to initiate a PPP connection to a modem to dial out to another modem, the supplicant in this case creates an EAPOL or Extensible Authentication Protocol Over LAN connection. Notice in the example above that this is not a physical connection between LAN cables; instead this is demonstrating a WiFi connection. But it could be a wired connection as well. Now, in the place of the NAS server, you see something called an authenticator. The authenticator simply acts as the doorman to the internet or other LAN resources for wired connections. The authenticator could be a switch, and for wireless connections it could be a WAP (wireless access point). In our earlier description, you can interpret this as taking the place of the NAS. Now, the RADIUS server is in the same position. It performs the same function, except it utilizes many stronger types of authentication protocols.


For wireless networks, protocols like EAP-TLS, which stands for Extensible Authentication Protocol - Transport Layer Security, can be very helpful. With physical connections, security was built in. Bad actors would need to physically connect to a switch or another piece of networking infrastructure in order to get on the network. But, when wireless connections came into play, bad actors could launch man-in-the-middle attacks that intercept valuable information between two users who think they’re engaged in secure communication. This worked by tricking users into thinking they’re connecting to trusted resources, but they’re actually connecting to bad actors.

In order to prevent man-in-the-middle attacks, digital certificates, called CA (certified authority) certificates, are used to authenticate users. There are no passwords exchanged. In the case of EAP-TLS, both parties exchange a certificate in order to authenticate to each other. That way, each party is aware of who and what they’re connecting to. One significant challenge as it relates to EAP-TLS is that it requires a lot of manual configuration in order to make it work. That has resulted in other protocols like EAP-TTLS and EAP-PEAP being used in place of it because they only require the client to authenticate to the server.

Below is a graph to demonstrate a EAP-TLS authentication flow between the constituent parts. Note that because EAP is an authentication framework, it prescribes how these types of communications happen for all EAP-related authentication protocols. Some have additional requirements, though, like client authentication.


By now, you may remember what EAP stands for, but what about the extra “T” in TTLS? Well, that stands for tunnelled. EAP-TTLS, like EAP-TLS, utilizes the transport layer security protocol, but TTLS only utilizes an authentication to the server using a certificate. The server does not authenticate to the client via a CA certificate. It is not as robust from a security perspective as EAP-TLS, but it also does not require near the amount of configuration. Instead, in order to achieve authentication with the client, a TLS tunnel is negotiated between the server and client.

A TLS tunnel is encrypted, so all data that travels between the two points is encrypted too. Once the RADIUS server receives the information from the client, it unencrypts it and verifies the user is in fact able to access the requested resources. If the user is verified, then s/he can access the requested resource.


PEAP stands for Protected Extensible Authentication Protocol. Like EAP-TTLS, it utilizes an encrypted TLS tunnel to send information between the components. As previously noted, PEAP is like TTLS in that it utilizes a certificate to authenticate the client to the server, but the server does not authenticate to the client.

One of the biggest reasons for the usage of EAP-PEAP is that it can be used with a lot of legacy authentication protocols, so it is able to help modernize IT environments with older infrastructure.

RADIUS Implementation

When it comes to actually putting boots on the ground and implementing your own RADIUS server, you have many options to consider. Chief among them, “Do I want to set up, secure, and maintain my own server?” If the answer to that is yes, you’re looking for an on-prem implementation. That said, implementing a RADIUS server requires a good amount of technical knowhow and expertise, so some are likely to seek out an alternative. That alternative would be a RADIUS server hosted externally—or in the cloud.

In this section, we will break down some of the common on and off-prem RADIUS implementations like FreeRADIUS, Microsoft NPS, and JumpCloud® Directory-as-a-Service®, while giving a basic overview of systems such as Cisco ISE.



The FreeRADIUS project was started in June of 1999 by Alan DeKok and Miquel van Smoorenburg. According to surveys done by FreeRADIUS, it is the most widely used RADIUS server today. FreeRADIUS was started because the Livingston server was no longer being maintained.

Nevertheless, FreeRADIUS exists as open source software. Anybody can download it and install it on their machine, whether that’s a desktop machine or an outright server. But, in order to install FreeRADIUS you need to run an operating system like Ubuntu, a Debian-based OS, CentOS, RedHat, or macOS. Or, you can simply buy a FreeRADIUS server from NetworkRADIUS, an offshoot of FreeRADIUS. Side note: If you’re looking to utilize FreeRADIUS on a Windows machine then you need to navigate to and follow the instructions found there.

Because of the need for hardware, FreeRADIUS is not exactly a free implementation. You need to have some sort of hardware to install the software on, and depending on your needs that can get quite expensive. In terms of cost, you also need to factor in network / infrastructure components, electricity, and the price of having somebody actually set the server up. Additional considerations have to do with space and the noise that these servers can make. For smaller companies this can be prohibitive.

Setting FreeRADIUS Up

For a beginner, FreeRADIUS can seem a bit daunting. There is no graphical user interface (GUI); everything happens on the command line. That’s why you’ll find many Google™ searches for FreeRADIUS GUI. This search is not likely to bear fruit unless you leverage a cloud RADIUS solution, Microsoft NPS, or add on an additional program to manage your RADIUS implementation, which of course increases complexity. Ultimately, in order to get FreeRADIUS working, you’ll need to become acquainted with the command line.

Thankfully, you can find a lot of documentation on both the FreeRADIUS Getting Started page, as well as GitHub’s FreeRADIUS page. These pages demonstrate the technical nature of FreeRADIUS. Each page goes over how to install FreeRADIUS and what to do after you’ve installed the software. Many of these steps require you to have deep technical knowhow, but ultimately, with that experience and knowledge it should not be too hard to get the RADIUS server off the ground—so to speak. You’ll need the IP address of your NAS and some of the information regarding your clients to validate that everything is working.

Once you’re set up and you have some devices connected to your server, FreeRADIUS works as the backend for the 802.1x authentication process. Plus, because it is based on RADIUS, FreeRADIUS supports just about every authentication protocol used today like EAP-TLS, EAP-TTLS/PAP, EAP-PEAP, and many more. Flexibility is its nature, which is often a hallmark of open source software.

In keeping with the idea of flexibility, RADIUS is a modular protocol, meaning you can add different capabilities to it with simple module installations. If you utilize Active Directory as your directory, you can also leverage Microsoft-centric authentication protocols like MS-CHAPv2 as well. Essentially, you can add different protocol types or attach different directories for your FreeRADIUS to search for users during the authentication process. Take a look here.


Now, the thing is, with a FreeRADIUS server, getting it set up is just a small fraction of what actually goes into making sure that it continues to run smoothly and effectively. You will need to constantly document everything that you’re doing to ensure that you can fix things when they break. That means recording all devices and users that leverage the server. As you ratchet up the number of users, NASes, permissions, OSes, supplicants, locations, and security considerations, you need to ensure that load balancing and high availability are at the forefront of your mind. The complexity here can be vast.

However, when FreeRADIUS is set up correctly with the proper infrastructure, you ensure that your network is safe and that only those with the required credentials are allowed to access it. Further, FreeRADIUS is extremely flexible; you can source user information from Active Directory, SQL, or LDAP servers, and modules are readily available for you to leverage. A major con is that if your RADIUS server goes down, no user will be able to access the network. This is why high availability, load balancing, etc. are so pivotal.

All told, FreeRADIUS is an excellent open source option for taking advantage of the RADIUS protocol if you are willing to do all of the heavy lifting required. That means purchasing all of the equipment and infrastructure necessary, setting up the software, and configuring all the users to authenticate to your network via RADIUS. Although it doesn’t cost anything for the software alone, the costs quickly rise depending on whether you build your server or purchase it outright, as well as the capabilities that it needs to have.

Microsoft NPS

Another on-prem RADIUS implementation, Microsoft’s Network Policy Server (NPS) is a set of features within Windows Server that allows for the same AAA functionality of the RADIUS protocol. A little bit of digging into the history of Microsoft NPS shows that it wasn’t always called Network Policy Server. Microsoft used to call it the Internet Authentication Service, or IAS for short.

Just like RADIUS, Microsoft IAS had been around for a long time. It was included with a Microsoft Server-like product when Microsoft released Windows NT 4.0 all the way back in 1996. It’s interesting to note that Microsoft included RADIUS with its Windows NT 4.0 OS before it was a recognized IETF standard in 1997. Unlike FreeRADIUS now, Microsoft NT was not free to download and it was closed source, so you would need software licenses and server hardware.

That same story continues into today with Microsoft Server 2019. Microsoft has created a revenue-making machine with its Server line of products, in large part because the early days of enterprise computing were dominated by the Microsoft ecosystem. You had Windows machines, running Windows applications, managed by Windows servers. The common denominator is Microsoft, and this strategy has enabled them to get a major foothold in IT. Even into today, as IT moves away from the all-Windows paradigm, Microsoft maintains its enormous presence.

Setting NPS Up

Per Microsoft’s documentation, “NPS is installed when you install the Network Policy Server in Windows Server 2016 and Windows Server 2019.” [Microsoft] If you’re new to RADIUS and don’t have much experience with the command line, Microsoft Network Policy can be a major boon to you. One of the reasons is that Microsoft Server utilizes a fleshed-out GUI. In that same vein, for much of the functionality that you need to set up, you will find that Microsoft has provided a wizard, AKA a to-do list, to help you get your NPS server set up correctly. It’s a far cry from setting up a FreeRADIUS server, but that accessibility comes at a cost. You’ll need a server license and a decent server to set it up on, data center space, networking components, load balancing, security processes, and high availability to ensure that your setup works now and in the future.

Because your NPS will be installed on a Windows Server implementation, you’ll be authenticating your users against an Active Directory® backend. You just need to make sure that NPS and AD are linked. That ensures that your users are on the domain, so all you’ll have to do is set permissions for what they can and cannot access. Because everything in this system is built-in, you won’t need to add additional modules or anything to the mix.


If you do choose to go this route, you’re going to be tied to Microsoft. This can be a good and a bad thing. Microsoft has ample configuration documentation available, forums, and more on its website to ensure you get the most out of your product. Plus, as a leading vendor, IT pros study for Microsoft certifications, so the skillset is widely available.

But, as stated previously, it is a costly endeavor that forces you to remain on-prem, thereby limiting your ability to shift core infrastructure to the cloud. That said, you’ll need a decent server, plus the server license and software. Depending on your situation, that could cost significant dollars. Plus, Microsoft products often have a forced end of life (EOL), so even if your software and hardware are working well, Microsoft can stop supporting the software, essentially leaving you open to security vulnerabilities and forcing you to upgrade, costing you more money. Ultimately, if you’re looking to manage a pure Windows environment, this can be a great option. But you need to make sure you consider your environment and the risks inherent to vendor lock-in.

Cisco ISE

Cisco ISE, like Microsoft’s NPS, used to be called something different as well; it was known as Cisco ACS. Like NPS, it is a closed-source platform that makes use of the RADIUS protocol for authentication, authorization, and accounting (AAA). Aside from those basic functions, Cisco ISE provides a lot of benefits that fall outside the grasp of the RADIUS protocol.

These include elements such as “real-time contextual information from networks, users, and devices.” [Cisco] Unlike RADIUS in general, Cisco ISE is much more aimed at providing compliance and actively monitoring network environments to ensure they’re safe. RADIUS is simply the mechanism by which authentication, authorization, and accounting occurs. You can buy the software license by itself, or you can buy pre-built servers from Cisco (called the Cisco ISE 3300 Series appliance) or other vendors with the software pre-installed. It should also be noted that you can install the ISE software on a VMware® server like the ESXi.

Pros of this system include wide visibility into your network environment. You will be able to see everybody and every device that enters your network. Cons include the fact that whatever you install the ISE software on will then become a dedicated ISE machine. Unlike FreeRADIUS and Microsoft NPS where the software runs on a server in the background, your Cisco appliance will be dedicated to one task: network policy management. Plus, these servers can be prohibitively expensive for the majority of SMBs out there, which is most likely why FreeRADIUS is as popular as it is.

All in all, an on-prem RADIUS implementation can be a lot of work. But, if you’re utilizing an on-prem RADIUS server and your network goes down down, you will still be able to authenticate into local assets. On the flip side, if your RADIUS server goes down, your network follows. Ultimately, it is up to you to decide what’s important here. For many, offloading the work of setting up and maintaining a RADIUS server is worth it because they get the benefits of RADIUS authentication without all the headaches that go along with network outages, downtime, and costs.

Off-Prem / Future of RADIUS

Do You Need an On-Prem RADIUS Server

Perhaps you just read the on-prem implementation section and have never set up a RADIUS server, or you have set one up and know of the technical workload that comes with standing up a RADIUS instance and don’t want to deal with it. If that’s the case, then consider a hosted RADIUS solution. These solutions often go by many names, like RADIUS-as-a-Service, cloud RADIUS, virtual RADIUS, and more. While the names might vary, the idea and functionality remain constant. Basically, service providers have set up RADIUS servers all around the globe for you to use to secure your network. If that sounds like something you would like to consider, keep reading.

Hosted RADIUS Overview

Hosted solutions are inherently easier to work with than their on-prem counterparts. Plus, they often cost less because they require no significant upfront investment in the form of servers, software licenses, labor costs, and the bevy of infrastructure needed. The servers are already paid for, deployed, and configured, so admins simply reap the benefits.

Furthermore, IT admins don’t need to become RADIUS experts (or pay them) to utilize the security benefits that RADIUS offers. They don’t need to figure out which RADIUS server instantiation to use, if they have the budget for it, or where the thing will actually be placed in their datacenter along with the networking gear and infrastructure associated with that setup.

What IT admins do need to figure out is if the directory they’re using is compatible with the service they are aiming to utilize, the types of authentication methods their systems leverage, and whether or not their networking devices (WAPs, switches) are up to snuff. Thankfully, that’s a lesser ask than actually setting up a RADIUS server from scratch. Plus, when it comes to authentication protocols, if your fleet consists of up-to-date machines, it is likely this issue will be a non-factor.


Different services require different setup tasks. Some services, such as JumpCloud, are relatively painless and cloud-forward. They require the admin to configure the hosted RADIUS server from within the platform. Then, the admin needs to configure the wireless access points; after that, it is time to configure each client (or laptop/desktop). Others services require admins to install agents on an on-prem Windows server to take advantage of RADIUS. For some, this might be less than ideal, but you need to consider your environment so you can make the best choice for your organization.

Learn More about Cloud RADIUS with JumpCloud

Hosted RADIUS Servers from JumpCloud are a great way to gain all the benefits of network authentication with RADIUS, without all the hassle of actually setting up RADIUS for yourself. If you would like to see how it works for yourself, contact a product expert to learn more.