RADIUS Protocol Explained: How It Secures Telecom Networks

Summary

• RADIUS (Remote Authentication Dial-In User Service) is the client-server protocol that handles authentication, authorization, and accounting (AAA) for subscribers. A RADIUS server is the central decision point that grants or denies access and meters every session.
• Architecture: subscriber → NAS (the RADIUS client) → RADIUS server, over UDP ports 1812/1813, secured by a shared secret.
• In telecom: RADIUS authenticates broadband, carrier Wi-Fi (via EAP-SIM/AKA), and wholesale/MVNO access; Diameter runs the LTE/IMS core, and carriers converge both on one AAA platform.
• Carrier-grade vs open-source: production networks need five-nines availability, thousands of transactions/sec, native security (RADSEC, Message-Authenticator against Blast-RADIUS/CVE-2024-3596).

Every subscriber who connects to a fixed broadband line, joins a carrier Wi-Fi hotspot, or attaches to a mobile network sets off a decision that has to resolve in milliseconds: is this device allowed on the network, what level of service does it get, and how should its usage be recorded? In most communication service provider (CSP) networks, the component that answers those questions is a RADIUS server.

This guide explains the RADIUS protocol from first principles for telecom engineers learning the fundamentals. You will see what RADIUS is, how a RADIUS server works with the network equipment around it, the packet types that carry each exchange, how the protocol secures 4G, broadband, and Wi-Fi access, how it compares with Diameter, what Change of Authorization adds, and what separates a carrier-grade RADIUS server from an open-source build.

The scale behind the question keeps growing. IoT Analytics counted 21.1 billion connected IoT devices at the end of 2025 and projects 39 billion by 2030. Every one of those endpoints has to be authenticated, authorized, and accounted for before it can use the network – the exact job the RADIUS protocol was designed to do.

What Is the RADIUS Protocol?

The RADIUS protocol is an IETF-standardized client-server protocol that provides centralized authentication, authorization, and accounting – the three functions known together as AAA. It was first defined in RFC 2865 for authentication and authorization and RFC 2866 for accounting, and despite dating to the late 1990s it remains the default access-control protocol across fixed, mobile, and Wi-Fi networks.

Two ideas make the RADIUS protocol work. The first is centralization: instead of every access device keeping its own list of users and policies, all of them defer to one authoritative RADIUS server. The second is the shared secret – a pre-configured key known only to the RADIUS server and the access device, used to sign requests and obscure the password so the two ends can trust each other. That shared secret is the root of how RADIUS secures an exchange.

RADIUS messages travel over UDP, using port 1812 for authentication and port 1813 for accounting (older deployments used 1645 and 1646). It is worth being precise about what a RADIUS server is and is not: it is an access-control and policy engine, not a subscriber database. It authenticates against an identity store – an LDAP directory, an HSS/UDM, or a billing system – rather than replacing one. That distinction is what lets a single RADIUS server sit in front of millions of subscriber records without owning them.

RADIUS Architecture: Client, Server, NAS

Understanding how a RADIUS server works starts with the three roles present in every exchange:

• Subscriber (supplicant): the end-user device requesting access – a home gateway, smartphone, laptop, or IoT module.
• Network Access Server (NAS): the equipment the subscriber connects through – a Broadband Network Gateway (BNG), Wi-Fi access controller, or mobile gateway. In RADIUS terms the NAS is the client: it never makes the access decision itself, it asks the server.
• RADIUS server: the central system that validates the shared secret, checks the identity against the subscriber data store, applies policy, and returns an accept or reject.

The exchange is a request-response loop. The NAS packages the subscriber’s credentials into an Access-Request and sends it to the RADIUS server; the server verifies the shared secret, looks up the identity, evaluates the authorization profile, and replies with Access-Accept (carrying policy attributes such as IP address, bandwidth, and session timeout), Access-Reject, or Access-Challenge when it needs more – a one-time password or the next step of an EAP exchange. Once the subscriber is admitted, accounting packets meter the session from start to stop.

