# RADIUS Source: https://startwithidentity.com/standards/radius/ Last updated: 2026-11-05 License: content by Start with Identity. Cite the source URL. --- ## 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](https://www.rfc-editor.org/rfc/rfc2865) (June 2000) by C. Rigney, S. Willens, A. Rubens and W. Simpson; accounting is [RFC 2866](https://www.rfc-editor.org/rfc/rfc2866). EAP for 802.1X Wi-Fi and wired authentication rides inside it as defined in [RFC 3579](https://www.rfc-editor.org/rfc/rfc3579). 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](https://startwithidentity.com/vendors/mfa/duo/) documents RADIUS server sections in its Authentication Proxy, and [JumpCloud](https://startwithidentity.com/vendors/iam/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](https://www.rfc-editor.org/info/rfc2865)) | | RFC 2866, Accounting | Informational, June 2000 | | RFC 3579, RADIUS support for EAP | Informational, September 2003; defines `Message-Authenticator` use for EAP | | [RFC 6614](https://www.rfc-editor.org/rfc/rfc6614), RADIUS over TLS (RadSec) | Experimental, May 2012; TCP port 2083 | | [RFC 7360](https://www.rfc-editor.org/rfc/rfc7360), RADIUS over DTLS | Experimental, September 2014 | | [RFC 9765](https://www.rfc-editor.org/rfc/rfc9765), RADIUS/1.1 | Experimental, April 2025, by A. DeKok (FreeRADIUS); ALPN name `radius/1.1` | | [draft-ietf-radext-radiusdtls-bis](https://datatracker.ietf.org/doc/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](https://datatracker.ietf.org/doc/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](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml)) | 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](https://www.rfc-editor.org/rfc/rfc2865#section-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 `Class` value echoed into accounting. - **Access-Reject** (3). - **Access-Challenge** (11) with a `State` attribute 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](https://www.rfc-editor.org/rfc/rfc2865#section-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](https://www.rfc-editor.org/rfc/rfc3579#section-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](https://startwithidentity.com/guides/protocols/radius-message-flow/). ## Blast-RADIUS and what changed [CVE-2024-3596](https://startwithidentity.com/cves/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](https://www.blastradius.fail/) 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: 1. **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. 2. **The network access control plane is a target.** [CVE-2026-76460](https://startwithidentity.com/cves/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](https://startwithidentity.com/standards/saml-2-0/) or [OpenID Connect](https://startwithidentity.com/standards/openid-connect/) instead, and put the MFA at the identity provider where it can be phishing-resistant ([WebAuthn](https://startwithidentity.com/standards/webauthn-fido2/)). 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-Authenticator` sent 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](https://startwithidentity.com/techniques/mfa-fatigue-push-bombing/). ## How it works, message by message The [RADIUS message-flow walkthrough](https://startwithidentity.com/guides/protocols/radius-message-flow/) 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](https://startwithidentity.com/guides/protocols/radius-message-flow/). Standards: [LDAP](https://startwithidentity.com/standards/ldap/), [Kerberos](https://startwithidentity.com/standards/kerberos/). Glossary: [RADIUS](https://startwithidentity.com/glossary/radius/). Guides: [MFA implementation best practices](https://startwithidentity.com/guides/authentication/mfa-implementation-best-practices/), [zero trust rollout](https://startwithidentity.com/guides/implementation/zero-trust-rollout/).