RadSec is RADIUS transported inside TLS, defined in RFC 6614. Standard RADIUS runs over UDP and encrypts only the password attribute, leaving usernames, MAC addresses and accounting data in cleartext. RadSec encrypts the whole packet, authenticates both peers with X.509 certificates, and uses TCP for reliable delivery. The RADIUS attributes and server logic do not change.
Blog
RADIUS vs RadSec: Securing NAC Authentication
SUMMARY.
RADIUS and RadSec are two ways to carry network authentication traffic. RADIUS (Remote Authentication Dial-In User Service) runs over UDP with a shared secret and only obfuscates the password field. RadSec wraps the entire RADIUS exchange in TLS (Transport Layer Security) over TCP, with mutual certificate authentication. Choose RadSec when authentication traffic crosses the internet or connects to a cloud service. RADIUS remains common and adequate inside trusted, on-premise networks where the transport never leaves the LAN.
IN THIS ARTICLE
RADIUS was designed for a network that no longer exists
RADIUS is from 1997. RFC 2865 describes a protocol for a dial-up world: a handful of network access servers, a RADIUS server in the same rack, a trusted LAN between them.
That assumption is baked into the protocol. And it is the assumption that broke.
Today the access points are in 400 retail stores. The identity source is in a cloud tenant. The traffic between them crosses the public internet. RADIUS was never built for that path.
RadSec is the fix. It is RADIUS carried inside TLS, defined in RFC 6614. Same attributes, same semantics, same server logic — different transport.
This page explains what RADIUS actually protects, what it leaves exposed, and what changes when you wrap it in TLS.
What RADIUS encrypts — and what it does not
This is the part most architecture diagrams skip.
RADIUS does not encrypt the packet. It encrypts one attribute: User-Password. The method is an MD5 hash of the shared secret concatenated with the request authenticator, XORed against the password.
Everything else is cleartext on the wire:
| Attribute | Travels as | What it reveals |
|---|---|---|
| User-Name | cleartext | the identity of every user who authenticates |
| Called-Station-Id | cleartext | the BSSID / SSID being joined |
| Calling-Station-Id | cleartext | the client MAC address |
| NAS-IP-Address | cleartext | your network topology |
| Accounting attributes | cleartext | session start, stop, bytes, duration |
| EAP outer identity | cleartext | the realm, and often the username |
So an observer on the path learns who connected, from which device, to which access point, and for how long. They do not learn the password. On a trusted LAN in 1997 that was an acceptable trade. On a WAN link it is not.
The shared secret is the second problem
The MD5 construction means the shared secret is the whole security model. Two consequences follow.
First, the secret is offline-attackable. Capture one Access-Request and Access-Accept pair and you can run a dictionary attack against the secret without touching the network again. There is no rate limit on an offline attack.
Second, the secret has to be distributed. Every access point needs it. In a 400-site estate that is 400 copies of one string, configured by hand, rotated never. The operational reality is that RADIUS shared secrets are set once at install and outlive the people who set them.
UDP is the third problem
RADIUS runs over UDP — port 1812 for authentication, 1813 for accounting. UDP has no delivery guarantee and no ordering.
So the protocol does retransmission itself, at the application layer, with a timeout and a retry count configured per client. On a LAN with sub-millisecond latency that works. Over a WAN with 80ms of latency and occasional loss, it produces the failure mode every WiFi engineer recognises: authentication that works most of the time and fails unpredictably under load, with nothing useful in the logs.
What RadSec changes
RadSec is defined in RFC 6614 for TLS and RFC 7360 for DTLS. The default port is TCP 2083.
The change is structural, not incremental:
| RADIUS | RadSec | |
|---|---|---|
| Transport | UDP 1812 / 1813 | TCP 2083 (TLS) or UDP 2083 (DTLS) |
| What is encrypted | the User-Password attribute only | the entire packet, every attribute |
| Peer authentication | shared secret, MD5 | mutual X.509 certificates |
| Shared secret | the security model | set to the literal string radsec — TLS does the work |
| Reliable delivery | application-layer retry | TCP |
| Connection handling | one datagram per request | long-lived connection, reused across requests |
| Safe across the internet | no | yes |
| Peer discovery | static configuration | static, or dynamic via NAPTR (RFC 7585) |
Three of those rows matter more than the rest.
The entire packet is encrypted. Usernames, MAC addresses, SSIDs, accounting records — all inside the TLS session. The observer on the path sees a TLS connection to port 2083 and nothing about who is on your network. For anyone with a GDPR obligation, that changes the analysis: RADIUS accounting data is personal data, and on plain RADIUS it crosses the WAN in the clear.
Mutual certificate authentication replaces the shared secret. Both sides present a certificate. Both sides validate. There is no string to distribute, no string to attack offline, no string that outlives its owner. You get revocation — pull a certificate and that access point stops authenticating, immediately, without touching the other 399.
TCP replaces application-layer retry. One long-lived connection, TLS handshake amortised across thousands of authentications, TCP handling loss and ordering. The intermittent-failure-under-load pattern goes away because the transport is doing the job the transport should do.
Why this is the prerequisite for cloud RADIUS
A cloud RADIUS service means the RADIUS server is not in your rack. The authentication path runs from your access point, across the internet, to a service. With plain RADIUS there are only two ways to do that, and both are bad:
- Expose UDP 1812 to the internet. Now your identity traffic is in cleartext on the public network, and your shared secret is exposed to anyone who can capture two packets.
- Build a VPN or private circuit to every site. Now you have a WAN project, a tunnel to maintain per site, and a dependency that fails independently of the WiFi.
RadSec removes the choice. The TLS session is the secure channel. No tunnel, no exposed cleartext, no per-site VPN. That is why RadSec is not a feature bolted onto cloud RADIUS — it is the thing that makes cloud RADIUS structurally possible.
It is also why the WBA OpenRoaming federation runs on RadSec, and why eduroam uses it between institutions. Both are cases of RADIUS traffic crossing organisational boundaries over untrusted networks. Neither could work on plain RADIUS.
Cloud4Wi supports RadSec and OpenRoaming. See OpenRoaming and the NAC guide.
The honest trade-offs
You now have a certificate lifecycle. Certificates expire. An expired RadSec certificate means authentication stops — for that peer, completely, at the moment of expiry. You need monitoring on expiry dates and a renewal process that does not depend on one person remembering. This is the most common cause of RadSec outages.
Not every access point supports it. RadSec support on the AP or WLC side is uneven. Cisco, Meraki, Aruba and Ruckus have it on current firmware; older controllers and much of the SMB-tier hardware do not. Check the firmware level before you design around it. Where the AP cannot do RadSec, a local RadSec proxy in front of a plain-RADIUS AP is the usual pattern.
TCP 2083 has to be open outbound. It usually is, but in tightly controlled environments it is one more firewall change to negotiate.
How to decide
| Your situation | What to use |
|---|---|
| RADIUS server and access points on the same trusted LAN, single site | RADIUS is adequate |
| Authentication crossing a WAN, the internet, or an organisational boundary | RadSec |
| Using or planning a cloud RADIUS service | RadSec — a prerequisite, not an option |
| Multi-site estate where shared-secret distribution is already unmanaged | RadSec — certificate revocation replaces a secret you cannot rotate |
| Federated roaming (OpenRoaming, eduroam, partner networks) | RadSec — required |
| Accounting data subject to GDPR and crossing a public network | RadSec — plain RADIUS sends it in the clear |
| Legacy hardware with no RadSec support and no upgrade path | RADIUS inside a tunnel, or a local RadSec proxy in front of the AP |
Migration path
- Inventory RadSec support across every AP model and firmware version. This determines the scope, and it is the step that gets skipped.
- Stand up the certificate authority and decide who owns renewal. Answer this before issuing the first certificate.
- Issue certificates to the RADIUS server and to a pilot group of access points.
- Open TCP 2083 outbound from the pilot sites.
- Run one site on RadSec with plain RADIUS still configured as the fallback. Verify authentication, accounting, and a failover.
- Roll out per site. Keep the RADIUS listener alive until the last peer has moved.
- Close UDP 1812/1813 only when nothing is using them. Then add certificate expiry to your monitoring.ty tooling support it, the trusted-LAN exception shrinks. Treat mixed operation as a migration phase with a direction, not a permanent split.
Frequently asked questions
RadSec uses TCP port 2083 by default, as registered with IANA. DTLS-based RadSec, defined in RFC 7360, uses UDP 2083. You need outbound TCP 2083 open from your access points or controller to the RADIUS service. Plain RADIUS ports 1812 and 1813 can stay open during migration and be closed afterwards.
The shared secret becomes ceremonial. RFC 6614 specifies the literal string radsec as the shared secret when TLS is in use, because the TLS session already provides confidentiality and mutual authentication. You still enter a value in the configuration field, but its strength no longer matters. Certificates replace it as the trust mechanism.
Plain RADIUS over the internet exposes usernames, device MAC addresses and accounting records in cleartext, and exposes the shared secret to offline attack. The alternative is a VPN to every site. RadSec removes both problems by making the TLS session itself the secure channel, which is why it is treated as a prerequisite for cloud RADIUS rather than an enhancement.
Certificate expiry. When a RadSec certificate expires, authentication for that peer stops completely at that moment. Plain RADIUS has no equivalent failure because a shared secret does not expire. Monitoring expiry dates and owning a renewal process are mandatory, and expired certificates are the most common cause of RadSec outages.
Support is uneven. Current firmware from Cisco, Meraki, Aruba and Ruckus generally includes RadSec, while older controllers and much SMB-tier hardware do not. Inventory every model and firmware version before designing around it. Where an access point cannot do RadSec, a local RadSec proxy in front of it carries plain RADIUS on the LAN side.
© 2026 CLOUD4WI. ALL RIGHTS RESERVED.