Skip to main content
Identity Authority
Category: Authentication Factors

RADIUS

Also known as: RADIUS, Remote Authentication Dial-In User Service
Simply put

RADIUS is a networking protocol that lets a central server verify user credentials and decide whether to grant network access. It is commonly used so that devices like Wi-Fi access points, VPN gateways, and network switches can hand off login checks to a shared authentication service rather than storing credentials themselves.

Formal definition

RADIUS (Remote Authentication Dial-In User Service) is a client/server AAA protocol providing authentication, authorization, and accounting for network access. In a typical deployment a network access server (NAS) acts as the RADIUS client, forwarding a principal's credentials to a RADIUS server that performs authentication and returns an authorization decision (for example Access-Accept, Access-Reject, or Access-Challenge), often carrying policy attributes such as VLAN assignment; separate accounting messages track session activity. Note: the specific evidence packet provided does not contain authoritative sources describing the RADIUS protocol's technical details (such as transport, RFC references, or shared-secret handling), so those specifics are stated here from general domain knowledge and are not cited to the supplied evidence.

Why it matters

RADIUS centralizes authentication, authorization, and accounting (AAA) for network access, which means organizations can manage credentials and access policy in one place rather than provisioning them independently on every Wi-Fi access point, VPN gateway, or switch. This centralization reduces credential sprawl and gives security teams a consistent point at which to apply and audit network access decisions. Because network access devices act as clients that defer the actual credential check to a shared server, the endpoints themselves do not need to store or evaluate user secrets.

The protocol also matters because it commonly sits at the boundary between a principal and the network, making it a control point for enforcing policy such as VLAN assignment based on the authorization result. In many deployments RADIUS is the mechanism behind enterprise Wi-Fi authentication and remote-access VPNs, so its availability and correct configuration directly affect whether legitimate users can connect and whether unauthorized ones are kept out.

Because the supplied evidence digest does not contain authoritative technical sources on RADIUS, this entry describes the protocol from general domain knowledge and intentionally avoids stating specifics such as transport details, RFC numbers, or shared-secret handling that would require citation. Readers evaluating security properties should consult the relevant standards and vendor documentation for those details.

Who it's relevant to

Network and system administrators
Administrators who operate Wi-Fi, VPN, and switched network infrastructure rely on RADIUS to offload credential checks to a central server rather than storing credentials on each access device. They configure NAS devices as RADIUS clients and manage the policy attributes, such as VLAN assignment, returned on an Access-Accept.
Security architects
Architects designing network access controls treat RADIUS as a control point at the boundary between principals and the network, where authentication and authorization decisions are centralized. Understanding where RADIUS fits helps them reason about how network access policy is enforced and audited across heterogeneous access devices.
Compliance and audit teams
Because RADIUS provides accounting alongside authentication and authorization, its session records can support tracking of network access activity. Teams responsible for audit should confirm what accounting data is captured and retained in their specific deployment, since behavior varies by configuration and vendor.

Inside RADIUS

AAA protocol scope
RADIUS (Remote Authentication Dial-In User Service) is a network protocol providing centralized Authentication, Authorization, and Accounting (AAA) for users and devices connecting to network access services. It keeps identification, authentication, and authorization as distinct steps, and adds accounting for session usage tracking.
Client-server model
A Network Access Server (NAS), such as a VPN concentrator, wireless controller, or switch, acts as the RADIUS client, forwarding access requests to a RADIUS server. The NAS enforces the decision; the RADIUS server makes the authentication and authorization determination, functioning conceptually like a policy decision point relative to the enforcing device.
Message types
Core exchanges typically include Access-Request, Access-Challenge, Access-Accept, and Access-Reject for authentication and authorization, plus Accounting-Request and Accounting-Response for session accounting. Access-Challenge supports multi-step or challenge-response flows depending on the authentication method.
Attributes (AVPs)
RADIUS carries attribute-value pairs (AVPs) conveying user identity, credentials, requested service, and returned authorization parameters. Vendor-Specific Attributes (VSAs) extend the standard attribute set, so exact behavior depends on vendor and deployment.
Shared secret and credential protection
A RADIUS client and server authenticate to each other using a pre-shared secret. In traditional RADIUS, the User-Password attribute is obscured using this secret rather than the entire packet being encrypted, so protection of credentials and packet confidentiality differ and often depend on wrapping the transport (for example, RADIUS over TLS/DTLS in some deployments).
EAP integration
RADIUS commonly transports the Extensible Authentication Protocol (EAP), enabling a range of authentication methods (for example certificate-based or credential-based EAP methods) used in enterprise Wi-Fi (such as 802.1X) and VPN access, with the specific method determined by configuration.

