TACACS (Terminal Access Controller Access Control System) performs three core security functions known as AAA: authentication, authorization, and accounting. It’s a client/server protocol that lets network devices like routers and switches verify user identities, control what those users can do, and log their activity, all through a centralized server rather than managing credentials on each device individually.
The Three AAA Functions
TACACS organizes network security into three distinct layers, each handling a different part of access control.
Authentication is the first checkpoint. When someone tries to log into a network device, TACACS verifies their identity, typically through a username and password. The device doesn’t store those credentials locally. Instead, it forwards them to a central TACACS server, which checks them against its database and responds with a pass or fail.
Authorization kicks in after a user is authenticated. It determines what that user is actually allowed to do on the device. For example, a junior network technician might only be permitted to run diagnostic commands, while a senior administrator gets full access to change configurations. TACACS can check every single command a user tries to execute, sending it to the server for approval before the device runs it. This per-command authorization is one of the protocol’s most distinctive features. In a typical setup, one group of users might be allowed to run any command on a router, while another group is restricted to “show” commands that only display information without changing anything.
Accounting tracks what users do during their sessions. This includes how long they were connected, what commands they ran, and how much data they sent or received. That session logging serves multiple purposes: security auditing, billing, spotting usage trends, and capacity planning.
Why Separating AAA Matters
One of the key design choices in TACACS+ (the current version of the protocol) is that authentication, authorization, and accounting operate as separate, independent functions. You can use TACACS+ for authorization while using a different system for authentication, or you can enable accounting without changing your authorization setup. This modularity gives network administrators flexibility to mix and match security tools depending on their environment.
By contrast, some competing protocols bundle these functions more tightly together, which simplifies setup but limits how granularly you can control each piece.
How TACACS+ Handles Encryption
TACACS+ encrypts the entire body of every packet it sends between the client and server. Only a standard header is left unencrypted, and that header includes a field indicating whether the body is encrypted or not. During normal operation, the full packet body is always encrypted, which means usernames, passwords, and authorization data are all protected in transit.
This is a meaningful security advantage over some alternatives. RADIUS, the other widely used AAA protocol, only encrypts the password field within its packets, leaving the rest (including usernames and accounting data) readable. For environments where sensitive administrative commands are being sent back and forth, full-body encryption adds a significant layer of protection. There’s also ongoing work at the IETF to layer TLS 1.3 encryption on top of TACACS+ for even stronger security.
Technical Basics
TACACS+ uses TCP as its transport protocol, running on port 49 by default. The use of TCP rather than UDP is a deliberate choice: TCP provides reliable, ordered delivery of packets, which matters when you’re verifying credentials and authorizing commands in real time. If a packet gets lost, TCP ensures it’s retransmitted, so an authorization decision won’t silently fail.
The protocol is formally documented in RFC 8907, published by the IETF. It carries an “Informational” status rather than being an official internet standard, but it remains the definitive reference for how TACACS+ works.
TACACS vs. TACACS+ vs. XTACACS
The protocol has gone through three generations. The original TACACS was developed by BBN in the early 1980s for use on MILNET, a U.S. military network. It was simple: a terminal server forwarded login credentials to a central server, and the server responded with pass or fail. That was essentially the entire protocol.
In 1990, Cisco created XTACACS (Extended TACACS), which added more features but was still considered informational by the IETF. TACACS+ is a complete redesign, not just an update. It introduced the separated AAA architecture, full packet encryption, and per-command authorization that define the protocol today. Despite sharing a name with its predecessors, TACACS+ is effectively a different protocol.
Where TACACS+ Fits in Modern Networks
TACACS+ is primarily used for device administration, meaning it controls who can log into network infrastructure (routers, switches, firewalls, wireless controllers) and what they can do once connected. If you’re managing a network with dozens or hundreds of devices and multiple administrators with different responsibility levels, TACACS+ lets you define all of those access policies in one central location rather than configuring each device separately.
RADIUS, the other major AAA protocol, tends to dominate in network access scenarios like controlling which users can connect to Wi-Fi or VPN. The two protocols often coexist in the same organization: RADIUS for end-user network access, TACACS+ for administrative access to the devices themselves. The per-command authorization capability is the main reason network teams choose TACACS+ for device management. Being able to restrict exactly which commands a user can run on a router gives a level of control that RADIUS wasn’t designed to provide.