RADIUS and TACACS+ are both AAA protocols — protocols designed to centralise Authentication, Authorisation, and Accounting for network devices, rather than configuring separate local logins on every single switch, router, VPN concentrator, and Wi-Fi access point individually.
The AAA model
AAA describes three related but distinct functions:
- Authentication: Verifying that a user is who they claim to be — typically via a username and password, though other methods (certificates, multi-factor authentication) are also possible.
- Authorisation: Once authenticated, determining what that user is actually allowed to do — for example, whether a network administrator logging into a switch should get full configuration access, or only be able to view status information.
- Accounting: Recording what a user actually did during their session — which commands were run, when they logged in and out, how long the session lasted. This creates an audit trail that’s often essential for compliance and incident investigation.
Without a centralised AAA system, every single network device would need its own local list of usernames and passwords, making it slow and error-prone to add a new administrator, revoke access from someone who has left, or enforce a consistent password policy — the same underlying motivation that led to directory services and Kerberos being used for user accounts, as covered on the LDAP and Kerberos pages, just applied here to network infrastructure devices themselves rather than general end-user systems.
RADIUS (Remote Authentication Dial-In User Service)
RADIUS is the older and more widely supported of the two, originally designed (as its name suggests) for authenticating dial-up remote access connections, and now used far more broadly — including authenticating Wi-Fi logins (via 802.1X), VPN connections, and general network device administration.
RADIUS operates over UDP, typically on port 1812 for authentication and authorisation, and port 1813 for accounting (older implementations sometimes use ports 1645/1646 instead).
How RADIUS works
- A user attempts to log in to a RADIUS client — this is typically not the RADIUS server itself, but the device the user is actually trying to access (a switch, a VPN gateway, a Wi-Fi access point), which RADIUS terminology confusingly calls a “client” since it’s the one making requests to the actual RADIUS server.
- The client sends an Access-Request message to the RADIUS server, containing the user’s credentials.
- The RADIUS server checks these credentials (often by consulting a directory service like Active Directory/LDAP behind the scenes) and responds with either an Access-Accept or Access-Reject message.
- If accepted, the response can also include authorisation details — for example, which level of administrative access the user should be granted on that specific device.
- Separately, Accounting-Request messages can be sent to log session start, session stop, and interim updates throughout the session, building the audit trail described above.
A notable weakness
A significant limitation of RADIUS is that it only encrypts the password field within its messages — it does not encrypt the rest of the packet, including other potentially sensitive attributes. This is a meaningful contrast with TACACS+, covered next, and is one of the main reasons TACACS+ is often preferred specifically for network device administration.
TACACS+ (Terminal Access Controller Access-Control System Plus)
TACACS+ is a separate, Cisco-developed protocol (despite the similar-sounding name, it is not simply a newer version of the older TACACS or XTACACS protocols — it’s a largely unrelated redesign) that’s used almost exclusively for administrative access to network devices — logging into a router or switch to manage it — rather than RADIUS’s broader range of use cases like Wi-Fi and VPN authentication.
TACACS+ operates over TCP, typically on port 49.
Key differences from RADIUS
- Full packet encryption: Unlike RADIUS, TACACS+ encrypts the entire body of each packet, not just the password field — a meaningfully stronger baseline, especially relevant given how much sensitive command/authorisation detail can be contained in a network device administration session.
- Separates AAA more distinctly: TACACS+ treats authentication, authorisation, and accounting as more clearly separate processes than RADIUS does, allowing for more granular control — for example, authorising access on a per-command basis, so a specific administrator could be permitted to run diagnostic commands on a router but blocked from making configuration changes, with that decision made individually for each command entered.
- TCP rather than UDP: Being built on TCP gives TACACS+ built-in delivery confirmation and reliability, which RADIUS (being UDP-based) has to handle itself through retransmission logic.
RADIUS vs TACACS+ at a glance
| RADIUS | TACACS+ | |
|---|---|---|
| Transport | UDP | TCP |
| Encryption | Password only | Entire packet |
| Typical use case | Wi-Fi (802.1X), VPN, broad network access | Network device administration specifically |
| Command-level authorisation | Limited | Fine-grained, per-command |
| Developed by | Open standard (IETF) | Originally Cisco (though now more broadly implemented) |
In practice, many enterprise networks use both — RADIUS for broad, everyday network access like Wi-Fi and VPN logins, and TACACS+ specifically for controlling and auditing who can log into and configure the actual network infrastructure itself, since that’s a much higher-stakes category of access.
RADIUS/TACACS+ and security
Centralising authentication for network infrastructure is generally a strong security improvement over scattered local accounts, but both protocols come with their own considerations.
RADIUS’s partial encryption is a genuine weakness. Since only the password field is encrypted, other attributes within a RADIUS packet — including, depending on configuration, details about what a user is authorised to access — can potentially be read by anyone able to intercept traffic between the RADIUS client and server, similar in spirit to the risks already covered on the Man in the Middle page. This is a strong practical argument for keeping RADIUS traffic confined to a trusted, internal network segment, and for preferring TACACS+ specifically where full command-level administrative control and full packet encryption matter most.
Shared secret compromise affects everything downstream. Both RADIUS and TACACS+ rely on a shared secret — a pre-configured key known to both the client device and the AAA server, used to protect the encrypted portions of their communication. If this shared secret is weak, reused identically across many devices, or leaks, an attacker could potentially intercept or forge AAA traffic across every device relying on that same secret, making strong, unique shared secrets per device (or per small group of devices) an important, sometimes-overlooked control.
Centralisation is a double-edged sword. The same property that makes RADIUS/TACACS+ so valuable — a single, central point controlling access to potentially the entire network’s infrastructure — also makes that central AAA server an extremely high-value target. A compromised RADIUS or TACACS+ server could potentially be used to grant an attacker administrative access across a large portion of an organisation’s network devices simultaneously, making the AAA server itself a system that warrants some of the strongest protection and monitoring on the entire network.
Accounting data is a valuable forensic resource, if actually reviewed. The accounting function of AAA generates a detailed record of who accessed what, and when — genuinely useful during an incident investigation, but only if that data is actually being collected, retained for a reasonable period, and monitored, rather than simply generated and left unexamined in a log file somewhere.