How RADIUS Authentication Works in Telecom Networks

Every time a subscriber connects to a broadband line, logs into carrier Wi-Fi, or attaches to a mobile network, something has to decide – in milliseconds – whether that device is allowed on, what it’s allowed to do, and how its usage gets recorded. In most communication service provider (CSP) networks, the protocol making that decision is RADIUS.

RADIUS authentication is the process a network uses to verify a subscriber’s identity, apply their service policy, and start metering their session before granting access. This guide explains how RADIUS works in a telecom context – the request-response flow, the packet types involved, how carrier-grade deployments differ from enterprise ones, and the security considerations that matter when you’re authenticating millions of subscribers instead of a few hundred employees. It’s written for network engineers who are learning RADIUS ahead of a CSP deployment or migration.

The stakes scale with the network. IoT Analytics estimates the number of connected IoT devices reached 21.1 billion by the end of 2025, up 14% year over year, and projects 39 billion by 2030. Every one of those connections needs to be authenticated, authorized, and accounted for – which is exactly what RADIUS was built to do.

What Is RADIUS Authentication?

RADIUS (Remote Authentication Dial-In User Service) is an IETF-standardized client-server protocol that provides centralized Authentication, Authorization, and Accounting – the three functions collectively known as AAA. It was first defined in RFC 2865 (authentication and authorization) and RFC 2866 (accounting), and it remains the backbone of subscriber access control in fixed, mobile, and Wi-Fi networks.

RADIUS separates the device that a subscriber connects to from the system that makes access decisions. Three roles are involved:

• The subscriber (or supplicant) — the end user’s device requesting network access: a home router, smartphone, laptop, or IoT sensor.
• The Network Access Server (NAS) — the equipment the subscriber connects through, such as a Broadband Network Gateway (BNG), Wi-Fi access controller, or mobile gateway. The NAS acts as the RADIUS client.
• The RADIUS server — the centralized system that checks credentials against a subscriber database, applies policy, and returns an accept or reject decision.

Instead of every access device storing its own list of credentials and policies, the NAS forwards each request to a central RADIUS server. That centralization is the whole point: one authoritative source of subscriber identity and policy, consistent across thousands of access points. RADIUS is an access protocol, not a subscriber database – it authenticates against an identity store such as an LDAP directory, an HSS/UDM, or a billing system rather than replacing one. RADIUS messages travel over UDP, using port 1812 for authentication and port 1813 for accounting (older deployments used 1645 and 1646).

RADIUS Authentication Flow Step by Step

The RADIUS authentication process is a request-response exchange between the NAS and the RADIUS server, secured by a shared secret that both sides know in advance. Here are the RADIUS authentication steps in the order they happen:

1. Access request. A subscriber attempts to connect. The NAS collects their credentials (username and password, certificate, or SIM identity) and sends an Access-Request packet to the RADIUS server, carrying attribute-value pairs such as User-Name, NAS-IP-Address, and a protected User-Password.
2. Server lookup. The RADIUS server validates the shared secret, then checks the supplied identity against its subscriber data store – a local database, an LDAP directory, an HSS/UDM, or a billing system.
3. Policy decision. If the credentials are valid, the server evaluates the subscriber’s authorization profile: their service plan, bandwidth tier, session limits, and any active status flags.
4. Server response. The server returns one of three answers:
5. Access-Accept — identity verified and access granted, along with authorization attributes (IP address, bandwidth, session timeout).
6. Access-Reject — access denied because credentials failed or the account is inactive.
7. Access-Challenge — the server needs more information, such as a one-time password or the next step in an EAP exchange.
8. Session start. Once the subscriber is admitted, the NAS sends an Accounting-Request (Start) packet so the server can begin metering the session.
9. Ongoing accounting. Throughout the session, the NAS sends interim accounting updates, and at disconnect it sends an Accounting-Request (Stop) recording total time and data consumed – the raw material for billing and capacity planning.

This is the core loop that answers how RADIUS works: authenticate, authorize, then account – repeated for every subscriber session on the network.

