If your Remote Authentication Dial-In User Service (RADIUS) traffic ever leaves a network you fully control, you need both. EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) protects the credential exchange, and RadSec protects the RADIUS packets that carry it.
Many teams assume EAP-TLS already encrypts everything on the wire. It doesn't: the Blast-RADIUS researchers state plainly that EAP-TLS is not the same as RADIUS over Transport Layer Security (TLS). RadSec covers the hop between the access point or switch (the RADIUS client) and the RADIUS server.
Below: what each layer protects, when RadSec is required, how Blast-RADIUS changed the risk, and how to deploy it.
Key takeaways
- Different layers: EAP-TLS secures the certificate handshake. It does not encrypt the RADIUS packets that carry it. Those packets include the Wi-Fi session keys.
- RadSec scope: RadSec (RADIUS over TLS, port 2083) encrypts and authenticates the hop between RADIUS client and server.
- Blast-RADIUS exposure: Blast-RADIUS mainly hits non-EAP traffic, which often shares the same RADIUS servers as EAP-TLS.
- When it's required: You need RadSec when RADIUS crosses the internet, a wide area network (WAN), or another organization's network, including cloud RADIUS.
What is RadSec?
RadSec is RADIUS carried inside an encrypted, mutually authenticated tunnel. It runs as RADIUS/TLS over Transmission Control Protocol (TCP), or as RADIUS/DTLS using Datagram Transport Layer Security (DTLS) over User Datagram Protocol (UDP). Request for Comments (RFC) 6614 and RFC 7360 set port 2083 as the default for both, with one port for authentication, accounting, and dynamic authorization.
Classic RADIUS, defined in RFC 2865 (authentication, port 1812) and RFC 2866 (accounting, port 1813), runs over UDP. It uses a shared secret and the Message Digest 5 (MD5) algorithm to obfuscate passwords and authenticate responses. Alan DeKok's Internet Engineering Task Force (IETF) deprecation draft, draft-ietf-radext-deprecating-radius-10, states that most other information travels in clear text.
The Standards Track RadSec draft (the bis draft) keeps mutual authentication mandatory as RFC 6614 already did, using X.509 certificates or a TLS pre-shared key (TLS-PSK). It follows RFC 9325, which mandates TLS 1.2 and recommends TLS 1.3.
RFC 6614 (2012) and RFC 7360 (2014) are both Experimental, not Standards Track. Their replacement, draft-ietf-radext-radiusdtls-bis-18, was in Internet Engineering Steering Group (IESG) evaluation as of September 30, 2026, per the IETF Datatracker. RFC 9765 (RADIUS/1.1, Experimental, April 2025) adds an optional profile that removes MD5 and requires TLS 1.3.
RadSec does not remove MD5. The bis draft states the MD5-based fields remain, and TLS "adds confidentiality and integrity protection" around them.
RadSec vs EAP-TLS: two different layers
EAP-TLS and RadSec protect different layers, so neither replaces the other. For the Wi-Fi authentication context, see WPA2/3-Enterprise with 802.1X authentication.
EAP-TLS runs a TLS handshake between the device (the supplicant) and the RADIUS server, tunneled through the access point. It protects credentials end to end. RFC 9190 (EAP-TLS 1.3) adds forward secrecy, encrypts certificates, and forbids sending the username in clear text. These privacy gains require TLS 1.3 on both the supplicant and the RADIUS server.
EAP-TLS leaves the RADIUS envelope around it unprotected. The most sensitive item in that envelope is the session key material. After a successful EAP-TLS exchange, the RADIUS server sends the keys the access point uses to encrypt the client’s Wi-Fi traffic (MS-MPPE-Send-Key and MS-MPPE-Recv-Key, RFC 2548) inside the Access-Accept. Over RADIUS/UDP, these keys are hidden only with MD5 and the shared secret. Anyone who captures RADIUS traffic can run an offline dictionary attack against a weak shared secret. If it falls, they can recover the keys and decrypt that user’s Wi-Fi session. RFC 9190 states that EAP headers, EAP-Success, and EAP-Failure messages can be modified, spoofed, or replayed. It also notes that RADIUS carries non-EAP data such as Media Access Control (MAC) addresses, IP addresses, and network names (SSIDs).
Many deployments still negotiate EAP-TLS over TLS 1.2. In that case the client certificate, including the user or device identity in its subject, crosses the wire in clear text inside RADIUS. The realm in the username stays visible even with TLS 1.3, according to RFC 9190. The IETF deprecation draft adds that most RADIUS/UDP information except passwords travels in clear text. That covers network access server (NAS) identifiers, authorization attributes in the Access-Accept, and accounting records.
RadSec encrypts and authenticates the whole RADIUS packet on one hop, from RADIUS client to server or proxy. The RadSec bis draft is explicit that proxies can still read packets and may forward them over RADIUS/UDP. EAP-TLS keeps credentials hidden from every proxy, but not session keys. Each proxy decrypts and re-encrypts the MS-MPPE keys with the next hop’s shared secret, so every hop needs RadSec.
Alan DeKok, the FreeRADIUS maintainer, calls a checklist approach to RADIUS security "deeply misleading" in his IETF deprecation draft. His analogy: a strong lock on the front door doesn't secure a house with an open window. Zero Trust applies the same logic: strict identification per connection, plus protected transport.
Blast-RADIUS: Why the question got urgent
Blast-RADIUS made unprotected RADIUS/UDP a practical risk, mainly for non-EAP traffic. Disclosed in July 2024 as CVE-2024-3596, it lets an on-path attacker forge an Access-Accept in response to a failed login. According to the CERT Coordination Center (CERT/CC) Vulnerability Note VU#456537, the attacker uses an MD5 chosen-prefix collision and never needs the shared secret.
The researchers (Goldberg, Heninger and colleagues, USENIX Security 2024) say nearly all RADIUS/UDP implementations using non-EAP methods, such as Password Authentication Protocol (PAP), are affected. For EAP, they write that the attack "does not seem to be practically exploitable," though a theoretical attack may still exist.
CERT/CC says EAP-only servers are unaffected. The reason is RFC 3579: any RADIUS packet carrying EAP must include the Message-Authenticator attribute, an HMAC-MD5 over the whole packet that the collision attack can’t forge. Non-EAP methods such as PAP and MAB historically didn’t require it.
The catch: the same RADIUS servers often carry non-EAP traffic. Examples include MAC Authentication Bypass (MAB) for Internet of Things and operational technology (IoT/OT) devices, legacy password logins, and virtual private network (VPN) access. MAB is non-EAP by design: the NAS sends the device’s MAC address as a PAP-style password, which puts MAB squarely in the exposed group. In fairness, MAB’s bigger weakness is MAC spoofing, which is far cheaper than Blast-RADIUS. That’s why MAB should be combined with device profiling and segmentation.
On practicality, the researchers answer "yes and no." Their proof of concept took 3 to 6 minutes per collision, against common RADIUS timeouts of 30 to 60 seconds. They expect well-resourced attackers with specialized hardware to be tens to hundreds of times faster.
Fixes, per the researchers:
- Short term: Send and require the Message-Authenticator attribute on all requests and responses. Servers should also place Message-Authenticator as the first attribute in responses, as the post-disclosure vendor patches do.
- Long term: Move RADIUS into an encrypted, authenticated channel. The researchers say RadSec "should protect against our attack."
- Partial measures: A separate virtual LAN (VLAN) reduces risk but doesn't eliminate it. Shorter timeouts, multifactor authentication (MFA), and random shared secrets don't mitigate it.
Mixed populations are where "we use EAP-TLS" stops covering all RADIUS traffic. Cloudi-Fi puts employees, guests, and IoT/OT devices on one platform, onboarding unmanaged devices with Cloud DHCP fingerprinting.
When do you need RadSec? A decision checklist
You need RadSec whenever RADIUS crosses a network you don't fully control.
Encrypted transport is required when RADIUS crosses networks you don’t control; RadSec is the preferred form.
- Cloud RADIUS** and**** cloud network access control (NAC)**: Cloud-delivered RADIUS sends authentication traffic over the internet by definition.
- Multi-site networks: Branches reaching a central RADIUS server cross a WAN or the internet.
- Roaming federations: RFC 9765 states that RADIUS/TLS is widely deployed in eduroam and OpenRoaming.
- Managed service providers: RADIUS traffic crosses into another organization's network.
Cloudi-Fi's Cloud NAC replaces legacy on-premises NAC without local RADIUS, across 90+ countries and 100K+ secured sites. At that scale, MAC addresses and usernames cross borders, and the IETF deprecation draft warns that clear-text names and MAC addresses let individuals be tracked.
RadSec is strongly recommended for mixed traffic and privacy
- Non-EAP traffic on shared servers: PAP, MAB, or VPN logins on the same RADIUS servers keep those servers in the Blast-RADIUS target group.
- Privacy and compliance: The IETF deprecation draft calls sending device or location data in clear text across the internet "no longer acceptable."
RadSec is optional on segmented networks, with caveats
RADIUS on a segmented management network, or inside an Internet Protocol Security (IPsec) or software-defined WAN (SD-WAN) tunnel, carries less risk. Require Message-Authenticator there. The IETF draft still recommends TLS inside secure networks as defense in depth.
IPsec is an acceptable alternative here, but see below for why RadSec is preferred where the choice exists.
RadSec vs IPsec for RADIUS transport
RadSec puts transport security under the RADIUS application's control; IPsec does not. With IPsec, the RADIUS server can't see whether protection is in place, according to DeKok's IETF deprecation draft.
IPsec problems show up as packet loss, and a misconfiguration that removes protection stays invisible to RADIUS. RFC 7360 gives the same reasoning.
RadSec has costs: certificate lifecycle across every NAS, TCP connection management and failover (Status-Server keepalives, RFC 5997), and uneven DTLS and TLS-PSK support across vendors. Plan for these before you start the migration.
How to deploy RadSec alongside EAP-TLS
Keep EAP-TLS as is and add RadSec hop by hop, starting with hops that leave your network.
1. Inventory RADIUS clients and check RadSec support
List every access point, switch, wireless controller, and VPN gateway that sends RADIUS. RFC 9765 notes RADIUS/DTLS is "supported in many RADIUS clients and servers," but support isn't universal.
2. Front UDP-only devices with a local RadSec proxy
RFC 6614 Appendix B describes radsecproxy, which can run on the same host as a UDP-only client or server. RadSec then protects the traffic on the wire.
3. Plan certificates for network devices
RFC 7360 advises a private certificate authority (CA) for RADIUS, not a public CA. Plan mutual authentication and renewal, and never reuse old RADIUS/UDP shared secrets as TLS-PSK, as the bis draft warns.
4. Open TCP port 2083 outbound
Allow TCP 2083, or UDP 2083 for DTLS, from each RADIUS client or proxy to the RADIUS server or cloud service.
5. Require Message-Authenticator during migration
Enable and require Message-Authenticator on every server and client. This closes the Blast-RADIUS gap on hops still running UDP.
6. Remove RADIUS/UDP fallback after migration
The bis draft warns that leaving UDP fallback enabled lets an attacker force a downgrade. Disable it once every client connects over RadSec.
Cloudi-Fi is infrastructure-agnostic and plugs into your existing network vendors. Cloudi-Fi's 802.1X guide describes its cloud RADIUS service as using RadSec for authentication across sites. For organizations migrating from Microsoft NPS, see Microsoft NPS replacement with Cloud NAC.
Best practices and common mistakes with RadSec
Most RadSec mistakes come from expecting one protocol to do the other's job.
Common RadSec mistakes
- Treating EAP-TLS as transport encryption: EAP-TLS protects credentials. The RADIUS envelope still travels in clear text over UDP.
- Assuming RadSec is end to end: RadSec protects one hop. Proxies can read packets and forward them over UDP.
- Assuming RadSec removes MD5: RadSec wraps the MD5-based fields in TLS but keeps them. Only RADIUS/1.1 (RFC 9765) removes MD5.
- Leaving UDP fallback enabled: Fallback invites downgrade attacks, according to the bis draft.
RadSec best practices
- Pair EAP-TLS 1.3 with RadSec: Use an anonymous outer identity, as RFC 9190 recommends, plus RadSec on every hop that leaves a trusted network.
- Audit non-EAP traffic: List PAP, MAB, and VPN flows on each RADIUS server, since those form the Blast-RADIUS target group.
Conclusion: run both layers where RADIUS leaves your network
EAP-TLS and RadSec are complementary layers. EAP-TLS protects credentials end to end, and RadSec protects each RADIUS hop, so cloud and multi-site RADIUS needs both.
Start by auditing where your RADIUS traffic travels and which non-EAP traffic shares your servers. Then add RadSec to every hop that leaves a network you control.
Cloudi-Fi delivers Cloud NAC and cloud-ready 802.1X without local RADIUS or additional hardware. Its Cloud NAC unifies with Zero Trust Network Access (ZTNA) identity provider capabilities, and Cloudi-Fi is trusted by 200+ enterprises worldwide.
Frequently asked questions about RadSec
What port does RadSec use?
RadSec uses TCP port 2083 for RADIUS/TLS and UDP port 2083 for RADIUS/DTLS, per RFC 6614 and RFC 7360.
Does RadSec replace EAP-TLS?
No. Session keys, however, are visible to every RADIUS hop, which is why RadSec is still needed.
Does RadSec protect against Blast-RADIUS?
The Blast-RADIUS researchers say RadSec "should protect against our attack." Until every hop runs RadSec, send and require Message-Authenticator on all RADIUS traffic.
Is RadSec an official IETF standard?
Not yet. RFC 6614 and RFC 7360 are Experimental, and the Standards Track replacement was in IESG evaluation as of September 30, 2026.
What if my RADIUS server or access points don't support RadSec?
Run a local RadSec proxy such as radsecproxy, described in RFC 6614, next to UDP-only devices or servers. Require Message-Authenticator on any remaining UDP segment.
