What is RadSec? Configuring RadSec (RADIUS Over TLS)

As strong as the RADIUS protocol is, its reliance on the aging MD5 hash algorithm makes it susceptible to modern forgery and MITM attacks. Networks need to be transitioned to Transport Layer Security or TLS-protected transports like RadSec to ensure modern, end-to-end cryptographic protection.

We’ll explain what RadSec is and how it works, and we’ll a breakdown of the differences between RadSec and RADIUS, the benefits of RadSec, configuration options, and more.

What Is RadSec?

RadSec, defined in RFC 6614, is a secure transport method for RADIUS that encapsulates standard RADIUS packets within a TLS session over TCP. It preserves existing RADIUS packet structure and AAA (authentication, authorization, and accounting) semantics while adding transport-layer encryption and mutual certificate-based authentication.

Enabling RADIUS communication over TLS increases the level of security for authentication carried out across the cloud network. When configured, this feature ensures that the RadSec protocol is used to safely transmit the authentication and accounting data between the Instant AP and the RadSec server.

How RadSec works

RadSec, or RADIUS over TLS, changes how RADIUS messages move across networks, wrapping the entire packet in an encrypted TLS session over TCP. This is how it works:

1. RadSec uses TCP and TLS to carry standard RADIUS payloads inside an encrypted tunnel versus cleartext over UDP.
   • TLS relies on certificates and negotiated symmetric keys from the handshake to authenticate peers and encrypt traffic between them.
   • RadSec typically uses TCP port 2083 for RADIUS over TLS connection, instead of traditional RADIUS ports 1812 (authentication) and 1813 (accounting).
2. The use of TCP gives RadSec built-in reliability features like retransmission and ordered delivery, helping reduce packet loss and performance issues often seen with RADIUS/UDP over the internet.
3. Finally, existing foundational RADIUS semantics (identity, policy, and accounting attributes) stay the same, letting organizations upgrade their transport layer without completely redesigning their AAA logic.

How to Configure RadSec (RADIUS over TLS)

The RadSec configuration process can be broken down into a few high-level steps: configuring the RadSec destination and the TLS Connection. You need to specify the RADIUS server transferring the data and define the RadSec destination so the RADIUS traffic can be directed there. Here’s how to do that:

1. Import the server CA certificate that issues server certificates.
   • You can cross-import CAs if you have two separate CAs issuing server and client certificates.
   • This process will establish Server Certificate Validation.
2. Configure the destination hostname (server name).
3. Optional: Specify the port you want to use if the default RadSec port (2083) isn’t ideal.
4. Specify the TLS parameters.
   • TLS dictates how data will be transferred through RadSec.
   • The best practice is to use the EAP-TLS protocol (SecureW2 JoinNow is pre-built for EAP-TLS).

What Is the Difference between RADIUS and RadSec?

RADIUS relies on UDP (User Datagram Protocol) to transfer information, while RadSec relies on TCP (Transmission Control Protocol). UDP is considered less secure than TCP because messages are sent without a requirement for setting up communication channels. UDP is acceptable if packet loss is not a concern, but it makes RADIUS communication more vulnerable because important data packets could be lost. Attackers can exploit this vulnerability to infiltrate your network and farm credentials.

How Roaming Breaks Traditional RADIUS

Traditional RADIUS relies on clients communicating with known server IPs using pre-configured shared secrets.  This is perfect for a static LAN, but it quickly breaks once requests start to cross multiple proxies and domains, as is common with modern traffic flows to and from a public internet connection.

In today’s roaming federations like eduroam and OpenRoaming, authentication often travels through proxies controlled by others, making certificate-driven mutual TLS a safer and more scalable strategy for establishing trust across these more dynamic paths.

Key Benefits of RadSec vs. RADIUS

Beyond solving roaming and federation challenges, RadSec, or RADIUS over TLS, offers other key advantages over legacy RADIUS/UDP.

• End-to-end encryption for all RADIUS data
  RadSec encapsulates the entire RADIUS exchange within TLS tunnelling, so credentials and metadata like outer identity, NAS IP, and calling station ID are encrypted on the wire instead of exposed in plaintext.
• Robust integrity and anti-tampering features
  TLS ensures packets cannot be altered in transit without being detected, reducing the risk of spoofing, forgery, and MITM (man-in-the-middle) attacks that target legacy RADIUS/UDP environments.
• Mutual certificate-based authentication
  Instead of relying on shared secrets, RadSec uses X.509 certificates from a trusted CA to mutually authenticate client and server during the TLS handshake.
• Reliable delivery over untrusted networks
  Running over TCP gives RadSec ordered, predictable delivery of authentication and accounting records, which are critical when RADIUS traffic traverses lossy or congested WAN paths.
• Minimal impact on existing policies
  RadSec preserves standard RADIUS semantics of identities, attributes, and policies. This means organizations can upgrade reliability and security at the transport layer without additional re-work of AAA logic.

Since RadSec is only as strong as the PKI underneath it, certificate management must become part of your core network hygiene.  Automating certificate issuance, renewal, and revocation for RadSec endpoints preserves the new, stronger protections without driving outages or trust gaps when certs expire.