RADIUS Packet Types Explained

RADIUS defines a small set of packet types, each identified by a numeric code in the packet header. Knowing them makes RADIUS logs far easier to read during troubleshooting.

Each packet carries attribute-value pairs (AVPs) – standardized fields such as User-Name, Framed-IP-Address, and Session-Timeout. Vendors extend the protocol with Vendor-Specific Attributes (VSAs) to carry proprietary policy data, which is how RADIUS adapts to the specific equipment in a given network.

For deployments that need stronger credential exchange than a simple password, RADIUS carries the Extensible Authentication Protocol (EAP). Telecom networks rely on EAP methods heavily – EAP-SIM and EAP-AKA authenticate subscribers using SIM credentials for Wi-Fi calling and trusted Wi-Fi offload, while EAP-TLS uses certificates for high-assurance access.

RADIUS in Telecom vs Enterprise Networks

RADIUS is the same protocol in both worlds, but a carrier deployment operates under constraints an enterprise never faces. The difference is scale, availability, and integration.

An enterprise RADIUS server might authenticate a few thousand employees against Active Directory for Wi-Fi and VPN access. A telecom RADIUS deployment authenticates millions of subscribers, sustains thousands of authentication transactions per second, and cannot afford downtime measured in minutes.

In a CSP network, the RADIUS server rarely works alone. It coordinates with the policy and charging layer, the subscriber data repository, and the billing stack, and it often runs alongside Diameter for LTE and interworks with the 5G core. For a closer look at where RADIUS-based AAA meets the 5G authentication function, see Alepo’s guide on AAA Server vs AUSF in 5G core authentication.

Carrier-Grade RADIUS Differentiators

Carrier-grade RADIUS is defined by what happens under load and under failure – the qualities that separate a lab-grade AAA server from one a national operator can run its subscriber base on. Four differentiators matter most:

• Continuous availability. Carrier deployments target 99.999% uptime through active-active clustering and geographic redundancy, so a data-center failure never becomes a subscriber outage.
• Linear scalability. The platform must add capacity horizontally as subscriber counts grow, without re-architecting, and increasingly runs cloud-native on Kubernetes for elastic scaling.
• Multi-protocol convergence. A single AAA fabric handles RADIUS, Diameter, and TACACS+ across broadband, Wi-Fi, and mobile access, so operators run one policy layer instead of separate silos per access type.
• Deep BSS integration. Real-time hooks into billing, charging, and subscriber management turn authentication events into accurate, monetizable records the moment a session starts.

This is where a purpose-built platform earns its place. The Alepo AAA Server delivers carrier-grade RADIUS and Diameter with an AI-native control plane, authenticating subscribers across Tier-1 carrier networks – proof that the same protocol an enterprise runs for a few thousand users can be engineered to carry a national subscriber base. Alepo has delivered carrier-grade AAA across 10+ operator deployments globally, including networks serving multi-million subscriber bases.

The relevance is timely. Cisco’s Prime Access Registrar (CPAR), a long-standing carrier RADIUS platform, has reached end-of-life, leaving operators on that platform evaluating carrier-grade replacements. When assessing any migration, engineers should weigh uptime track record, protocol support, scalability model, and roadmap – and let each platform’s proof points speak for themselves.

RADIUS CoA: Dynamic Session Control

Change of Authorization (CoA) lets a RADIUS server modify or terminate a subscriber’s session while it is still active, without waiting for the subscriber to reconnect. Standardized in RFC 5176, CoA is what makes RADIUS a real-time policy tool rather than a one-time gatekeeper.

In the basic flow described earlier, the RADIUS server only speaks when the NAS asks. CoA reverses that: the server initiates the message. Two packet types make it work:

• CoA-Request (code 43) changes attributes on a live session – for example, raising a subscriber’s bandwidth the instant they upgrade their plan, or dropping them to a captive portal when their data quota is exhausted.
• Disconnect-Request (code 40) terminates an active session immediately, which operators use to end fraudulent sessions or enforce a hard quota cutoff.

