Geoff Huston was at NZNOG 2026 when I gave my talk on the future of Remote Authentication Dial-In User Service (RADIUS), and he quoted me accurately:
RADIUS is the protocol that will never die.
Alan DeKok, at NZNOG2026
I don’t mean it as a complaint or as a compliment. RADIUS has outlasted every attempt to replace it. Diameter was supposed to be its successor, but you only see it in an increasingly narrow set of carrier use cases. In enterprise networks, in Internet Service Provider (ISP) networks, in eduroam, and in 802.1X, RADIUS is still the only option.
So, given that RADIUS is staying, what do we need to do to make it secure for the next 30 years?
The answer is a set of documents that are progressing through the IETF’s RADEXT Working Group.
Why RADIUS needs fixing
RADIUS was designed in 1991 and first standardized in 1993. The cryptographic assumptions baked into it then (specifically MD5) are now three decades old, and MD5 has been considered broken for the better part of 20 years.
What you should know is that RADIUS/UDP over the Internet offers much weaker protection than most operators assume. The protection given to the User-Password attribute is only as strong as the shared secret you use. With modern Graphical Processing Unit (GPU) hardware, shared secrets of eight characters or fewer can be cracked pretty much immediately.
Historically, poor shared secrets defined the security posture of a significant proportion of deployed RADIUS infrastructure. Let’s hope that your network is using better practices.
BlastRADIUS made this issue concrete. The vulnerability, disclosed in 2024, showed that an attacker on the network path between a Network Attached Storage (NAS) and a RADIUS server could exploit the lack of integrity protection on Access-Request packets to forge authentication responses — granting anyone arbitrary access.
The design flaw was there in 1997 when I first pointed it out. And was still there in 2007 when I wrote RFC 5080, identifying the problem, and recommending that servers include Message-Authenticator in all Access-Request packets.
FreeRADIUS did this from 2013. A decade later, BlastRADIUS revealed how many vendors had not implemented any of those recommendations. That gap between what standards say and what ships in field equipment is the central challenge of RADIUS modernization.
What the IETF is doing about RADIUS
The RADEXT Working Group has a substantial pipeline of documents in various stages of completion. The most significant is RADIUS 1.1, which makes two changes.
- It removes the dependency on MD5. RADIUS 1.1 runs over Transport Layer Security (TLS), so the transport layer handles security. It also removes MD5 for all RADIUS traffic inside the TLS tunnel. This removal makes RADIUS fully FIPS-140 compliant, which is a hard requirement for government and regulated-industry deployments. The use of MD5 has historically caused problems for these use cases with standard RADIUS.
- It lifts the 8-bit packet identifier limit. The original protocol used an 8-bit
Identifierfield, capping any single connection at 256 outstanding packets. The result was slow traffic and many connections. RADIUS 1.1 replaces this with a 32-bitTokenfield: Four billion outstanding packets per connection. For high-throughput ISP and carrier environments, this change enables higher-performance servers.
RADIUS 1.1 is negotiated per connection and is backwards compatible. If one end does not support it, the exchange falls back gracefully. From an operator’s perspective, it is a configuration flag, not a migration project.
Two companion documents complete the near-term work.
The first formalizes TLS-PSK (pre-shared keys) for RADIUS, delivering the security of TLS without the overhead of a full PKI. Certificate management has always been the practical barrier to RADIUS/TLS adoption: Certificates expire, and institutional knowledge of the renewal process tends to expire with the people who set them up. TLS-PSK is administratively comparable to managing a shared secret.
The second formally deprecates bare UDP and TCP for RADIUS across the public Internet. Not new advice, as making RADIUS more secure has been the recommendation for years, but normative IETF language changes the conversation with vendors who have treated it as optional.
The adoption gap: Why we focus on servers
The consistent concern from operators is getting new functionality into field equipment. It is not an unfounded concern. BlastRADIUS showed how slowly fixes propagate through the installed base. Some vendors, when asked to implement the mitigations, were not yet implementing recommendations from 2007.
This shapes the strategy. On a typical network, there are 100 or more edge devices for every RADIUS server, and dozens of vendors, each with its own firmware roadmaps and compliance track records. In contrast, there are fewer than ten RADIUS server implementations in widespread use, and nearly all of them are actively involved in RADEXT. That is where the leverage is.
So the new standards prioritize changes that can be implemented in servers and proxies first. RADIUS 1.1 and TLS-PSK can be deployed between servers today, which is already a meaningful security improvement even if the NAS at the edge is still speaking plain RADIUS/UDP. The perimeter moves outward as edge devices catch up. Which they will, just slowly.
What operators should do now?
Three things, in order.
- Move to RADIUS/TLS for server-to-server and server-to-proxy connections. It is available now in all major RADIUS server implementations. If certificate management is the obstacle, TLS-PSK is available in FreeRADIUS today.
- Verify that your server is enforcing the
Message-Authenticatorattribute on allAccess-Requestpackets. This was the BlastRADIUS mitigation. If it is not enforced, that is worth knowing. - Watch for RADIUS 1.1 in your vendor’s upcoming releases and enable it on server-to-server connections when it arrives. For edge equipment, ask vendors directly about RADIUS/TLS support; the answers are informative.
The work underway in RADEXT is the most substantial update to RADIUS security since the protocol was defined. Operators who understand what is coming are better placed to manage the transition than those who wait for vendors to sort it out.
Alan DeKok is CEO of InkBridge Networks, the company behind FreeRADIUS, the world’s most widely deployed RADIUS server. He has written approximately 25% of the RADIUS standards at the IETF and has been involved with the protocol since 1999.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.