A RADIUS server is the system that authenticates a subscriber or device requesting network access, returns the service profile they are entitled to, and records what they used. It is the enforcement point where a commercial plan becomes a technical reality.
- RADIUS is the protocol; AAA is the role. Authentication asks who you are, authorization asks what you may do, accounting records what you used. RADIUS is one way to implement all three.
- The RADIUS “client” is not the subscriber’s device. It is the network access server – the BNG, BRAS, wireless LAN controller, switch, or VPN gateway that enforces the server’s decision.
- Two ports do the work. UDP 1812 for authentication and authorization, UDP 1813 for accounting. Change-of-Authorization (RFC 5176) modifies or ends a live session without re-authentication.
- Diameter did not replace it. Diameter is mandatory in the 3GPP mobile core; RADIUS still dominates broadband, Wi-Fi, and enterprise access. Converged operators run both.
- The protocol is easy; the deployment is not. Session state, vendor-specific attribute mapping, and redundancy are what separate a lab install from a carrier one.
Introduction
A RADIUS server is a centralized authentication server that decides who is allowed onto a network, what they are allowed to do once connected, and how their usage is recorded. Every time a broadband subscriber’s router dials PPPoE (Point-to-Point Protocol over Ethernet), a Wi-Fi user joins a hotspot, or an engineer logs into a core router, a RADIUS server is usually the system that says yes or no.
For telecom operators and internet service providers (ISPs), that decision point is revenue infrastructure, not a convenience. A subscriber who cannot authenticate cannot be served. A session that is not accounted for cannot be billed. Operators need one reliable place to authenticate and authorize subscribers across broadband, fixed wireless, carrier Wi-Fi, and enterprise access – instead of scattered credentials sitting on individual broadband network gateways, switches, and wireless controllers. RADIUS was built to solve exactly that problem, and it still does at carrier scale.
This guide covers what RADIUS stands for, how a RADIUS server works packet by packet, the components of a RADIUS architecture, how AAA fits together, where operators deploy it, how RADIUS compares with Diameter and TACACS+, and its real advantages and limitations.
What Does RADIUS Stand For?
RADIUS stands for Remote Authentication Dial-In User Service. The name is a fossil from its origins: Livingston Enterprises created it in 1991 to manage dial-up modem pools, where a single authentication server needed to serve many dial-in access devices.
The dial-up era ended; the protocol did not. The IETF standardized it in RFC 2058, then revised it into RFC 2865 for authentication and RFC 2866 for accounting. Later extensions include RFC 2869 and RFC 3579 for Extensible Authentication Protocol (EAP) support, RFC 3748 for EAP itself, and RFC 5176 for Change-of-Authorization. Those extensions are why a protocol designed for modems now authenticates fiber-to-the-home (FTTH) subscribers, Wi-Fi offload users, and enterprise 802.1X endpoints.
The important thing to internalize as a beginner: RADIUS is a protocol, an AAA server is the role, and a RADIUS server is a system that performs the AAA role by speaking the RADIUS protocol. People use the three terms loosely and interchangeably in real conversations.
How Does a RADIUS Server Work?
The RADIUS protocol follows a simple client/server request-response model. The terminology trips up almost every newcomer: the RADIUS “client” is not the subscriber’s device. The client is the network access device – the broadband network gateway (BNG), broadband remote access server (BRAS), wireless LAN controller (WLC), switch, VPN concentrator, or aggregation node facing the optical line terminal (OLT). That device is generically called a NAS (Network Access Server).
A typical RADIUS authentication exchange runs like this:
- A subscriber device attempts to connect and presents credentials to the NAS. That might be a PPPoE username and password, an EAP identity, a MAC address, or a captive-portal login.
- The NAS packages those credentials into a RADIUS Access-Request packet and sends it to the RADIUS server, typically over UDP port 1812.
- The RADIUS server checks the identity against its credential store – a local subscriber database, an SQL database, LDAP or Active Directory, a home subscriber server (HSS) or unified data management (UDM) function, or a SIM-based store – and applies any policy rules attached to that subscriber.
- The server replies with an Access-Accept, an Access-Reject, or an Access-Challenge if more information is needed, as in multi-round EAP or CHAP exchanges.
- If accepted, the reply also carries authorization attributes: IP address or pool, virtual LAN (VLAN), framed routes, session timeout, and vendor-specific attributes (VSAs) that map to bandwidth or quality-of-service (QoS) profiles.
- Once the session is live, the NAS sends Accounting-Request packets over UDP port 1813 to record session start, interim updates, and session stop, along with data volumes and duration.
Two design details matter. First, the shared secret: the NAS and the server share a common secret used to authenticate each other and obscure the User-Password attribute. That is why a NAS must be explicitly defined on the server before it gets a reply. Second, RADIUS is stateless per transaction and retransmission-driven. That is what lets one server cluster absorb very high transaction volumes without holding a connection open to every access device.
Components of a RADIUS Architecture
A production RADIUS deployment has five moving parts:
- Supplicant / subscriber device — the customer premises equipment (CPE), optical network terminal (ONT), laptop, phone, or Internet-of-Things (IoT) endpoint that wants access. In 802.1X terminology it is the supplicant.
- NAS / RADIUS client — the BNG, BRAS, WLC, access point, VPN gateway, or switch that enforces the decision. It blocks or admits traffic; it never decides.
- RADIUS server — the decision engine. It parses requests, evaluates policy, returns authorization attributes, and writes accounting records.
- Identity and policy stores — where truth actually lives: subscriber databases, SQL, LDAP or Active Directory, SIM and HSS data, or a provisioning API fed by business support systems (BSS) and CRM.
- Downstream systems — billing and charging, policy control, CRM, and the analytics or security information and event management (SIEM) platforms that consume accounting and authentication telemetry.
Larger networks add RADIUS proxies, which forward requests to another realm’s server based on the domain in the username (user@realm). Proxying is what makes Wi-Fi roaming, eduroam, and wholesale broadband possible: the visited network authenticates the user against the home operator’s AAA server without ever holding the credentials. For how these pieces behave under peak load at operator scale, see Alepo’s guide to self-scaling AAA for peak traffic.
Authentication, Authorization, and Accounting (AAA) Explained
RADIUS is one implementation of the AAA framework, and each “A” answers a distinct question.
Authentication — who are you? The server validates an identity claim using PAP, CHAP, MS-CHAPv2, MAC-based authentication, or one of the EAP methods: EAP-TLS for certificate-based access, EAP-TTLS and EAP-PEAP for tunneled credentials, and EAP-SIM, EAP-AKA, and EAP-AKA’ for SIM-based Wi-Fi and mobile offload. Failure here is a hard stop; the port stays closed.
Authorization — what are you allowed to do? Authentication only proves identity. Authorization returns the service profile: IP pool or static address, VLAN, upstream and downstream bandwidth, QoS class, access control lists, concurrent-session limits, and session or idle timeouts. This is where a 100 Mbps plan becomes technically different from a 1 Gbps plan for the same user. It is also where a subscriber who has exhausted a prepaid quota lands in a walled garden instead of being disconnected.
Accounting — what did you actually use? Accounting records session start and stop, uptime, input and output octets and packets, assigned IP, and NAS and port identifiers. It feeds usage-based billing, fair-usage enforcement, capacity planning, fraud detection, and regulatory retention. Weak accounting is a common source of silent revenue leakage in broadband networks – see how AAA tightens authentication and session efficiency in FTTH deployments.
A fourth capability now sits alongside these three: Change-of-Authorization (CoA) and Disconnect-Message, defined in RFC 5176. CoA lets the server modify or terminate a live session without re-authentication – instant speed boosts, mid-session quota enforcement, plan upgrades, or ending a compromised session. For how this plays out in prepaid services, read Alepo’s guide to real-time quota management for prepaid broadband and Wi-Fi.
Common Telecom Use Cases
- Fixed broadband (FTTH, DSL, cable, PON). PPPoE and IP-over-Ethernet sessions terminate on a BNG or BRAS that authenticates each session against RADIUS and receives the subscriber’s IP, VLAN, and bandwidth profile in the Access-Accept.
- Carrier and public Wi-Fi. Hotspots, stadiums, transit hubs, and hospitality networks use RADIUS for captive-portal, voucher, MAC-based, and EAP-SIM or EAP-AKA authentication. That enables mobile offload and monetized guest access.
- Fixed wireless access (FWA). FWA operators authenticate CPE by MAC address or credentials and apply per-plan rate limits through returned VSAs.
- Enterprise and campus 802.1X. Port-based access control, dynamic VLAN assignment, and device onboarding all run over RADIUS – which is why operators selling managed enterprise connectivity run the same AAA stack.
- VPN and remote access. VPN concentrators authenticate remote users against RADIUS, frequently combined with a second factor.
- Prepaid and quota-managed services. Real-time accounting plus CoA enables prepaid broadband, day passes, data buckets, and top-up-triggered speed changes without manual intervention.
- Wholesale and roaming. Realm-based proxying lets wholesale ISPs, mobile virtual network operators (MVNOs), and Wi-Fi roaming federations authenticate subscribers against the home operator’s AAA.
- Network device administration. Router and switch logins can use RADIUS, though TACACS+ is generally preferred for per-command authorization.
RADIUS Packet Types and the Authentication Flow
A RADIUS packet has a fixed header – Code, Identifier, Length, and a 16-byte Authenticator – followed by a variable list of attribute-value pairs (AVPs). The codes you will meet in a packet capture:
| Code | Packet type | Purpose |
| 1 | Access-Request | NAS asks the server to authenticate a user |
| 2 | Access-Accept | Access granted, with authorization attributes |
| 3 | Access-Reject | Access denied |
| 11 | Access-Challenge | Server requests additional data (EAP, CHAP, one-time password) |
| 4 | Accounting-Request | Session Start, Interim-Update, or Stop record |
| 5 | Accounting-Response | Server acknowledges the accounting record |
| 40–45 | Disconnect / CoA requests and responses | RFC 5176 session control |
Common attributes include User-Name, User-Password, CHAP-Password, NAS-IP-Address, NAS-Port-Type, Called-Station-Id and Calling-Station-Id, Framed-IP-Address, Session-Timeout, Acct-Session-Id, Acct-Input-Octets, Acct-Output-Octets, and Acct-Terminate-Cause.
Vendor-Specific Attributes (attribute 26) carry vendor semantics. Each vendors define their own, and mapping VSAs correctly is usually the most time-consuming part of any real integration.
An EAP-PEAP Wi-Fi login is therefore less a round trip than a conversation: Access-Request with EAP identity → Access-Challenge → several Access-Request and Access-Challenge pairs carrying the TLS and inner-method exchanges → Access-Accept with keying material and VLAN → Accounting-Request (Start) → Interim-Updates → Accounting-Request (Stop).
How Does RADIUS Compare With Diameter?
The RADIUS vs Diameter question comes up constantly, and the honest answer is that they are complements, not competitors.
| Dimension | RADIUS | Diameter |
| Standard | RFC 2865 / 2866 | RFC 6733 |
| Transport | UDP (1812/1813) | TCP or SCTP |
| Reliability | Application-level retransmission | Reliable transport, built-in failover |
| Security | Shared secret, MD5-based hiding; RadSec (RFC 6614) for TLS | TLS/DTLS or IPsec |
| Model | Client/server, request-response | Peer-to-peer; server can initiate |
| Attribute space | 8-bit attribute IDs, 253-byte values | 32-bit AVP codes, grouped AVPs |
| Typical domain | Broadband, Wi-Fi, enterprise, VPN | 3GPP mobile core: Gx, Gy, S6a, S6b, SWx, SWm |
| Capability negotiation | None | Yes |
Diameter was designed as RADIUS’s successor and is mandatory on 3GPP mobile core interfaces – policy over Gx, online charging over Gy, subscriber data over S6a. But it never displaced RADIUS at the fixed access edge. Virtually every BNG, WLC, and switch speaks RADIUS, and the lightweight UDP model suits high-volume, short-lived access transactions.
The practical consequence: converged networks need both. A subscriber may be authenticated over RADIUS at the BNG while their policy and charging travel over Diameter to the policy and charging rules function (PCRF) and the online charging system (OCS). That is why modern platforms are built as dual-stack AAA rather than RADIUS-only or Diameter-only servers. For a deeper three-way comparison including device administration, see RADIUS vs Diameter vs TACACS+ in CSP environments.
Advantages and Limitations
Advantages
Centralized identity and policy for every access type. Near-universal vendor support. A lightweight protocol with very high throughput. Extensibility through VSAs without protocol changes. Mature accounting that maps directly to billing. Horizontal scalability and geo-redundancy. And real-time session control via CoA.
Limitations
Classic RADIUS security is dated. Only the User-Password attribute is obscured, using MD5, so traffic should stay on trusted transport or be wrapped in RadSec or IPsec. UDP puts retransmission and duplicate handling on the application. The 8-bit attribute space and 253-byte value limit constrain payloads, and there is no capability negotiation between peers. And because RADIUS defines the transaction rather than the session, session state, ghost-session cleanup, and concurrency enforcement are implementation qualities rather than protocol guarantees. That is precisely where open-source and carrier-grade products diverge.
How Alepo Uses RADIUS
Alepo’s AAA Server was built for communication service providers (CSPs) that need to authenticate subscribers, authorize services, and meter usage across millions of subscribers – with broadband, mobile, and Wi-Fi access all handled by one platform rather than three separate silos.
In that design, RADIUS is one interface on a converged stack, not a standalone product. The same stack terminates RADIUS, Diameter, and TACACS+, and supports the access methods operators actually encounter: EAP-SIM, EAP-AKA, and EAP-AKA’ for SIM-based Wi-Fi and offload; EAP-TLS, EAP-TTLS, and EAP-PEAP for certificate and tunneled credentials; plus PAP, CHAP, and MAC-based authentication.
Session handling is where carrier-grade requirements show up most clearly: per-subscriber concurrency tracking, mid-session policy changes via CoA, ghost-session cleanup, and real-time session visibility. That combination is what makes prepaid enforcement accurate instead of approximate.
Deployment is flexible – containerized on Kubernetes in public cloud or on premises, as virtual machines, or on bare metal for latency-sensitive workloads – with RADIUS and Diameter terminating on the same stack in every model. If you are planning a move off an existing AAA platform, the AAA migration checklist covers sequencing and cutover.
Frequently Asked Questions
Q. What is a RADIUS server?
A RADIUS server is a centralized system that authenticates users requesting network access, authorizes what services and bandwidth they receive, and records session usage for billing and reporting. Network access devices such as BNGs, wireless controllers, and switches send RADIUS requests to it and enforce the decision it returns.
Q. What is a RADIUS server used for?
It is used to control and account for network access. ISPs use it to authenticate broadband and Wi-Fi subscribers and apply per-plan speeds; enterprises use it for 802.1X port security, VPN logins, and dynamic VLAN assignment. In every case, it centralizes credentials and policy instead of duplicating them on each access device.
Q. Is RADIUS the same as LDAP?
No. RADIUS is an access-control protocol that carries authentication requests and returns authorization and accounting decisions. LDAP is a directory-access protocol used to look up identities and attributes. They are complementary: a RADIUS server frequently queries an LDAP directory or Active Directory to validate the credentials it receives.
Q. What is the RADIUS server system?
The RADIUS server system is the full architecture around the protocol: subscriber devices, the network access servers acting as RADIUS clients, the RADIUS server itself, optional proxies for realm-based forwarding, identity stores such as SQL, LDAP, or SIM databases, and downstream billing, policy, and analytics platforms that consume the resulting records.
Q. What is the difference between RADIUS and AAA?
AAA is the framework – authentication, authorization, and accounting. RADIUS is one protocol that implements it. An AAA server is the system performing the role, and it may speak RADIUS, Diameter, TACACS+, or all three. Saying “RADIUS server” and “AAA server” interchangeably is common but technically imprecise.
Q. Why do ISPs use RADIUS?
Because it links network access directly to the subscriber’s commercial plan. RADIUS authenticates each session, returns the correct bandwidth and IP configuration, and generates accounting records that feed billing, fair-usage policy, and prepaid enforcement. It also scales to millions of subscribers and works with multi-vendor access equipment.
Q. What is the difference between RADIUS and TACACS+?
RADIUS runs over UDP, encrypts only the password field, and combines authentication with authorization – making it well suited to subscriber and end-user network access. TACACS+ runs over TCP port 49, encrypts the full payload, and separates the three A’s, allowing per-command authorization. That is why TACACS+ is preferred for network device administration.
Q. Is Diameter replacing RADIUS?
Not in practice. Diameter was designed as RADIUS’s successor and is mandatory across 3GPP mobile core interfaces, but RADIUS still dominates fixed broadband, Wi-Fi, and enterprise access because of universal equipment support and its lightweight transaction model. Most operators run both, which is why dual-stack AAA platforms are the norm in converged networks.
Conclusion
A RADIUS server is the control point where identity, service policy, and usage data meet. It authenticates every access attempt, returns the attributes that turn a plan into a real service profile, and produces the records operators bill against. The architecture is simple -NAS as client, server as decision engine, identity store as source of truth – but session state, VSA mapping, and redundancy are what separate a lab deployment from a carrier one. More than three decades after its dial-up debut, RADIUS remains the backbone of centralized authentication for broadband, Wi-Fi, and enterprise access, working alongside Diameter rather than being replaced by it.
Next steps
See it running on your network. A single platform terminates RADIUS, Diameter, and TACACS+ natively. And it’s explicitly described as carrier-grade (active-active geo-redundant, proven at Tier-1 scale). Request an AAA demo to walk through authentication, authorization, accounting, and real-time session control with an Alepo AAA specialist.