For CSPs, CoA is essential to the monetization loop. A subscriber who buys a speed boost or a top-up expects it to take effect now, not at their next login. CoA turns that expectation into an automated, real-time policy change – one of the clearest examples of why carrier RADIUS has to be more than a login check.

RADIUS Security Considerations

RADIUS was designed in the 1990s, and its original security model shows its age – which matters more, not less, as networks scale. Engineers deploying RADIUS in a modern CSP network should account for several considerations:

• Only the password is hidden. In the original protocol, the User-Password attribute is obscured using a shared secret and an MD5-based hash, but the rest of the packet travels in the clear. Attributes like usernames and accounting data are exposed to anyone who can see the traffic.
• The shared secret is a single point of trust. RADIUS relies on a shared secret between the NAS and server. A weak, reused, or leaked secret undermines the whole exchange, so secrets should be long, unique per client, and rotated.
• MD5 is cryptographically weak. The protocol’s dependence on MD5 has produced real vulnerabilities. The 2024 Blast-RADIUS attack (CVE-2024-3596) showed that an on-path attacker could forge a valid Access-Accept from an Access-Reject in some configurations, turning a denied user into an admitted one.
• UDP offers no transport protection. Running over UDP, RADIUS has no built-in encryption or reliable delivery for the packet as a whole.

The modern mitigations are well established. RADSEC (RADIUS over TLS), defined in RFC 6614, wraps RADIUS in a TLS tunnel over TCP (port 2083), encrypting the entire exchange and authenticating both endpoints. Operators also deploy the Message-Authenticator attribute to counter forgery attacks, run RADIUS over IPsec, and segment AAA traffic onto protected management networks. A carrier-grade AAA platform should support these protections natively rather than leaving them as bolt-ons – a key evaluation point for any new deployment.

Frequently Asked Questions

Q. What is RADIUS authentication used for?

RADIUS authentication verifies a subscriber’s identity, applies their service policy, and starts metering their session before granting network access. In telecom networks it authenticates broadband, Wi-Fi, and mobile subscribers, and it feeds usage data to billing and charging systems.

Q. What is the difference between authentication, authorization, and accounting in RADIUS? Authentication confirms who the subscriber is. Authorization determines what they are allowed to do – bandwidth, session limits, and service tier. Accounting records how much they used, capturing session time and data volume for billing and capacity planning. Together these are the AAA functions RADIUS provides.

Q. Which ports does RADIUS use?

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

Q. Is RADIUS the same as LDAP?

No. RADIUS is an access protocol that authenticates and authorizes subscriber sessions and records accounting data. LDAP is a directory protocol used to store and query identity records. In many deployments they work together – the RADIUS server checks a subscriber’s credentials against an LDAP directory (or an HSS/UDM or billing system) before granting access.

Q. Is RADIUS still used in 5G networks?

Yes. RADIUS remains widely deployed for non-3GPP access, fixed broadband, and Wi-Fi authentication, and carrier AAA platforms run it alongside Diameter while integrating with the 5G core’s authentication function (AUSF). Many operators run a converged AAA fabric that supports all three.

Q. What is RADIUS CoA?

Change of Authorization (CoA) is a RADIUS mechanism, defined in RFC 5176, that lets the server modify or terminate a live subscriber session in real time – for example, to apply a plan upgrade instantly or enforce a data-quota cutoff – without the subscriber reconnecting.

Bringing It Together

RADIUS authentication is the quiet, continuous process that decides who gets onto a network, what they can do, and how their usage is recorded – repeated for every subscriber session, millions of times over. Its request-response flow and small set of packet types are straightforward to learn, but running RADIUS at carrier scale is a different discipline: it demands five-nines availability, real-time session control through CoA, multi-protocol convergence, and a security posture built for modern threats rather than 1990s assumptions.

For network engineers stepping into a CSP deployment or planning a migration, the protocol is the starting point – the platform is what makes it production-ready.

Ready to go deeper? Schedule a demo with the Alepo technical team to explore your RADIUS deployment or migration strategy and accelerate your implementation.