Best Practices for Secure RadSec Deployments

Deploying RadSec is an important step, but you still need to treat the TLS layer as critical security infrastructure. This means hardening it with the same attention paid to the rest of your PKI infrastructure

Enforce Modern TLS Versions and Strong Cipher Suites

Prioritize for TLS 1.2+ (ideally 1.3 where possible) and disable weak or legacy cipher suites to avoid downgrades and known cryptographic weaknesses.

Strictly Validate Servers and Hostnames

Ensure RadSec clients validate the server certificate chain, check revocation status where possible, and verify that the certificate’s name matches the expected RadSec endpoint.

Automate Certificate Lifecycle Management

Upgrade issuance, renewal, and revocation operations from manual to automated, to prevent outages or trust gaps from expired certifications, all while reducing IT workload.

Monitor and Log RadSec Activity

Turn on detailed logging for all RadSec connections and alert on repeated TLS handshake failures, certificate errors, or unusual patterns that indicate possible misconfiguration or attack.

How to Enable RadSec with JoinNow Cloud RADIUS

While RadSec is an open protocol that anyone can use, you need the right hardware to implement it. This GitHub link allows you to implement RadSec if your current hardware doesn’t natively support it, but configuration can be a monumental task. Luckily, the SecureW2 JoinNow Cloud RADIUS license supports RadSec.

Cloud RADIUS is a turnkey RADIUS solution that can be implemented into virtually any environment because it works with all major SAML and LDAP Identity Providers like Google, Okta, and Azure. Designed from the ground up for certificate-based authentication, it eliminates the risk of sending credentials over the internet and the potential for credential theft.

Our turnkey PKI solution easily distributes client and server certificates, including provisioning RadSec servers with a server certificate. And our JoinNow onboarding solution can be completed by users in minutes. Or, use API gateways to equip managed devices with certificates, all without end-user interaction.

Everything you need for certificate-based authentication can be set up in under an hour! Check out our affordable solutions for bringing certificate-based authentication to your network resources.

RadSec FAQs

When is plain RADIUS/TDP sufficient?

For small, single-site environments where RADIUS traffic never leaves a trusted LAN, and there are no roaming or federation requirements, traditional RADIUS/UDP can still be sufficient. Even here, though, best practices call for hardening networks and isolating traffic.

As organizations adopt cloud identity models and build for multi-site access and roaming networks, RadSec becomes the safe and clear choice for futureproofing networks, building on RADIUS fundamentals without redesigning networks from scratch.

Does OpenRoaming Require RadSec?

RadSec is highly recommended when it comes to OpenRoaming. OpenRoaming traffic is sent over the internet, meaning most of the time, you won’t know where it will end up or whether it will arrive in the correct order. 

The transfer of RADIUS packets over the internet involves breaking them down and reassembling them upon arriving at their destination. Usually, admins aren’t concerned about losing some data over UDP, but it can cause frustration or even security issues. A quick Google search of “lost RADIUS packets” shows how packet loss can become a real headache for admins.

OpenRoaming causes an issue with the RADIUS protocol because the latter relies on the client and server sharing IP addresses and using a shared secret to establish a connection. A roaming solution, like eduroam, requires considerable coordination that normal RADIUS isn’t equipped to handle. 

With RadSec, the connection is limited within the PKI. One organization issues certificates to the client and the server. The PKI serves as a trust anchor, so the RADIUS server and client can safely communicate, and no prior knowledge is necessary.

How does RadSec in eduroam work?

RadSec (RADIUS over TLS) secures the proxy links in the eduroam federation by encrypting RADIUS traffic with TLS over TCP port 2083, using X.509 certificates for mutual authentication.

In eduroam, a user’s device authenticates to the local campus Wi-Fi (Service Provider). The request is proxied through national and global servers to the user’s home institution (Identity Provider). Traditional RADIUS uses unencrypted UDP with weak shared-secret protection. RadSec replaces this with strong encryption and certificate-based trust, protecting credentials and attributes from interception, especially important across institutional boundaries and the internet.

It is commonly used between eduroam proxies (often via radsecproxy) and complements strong EAP methods like EAP-TLS. This is why proper device onboarding with server certificate validation is critical: it prevents credentials from being sent to fake “eduroam” networks.

Does RadSec work with NPS and Active Directory?

Currently, it doesn’t appear RadSec is possible with an Active Directory/NPS setup unless you have a third-party extension. However, RadSec would likely be unnecessary for most AD environments. However, you can configure a Microsoft RADIUS server with NPS.

It is possible to implement RadSec with a radsecproxy that converts legacy RADIUS into RadSec, but this only works for on-premise systems. In order to forward connection requests to a remote NPS or another RADIUS server:

• Create a Remote RADIUS Server Group.
• Configure a connection request policy that forwards requests to that Remote RADIUS Server Group.

With this configuration, NPS can forward authentication requests to any RADIUS server, and users with accounts in untrusted domains can be authenticated. This Windows forum post explains in more detail.