This client-server split is the architectural reason RADIUS scales. Add a thousand more access points and none of them need their own credential store; they all point at the same RADIUS server or cluster, so policy stays consistent everywhere and identity lives in one place.

RADIUS Packet Types

Every RADIUS exchange is carried by a small set of packet types, each identified by a numeric code in the header. Grouping them by function makes RADIUS logs far easier to read during troubleshooting.

Inside every packet are attribute-value pairs (AVPs) – standardized fields such as User-Name, Framed-IP-Address, and Session-Timeout. Vendors add their own data through Vendor-Specific Attributes (VSAs), which is how RADIUS adapts to the particular equipment in a given network. When stronger credential exchange is needed than a simple password, RADIUS carries the Extensible Authentication Protocol (EAP) – the mechanism telecom networks lean on for SIM-based and certificate-based access.

One AVP matters specifically for security: the Message-Authenticator attribute, which signs the packet so a NAS or server can detect tampering. It moved from best practice to necessity after the 2024 vulnerability discussed further below.

RADIUS in Telecom: 4G, Broadband, Wi-Fi

RADIUS in a telecom network looks different from RADIUS in an enterprise. The protocol is the same, but a CSP runs it across several access types at once, each with its own demands. Here is where a RADIUS server, explained in a CSP context, earns its keep:

• Fixed broadband: When a subscriber’s home router establishes a PPPoE or IPoE session, the BNG acts as the NAS and asks the RADIUS server to authenticate the line and return the IP address, bandwidth profile, and session policy. Accounting records then feed usage-based billing and capacity planning.
• Carrier Wi-Fi: Public and managed Wi-Fi rely on RADIUS with EAP. EAP-SIM and EAP-AKA authenticate subscribers using their existing SIM credentials, which is what lets Wi-Fi calling and trusted Wi-Fi offload work without a separate sign-in – the subscriber never types a password because the SIM is the identity.
• 4G/LTE and mobile: In the mobile core, Diameter handles most signaling, but RADIUS remains widely used at the edges – for non-3GPP and untrusted Wi-Fi access into the packet core, for wholesale and Mobile Virtual Network Operator (MVNO) authentication, and for interworking with policy and charging. Many operators run RADIUS and Diameter side by side on one converged AAA fabric.

Across all three, the RADIUS server is the single point where identity, policy, and usage meet – which is also why its availability and security posture are non-negotiable at carrier scale.

RADIUS vs Diameter

Engineers new to telecom AAA quickly hit the question of RADIUS versus Diameter. Diameter was developed as a successor to RADIUS and standardized in RFC 6733; it addressed several of RADIUS’s structural limits and became the signaling protocol of the LTE and IMS core, on interfaces such as Gx, Gy, and S6a. But it did not replace RADIUS – the two coexist.

The practical takeaway for a CSP: access-layer authentication – the broadband line, the Wi-Fi session, the wholesale partner – is still overwhelmingly RADIUS, while the mobile core leans on Diameter. Rather than choosing one, carriers converge both onto a single AAA platform so policy and subscriber identity stay consistent no matter which protocol the access network speaks.

RADIUS CoA Explained

In the basic RADIUS protocol, the server only speaks when the NAS asks – a subscriber is authorized once, at login, and that decision stands until they disconnect. Change of Authorization (CoA), standardized in RFC 5176, breaks that limitation by letting the RADIUS server reach into a live session and change it.

Two packet types make it work. A CoA-Request (code 43) modifies attributes on an active session – raising a subscriber’s speed the instant they buy an upgrade, or dropping them to a captive portal when a data quota runs out. A Disconnect-Request (code 40) terminates a session outright.

CoA is where RADIUS becomes a real-time control and security tool rather than a one-time gate. On the monetization side, a subscriber who buys a speed boost or a top-up expects it to apply now, not at next login, and CoA delivers that. On the security side, CoA is how an operator ends a fraudulent or compromised session immediately, or enforces a hard cutoff the moment abuse is detected – without waiting for the session to expire on its own.

Carrier-Grade RADIUS vs Open-Source

