Is RADIUS Secure? Vulnerabilities, BlastRADIUS & Fixes

---

Network teams treat Remote Authentication Dial-In User Service (RADIUS) as background plumbing until something goes wrong with it. Every Wi-Fi login, VPN session, and switch port authentication can pass through a RADIUS exchange, and that exchange has run on largely the same design since the protocol shipped in the 1990s. Asking “is RADIUS secure” is really asking whether three-decade-old assumptions still hold up against current attackers.

The honest answer is that RADIUS security depends on what’s wrapped inside it. Password-based methods sent over unencrypted User Datagram Protocol (UDP) are weak by modern standards. Certificate-based Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) carried over encrypted RadSec is strong.

This article breaks down how RADIUS authenticates, compares the protocol options and their tradeoffs, and covers the BlastRADIUS vulnerability that forced a rethink of RADIUS’s default assumptions.

What Is RADIUS?

RADIUS, or Remote Authentication Dial-In User Service, is a networking protocol that carries authentication, authorization, and accounting (AAA)information between a network access server (NAS) and a centralized authentication server. A NAS is any device that grantsnetworkaccess on the authentication server’s behalf, including Wi-Fi controllers, VPN concentrators and managed switches.

RADIUS runs overUDP, with port 1812 officially assigned for authentication requests. When a user or device tries to connect, the NAS forwards the login attempt to the RADIUSserver, which checks it against a directory, certificate store or local database and returns an accept or reject decision.

For a deeperlook at RADIUS server architecture and deployment options, see the complete guide to RADIUS servers.

How RADIUS Authentication Works

RADIUS authentication follows a defined request-and-response sequence between the network device and the authentication server:

1. Connection attempt: A user or device tries to join a network, VPN or switch port managed by a NAS.
2. Access-Request: The NAS packages the login attempt and sends an Access-Requestpacket to the RADIUS server. When a password field exists, an MD5 hash of the shared secret and the Request Authenticator obscure it.
3. Verification: The RADIUS server checks the credentials or certificate against its identity source and evaluates any access policies tied to that user or device.
4. Access-Challenge (when needed): Protocols that require multiple round trips, such as Protected Extensible Authentication Protocol (PEAP) or EAP-TLS, exchange one or more Access-Challenge packets before the server makes a decision.
5. Access-Accept or Access-Reject: The server returns a final accept or reject response, and the NAS grants or denies the connection accordingly.

Every step in this exchange relies on the shared secret to prove the packets came from a trusted source, and that shared secret is exactly what the BlastRADIUS attack exploited.

RADIUS Authentication Protocols Compared: From PAP to EAP-TLS

RADIUS is a transport and packet format. The actual security of a login attempt comes from the authentication protocol carried inside it. Some wrap a plain password, some tunnelcredentials insideencryption, and one skips passwords entirely. EAP-TLS authentication is the strongest of the group because it replaces the password with a certificate exchange.

Protocol	How It Authenticates	Security Level	Key Weakness
Password Authentication Protocol (PAP)	Sends the password obscured only by the shared-secret MD5 hash	Weak	The hash is reversible if the shared secret is guessed or leaked
PEAP-MSCHAPv2	Wraps an MS-CHAPv2 credential exchange inside a TLS tunnel	Moderate	Security collapses if the outer tunnel is misconfigured or bypassed
EAP-TTLS/PAP	Tunnels a plain PAP exchange inside TLS	Moderate	Still fundamentally password-based once inside the tunnel
EAP-TLS	Exchanges mutual X.509 certificates between client and server, no password sent	Strong	Requires certificate issuance and lifecycle management

Each step up this table trades a little setup complexity for a large drop in exposed attack surface. For a closer comparison of how these methods map to 802.1X deployments, see the 802.1X authentication methods comparison.

Is RADIUS Secure? The Direct Answer

RADIUS is secure enough for production use, but only when it’s configured with the right authenticationprotocol and transport. Deployments still running PAP or plain MS-CHAP over unencrypted UDP are exposed to credential interception and shared-secret attacks. Deployments running EAP-TLS over an encrypted transport are resistant to almost all of the same attacks, because there’s no password to steal in the first place.

RADIUS stays flexible about which authentication method it carries. This means weak configurations run in the wild right next to strong ones on the same network. The protocol’s age isn’t the real risk; the configuration is.

Is RADIUS Secure Against BlastRADIUS and Other Vulnerabilities?

The most significant RADIUS vulnerability to date is BlastRADIUS, tracked as CVE-2024-3599. Researchers disclosed it in 2024 as a man-in-the-middle (MITM) forgery attack that combines a protocol design flaw with an MD5 chosen-prefix collision, letting an attacker turn a legitimate Access-Reject response into a forged Access-Accept. The short-term fix requires every RADIUS client and server in the path to enforce the Message-Authenticator attribute, which closes the specific gap BlastRADIUS relies on.

The attack requires the attacker to sit on the network path between the RADIUS client and server, which limits it to insiders, compromised infrastructure or attackers who have already gained a foothold on the network segment. That’s a meaningful barrier, but it’s not a reason to ignore the finding. Any organization still authenticating over plain UDP with legacy password protocols is carrying the same underlying MD5 weakness BlastRADIUS exposed.

The longer-term fix is architectural. The IETF published RADIUS/1.1, which uses application-layer protocol negotiation (ALPN) during the TLS handshake to remove RADIUS’s dependency on MD5 altogether.

RADIUS carries other common weak points beyond BlastRADIUS:

• It defaults to unencrypted UDP transport.
• Shared secrets are often weak, reused across sites, or rarely rotated.
• Packet bodies leave most attributes outside the password field

