Learn how security-by-design improvements have transformed RADIUS into a more secure protocol than the expensive platforms built on top of it.
“Is RADIUS secure?” is one of the most common questions network administrators ask when evaluating authentication infrastructure. In fact, RADIUS is more secure today than it has ever been, thanks to systematic security-by-design improvements at the standards level.
The protocol debuted in 1993 using MD5 hashing - technology that seemed destined for obsolescence. Instead, RADIUS proved flexible enough to evolve while maintaining backward compatibility with existing infrastructure.
This article examines RADIUS protocol security in depth: how the protocol works, what makes it secure, recent security improvements, and how it compares to alternatives in real-world deployments.
What is RADIUS in cybersecurity?
RADIUS (Remote Authentication Dial-In User Service) provides centralised Authentication, Authorisation, and Accounting (AAA) for network access control. In cybersecurity terms, RADIUS acts as the gatekeeper between users seeking network access and the resources they're trying to reach.
When someone connects to a corporate Wi-Fi network or logs into a VPN, RADIUS validates their identity before granting access. The protocol defines how authentication information passes between network devices and authentication servers, but it doesn't dictate the specific authentication methods used.
Core security functions
RADIUS performs three fundamental security functions:
Authentication: RADIUS authenticates devices or users before allowing network access. This verification step ensures that only authorised entities can connect to network resources.
Authorisation: After authentication succeeds, RADIUS authorises specific services and resources that the authenticated user can access. This might include VLAN assignments, bandwidth restrictions, or access to particular network segments.
Accounting: RADIUS accounts for resource usage during each session, tracking metrics like connection duration, data transferred, and services accessed. This information proves essential for security auditing and compliance requirements.
Understanding RADIUS protocol security
Network administrators questioning RADIUS security often focus on the wrong issues. The protocol's security doesn't depend primarily on the transport mechanism or the original MD5-based design. Instead, RADIUS security comes from how organisations implement and configure it, combined with recent standards-level improvements.
How RADIUS authentication works
The RADIUS authentication process follows a client/server model:
- Access request initiated: A user attempts to connect to a network resource. The network access server (NAS) - which could be a wireless access point, VPN concentrator, or switch - receives the connection request.
- Credentials forwarded: The NAS sends an Access-Request packet to the RADIUS server. This packet contains the user's credentials and other attributes like the client IP address.
- Server validates credentials: The RADIUS server checks the credentials against its user database. This might involve Active Directory lookups via LDAP, queries to another RADIUS server, or database lookups.
- Authentication decision: The server responds with Access-Accept (credentials valid), Access-Reject (credentials invalid), or Access-Challenge (more information needed).
- Access granted or denied: Based on the server's response, the NAS either grants or denies network access.
Throughout this process, RADIUS uses a shared secret between the client and server to protect sensitive information. This shared secret acts as a cryptographic key for obfuscating passwords and certain attributes within RADIUS packets.
Authentication protocols and security
RADIUS supports multiple authentication protocols, each with different security characteristics:
Password Authentication Protocol (PAP): Despite common misconceptions, PAP can be the most secure option when properly implemented. While PAP transmits passwords in cleartext within the authentication protocol itself, the RADIUS shared secret obfuscates these passwords in transit. When combined with strong shared secrets and proper network segmentation, PAP provides robust security while avoiding the vulnerabilities present in challenge-response protocols.
Extensible Authentication Protocol (EAP): EAP provides a framework supporting multiple authentication methods, including certificate-based authentication and public key infrastructure (PKI). EAP's flexibility makes it particularly suitable for wireless networks using 802.1X authentication. Common EAP methods include EAP-TLS (using certificates), EAP-TTLS (tunnelled TLS), and PEAP (Protected EAP).
Challenge-Handshake Authentication Protocol (CHAP): CHAP uses a challenge-response mechanism where the server sends a challenge, the client responds with a hashed value, and the server validates this response. The password never travels over the network. However, CHAP requires storing passwords in a reversible format, which introduces security risks.
MS-CHAP (Microsoft CHAP): Microsoft's implementation of CHAP includes additional features but suffers from known cryptographic weaknesses. MS-CHAPv2, while an improvement, remains vulnerable to offline attacks. Modern implementations should avoid MS-CHAP when possible.
Is RADIUS authentication secure?
RADIUS authentication security depends on three factors: the authentication protocol chosen, the implementation quality, and the operational practices surrounding deployment.
What makes RADIUS secure
Several design elements contribute to RADIUS security:
Shared secret protection: The shared secret between RADIUS clients and servers provides the foundation for secure communication. Strong secrets (minimum 22 characters, random generation, regular rotation) prevent unauthorised devices from impersonating legitimate clients.
Password obfuscation: RADIUS obfuscates passwords using the shared secret and MD5 hashing. While MD5 has known weaknesses, the obfuscation prevents casual observation of credentials in transit.
Message integrity: Modern RADIUS implementations add integrity checking to Access-Request packets, preventing packet manipulation attacks. This improvement addresses vulnerabilities like BlastRADIUS (more on this later).
Attribute protection: Sensitive attributes within RADIUS packets receive cryptographic protection based on the shared secret, preventing unauthorised modification of authorisation parameters.
Flexible authentication support: RADIUS's ability to work with certificate-based authentication (via EAP-TLS) provides strong security for organisations requiring phishing-resistant authentication.
Common security misconceptions
Network administrators often misunderstand certain aspects of RADIUS security:
Misconception: PAP is insecure. Reality: PAP with proper shared secrets provides robust security. The protocol sends passwords in cleartext within the authentication exchange, but RADIUS obfuscates them using the shared secret. This approach avoids the password storage vulnerabilities present in challenge-response protocols like CHAP.
Misconception: UDP makes RADIUS insecure. Reality: RADIUS typically uses UDP as the transport protocol, but this doesn't inherently reduce security. The protocol's security comes from cryptographic protection of packet contents, not the transport layer. Modern implementations like RadSec add TLS encryption over TCP when environments require additional transport security.
Misconception: MD5 usage makes RADIUS insecure. Reality: While MD5 has known cryptographic weaknesses, RADIUS's use of MD5 for password obfuscation doesn't create practical vulnerabilities when combined with strong shared secrets. More importantly, RADIUS 1.1 removes MD5 dependency entirely, moving to modern cryptographic standards.
Misconception: RADIUS is too old to be secure. Reality: Protocol age doesn't determine security. RADIUS has evolved through security-by-design improvements while maintaining backward compatibility. The protocol supporting your network today incorporates decades of security lessons learned.
Security-by-design in practice
Security-by-design means building security requirements into systems from the start, rather than trying to retrofit protection later. This approach has transformed RADIUS over the past two decades through systematic improvements at the standards level.
The BlastRADIUS response
When the BlastRADIUS vulnerability was identified in 2024, it highlighted both the importance of continuous security improvement and how open-source development responds to threats.
Our team had already addressed the underlying issue years earlier. RFC 5080, written in 2007, recommended that RADIUS clients add integrity protection to all Access-Request packets and that servers drop packets missing integrity protection. Those changes were added to FreeRADIUS in 2007 and made mandatory in FreeRADIUS version 3.0.0 in 2013.
Organisations running current FreeRADIUS versions were already protected against BlastRADIUS before the vulnerability received its name.
The BlastRADIUS response demonstrated how open-source security works in practice. While some organisations downplayed the threat, we recognised that cyberattacks typically involve multiple vulnerabilities, and fixing any single issue in the sequence can prevent an attack from succeeding. We rapidly developed comprehensive verification tools and updated both the RADIUS protocol standards and FreeRADIUS implementation.
RADIUS 1.1: removing the old cryptography
More recent improvements have addressed RADIUS's dependency on outdated cryptography. The RADIUS 1.1 standard removes MD5 encryption and eliminates the 8-bit packet limit that restricted high-throughput environments.
RADIUS 1.1 uses a 32-bit Token field to track requests and responses, allowing a client to send four billion packets to a server before needing to open a new connection. Organizations can enable RADIUS 1.1 through a simple configuration flag, with full backward compatibility when connecting to older systems.
RadSec: transport-level security
RadSec (RADIUS over TLS) addresses concerns about transport security by encrypting all RADIUS traffic using TLS. This eliminates several attack vectors present in traditional UDP-based RADIUS implementations.
RadSec provides:
Transport encryption: All RADIUS packets travel over TLS-encrypted connections, preventing network eavesdropping.
Certificate-based authentication: RadSec uses certificates to authenticate RADIUS clients and servers, eliminating shared secret management challenges for some deployment scenarios.
Connection reliability: The TCP-based transport provides reliable delivery, which matters for accounting packets where packet loss could compromise billing or auditing.
Proxy traversal: RadSec simplifies RADIUS traffic through firewalls and proxy servers, particularly in federated authentication scenarios like eduroam.
We've championed RadSec advancement at the protocol level, implemented it in FreeRADIUS, and incorporated it into our commercial solutions. These improvements benefit the entire RADIUS ecosystem, not just our customers.
RADIUS in network security: real-world deployment
RADIUS security matters most in the context of real-world networks handling millions of authentication requests daily. Theoretical security analysis means little if implementations can't scale or fail under production loads.
Scale validates security design
FreeRADIUS handles authentication for more than 100 million daily users across nearly every industry worldwide. This scale provides critical validation of security design choices.
Large national ISPs run 10-20 million users on FreeRADIUS. Global Fortune 50 companies authenticate every switch port and Wi-Fi access point worldwide through FreeRADIUS. Major equipment vendors test their products for FreeRADIUS compatibility before releasing new firmware.
This deployment scale matters for security. Attackers target widely-deployed systems, so vulnerabilities in popular software receive immediate attention. The FreeRADIUS codebase has been examined by thousands of security professionals over two decades. This scrutiny catches issues that internal QA teams at proprietary vendors often miss.
Defence in depth for RADIUS security
Securing RADIUS deployments requires multiple defensive layers:
Network segmentation: RADIUS servers should reside on protected network segments, isolated from general user traffic. Management access should require additional authentication and use encrypted protocols like SSH.
Strong shared secrets: Generate shared secrets using cryptographically secure random number generators. Minimum secret length should be 22 characters. Rotate secrets regularly according to security policy.
Access control: Restrict which network devices can communicate with RADIUS servers using firewall rules. Only legitimate NAS devices should reach RADIUS ports (typically 1812/1813).
Certificate validation: When using EAP-TLS or RadSec, properly validate certificates to prevent man-in-the-middle attacks. Implement certificate pinning where possible.
Monitoring and logging: Enable comprehensive logging of authentication attempts. Monitor for unusual patterns like sudden increases in failed authentication or connections from unexpected sources.
Regular updates: Keep RADIUS software current with security patches. Subscribe to security mailing lists for your RADIUS implementation.
RADIUS security best practices
Network administrators can maximise RADIUS security through operational best practices:
Choose appropriate authentication protocols. Use EAP-TLS with certificates when possible for the strongest security. If password-based authentication is required, PAP with strong shared secrets typically provides better security than MS-CHAP.
Implement certificate-based authentication. For wireless networks and VPN access, certificate-based authentication via EAP-TLS prevents phishing attacks and provides stronger security than password-based methods.
Use RadSec for sensitive environments. Deploy RadSec when RADIUS traffic traverses untrusted networks or when compliance requirements mandate transport encryption.
Separate Authentication from Accounting. Deploy separate RADIUS servers for Authentication and Accounting to prevent accounting load from impacting Authentication performance during usage spikes.
Enable RADIUS 1.1. Configure RADIUS 1.1 support on both clients and servers to benefit from improved cryptography and session tracking.
Monitor failed authentication. Failed authentication attempts often indicate attacks or compromised credentials. Set up alerting for authentication failures exceeding baseline thresholds.
What is a wireless security mode that requires RADIUS?
Wi-Fi networks supporting WPA2-Enterprise or WPA3-Enterprise require RADIUS for Authentication. These enterprise wireless security modes provide per-user authentication rather than shared pre-shared keys (PSK).
WPA2-Enterprise with RADIUS
WPA2-Enterprise uses 802.1X authentication with RADIUS to verify user credentials before granting network access. Each user has individual credentials rather than sharing a single password.
Security advantages include:
Individual accountability: Network activity can be traced to specific users, which matters for security incident response and compliance requirements.
Credential management: Disable access for individual users immediately without changing network-wide passwords. This matters when employees leave or credentials become compromised.
Stronger encryption: 802.1X generates unique encryption keys for each session, preventing one compromised device from exposing other network traffic.
Certificate-based authentication: Support for EAP-TLS enables certificate-based authentication, which resists phishing attacks that compromise password-based methods.
WPA3-Enterprise with RADIUS
WPA3-Enterprise improves upon WPA2-Enterprise with stronger cryptographic algorithms and mandatory use of 192-bit security mode for sensitive environments.
Additional security features include:
Protected Management Frames (PMF): Mandatory PMF prevents certain wireless attacks that were possible against WPA2 networks.
Stronger cryptography: 192-bit security mode uses stronger cryptographic algorithms, including GCMP-256 for encryption and HMAC-SHA-384 for integrity protection.
Forward secrecy: Even if an attacker compromises long-term credentials, they cannot decrypt previously captured wireless traffic.
Both WPA2-Enterprise and WPA3-Enterprise rely on RADIUS for the authentication component. The wireless access point acts as the RADIUS client (NAS), forwarding authentication requests to the RADIUS server. Upon successful authentication, the RADIUS server provides the access point with authorisation information controlling what the user can access.
Which is the most secure: PSK, RADIUS, or PKI?
This question reveals a common misunderstanding about these technologies. PSK (Pre-Shared Key), RADIUS, and PKI (Public Key Infrastructure) serve different functions and aren't directly comparable.
Pre-Shared Keys (PSK) represent a shared password that all users of a wireless network must know. PSK is used with WPA2-Personal or WPA3-Personal. The security limitation is that everyone shares the same credentials, so you cannot revoke access for individual users or trace network activity to specific people.
RADIUS is an authentication protocol that validates user credentials. RADIUS doesn't dictate which authentication method you use - it can work with passwords, tokens, certificates, or other credentials.
PKI provides certificate-based authentication using public/private key pairs. PKI works with RADIUS through protocols like EAP-TLS. The wireless network uses RADIUS to communicate with the authentication server, and PKI provides the actual credentials (certificates) being validated.
The most secure wireless configuration combines these technologies: WPA3-Enterprise using RADIUS with EAP-TLS (certificate-based authentication). This approach provides:
- Individual user credentials (not shared PSK)
- Strong cryptographic authentication (PKI certificates)
- Centralised authentication management (RADIUS)
- Per-session encryption keys
- Protection against phishing attacks (certificates cannot be phished like passwords)
Organisations requiring maximum wireless security should deploy WPA3-Enterprise with certificate-based authentication. This provides phishing-resistant authentication while maintaining the centralised management benefits of RADIUS.
Why open source enables better security
Commercial software companies optimise for revenue extraction rather than continuous improvement. When you've invested millions developing a product, your incentive is to milk that investment for decades rather than investing in major security improvements.
Open-source projects like FreeRADIUS optimise for different goals. We don't have shareholders demanding quarterly growth from legacy products. We have users demanding that systems actually work and stay secure against evolving threats.
Transparency creates better security
When anyone can audit the code, more eyes find potential vulnerabilities. Community scrutiny catches issues faster than vendor QA processes. Fixes don't wait for vendor release cycles, so critical patches can deploy within days of discovery.
This transparency matters for security. Proprietary vendors sometimes hide vulnerabilities until they've developed patches, leaving customers exposed during the development cycle. Open-source projects can't hide known issues because anyone examining the code would find them.
Standards work that benefits everyone
RADIUS improvements happen at the protocol level, benefiting every implementation. We contribute to IETF standards development, write RFCs that define how vendors should implement security updates, and maintain comprehensive compliance with standards ranging from RFC 2865 (the original RADIUS specification) through RFC 8044 (data types) to Wi-Fi Alliance specifications for WPA2 and WPA3 Enterprise.
When we improve RADIUS security, these improvements benefit organisations using any RADIUS implementation - not just FreeRADIUS. This commitment to the broader ecosystem distinguishes open-source development from proprietary vendor behaviour.
Is RADIUS secure enough for your network?
For most networks, properly implemented RADIUS provides robust security for Authentication, Authorisation, and Accounting. The protocol supports modern cryptographic methods through EAP-TLS, includes integrity protection preventing packet manipulation, and continues evolving through standards development.
RADIUS security depends primarily on implementation quality and operational practices rather than protocol limitations. Organisations using current software versions, strong shared secrets, appropriate authentication protocols, and defence-in-depth security practices can deploy RADIUS with confidence.
The alternative protocols sometimes proposed as RADIUS replacements - LDAP, TACACS+, SAML, or OIDC - don't actually replace RADIUS's core AAA functions for network access control. Each serves different purposes:
LDAP provides directory services but lacks the NAS communication capabilities RADIUS provides. You often use LDAP with RADIUS, not instead of it.
TACACS+ handles device administration authentication but doesn't support the full range of NAS types RADIUS does. Many networks run both protocols for different purposes.
SAML and OIDC work brilliantly for web application authentication but require browser-based interaction. They cannot authenticate network devices or handle non-web access scenarios where RADIUS excels.
RADIUS remains the standard for network access authentication because no other protocol actually provides the same capabilities. The security improvements documented in this article demonstrate that RADIUS continues evolving to meet modern security requirements while maintaining the backward compatibility critical for real-world networks.
Conclusion
RADIUS security has evolved substantially since the protocol's introduction in 1993. Modern implementations remove dependency on outdated cryptography, add integrity protection preventing packet manipulation, support strong cryptographic authentication via certificates, and optionally encrypt all traffic using RadSec.
The question “is RADIUS secure?” has a clear answer: yes, when properly implemented. RADIUS provides robust security for network authentication while supporting the scale and reliability requirements of production networks serving millions of users daily.
Organisations evaluating authentication security should focus on implementation quality rather than dismissing RADIUS based on age. The protocol continues evolving through security-by-design improvements at the standards level, benefiting every RADIUS deployment regardless of vendor.
Security depends primarily on operational practices: choosing appropriate authentication protocols, using strong shared secrets, maintaining current software versions, implementing defence-in-depth security measures, and monitoring authentication systems for unusual activity.
For most networks, RADIUS remains the optimal choice for network access authentication. No other protocol provides the same combination of security, scalability, flexibility, and proven reliability across the diverse range of network devices requiring authentication.
Need help?
Ready to improve your network authentication security? Get a quote for support and implementation services tailored to your specific infrastructure requirements and security needs.
Related Articles
We toppled a $500 million industry with free software
Twenty-five years ago, I started building FreeRADIUS in my spare time, with the help of a ragtag group of volunteers. I didn’t know then that it would become the world’s most widely deployed RADIUS server alternative.
Steel-Belted RADIUS Server End-of-Life: What You Need to Know Now
If you're still running Steel-Belted RADIUS server (SBR), you're operating on borrowed time. SBR Enterprise and Global Enterprise reached end-of-life on December 31, 2020. The Carrier Edition's End of Engineering came on February 28, 2023, followed by End of Support on September 30, 2023.