Every few years, someone announces that RADIUS is dead. They are still wrong.
Alan DeKok, CEO and Founder, InkBridge Networks
The specifics vary. Sometimes the argument is that RADIUS is too old, relying on cryptographic primitives from 1993. Sometimes it’s that the protocol is insecure by design. I’ve heard it said that RADIUS is now just a wrapper around a REST API that wraps a service database, so why not cut out the middleman?
My answer to these arguments hasn’t changed for decades. RADIUS isn’t going anywhere, for a number of very real and specific reasons.
What does RADIUS do?
RADIUS is the world’s most widely deployed network access control protocol.
When a user connects to a Wi-Fi access point, a VPN, or a wired network port, the network access server (NAS) (the access point, switch, or VPN concentrator) sends a query to a RADIUS server: should I let this person in?
The server responds with an accept, reject, or challenge.
The NAS then decides what to do with that response.
The common belief is that the RADIUS server is in charge. It’s not. The NAS makes the final call. RADIUS can be thought of as a database query protocol: a standardised way for network equipment to ask an authentication system yes-or-no questions. Once you understand that the NAS controls the outcome, a significant category of troubleshooting confusion disappears.
Understanding that architecture is also essential for evaluating any proposed replacement. The alternative doesn’t just need to store credentials and verify them. It needs to work within the NAS-query-and-respond model, over whatever transport the NAS supports, at whatever scale the network demands.
Why a REST API is not the answer
To begin, the argument that RADIUS is just a REST API wrapper gets something right and most things wrong.
It’s right that RADIUS often sits between a NAS and a back-end database, and that the RADIUS server translates between the two. In that sense, yes, RADIUS is acting as a translation layer.
The argument misses why that translation layer exists and what it has to do.
The first issue is transport. RADIUS runs over UDP, and this is deliberate. UDP is connectionless and lossy by design; a packet can be dropped and the client simply retransmits. For network authentication at scale, this is a feature.
TCP, which underpins REST APIs and HTTP, has “head of line” blocking. If one packet is lost, all subsequent packets wait until the first one is successfully transmitted. This is a desirable feature for viewing web pages. It’s a problem for RADIUS. It’s better for RADIUS systems to make some progress, rather than making no progress.
The second issue is encoding. RADIUS represents attributes as compact binary type-length-value tuples. JSON is text. Even compressed, JSON is larger. At scale, meaning ISPs with tens of millions of subscribers, that additional data volume adds up, and the server has to parse it. These are the reasons that high-throughput systems have avoided text-based encodings for decades.
The third issue is proxying. RADIUS has a mature, standardised proxying architecture. An authentication request can travel from a NAS to a local RADIUS server, which forwards it to a regional server, which forwards it to a home network. At each hop, attributes can be rewritten according to contractual or policy obligations.
This is how federated Wi-Fi systems like eduroam work: your university credentials let you connect to a Wi-Fi network at a university on the other side of the world because RADIUS proxying carries the request home and brings the answer back.
There is no equivalent standard for REST API proxying. You could build one, but you would be building a new protocol, and then you would have to get every NAS vendor, every network operator, and every identity provider on the planet to implement it. That problem is likely to be difficult (to say the least).
The installed base problem
Even if someone built a technically superior replacement for RADIUS tomorrow, the deployment question would remain.
Wi-Fi access points, network switches, VPN concentrators, and broadband remote access servers all implement RADIUS in firmware. These devices have replacement cycles measured in years; five to ten years is typical. Companies often don’t know where all their access points are, or how to reach them for a firmware update, or whether the vendor still supports the hardware.
Twenty years ago, the RADIUS community was discussing how difficult it was to upgrade Wi-Fi access points. The problem has gotten significantly worse since then, because there are now five to ten times more access points.
In practice, any replacement for RADIUS would need to coexist with RADIUS in the field for at least a decade, probably two. During that coexistence period, every NAS that hadn’t been upgraded would still be sending RADIUS packets. Any “replacement” that couldn’t accept those packets would be an addition.
Overlapping replacement cycles make for longer timelines. If every access point has a five-year cycle, and they were all installed at different times, then five years from today some of them will be replaced - but not all of them. All of them won’t be replaced until everyone’s cycles have completed, which is nine or ten years away at best.
And that’s before accounting for the time it takes to standardise the new protocol, get it implemented by NAS vendors, and deploy it. A realistic estimate for any replacement started today would be fifteen to twenty years before it was ubiquitous.
Worth subscribing to.
Worth reading.
Our weekly newsletter covers network authentication tips, how-tos, security vulnerabilities, free resources, standards updates, and industry news. (All stuff you should stay up to date on!)
The standards problem
RADIUS has a thousand vendors, multiple roaming organizations, and no way to force those organisations to change. This is both a weakness and a strength.
The 3GPP consortium, which governs 3G, 4G, 5G, and 6G mobile network standards, has spent decades building Diameter, a protocol designed to be a RADIUS successor for the telecommunications world. It works in that world because 3GPP operates as a closed consortium. All the relevant vendors are in the room. When 3GPP decides that the next version of the standard will use a particular API, every member implements it. They’re now moving those systems to REST APIs over QUIC, and they can do that because they control the table.
RADIUS
has no equivalent organisation that can mandate support for new
features. There are thousands of vendors building NAS equipment,
hundreds of network operators, and dozens of RADIUS server
implementations. Getting all of them to agree on a replacement protocol, even a technically excellent one, requires a co-ordination mechanism that doesn’t exist.
The
way RADIUS evolves is through public embarrassment: a vendor ships
support for a new standard, another vendor’s customers notice the gap,
and the second vendor eventually implements it too. This is slow, but it’s how the ecosystem works.
This is part of why our approach at InkBridge Networks has been to evolve RADIUS rather than replace it. The work on making RADIUS more secure - including RADIUS 1.1, which removes the dependency on MD5 encryption and eliminates the 8-bit packet identifier limit that was a practical bottleneck at high packet rates - happens at the protocol level and benefits every implementation: every NAS vendor, every RADIUS server, every operator. We don’t need everyone at the same table to improve RADIUS. We need to write a good RFC and make the case for implementing it.
What the “alternatives” are
The protocols that are sometimes cited as genuine RADIUS alternatives (TACACS+, Diameter, Kerberos, SAML, OIDC) each do specific things well, but none of them replaces RADIUS’s role as the gatekeeper between network equipment and the authentication system.
TACACS+ handles device administration.
Diameter works in telecoms environments where all the relevant vendors are in the same consortium.
SAML and OIDC handle web and application authentication, where the device already has network access.
RADIUS handles network access control, the step that comes before any of those, at the point where the user is trying to connect to the network at all.
These protocols are not interchangeable and treating them as alternatives leads to security gaps. We noted this during the BlastRADIUS response, when several organisations received advice to switch to TACACS+ or Diameter as a workaround. That advice was wrong, and in some cases dangerous.
Will RADIUS ever be replaced?
I don’t think so, and I say that as someone who has spent the better part of three decades working on the protocol. RADIUS isn’t perfect but it does too many things in too many places for any replacement to have a realistic path to ubiquity.
The point that RADIUS is old is accurate but irrelevant. Hours still have sixty minutes. The base-sixty system the Babylonians used for timekeeping is far older than RADIUS, and we haven’t moved on from it because it’s embedded in every clock, time zone calculation, and piece of software that handles time. RADIUS is similarly embedded in the firmware of hundreds of millions of network devices, in the operational processes of thousands of network operators, and in the training of the engineers who manage those systems.
What will happen - what is already happening - is that RADIUS will continue to evolve. The security weaknesses that made it vulnerable get addressed at the standards level. The cryptographic primitives get updated. The packet identifier limits get removed. The transport gets secured with TLS. Updating the protocol is a tractable problem with a functioning, if slow, ecosystem for doing so.
If you’re asking whether to deploy RADIUS today: yes. If you’re asking whether RADIUS will be irrelevant by the time your current access points reach end of life: probably not. If you’re asking whether there’s a credible replacement on the horizon: I’m not holding my breath.
Need more help?
If your team is wrestling with network configuration, a troubleshooting problem you cannot resolve, or a system that needs to be more resilient, we can help. InkBridge Networks has 25 years of expertise: we wrote the standards, maintain FreeRADIUS, and have seen every failure mode there is. Reach out to request a quote.
Related Articles
RADIUS security best practices: How to harden your deployment
RADIUS has several well-known security limitations, most of which are easy to mitigate once you know what to do. This guide walks through five common weaknesses in the RADIUS protocol and the practical steps you can take to harden your deployment against each.
Introducing RADIUS 1.1
RADIUS has a problem. The name of the problem is MD5. The MD5 hash algorithm was defined in 1991, and was used in RADIUS in 1993. However, MD5 is no longer secure. It is a bit of a miracle that RADIUS is still safe to use, even though it is using 30 year-old cryptographic primitives!