Any engineer can stand up an open-source RADIUS server in an afternoon, and for a lab, a campus, or a few thousand users that is often the right call. The gap between that and a carrier-grade RADIUS server only appears under production load and failure conditions – exactly the conditions a national subscriber base creates every day.

Two dimensions deserve extra attention.

1. Security

RADIUS’s original security model is showing its age. Only the User-Password attribute is obscured – using a shared secret and an MD5-based hash – while the rest of the packet crosses the network in the clear. MD5’s weakness became concrete with the 2024 Blast-RADIUS attack (CVE-2024-3596), which showed that an on-path attacker could, in some configurations, forge a valid Access-Accept out of an Access-Reject and turn a denied user into an admitted one. The established mitigations — RADSEC (RADIUS over TLS, RFC 6614, TCP port 2083) to encrypt the whole exchange, the Message-Authenticator attribute to block forgery, and IPsec or segmented management networks for transport – are exactly the protections a carrier-grade platform should support natively rather than leaving operators to bolt on.

2. Continuity

The Alepo AAA Server delivers carrier-grade RADIUS and Diameter on an AI-native AAA fabric, with the five-nines (99.999%) availability, elastic scalability, multi-protocol convergence, and native security a national deployment requires. It authenticates subscribers for Tier-1 fixed and mobile operators worldwide, backed by a long track record of carrier-grade AAA deployments. For operators planning elastic scaling, Alepo’s cloud-native AAA architecture guide goes deeper on the deployment model.

Frequently Asked Questions

Q1. What is a RADIUS server used for?

A RADIUS server authenticates a subscriber’s identity, authorizes their level of service, and records their session usage before and during network access. In telecom networks it controls access for broadband, carrier Wi-Fi, and mobile subscribers, and it feeds usage data to billing and charging systems.

Q2. How does a RADIUS server work?

A RADIUS server works as the central decision point in a client-server exchange. The network access device – the NAS, acting as the client – sends an Access-Request with the subscriber’s credentials; the RADIUS server validates the shared secret, checks the identity against a data store, applies policy, and replies with Access-Accept, Access-Reject, or Access-Challenge. Accounting packets then meter the session from start to stop.

Q3. Which ports does a RADIUS server use?

A RADIUS server uses UDP port 1812 for authentication and authorization and UDP port 1813 for accounting. Legacy deployments may still use ports 1645 and 1646, and RADSEC (RADIUS over TLS) uses TCP port 2083.

Q4. RADIUS vs Diameter – which does telecom use?

Both. RADIUS dominates access-layer authentication for broadband, Wi-Fi, and wholesale, while Diameter handles LTE and IMS core signaling for policy, charging, and mobility. Most carriers run the two together on a converged AAA platform.

Q5. Is RADIUS secure?

RADIUS’s original design protects only the password and relies on MD5, which the 2024 Blast-RADIUS vulnerability (CVE-2024-3596) exposed as forgeable in some setups. Modern deployments secure RADIUS with RADSEC (RADIUS over TLS), the Message-Authenticator attribute, and IPsec or segmented networks – protections a carrier-grade RADIUS server supports natively.

Q6. What is the difference between carrier-grade and open-source RADIUS?

An open-source RADIUS server is fine for small or lab deployments, but a carrier-grade RADIUS server adds five-nines availability, geo-redundancy, throughput in the thousands of transactions per second, real-time CoA at scale, multi-protocol convergence with Diameter, native BSS integration, and vendor-backed security and support.

Conclusion

The RADIUS protocol is deceptively simple – a request, a lookup, a response, and a stream of accounting records – but that simple loop is what secures access to broadband, Wi-Fi, and mobile networks millions of times a day. What changes at carrier scale is not the protocol; it is everything around it: continuous availability, real-time session control through CoA, convergence with Diameter, and a security posture built for 2020s threats rather than 1990s assumptions. For telecom engineers, the protocol is the foundation – the RADIUS server you build it on is what makes it production-ready.

Experience how Alepo secures telecom networks with advanced RADIUS solutions. Book a Demo.