RadSec

What RadSec is

RadSec is RADIUS over TLS, standardized in RFC 6614. It takes the same RADIUS authentication exchange that networks already rely on and carries it inside an encrypted, mutually authenticated TLS tunnel over TCP. It no longer sends that traffic as plain UDP.
In short, RadSec is classic RADIUS with a modern, secure transport layer underneath it. The authentication logic above does not change; the way the packets travel does.

The problem with classic RADIUS

Traditional RADIUS runs over UDP and only encrypts the user's password. The rest of the packet — usernames, the network device's identity, and policy attributes such as VLAN assignments — travels in the clear. It also depends on a shared secret whose strength varies in practice, and UDP offers no guaranteed delivery or ordering.
Inside a trusted data center this is tolerable. The moment RADIUS traffic crosses the public internet or passes through networks you do not control, those weaknesses become a real exposure.

How RadSec works

RadSec wraps the entire RADIUS conversation in a TLS session, typically over TCP port 2083. The client and server authenticate each other with X.509 certificates — mutual TLS — so each end proves its identity, and everything between them is encrypted.
Because it runs over TCP, RadSec also gains reliable, ordered delivery and automatic retransmission, which removes the packet-loss problems of UDP RADIUS. If a TLS connection drops, it can be re-established and traffic can fail over to another server.

RadSec vs VPN tunnels for RADIUS

Before RadSec, the common way to protect RADIUS across the internet was to build IPsec or site-to-site VPN tunnels between each location and the RADIUS server. That works, but it adds tunnels to configure, monitor and troubleshoot at every site.
RadSec secures the RADIUS traffic itself, so the protection travels with the protocol rather than depending on a separate tunnel. For large, distributed estates this is far simpler to operate and scales more cleanly.

Deploying RadSec

A RadSec deployment needs certificates on both the network device (or a RadSec proxy near it) and the RADIUS server. Both sides also need a trusted certificate authority they recognize. Many access points and controllers support RadSec natively; where they do not, a local RadSec proxy can convert UDP RADIUS to RadSec on the way out.
The main planning items are certificate issuance and renewal and making sure TCP 2083 is open along the path.

Why RadSec matters

RadSec is what makes cloud RADIUS safe over the internet. Without it, sending authentication traffic to a hosted RADIUS service would mean either exposing data or building VPN tunnels just to carry RADIUS securely. RadSec removes that burden by securing the transport itself.
It is also the foundation of large roaming federations such as WBA OpenRoaming, where a user's authentication has to travel securely across many different networks and operators.

RadSec in a cloud NAC architecture

For a distributed organization, RadSec is the link that lets every site reach a central cloud RADIUS service without local servers and without per-site VPNs. Cloud4Wi uses secure transport including RadSec, so 802.1X and MAC Authentication Bypass at each location authenticate against cloud RADIUS with their data encrypted end to end. If a connection is interrupted, there is reliable failover.

Adoption and limitations of RadSec

RadSec adoption has accelerated as networks moved authentication to the cloud and as roaming federations grew. It is now expected wherever RADIUS traffic must cross untrusted networks, and major access point and controller vendors support it natively or through a local proxy. The WBA OpenRoaming federation, which lets users move between participating networks securely, relies on RadSec as its transport.
The main limitation is operational rather than technical. RadSec depends on a working public key infrastructure: certificates must be issued to both ends, trusted through a common certificate authority, and renewed before they expire. An expired or mistrusted certificate breaks authentication, so certificate lifecycle management has to be taken seriously.
There is also a compatibility consideration. Older or low-end network hardware may not support RadSec directly. In that case, a local RadSec proxy converts ordinary UDP RADIUS to RadSec on the way out of the site. That keeps the secure-transport benefit without forcing a hardware refresh, which is why RadSec suits cloud deployments far more than it disrupts existing estates.
For an organization weighing the move to cloud-managed authentication, RadSec is best treated as a prerequisite rather than an optional add-on. Sending RADIUS over the public internet without it exposes usernames, device identities and policy attributes, and offers no reliable delivery.
The practical plan is straightforward. Confirm whether each access point and controller supports RadSec natively, deploy a local proxy where it does not, and put a certificate lifecycle process in place before go-live. With those steps handled, RadSec quietly secures every authentication that leaves the site, and most teams never have to think about it again.
That quiet reliability is the point. By securing the transport once, RadSec lets the rest of the access design — 802.1X, the EAP methods, the authorization policy — stay exactly as it is. Authentication then travels safely between every site and the cloud.