RADIUS has outlasted every replacement. RadSec (RADIUS over TLS) is the most practical way to secure it in transit, and it is available today.
Alan DeKok, CEO and Founder, InkBridge Networks
RADIUS is the protocol that will never die. I said so at NZNOG 2026, and I meant it as a statement of fact rather than praise or complaint. RADIUS has outlasted every protocol meant to replace it. In enterprise networks, ISP networks, eduroam, and 802.1X it is still the only realistic option.
So the useful question is not how to replace RADIUS but how to secure it, and the first practical step is RadSec, also known as RADIUS over TLS.
I set out the wider case for where RADIUS security is heading over the next 30 years, and the standards work behind it in a guest post for the APNIC blog. What you’re reading now is the practical companion to that argument: what RadSec is, what it is not, and how to adopt it without the usual headaches.
If you want the standards roadmap, read the APNIC piece. If you want to understand and deploy RadSec, start here.
What is RadSec? RADIUS over TLS, explained
RadSec is RADIUS carried inside a Transport Layer Security (TLS) tunnel, defined in RFC 6614.
Classic RADIUS sends its packets as bare User Datagram Protocol (UDP) traffic, protected only by a shared secret and the long-broken MD5 hash, which is why “is RADIUS secure?” has always really meant “how are you transporting it?”
RadSec instead has the client and server open a mutually authenticated TLS connection over Transmission Control Protocol (TCP), usually on port 2083, and every RADIUS packet travels inside it. The transport layer supplies the confidentiality, integrity, and reliability that classic RADIUS never had, so an attacker on the path can no longer read or alter the traffic. RadSec runs on TCP port 2083 rather than the classic UDP ports 1812 and 1813, and a companion specification (RFC 7360) provides the same protection over UDP using DTLS where a datagram transport is required.
What matters for anyone weighing it up is how little else changes. The RADIUS packet format, the attributes, and the Authentication, Authorization, and Accounting (AAA) semantics are all identical. RadSec is a different pipe for the same messages, so you can enable it incrementally, one connection at a time, without a flag day. It is also what makes secure RADIUS roaming practical, which is why federations such as eduroam and OpenRoaming depend on it.
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!)
What RadSec is not
Most confusion about RadSec comes from assuming it replaces something it does not. RadSec is not an authentication method, and it is not the same thing as RADIUS using EAP-TLS for certificate-based logins. EAP-TLS authenticates users, while RadSec protects the transport.
It is not a new, incompatible version of RADIUS either, because a RadSec connection still carries ordinary RADIUS packets. And despite how often you will see it written, it is not “an 802.1X protocol”.
Adopting RadSec does not mean re-architecting your authentication. All you’re doing is securing the channel your existing RADIUS already runs on.
RadSec and RADIUS 1.1: where each fits
RadSec is the step you can take today, and it pairs with a second change that is still arriving. A plain RADIUS packet carries MD5 inside it even when it travels through a TLS tunnel, so RadSec secures the transport without removing that final dependency.
Removing MD5 from the packet itself is the job of RADIUS 1.1, which also makes RADIUS fully Federal Information Processing Standards (FIPS) compliant and lifts the old limit of 256 outstanding requests per connection. That work, together with a formal pre-shared-key mode and the deprecation of bare UDP on the public Internet, is moving through the IETF’s RADIUS Extensions (RADEXT) working group. The practical sequence is simple: turn on RadSec now to protect the channel; adopt RADIUS 1.1 on your server connections once your vendors ship it.
Adopting RadSec without the certificate headache
In practice, the thing that stops teams moving to RADIUS over TLS is certificate management. Certificates expire, and the knowledge of how to renew them tends to leave with the person who set them up.
There are two ways through it. The first is TLS-PSK, which uses pre-shared keys instead of a full public key infrastructure (PKI). Administratively it is comparable to managing a shared secret, which every RADIUS operator already does, while still giving you the security of TLS. It is available in FreeRADIUS today.
The second is to start where the leverage is: server-to-server and server-to-proxy connections. There are fewer than ten widely used RADIUS servers, and well over a hundred edge devices for every server, so securing the links between servers is both easier and higher-value than waiting for every switch and access point to catch up. RadSec between your servers is a genuine improvement even while the edge is still speaking plain UDP, and the secure perimeter moves outward as that edge follows.
One thing worth checking while you are in there: confirm that your server enforces the Message-Authenticator attribute on every Access-Request. That was the mitigation for BlastRADIUS, the 2024 vulnerability that lets an attacker forge RADIUS responses on an unprotected path, and the concrete reason RADIUS/UDP is deprecated, and why transport security stopped being optional.
That is the practical case for RadSec. For the bigger picture - why RADIUS has outlasted its replacements, and the standards roadmap for securing it over the next 30 years - my full guest post is on the APNIC blog: RADIUS isn’t going away, so let’s fix it properly.
We publish this kind of analysis regularly. Subscribe to the InkBridge Networks newsletter to get it in your inbox.
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
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!
30-year RADIUS design flaw fixed at the IETF Montreal 124 hackathon
For the past 30 years, RADIUS has had a fundamental problem: in some cases, servers must discard well-formed, authentic packets from known clients.