Common questions

Answers to the questions practitioners most commonly ask about RADIUS.

Is RADIUS an authentication factor or a type of MFA?
No. RADIUS is a network AAA (authentication, authorization, and accounting) protocol, not an authentication factor. It does not itself constitute a knowledge, possession, or inherence factor. Rather, RADIUS is a transport and coordination protocol that a network access server (acting as a RADIUS client) uses to send credential and access requests to a RADIUS server. The actual factors, passwords, tokens, certificates, or others, are conveyed through or validated by way of RADIUS, but RADIUS is the protocol carrying the exchange, not the factor being verified.
Does RADIUS handle only authentication?
No, though the name (Remote Authentication Dial-In User Service) emphasizes authentication. RADIUS coordinates all three AAA functions: authentication (verifying the identity of the requesting principal), authorization (returning attributes that determine what network access or privileges the principal receives), and accounting (recording session activity such as start, stop, and usage data). Treating RADIUS as authentication-only overlooks the authorization attributes and accounting records it typically carries, though which functions are used depends on deployment and configuration.
What role does a RADIUS server play relative to the device a user connects through?
In a typical deployment, the network access device, such as a VPN concentrator, wireless controller, or switch, acts as the RADIUS client, sometimes called the network access server (NAS). The user or device does not speak RADIUS directly to the RADIUS server; instead, the NAS collects credentials and forwards an access request to the RADIUS server, which returns an accept, reject, or challenge response. This keeps identity verification centralized while the enforcement point remains at the network device.
How does RADIUS integrate with an existing identity store or directory?
RADIUS servers commonly act as a front end that validates credentials against a backing identity source rather than storing credentials themselves. In many deployments the RADIUS server queries an LDAP directory or another user store to verify submitted credentials and to retrieve attributes used for authorization decisions. The specific integration, attribute mapping, and supported backends vary by RADIUS server implementation and configuration, so validate capabilities against your chosen vendor.
How can RADIUS be used to support multi-factor authentication?
RADIUS can participate in MFA flows through its challenge-response capability, where the RADIUS server returns an Access-Challenge prompting for an additional factor before issuing an Access-Accept. This lets a first factor (such as a password) be followed by a second factor (such as a one-time code). Whether and how this works depends on the RADIUS server, the network access client's support for challenge handling, and the integrated factor provider; not all clients handle challenge exchanges consistently.
What should be considered about protecting RADIUS traffic in transit?
Attention to transport protection is important because base RADIUS was not designed with strong end-to-end confidentiality for all attributes. Deployments frequently address this by tunneling RADIUS over a protected transport or by using deployment options that add transport-layer protection, depending on what the RADIUS server and clients support. Confirm which protection mechanisms your implementation offers and how shared secrets are managed, since these details vary by vendor and profile and affect the security of the exchange.

Common misconceptions

RADIUS encrypts the entire authentication exchange.
In traditional RADIUS, only the User-Password attribute is obscured using the shared secret; the rest of the packet is not encrypted by default. Full transport confidentiality typically requires wrapping RADIUS in TLS or DTLS, depending on the deployment.
RADIUS only performs authentication.
RADIUS is an AAA protocol. It handles authentication, returns authorization parameters, and provides accounting for session tracking. Treating it as authentication-only ignores its authorization and accounting roles.
The RADIUS server enforces access directly.
The RADIUS server makes the decision, but the Network Access Server (NAS) acting as the RADIUS client enforces it. Enforcement and decision-making are separate responsibilities in most deployments.

Best practices

Use strong, unique shared secrets per RADIUS client and rotate them according to your security policy, since the shared secret protects client-server trust and the obscured password attribute.
Where confidentiality of the full exchange matters, deploy RADIUS over a protected transport such as TLS or DTLS rather than relying on the default attribute-level obscuring, subject to vendor support.
Prefer EAP methods that provide mutual authentication and strong credentials (for example certificate-based methods) for 802.1X and VPN access, matching the method to your environment.
Enable and retain RADIUS accounting to support session auditing, troubleshooting, and compliance evidence, keeping accounting data distinct from real-time authorization decisions.
Segment and firewall RADIUS traffic between the NAS and RADIUS server, and restrict which clients may submit Access-Requests to reduce exposure.
Deploy redundant RADIUS servers and validate failover behavior, since the RADIUS server is typically a central point for network access decisions.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide