RADIUS
What it is
RADIUS (Remote Authentication Dial In User Service) is a client and server protocol for network access. The client is a network access server (NAS) such as a VPN gateway, wireless controller or switch; the server checks credentials against a directory or MFA service and answers with one of three packets: Access-Accept, Access-Reject or Access-Challenge. The protocol is RFC 2865 (June 2000) by C. Rigney, S. Willens, A. Rubens and W. Simpson; accounting is RFC 2866. EAP for 802.1X Wi-Fi and wired authentication rides inside it as defined in RFC 3579.
RADIUS is old, but it is where a lot of identity meets the network: enterprise Wi-Fi, VPN logins, device administration and many MFA integrations. Duo documents RADIUS server sections in its Authentication Proxy, and JumpCloud sells a Cloud RADIUS service for Wi-Fi and VPN (both checked on the vendors' sites, 5 November 2026).
Status (November 2026)
| Item | Status |
|---|---|
| RFC 2865, RADIUS | Draft Standard, June 2000; updated by RFC 2868, 3575, 5080, 6929, 8044 and 9765 (RFC Editor) |
| RFC 2866, Accounting | Informational, June 2000 |
| RFC 3579, RADIUS support for EAP | Informational, September 2003; defines Message-Authenticator use for EAP |
| RFC 6614, RADIUS over TLS (RadSec) | Experimental, May 2012; TCP port 2083 |
| RFC 7360, RADIUS over DTLS | Experimental, September 2014 |
| RFC 9765, RADIUS/1.1 | Experimental, April 2025, by A. DeKok (FreeRADIUS); ALPN name radius/1.1 |
| draft-ietf-radext-radiusdtls-bis | Revision 18, 30 September 2026; intended Standards Track; would obsolete RFC 6614 and RFC 7360 if approved |
| draft-ietf-radext-deprecating-radius | "Deprecating Insecure Practices in RADIUS", revision 10, active working group draft |
| Ports | 1812 radius and 1813 radius-acct (UDP and TCP), 2083 radsec (IANA) |
The direction is clear even though the documents are not finished: RADIUS over plain UDP is being treated as legacy, and the working group's effort is on TLS transport and on removing MD5.
How it works
Every packet has a 1-byte Code, a 1-byte Identifier, a 2-byte Length, a 16-byte Authenticator and a list of type-length-value attributes (RFC 2865 §3). The NAS sends an Access-Request (Code 1) with attributes such as User-Name, User-Password, NAS-IP-Address and Calling-Station-Id. The server replies:
- Access-Accept (2), often with authorization attributes: a VLAN, a filter, a session timeout, or a
Classvalue echoed into accounting. - Access-Reject (3).
- Access-Challenge (11) with a
Stateattribute and a prompt, used for one-time codes and for every round of EAP.
Security rests on a shared secret configured on both sides. It hides User-Password with an MD5-based keystream (§5.2) and authenticates responses with the Response Authenticator, MD5(Code + ID + Length + RequestAuth + Attributes + Secret) (§3). The optional Message-Authenticator attribute adds an HMAC-MD5 over the whole packet (RFC 3579 §3.2); RFC 3579 makes it mandatory only for packets carrying EAP. The full packet-by-packet view is in how RADIUS works, message by message.
Blast-RADIUS and what changed
CVE-2024-3596 (Blast-RADIUS, disclosed 9 July 2024) showed that an attacker in the network path can use an MD5 chosen-prefix collision to forge an Access-Accept from an Access-Reject when the exchange is PAP or CHAP without Message-Authenticator. The researchers' guidance is, in the short term, for clients and servers to always send and require Message-Authenticator on all requests and responses, with servers placing it first in Access-Accept and Access-Reject; and, in the long term, to run RADIUS inside TLS. EAP exchanges were already protected because Message-Authenticator is mandatory there.
Two consequences for identity teams:
- MFA behind RADIUS inherits RADIUS's weakness. If the NAS accepts a forged Access-Accept, the phishing-resistant factor behind the RADIUS server never mattered.
- The network access control plane is a target. CVE-2026-76460, an exploited authentication bypass in Cisco Identity Services Engine added to CISA KEV on 16 September 2026, sits in the RADIUS server product itself.
When to use it
Use RADIUS where the device gives you no alternative: 802.1X with EAP-TLS for Wi-Fi and wired access, VPN gateways, and device administration. Prefer EAP methods that run inside TLS over PAP and CHAP, require Message-Authenticator on both sides, and use RadSec where the NAS supports it. For web and SaaS sign-in, use SAML 2.0 or OpenID Connect instead, and put the MFA at the identity provider where it can be phishing-resistant (WebAuthn). Many VPNs now also accept SAML, which removes the RADIUS hop from user sign-in.
Pitfalls
- Shared secrets that are short, reused across every NAS, or older than the staff who set them. RFC 2865 §3 prefers secrets of at least 16 octets and forbids empty ones.
- RADIUS over UDP across networks you do not control, including to cloud RADIUS services, without TLS or IPsec.
Message-Authenticatorsent but not required, which leaves a downgrade.- PAP across the network, where the password is protected only by the shared-secret keystream.
- MFA push approvals through RADIUS with no number matching, which invites MFA fatigue.
How it works, message by message
The RADIUS message-flow walkthrough decodes an Access-Request attribute by attribute, then the Access-Challenge used for one-time codes, the Access-Accept with its authorization attributes and the accounting records, with each attribute tied to RFC 2865, RFC 2866 or RFC 3579 and the checks a NAS and a server must run after Blast-RADIUS.
Related
Walkthrough: how RADIUS works, message by message. Standards: LDAP, Kerberos. Glossary: RADIUS. Guides: MFA implementation best practices, zero trust rollout.
RADIUS: frequently asked questions
- What is RADIUS?
- RADIUS (Remote Authentication Dial In User Service) is the IETF protocol, defined in RFC 2865 (June 2000), that network devices such as VPN gateways, Wi-Fi controllers and switches use to send a user's credentials to a central authentication server and receive Access-Accept, Access-Reject or Access-Challenge. RFC 2866 adds accounting. It runs over UDP on ports 1812 and 1813 by default.
- What was Blast-RADIUS?
- Blast-RADIUS, CVE-2024-3596, disclosed on 9 July 2024, is an attack in which a machine in the middle uses an MD5 chosen-prefix collision to turn an Access-Reject into a valid-looking Access-Accept, because the Response Authenticator is an MD5 hash. It works against PAP and CHAP exchanges that are not protected by the Message-Authenticator attribute. The short-term fix is to send and require Message-Authenticator on every packet; the long-term fix is RADIUS over TLS.
- What is RadSec?
- RadSec is RADIUS carried inside TLS over TCP (RFC 6614, Experimental, May 2012, TCP port 2083) or DTLS (RFC 7360). The IETF RADEXT working group's draft-ietf-radext-radiusdtls-bis, revision 18 dated 30 September 2026, intends to make it a Standards Track replacement for both. RFC 9765 (April 2025) defines RADIUS/1.1, negotiated with ALPN inside TLS, which removes the MD5-based protections and the shared secret entirely.
- Is RADIUS still used with MFA?
- Yes. Many VPNs and network devices only speak RADIUS, so MFA products often sit behind a RADIUS proxy that receives the Access-Request, checks the password and a second factor, and returns Access-Accept or Access-Challenge. That makes the RADIUS hop part of the MFA's security: a forgeable Access-Accept bypasses whatever factor sits behind it.