RadSec Explained: Why RADIUS over TLS Is Becoming the New Baseline for Network Authentication

Every time someone connects to your enterprise WiFi, a RADIUS packet carries their identity from the access point to an authentication server. In most networks, that packet is still protected the way it was in 2000: a shared secret and an MD5 hash. For years this was one of networking's accepted quirks. Then the BlastRADIUS disclosure demonstrated a practical forgery attack against the protocol, the IETF began work to formally deprecate RADIUS over UDP, and "how do we encrypt RADIUS?" became a question network teams are expected to have an answer to.

The answer has a name: RadSec, or RADIUS over TLS. This guide covers what it is, what actually broke in 2024, what the IETF is changing, where RadSec is already mandatory, and how to migrate without disrupting your users.

Why Is a Decades-Old Protocol Suddenly Under Scrutiny?

RADIUS has been the workhorse of network authentication since the dial-up era - if you want a refresher on how it fits together, start with our guide to what a RADIUS server does. Its core specification, RFC 2865, was published in 2000, and its security model is older still: every RADIUS client and server share a secret, and packets are validated with MD5 hashes derived from it.

That model has two structural problems:

• Almost everything travels in cleartext. Traditional RADIUS obfuscates only the User-Password attribute. Usernames, device MAC addresses, access point identifiers, VLAN assignments, and accounting records all cross the wire unencrypted, readable by anyone on the path
• The cryptography is obsolete. Researchers demonstrated practical MD5 collisions back in 2004. RADIUS kept using it anyway, because the design assumed packets would never leave a trusted management LAN

That assumption is what changed. Authentication traffic now routinely crosses site-to-site links, managed service provider networks, and the public internet on its way to cloud authentication services. The trusted network segment the protocol was designed for often no longer exists.

What Did BlastRADIUS Actually Break?

In July 2024, a team of academic and industry researchers disclosed BlastRADIUS (CVE-2024-3596), a protocol-level vulnerability in RADIUS over UDP. The short version: an attacker positioned between a RADIUS client and server can use an MD5 chosen-prefix collision to turn the server's Access-Reject into a valid-looking Access-Accept - without ever learning the shared secret. A denied login becomes granted access.

Three details matter when you assess your own exposure:

• It is a man-in-the-middle attack. The attacker needs to observe and modify RADIUS traffic in transit - realistic on an untrusted WAN path, harder inside a tightly segmented LAN
• Non-EAP flows were the exposed ones. Authentication methods like PAP, CHAP, and MAC-based authentication were vulnerable. EAP exchanges - the foundation of WPA-Enterprise - were already protected, because EAP mandates the Message-Authenticator attribute that defeats the forgery
• The mitigation is a patch, not a cure. Vendors responded by requiring Message-Authenticator on every packet. That blocks this specific attack, but the underlying MD5-and-shared-secret construction remains - and the researchers and the IETF drew the same conclusion: RADIUS needs a modern transport

What Exactly Is RadSec?

RadSec is RADIUS over TLS, standardized in RFC 6614 in 2012. Instead of sending UDP datagrams protected by MD5, the RADIUS client opens a TLS connection to the server - on TCP port 2083 - and every RADIUS message travels inside that encrypted tunnel. The name predates the RFC: IANA had already assigned port 2083 to "RadSec", an early implementation of the same idea. A DTLS variant for UDP transport, RFC 7360, followed in 2014.

Wrapping RADIUS in TLS changes four things:

• Full confidentiality. The entire packet is encrypted - usernames, MAC addresses, VLAN assignments, and accounting data included, not just the password field
• Modern integrity. Tamper protection comes from TLS, not from MD5 constructions designed decades ago
• Certificates replace shared secrets. Client and server authenticate each other with certificates, eliminating static secrets sprawled across hundreds of access points
• Reliable, internet-friendly transport. Long-lived TCP connections traverse NAT and WAN links cleanly, which is exactly what proxying and cloud authentication need

One point that surprises people: even a perfectly configured 802.1X network benefits. EAP protects the credential exchange itself, but over RADIUS/UDP the outer packet still leaks metadata - identities, calling-station MAC addresses, access point and VLAN details. RadSec closes that gap by encrypting the whole conversation.

Is RADIUS over UDP Really Being Deprecated?

Yes - deliberately and formally. The IETF's RADEXT working group is advancing Deprecating Insecure Practices in RADIUS, a document that deprecates cleartext UDP and TCP transports and mandates support for TLS-based ones. Cleartext RADIUS remains permitted inside secure, closed networks - but even there, the document discourages it. The direction was set as far back as RFC 6421, which required crypto-agility work for RADIUS; RadSec and its DTLS sibling were the outcome.

Standards documents don't rewire networks overnight, and equipment refresh cycles are measured in years. But the signal is unambiguous: a deployment that starts on RADIUS/UDP today is starting on a foundation the protocol's own stewards consider deprecated.

Where Is RadSec Already the Rule?

In several of the fastest-growing corners of enterprise WiFi, encrypted RADIUS transport is not a best practice - it is an entry requirement:

• OpenRoaming. The Wireless Broadband Alliance federation secures RADIUS traffic between identity providers and access networks with RadSec, using certificates issued under the WBA's PKI. See our OpenRoaming guide for how the federation works, and OpenRoaming RADIUS for joining it
• eduroam. The academic roaming federation uses RadSec with dynamic discovery so an institution's RADIUS server can securely reach a visiting user's home institution
• Passpoint roaming. Seamless offload built on Passpoint profiles typically rides on these federations - and inherits their encrypted-transport requirements
• Cloud authentication. When your authentication server lives in the cloud, RADIUS crosses the public internet by definition. IronWiFi's Cloud RADIUS supports RadSec between your access points and the cloud, so the untrusted middle of the path is precisely the part that gets encrypted

How Do You Migrate to RadSec?

Treat it as a sequence, not a big bang:

• 1. Inventory your RADIUS flows. WiFi SSIDs, wired 802.1X switch ports, VPN concentrators - and note which paths cross segments you don't control. Authentication logs and network analytics help surface forgotten clients
• 2. Apply interim hardening now. Install BlastRADIUS patches and require Message-Authenticator on every packet, on clients and servers alike
• 3. Check RadSec support. Most current enterprise access points and controllers speak RadSec natively; for legacy gear, a small on-site proxy can accept RADIUS/UDP locally and forward it over TLS
• 4. Plan the certificate lifecycle. Trust moves from shared secrets to certificates, so decide how certificates are issued, renewed, and monitored before you switch - an expired certificate means failed logins
• 5. Migrate incrementally. Move SSID by SSID or site by site. If you are also retiring shared WiFi passwords, fold transport encryption into your PSK-to-802.1X migration so you touch each access point once
• 6. Verify and retire. Confirm authentication is flowing over TCP 2083, then disable cleartext UDP listeners wherever nothing still depends on them

Conclusion

RADIUS itself is not going anywhere - it remains the lingua franca of network access control. What is being retired is the transport underneath it. BlastRADIUS was the demonstration that the old model fails against a modern adversary; the IETF's deprecation work is the formal confirmation; and roaming federations that already require RadSec are the proof that running it at scale is operationally routine.

The practical takeaway fits in three lines: patch and enforce Message-Authenticator today, move every RADIUS flow that crosses an untrusted network onto TLS, and make RadSec the default for anything new. Every other layer of the stack made this transition years ago - the web got HTTPS everywhere, mail transport got TLS. Network authentication is simply the next layer catching up.