RadSec: RADIUS Over TLS Fixes the Transport Problem

RADIUS over TLS, or RadSec, is a transport profile that moves RADIUS traffic from unencrypted UDP to a TLS-encrypted TCP connection, with a default port of TCP/2083. Instead of relying on a static shared secret to authenticate the connection, RadSec uses mutual TLS certificates, removing the exact mechanism BlastRADIUS targets.

The diagram below shows where RadSec sits in the connection: the client authenticates over Wi-Fi and 802.1X, while the RADIUS exchange between the access point and server travels inside a TLS tunnel.

RadSec doesn’t change what authentication protocol runs inside RADIUS. A PEAP-MSCHAPv2 exchange carried over RadSec is still password based. What RadSec fixes is the transport layer around it: the entire packet, not just the password field, travels encrypted.

For a direct breakdown of how the two compare, see RadSec vs RADIUS, and for setup details, see how to configure RADIUS over TLS.

RADIUS vs. PKI: Why They Work Together, Not Against Each Other

RADIUS and public key infrastructure (PKI) are often pitted against each other, but they operate at different layers: RADIUS is the transport and decision-making layer, while PKI supplies the certificates that EAP-TLS uses to authenticate without a password.

The real comparison worth making is password-based RADIUS versus certificate-based RADIUS.

Dimension	Password-Based RADIUS (PAP, PEAP-MSCHAPv2)	Certificate-Based RADIUS (EAP-TLS With PKI)
What’s exposed if intercepted	A hashed or tunneled password an attacker can try to crack or replay	A public certificate with no usable secret inside it
Credential theft risk	High — Phishing and password reuse both work against it	Low — There’s no password to phish or reuse
Revocation	Requires a password reset across every affected account	Requires revoking a single certificate
Setup effort	Low — Works with existing directory passwords	Higher — Requires certificate issuance and lifecycle management

Password-based RADIUS is simpler to stand up. Certificate-based RADIUS closes the credential-theft gap that password methods can’t.

Best Practices for Hardening RADIUS Security

Whether an organization runs on-premises RADIUS or a managed cloud service, the samehardeningprinciples apply:

• Move to EAP-TLS: Eliminating passwords from the authentication exchange removes the most commonattack vector
• Adopt RadSec: Encrypting the full RADIUS session, not just the password field, closes the gap that unencrypted UDP leaves open.
• Strengthen and rotate shared secrets: For any deployment still on classic RADIUS transport, long, unique and regularly rotated shared secrets reduce the blast radius of a leak.
• Enforce the Message-Authenticator attribute: This closes the specific BlastRADIUS forgery path on servers and clients that haven’t moved to RadSec or RADIUS/1.1 yet.
• Monitor and control sessions with Change of Authorization:RADIUS Change of Authorization lets an administrator modify or terminate an active session without waiting for reauthentication, which limits how long a compromised session stays live.
• Segment RADIUS infrastructure: Isolating RADIUS servers and NAS devices on their own network segment reduces the odds an attacker can position for an on-path forgery

Secure Your RADIUS Deployment With JoinNow Cloud RADIUS

Getting RADIUS security right means running EAP-TLS, encrypting the transport with RadSec and keeping certificate lifecycle management out of the way of IT teams that already have enough to patch. That’s a heavier lift on self-managed, on-premises RADIUS infrastructure than most teams have time for.

JoinNow Cloud RADIUS is built around exactly this configuration. It runs EAP-TLS and RadSec by default, ties every authentication to a managed certificate instead of a password and removes the shared-secret and legacy-protocol weaknesses covered in this article without requiring on-premises hardware.

See what a certificate-first, RadSec-encrypted RADIUS deployment looks like at Cloud RADIUS.

Frequently Asked Questions

What is BlastRADIUS and does it affect me?

BlastRADIUS (CVE-2024-3596) is a man-in-the-middle attack that forges a RADIUS Access-Accept response by exploiting an MD5 collision, and it affects any RADIUS deployment that still uses classic UDP transport without the Message-Authenticator attribute enforced. If a network runs EAP-TLS over RadSec or has already applied the Message-Authenticator mitigation, exposure is significantly reduced.

Is RADIUS secure over Wi-Fi with WPA2-Enterprise or WPA3-Enterprise?

RADIUS is the authentication backend behind both WPA2-Enterprise and WPA3-Enterprise Wi-Fi, and its security over Wi-Fi depends on the same factors as any other RADIUS deployment: which EAP method authenticates the client and whether the RADIUS transport itself is encrypted. EAP-TLS over RadSec is the strongest combination available for enterprise Wi-Fi today.

Is RADIUS more secure than TACACS+?

RADIUS and TACACS+ solve different problems, so “more secure” depends on the use case. TACACS+ obfuscates the body of the full packet payload and is built for administrative access to network devices, while RADIUS is designed for broader network access authentication across Wi-Fi, VPN, and wired connections. Neither is a drop-in replacement for the other.

Is certificate-based authentication (EAP-TLS) more secure than RADIUS passwords?

Yes. EAP-TLS authenticates with X.509 certificates instead of a password, so there’s no credential for an attacker to phish, guess, or replay. Password-based RADIUS methods, even tunneled ones like PEAP-MSCHAPv2, still depend on a secret that can be stolen or cracked.

What is RadSec and does it fix RADIUS’s security problems?

RadSec is RADIUS carried over a TLS-encrypted TCP connection instead of plain UDP, and it fixes the transport-layer weaknesses in RADIUS, including the shared-secret exposure BlastRADIUS exploited. It does not change the authentication protocol running inside the session, so pairing RadSec with EAP-TLS gives the strongest overall result.