Is RadSec Necessary if I Already Use EAP-TLS?

EAP-TLS is a powerful certificate-based authentication technique that has been extensively used due to its high security posture. It enables mutual authentication between the client and server and secures credentials using a TLS tunnel, making it resistant to credential theft or impersonation attempts.

Because EAP-TLS is so secure, many businesses think, “If I already have EAP-TLS, do I really need RadSec?”

Your threat model determines whether RadSec is necessary.

While EAP-TLS ensures authentication integrity, RadSec strengthens the transport layer. It’s especially valuable in systems that use credential-based authentication or send RADIUS traffic over untrusted networks.

In a nutshell, EAP-TLS secures the authentication exchange, whereas RadSec safeguards the path it takes. Even with certificate-based authentication reducing the threat, encrypting RADIUS traffic in transit remains a best practice — and in some setups, it’s essential.

What is RadSec?

RadSec, or RADIUS over TLS, is a modern and secure alternative to standard RADIUS transmission. While traditional RADIUS sends data over UDP, a fast but unencrypted and connectionless protocol, RadSec employs TCP and TLS to provide a secure, reliable communication channel between RADIUS clients (such as access points or controllers) and the RADIUS server.

The main advantage of RadSec is that it encrypts all RADIUS messages in transit. This prohibits unauthorized parties from intercepting or tampering with authentication traffic, particularly on public or federated networks. It also allows for mutual authentication between devices using digital certificates, utilizing Public Key Infrastructure (PKI) to build trust without depending on static secrets.

How RadSec works

RadSec sets up a TLS tunnel between RADIUS servers and network infrastructure components. This encrypted tunnel secures everything in the RADIUS communication, including user identification attributes and access control instructions, preserving data confidentiality and integrity as it travels across networks.

Cloud-based and multi-organization setups benefit significantly from this level of security. In these environments, RADIUS traffic often passes through intermediary proxies or untrusted infrastructure.

RadSec Vs. Traditional RADIUS

Here are the significant differences between RADIUS and RadSec:

In short, EAP-TLS protects the authentication dialog between the client and the server, whereas RadSec safeguards the channel that transports that interaction.

What EAP-TLS Actually Protects?

EAP-TLS is universally acknowledged as the benchmark for secure network authentication.  It employs mutual TLS to establish an encrypted tunnel between the client (e.g., a user’s laptop or mobile device) and the home RADIUS server.

Unlike password-based methods, EAP-TLS uses asymmetric cryptography.  This means that private keys never leave the device and are securely held in hardware (such as TPMs or secure enclaves). Even if an attacker intercepts the RADIUS exchange, they will be unable to access or reuse the credentials since the private key cannot be extracted or replicated. This is what makes EAP-TLS both phishing-resistant and very secure.

EAP-TLS protects the following:

• Client Credentials – Digital certificates and private keys are safely sent via the TLS tunnel.
• Passwords – Although not used in EAP-TLS, they would be as safeguarded if they were.
• Authentication Process – The challenge/response interaction that verifies identification is fully protected.

However, EAP-TLS provides protection just during the EAP exchange, namely between the client and the home authentication server.  It fails to safeguard the RADIUS transport pathway that transmits these packets among network components.

This indicates that although your credentials remain secure, the accompanying metadata, such as user identities or network policy determinations, may still be vulnerable if the RADIUS communication is not encrypted.

The Problem: Metadata Exposure in the Absence of RadSec

Despite the implementation of EAP-TLS, RADIUS communications frequently traverse many hops, including from the access point to a cloud RADIUS server or across federated RADIUS proxies. Without RadSec configuration, these communications are often transmitted unencrypted via UDP, rendering them susceptible to interception or alteration.

This is less significant with certificate-based authentication than passwords; yet, it remains a possible exposure concern.

What a Hacker Could See Without RadSec

If someone could intercept RADIUS traffic along the route, particularly in cloud-based or federated settings, they could look at:

• User identification – Full usernames (e.g., user@organization.com), unless privacy settings for identity are established.
• Device Identifiers — MAC address, SSID, and access point details.
• Network Configuration – VLAN allocations and RADIUS return properties, such as group affiliation or session duration.
• NAS or Proxy Metadata — IP addresses and additional routing information.

Even if the credentials are not hacked, this information might be valuable for profiling users, mapping out the network layout, or planning deeper attacks.

Real Risks Without RadSec

EAP-TLS secures the authentication exchange itself. However, ordinary RADIUS over UDP exposes the transport layer.  This offers new attack vectors, particularly in cloud-hosted or federated setups where traffic may transit numerous networks or proxies.

What’s at risk without RadSec?

