Overview
RADIUS vs TACACS+ is not a contest with a winner; the two protocols answer different questions. RADIUS decides who may use the network – subscribers, devices, Wi-Fi clients – over UDP at very high volume. TACACS+ decides who may administer the network – engineers logging in to routers, switches, and firewalls – over TCP, with per-command authorization and a full audit trail. Diameter extends the RADIUS role into the 4G core, and RadSec wraps RADIUS in TLS for untrusted transport. Most carrier networks need several of these at once, which is why the practical question is rarely “which protocol?” and almost always “which protocol for which job?”
Ask a network engineer to compare RADIUS vs TACACS+ and the honest first answer is a question back: authentication of whom? RADIUS is the AAA protocol – Authentication, Authorization, and Accounting – that authenticates the people and devices that use a network: broadband subscribers on a Broadband Network Gateway (BNG), Wi-Fi clients on a controller, mobile data sessions. TACACS+ is the AAA protocol that authenticates the people who manage the network: engineers opening privileged sessions on routers, switches, and firewalls, where every command they run can be individually authorized and recorded.
The distinction matters more for communications service providers (CSPs) than for anyone else, because a CSP runs both problems at carrier scale simultaneously. Millions of subscriber authentications per day ride on RADIUS and Diameter; hundreds of privileged administrative sessions per day ride on TACACS+. Confuse the two, or run one where the other belongs, and the cost shows up as security gaps, failed audits, and authentication behavior that does not survive a busy hour.
This guide answers that comparison with TACACS+ at the center: what TACACS+ does that RADIUS structurally cannot, per-command authorization, separated AAA exchanges, an audit trail tied to the individual and where RADIUS remains the right tool. Diameter and RadSec appear where they belong in the picture, as the extensions that carry the RADIUS side into mobile cores and across untrusted transport. It is written for telecom expertise deciding how to secure administrative access to network devices, with the RFC references to check every claim.
AAA Protocols in Telecom: A Complete Guide
AAA stands for authentication, authorization, and accounting the three questions any access decision has to answer.
Authentication: Is this user or device who it claims to be?
Authorization: What is it allowed to do?
Accounting: What did it actually do, for how long, and how much of it?
An AAA server is the central system that answers those questions for the rest of the network; if you want the fuller grounding first, start with the Alepo AAA server overview.
Four protocols carry AAA traffic in practice, and a clean way to hold the taxonomy in your head is by the population each one serves.
| Protocol | Serves | Typical job in a carrier network | Defined in |
| RADIUS | Network users | Subscriber and device authentication: broadband (BNG/BRAS), Wi-Fi, enterprise 802.1X | RFC 2865 |
| Diameter | Network users (mobile core) | 4G/EPC signaling: subscriber auth, policy, and charging interfaces | RFC 6733 |
| TACACS+ | Network administrators | Device administration: privileged login, per-command authorization, audit | RFC 8907 |
| RadSec | Network users (across untrusted transport) | RADIUS carried inside TLS for roaming, interconnect, and cloud paths | RFC 6614 |
Two of the four – RADIUS and TACACS+ are the pair people actually mean when they search for an AAA protocol comparison, so the next sections take each protocol in turn before returning to the selection question. If you want the three-protocol view framed specifically around CSP network domains rather than around the RADIUS/TACACS+ head-to-head, we cover that separately in RADIUS vs Diameter vs TACACS+ in CSP environments.
RADIUS: The Original AAA Protocol
RADIUS (Remote Authentication Dial-In User Service) dates from the dial-up era and was standardized in RFC 2865 in June 2000. The name betrays its age; the design has outlived the technology it was named for because the core transaction is so simple. A network access server (NAS) which today means a BNG, a wireless LAN controller, a VPN concentrator, or an 802.1X switch – receives a connection attempt, packages the credentials into an Access-Request, and sends it to the RADIUS server. The server answers Access-Accept, Access-Reject, or Access-Challenge, and the accept carries the authorization attributes with it: the IP pool, the bandwidth profile, the VLAN, the session timeout.
That last detail is the first structural difference from TACACS+ worth registering: RADIUS combines authentication and authorization in a single exchange. You cannot ask a RADIUS server “is this user genuine?” and separately “what may this user do?” – the answer to both arrives in one packet.
Accounting is the separate flow. The NAS sends Start, Interim-Update, and Stop records that become the raw material for usage tracking and billing. This is the part of RADIUS that quietly matters most to a CSP’s revenue, and the part most often mis-tuned. Interim-Update intervals set too long leave the billing system blind between records; a lost Stop record leaves a session that looks live long after the subscriber has gone, holding an IP address and, on a usage-rated plan, potentially accruing charges against nobody. Accounting integrity is an operational discipline, not a protocol feature.
Diameter: RADIUS for the 4G and 5G Core
Diameter is the IETF’s answer to RADIUS’s limits in the mobile core – and the protocol 3GPP adopted for it. Defined in RFC 6733, it keeps the AAA mission but rebuilds the machinery: TCP or SCTP instead of UDP, so delivery is reliable; long-lived peer connections with capability exchange and watchdog supervision instead of fire-and-forget datagrams; explicit failover behavior; a much larger attribute space; and mandatory support for TLS/DTLS transport security.
The architectural difference is bigger than the transport one. Where RADIUS is client-server, Diameter is a network of peers and agents – relays, proxies, and Diameter Routing Agents (DRAs) that carriers use to build signaling topologies at national scale, with routing, load distribution, and overload control handled in the signaling layer rather than bolted on.
In the 4G Evolved Packet Core (EPC), Diameter is not one interface but a family of them, and a telecom AAA server earns its place by speaking the right subset: S6b and SWm for non-3GPP access, SWx toward the Home Subscriber Server (HSS) for authentication vectors, Gx toward the Policy and Charging Rules Function (PCRF) for policy, Gy toward the Online Charging System (OCS) for real-time charging. This is where the “RADIUS for 4G” shorthand is fair – the jobs are recognizably AAA jobs, done with carrier-core reliability semantics.
The 5G part of the shorthand needs one correction, because it is the most common error in comparison articles. The 5G standalone core does not extend Diameter. It replaces core signaling with service-based interfaces – HTTP/2 APIs between network functions such as the AUSF and the UDM, per 3GPP TS 23.501 – and primary authentication runs 5G-AKA or EAP-AKA’ inside that core, per TS 33.501.
Diameter’s role in a 5G-era network is at the boundaries: 4G/5G interworking while both cores coexist, non-3GPP access, and the EPC estate that will run for years yet. Operators will run RADIUS, Diameter, and the 5G core’s native authentication side by side for the rest of the decade. That is an argument for platforms that terminate all of them, not for picking one and waiting.
TACACS+: AAA for Network Devices
TACACS+ (Terminal Access Controller Access-Control System Plus) grew out of Cisco’s device-administration lineage in the 1990s and was finally documented by the IETF as RFC 8907 in 2020. Its job is narrower than RADIUS’s and deeper: controlling what named human beings do on network equipment.
When an engineer opens an SSH session to a router, the router forwards the login to the TACACS+ server. When that engineer types a command, the router can ask the server – per command, in real time – whether this user, in this role, may run it. And everything that happens in the session is recorded against the individual, not against a shared “admin” account.
Three design choices that fit
First, TACACS+ runs over TCP, port 49. A device-admin session is a conversation rather than a datagram, and reliable transport suits it.
Second, it separates authentication, authorization, and accounting into fully independent exchanges. This is precisely what makes per-command authorization possible: authorization is not a one-time attribute dump at login but a question the device can keep asking. It also means the three functions can point at different back ends – authenticate against a corporate directory, authorize against a role model held elsewhere, log to a third system.
Third, it protects the entire packet body rather than a single password field. The classic comparison-table line “TACACS+ encrypts the whole payload, RADIUS only the password” is true, with a modern caveat both sides share: the legacy protection is an MD5-based obfuscation that RFC 8907’s own security considerations describe as inadequate. The IETF’s current answer is RFC 9887, which runs TACACS+ inside TLS 1.3 and forbids the legacy obfuscation on TLS connections. Any TACACS+ platform selection made in 2026 should ask about RFC 9887 support explicitly.
Why a CSP cares: accountability, not throughput
The business case for TACACS+ is not performance. It is attribution.
Shared local passwords replicated across hundreds of devices are how networks fail audits. There is no per-user attribution, so an incident review cannot say who ran the command that took the region offline. There is no least-privilege enforcement, so a junior engineer and a principal architect have identical power. And offboarding takes weeks, because removing one departing engineer’s access means touching every device individually – which is why, in practice, it often does not happen at all.
Centralized device administration closes all three gaps at once: one identity per engineer, a role model that constrains what each role may run, and an immutable per-command log that an auditor can read. That is why security frameworks and regulators keep steering operators toward it, and why the end-of-life of Cisco Secure ACS left many operators looking for a supported TACACS+ platform to migrate to.
RadSec: RADIUS over TLS
RadSec, defined in RFC 6614, is not a fourth AAA model. It is RADIUS with its transport problem fixed.
The protocol wraps standard RADIUS packets inside a mutually authenticated TLS connection over TCP port 2083. Both ends present certificates – a requirement of the specification rather than an option. Everything RADIUS sends in cleartext over UDP crosses a RadSec link encrypted and integrity-protected, and TCP gives the reliable delivery that matters when the RADIUS packets in question are billing-grade accounting records.
Worth knowing before you cite it in a design document: RFC 6614 is formally an Experimental RFC rather than Standards Track. In practice that has not slowed adoption where RadSec solves a real problem. Roaming federations such as OpenRoaming and eduroam rely on it, and it is the sensible answer whenever RADIUS must cross infrastructure the operator does not control: wholesale and MVNO (mobile virtual network operator) interconnects, links to cloud-hosted AAA, inter-operator Wi-Fi roaming.
The honest trade-off is operational. Mutual TLS means a certificate lifecycle – issuance, distribution, rotation, revocation – across every RADIUS endpoint that speaks it, and an expired certificate on a busy interconnect fails closed. Inside a private, well-segmented management network, plain RADIUS with strong secrets remains defensible. The moment the path crosses the public internet or a partner’s network, RadSec stops being optional and the certificate overhead becomes the cost of doing business.
RADIUS vs TACACS+: Which Protocol for Which Job?
With all four protocols on the table, selection reduces to a short set of questions.
| If the job is… | Use | Because |
| Subscriber or device access – broadband, Wi-Fi, 802.1X, VPN | RADIUS | High-volume, low-overhead, universal NAS support; EAP rides inside it |
| 4G/EPC core signalling – subscriber auth, policy, charging | Diameter | 3GPP-defined interfaces (SWx, S6b, Gx, Gy) with reliable transport and failover |
| Privileged access to routers, switches, firewalls | TACACS+ | Per-command authorization, separated AAA exchanges, individual audit trails |
| RADIUS across untrusted or third-party transport | RadSec | TLS encryption and mutual certificate authentication over TCP |
The head-to-head
RADIUS and TACACS+ differ on four axes, and every one of them traces back to the population served:
- Transport: UDP 1812/1813 vs TCP 49.
- Confidentiality: password-only protection vs whole-payload protection, with TLS now the right answer for both.
- Structure: combined authentication-plus-authorization vs three independent exchanges.
- Granularity: session-level attributes issued once vs per-command decisions issued continuously.
RADIUS is built to say yes or no at very high transaction rates to users who each ask once. TACACS+ is built to watch a small number of powerful users continuously, command by command.
Protocol Coexistence in Modern Carrier Networks
Walk through a converged operator’s estate and you find every protocol in this guide doing live work in the same network: RADIUS authenticating FTTH subscribers at the BNG and Wi-Fi clients at the controller, Diameter carrying SWx and Gx in the packet core, TACACS+ governing every privileged session on the routers and switches that carry all of the above, and RadSec protecting the RADIUS legs that leave the operator’s own transport.
Coexistence is the normal operating condition in a carrier network, and it will stay that way through the 5G transition.
The real question is how many platforms, not how many protocols
The operational question is whether that coexistence runs on one platform or four. Separate point products – a subscriber RADIUS here, a Diameter stack there, a device-admin daemon on an ageing server nobody wants to patch – multiply four things that all cost money:
- Licensing and support contracts, negotiated and renewed separately.
- Integration surfaces: each platform needs its own connections to the subscriber store, the billing system, and the security stack.
- Runbooks and on-call load: three or four different failure modes, escalation paths, and upgrade windows.
- Policy drift : the same subscriber or the same engineer described differently in each system, which is how access that should have been revoked survives.
The consolidated alternative is an AAA platform that terminates all three protocols natively, so one policy model, one subscriber and administrator data layer, and one operations team cover the whole estate. The security dimension of that argument – what centralized authentication actually protects against – is covered in how the AAA server ensures security in telecom networks.
What consolidation looks like in practice
This consolidated model is the one Alepo builds. The Alepo AAA Server terminates RADIUS with Dynamic Authorization, the Diameter interface set the EPC boundary needs – S6a, S6b, SWx, SWm, Gx, and Gy among them – and TACACS+ with per-command authorization, on a single stack, with the full EAP family from EAP-SIM through EAP-PEAP. It deploys on Kubernetes, VMs, bare metal, private cloud, on premises, or as a managed service, in active-active geo-redundant pairs designed for five-nines availability.
An AI agent layer sits across all three protocols’ telemetry, turning authentication logs into brute-force, credential-stuffing, and privilege-escalation detection rather than leaving them as archive material – the same records that were previously written once and read only after an incident.
Most of this work is brownfield. Alepo builds carrier AAA for Tier-1 and Tier-2 operators across the Middle East, Europe, LATAM, Africa, and Asia, and the common starting point is an AAA platform already carrying live subscribers rather than empty ground – frequently an end-of-life RADIUS or device-administration product where many operators are now. Replacing authentication under live traffic is the harder version of the job, and the one worth asking a vendor about specifically.
Conclusion
RADIUS vs TACACS+ resolves cleanly once the populations are separated. RADIUS – extended by Diameter, protected by RadSec – authenticates the users of a network at scale. TACACS+ authorizes and audits the engineers who run it, command by command. A modern carrier network needs both sides of that division working every hour of the day, and benefits most when they run on one platform instead of four.
Of the two, the administrator side is the one most operators have not centralized yet – shared device passwords are still the default in more networks than anyone likes to admit. If that describes your estate, start there.
Book a demoand see how per-command authorization works in the Alepo TACACS+ Server.
Frequently Asked Questions
Q1. What is the main difference between RADIUS and TACACS+?
RADIUS authenticates network users subscribers, Wi-Fi clients, devices, over UDP, combining authentication and authorization in one exchange. TACACS+ authenticates network administrators over TCP, separating authentication, authorization, and accounting so devices can authorize each command individually. In short: RADIUS controls who uses the network, TACACS+ controls who manages it.
Q2. What is the difference between RADIUS and Diameter?
Diameter is the carrier-core successor to RADIUS for subscriber-facing AAA. It runs over TCP or SCTP with guaranteed delivery, maintains supervised peer connections with failover, and carries the 3GPP-defined interfaces (SWx, S6b, Gx, Gy) that 4G cores require. RADIUS remains dominant for broadband and Wi-Fi access because it is lighter and universally supported by access equipment.
Q3. How does AAA authentication work in telecom?
A network element – a BNG, Wi-Fi controller, or gateway – forwards each connection attempt to an AAA server. The server authenticates the credentials against a subscriber store, authorizes the session with attributes such as bandwidth profile and IP pool, and collects accounting records of usage for billing and analytics. The same model governs administrator logins via TACACS+.
Q4. What protocols do AAA servers use?
Carrier-grade AAA servers speak four protocol families: RADIUS (with CoA per RFC 5176) for subscriber and device access, Diameter (RFC 6733) for 4G core interfaces, TACACS+ (RFC 8907) for network device administration, and RadSec (RFC 6614) for RADIUS over TLS. EAP methods, including SIM-based ones, are carried inside RADIUS.
Q5. How does RADIUS authentication work step by step?
First, the user or device connects to a network access server (NAS). Second, the NAS sends an Access-Request with the credentials to the RADIUS server on UDP 1812. Third, the server validates them against its data store, possibly via an EAP challenge exchange. Fourth, it returns Access-Accept with authorization attributes, or Access-Reject. Finally, the NAS sends accounting records to UDP 1813.
Q6. Is TACACS+ more secure than RADIUS?
For device administration, yes, in one specific sense: TACACS+ protects the entire packet body, while RADIUS obscures only the password field. But both legacy protections are MD5-based and dated. The current best practice is TLS for either protocol – RadSec (RFC 6614) for RADIUS, and TACACS+ over TLS 1.3 (RFC 9887) for device administration.
Q7. Can RADIUS do per-command authorization like TACACS+?
Not in a practical sense. RADIUS delivers authorization attributes once, at session establishment, and was not designed for a device to query it before each command. TACACS+ separates authorization into its own exchange precisely so a router can ask, command by command, whether the logged-in engineer may run it. For privileged device access, that granularity is the deciding feature.
Q8. What is a carrier-grade AAA server?
A carrier-grade AAA server is an AAA platform engineered for operator scale and availability: multi-protocol support (RADIUS, Diameter, TACACS+), the full EAP family, geo-redundant active-active deployment, five-nines availability targets, and integration with HSS/UDM, PCRF, OCS, and BSS systems. It differs from enterprise RADIUS mainly in scale, protocol breadth, and billing-grade accounting.