• Metadata Interception – Attackers on the network channel can intercept metadata, including user identities, device MACs, SSIDs, VLAN assignments, and policy choices, even when credentials are encrypted.
• Packet Manipulation – Without transport encryption and message integrity, RADIUS characteristics such as VLAN ID and session timeouts can be tampered with in transit.
• Replay or Spoofing Attacks – Malicious actors may use a captured Access-Accept message to impersonate successful authentications or insert unauthorized devices.
• Rogue Proxy Insertion – In federated configurations (e.g., Eduroam or multi-organization networks), an attacker can inject a phony proxy server into the RADIUS chain to influence traffic.

Such risks underline the necessity for a secure transport technology such as RadSec, which encrypts RADIUS, verifies both ends using certificates, and ensures integrity.

Why it matters with EAP-TLS

It is true that EAP-TLS considerably minimizes the risk of credential theft, even when RADIUS packets are intercepted.  That is because:

• Certificates are hard to abuse – Unlike passwords, a stolen certificate is useless without the associated private key, which is usually securely kept in the device’s TPM or keychain.
• EAP-TLS tunnel secures the authentication conversation – The client certificate and private key are saved on the device, usually in an HSM or Secure Enclave, and never transferred over the network, so even if someone intercepts the RADIUS exchange, they cannot access them.

But here’s why RadSec is still important:

• Metadata leakage is valuable – Attackers might use exposed usernames, group IDs, VLAN assignments, and AP locations to map your network, follow users, and conduct social engineering attacks.
• Access control can be tampered with – An attacker who alters RADIUS attributes in transit may influence which VLAN a device is assigned to, or change session policies, leading to privilege escalation or network segmentation bypass.

In summary, EAP-TLS secures the identity exchange, whereas RadSec safeguards the delivery channel.  While risk is lower than credential-based authentication, metadata disclosure and manipulation can still impact your network’s security.

When RadSec Is Especially Important

While RadSec is a good idea for most situations, there are particular instances when it becomes crucial to implement, even if EAP-TLS is in use.

Credential-Based Authentication

Protocols like PEAP or EAP-MSCHAPv2 send user credentials over the RADIUS exchange. Without RadSec, these credentials can be captured in plaintext, making RadSec a must-have for safeguarding username/password authentication.

Cloud RADIUS Deployments

When your RADIUS server is in the cloud, RADIUS packets are frequently transmitted over the public internet. In this situation, RadSec is critical for preventing eavesdropping and manipulation between your on-premises equipment (such as your wireless controller) and the cloud server.

Federated Identity Setup

In roaming or federated setups (such as eduroam), RADIUS communications can be routed through several proxies or administrative domains. Each hop is a possible point of vulnerability or compromise unless the entire path is encrypted with RadSec.

Untrusted or Public Transportation Paths

Any situation in which RADIUS communication flows across untrusted networks, shared service providers, or external VPNs puts your metadata and policy choices at risk without the encryption and integrity provided by RadSec.

In short, if your environment involves external communication or credential-based authentication, RadSec is not a choice; it is required.

The Blast Radius Vulnerability

Even with RadSec in place, another critical consideration: The Blast Radius vulnerability.

What is the Blast Radius?

Blast Radius is a RADIUS-based attack that targets return properties such as VLAN assignments, access control policies, or group memberships by leveraging poor integrity enforcement. An attacker might insert or modify attributes to change access decisions if the RADIUS packet does not include a properly enforced Message-Authenticator attribute.

Why Message-Authenticator Enforcement is Important?

The Message-Authenticator attribute is a cryptographic checksum used to ensure the authenticity of RADIUS packets. In RADIUS processes that do not employ EAP (such as MAC authentication, VPN authentication, or PPSK), the lack or insufficient enforcement of this property exposes systems to attacks such as Blast-RADIUS.

However, RadSec mitigates Blast-RADIUS by encapsulating the whole RADIUS exchange in TLS, making MD5-based manipulation impossible. However, imposing Message-Authenticator remains a suggested best practice, particularly for devices or flows that do not support RadSec or EAP-based authentication, because it guards against faked Access-Request packets and other attacks.

How SecureW2 Mitigates This?

SecureW2’s Cloud RADIUS is protected against the Blast Radius vulnerability. It validates message integrity for all responses, with or without RadSec, guaranteeing that return attributes cannot be faked or tampered with. This ensures that your network regulations are safe against manipulation, regardless of how the traffic is sent.

Final Verdict: Yes, Use RadSec

EAP-TLS protects user credentials, but not the complete RADIUS route. Without RadSec, information like usernames and VLANs can still be exposed or altered during transit. RadSec bridges the gap using TLS encryption and mutual authentication. While it’s most important in credential-based or federated configurations, it’s still a useful security layer even with EAP-TLS.

SecureW2’s Cloud RADIUS supports RadSec out of the box and is resistant to known attacks such as Blast Radius. Contact us now to evaluate and protect your RADIUS transport from inception to completion.