Overview
Take a look at how engineers log in to the routers, switches, and firewalls on most production networks. You’ll usually find a local admin account on every box, the same password on most of them, and no reliable list of who knows it. Then a config changes at 2 a.m., and nobody can say who made it.
So what is TACACS+? It’s the protocol that takes administrator logins off individual devices and hands them to a central server. That server checks who you are, decides which commands you can run, and keeps a record of what you did.
This guide explains what TACACS+ is, how it works, how it compares with RADIUS, and what it takes to run it across a multi-vendor network. It is also current through RFC 9887, the December 2025 standard that moves TACACS+ onto TLS (Transport Layer Security) 1.3.
What Does TACACS+ Stand For?
TACACS+ is a protocol that centralizes authentication, authorization, and accounting (AAA) for administrative access to network devices such as routers, switches, and firewalls. Unlike RADIUS, it handles the three functions separately, so a server can approve or deny each command an administrator runs, not just the login.
A simple way to keep the protocols straight: RADIUS and Diameter govern the people and devices that use the network. TACACS+ governs the people who run it.
Cisco developed TACACS+ in the early 1990s. Today it is a vendor-neutral specification from the IETF (Internet Engineering Task Force), documented in RFC 8907 and updated by RFC 9887.
How TACACS+ Works: Authentication, Authorization, and Accounting
How does TACACS+ work? It splits device administration into three questions and answers each one in its own exchange between the device and the server.
- Authentication: who are you?
- Authorization: what are you allowed to do?
- Accounting: what did you do, and when?
| Function | Question it answers | What it looks like on a router |
| Authentication | Who are you? | The server verifies the engineer’s password or MFA (multi-factor authentication) code. |
| Authorization | What are you allowed to do? | show commands are allowed; configure terminal is blocked. |
| Accounting | What did you do, and when? | Every command is logged with the engineer’s name and a timestamp. |
RFC 8907 is explicit that “an implementation or deployment is not required to employ all three.” Some teams use TACACS+ mainly for command accounting.
TACACS+ Protocol Fundamentals
1. Does TACACS+ Use TCP or UDP?
TACACS+ uses TCP, not UDP (User Datagram Protocol). The standard TACACS+ port is TCP 49. The TLS variant uses TCP 300, registered with IANA (the Internet Assigned Numbers Authority) under the service name tacacss. TCP matters because a device can detect a dead server quickly and move to a backup instead of waiting out UDP retry timers.
The UDP confusion comes from the original TACACS, documented in RFC 1492 (1993), which could run over UDP. The plus version is not an update of that protocol. Cisco redesigned it from scratch, and it is not backward compatible with TACACS or with Cisco’s interim XTACACS extension.
2. What’s in a TACACS+ Packet?
Every packet starts with a 12-byte header, always sent in the clear, followed by a body.
| Header field | Purpose |
| Major and minor version | Protocol version negotiation |
| Type | Authentication, authorization, or accounting |
| Sequence number | Orders packets within a session |
| Flags | Signals an unobfuscated body and single-connection mode |
| Session ID | Identifies the session on a shared connection |
| Length | Size of the body that follows |
3. What Is Single-Connection Mode?
By default, a device opens a new TCP connection for every session. Single-connection mode lets a client keep one connection open and multiplex many sessions over it, telling them apart by session ID. The client asks for it by setting TAC_PLUS_SINGLE_CONNECT_FLAG in its first packet, and the server agrees by setting the same flag in its reply. On a server fronting thousands of devices, this removes a great deal of TCP setup and teardown.
4. Is TACACS+ Encrypted?
TACACS+ encryption is often misunderstood. The traditional form uses a shared secret to scramble the entire packet body; only the 12-byte header travels in cleartext. RADIUS, by contrast, hides little more than the user password. That contrast is why people often say TACACS+ encrypts the whole packet.
RFC 8907 is more careful. It calls the method obfuscation rather than encryption, because the MD5-based scheme provides no meaningful integrity, privacy, or replay protection. The RFC also calls for the protocol to run on a network separated from other traffic.
RFC 9887 replaces the obfuscation scheme. It carries the protocol inside a TLS 1.3 session with mutual authentication (certificates by default, pre-shared keys as an option) and deprecates MD5-based obfuscation.
TACACS+ vs. RADIUS: What’s the Difference?
Both are AAA protocols, but they control different kinds of access. TACACS+ controls administrator access to network devices. RADIUS controls user, subscriber, and device access through the network.
| Comparison | TACACS+ | RADIUS |
| Primary use | Device administration | Network access |
| Typical clients | Routers, switches, firewalls, BNG/BRAS management | Wi-Fi, VPN, and broadband or mobile subscriber sessions |
| Transport and ports | TCP 49; TCP 300 with TLS | UDP 1812 and 1813 |
| What’s protected | Entire body, obfuscated (MD5); fully encrypted with TLS 1.3 under RFC 9887 | Password attribute only; RadSec adds TLS |
| AAA structure | Three separate exchanges | Authentication and authorization combined |
| Command authorization | Yes, per command | No |
| Accounting focus | Who ran which command, and when | Session time and data usage |
| Specification | RFC 8907 (2020); RFC 9887 (2025) | RFC 2865 and RFC 2866 (2000) |
In practice, the biggest TACACS+ vs. RADIUS difference is per-command authorization. RADIUS can handle a management login and hand back a privilege level, but it cannot check each command against policy.
RADIUS was built for a different job: fast decisions across millions of access sessions, with usage records that feed billing. That billing role is a large part of AAA’s value beyond security, and more operators now run RADIUS as a managed cloud RADIUS service. Most networks run both protocols side by side, increasingly on a unified AAA platform. For the RADIUS vs. TACACS+ split as it plays out in a service-provider network, see our guide to RADIUS vs. Diameter vs. TACACS+ in CSP environments.
TACACS+ Privilege Levels and Command Authorization
A TACACS+ privilege level is a number from 0 to 15 that sets what a user can do on a device, with each level including everything below it. Level 1 is a normal user login and level 15 is full administrative access, but the device’s own configuration decides what each level unlocks. On a Cisco TACACS+ client running IOS, the defaults are:
| Level | Typical access (Cisco IOS defaults) |
| 0 | A handful of commands: disable, enable, exit, help, and logout |
| 1 | User EXEC mode: basic show, ping, and traceroute |
| 2–14 | Empty by default; used to build custom roles |
| 15 | Privileged EXEC mode: full configuration access |
For the device-side setup on a Cisco router or switch, see Cisco’s TACACS+ configuration guide for IOS XE.
The ladder has a problem: real teams don’t work that way. A NOC (network operations center) operator needs show and ping, and maybe clear on a subscriber session, but never reload. A transport engineer needs interface configuration but not routing policy. Neither role maps cleanly onto a single number.
TACACS+ command authorization fills the gap. The device asks the server about each command before it runs, and the server answers from a policy defined by user and role. Change the role once on the server, and every device picks it up on the next command.
Command Authorization at Carrier Scale: A Worked Example
Picture a national operator with thousands of devices. Its broadband network gateways (BNGs, also called broadband remote access servers, or BRAS) come from two vendors, its core routers from a third, and its NOC runs around the clock from two regions. Three TACACS+ roles cover most of the staff:
- NOC operators can run any show command and clear any subscriber session, but they cannot touch configuration.
- Access engineers can configure subscriber-facing interfaces on the BNGs but not routing policy.
- Core engineers, only a handful of them, hold level 15.
Now suppose that at 3 a.m. a fiber cut takes a regional site offline, along with the TACACS+ server that site’s devices talk to first. Every device fails over to the server in the other region within seconds. The access engineer on call logs in as herself and runs the commands her role allows; each one is logged with her name and a timestamp. When the post-incident review asks what changed and who changed it, the answer is a query, not a guess.
That only works if the servers are active-active across regions and the policy is defined once for every vendor in the estate. This is the environment Alepo’s carrier-grade TACACS+ Server is built for: active-active across regions, with one policy for BNG and BRAS platforms from Cisco, Nokia, and Juniper.
Open-Source TACACS+ vs. Commercial Platforms
Is TACACS+ open source? The protocol is an open IETF specification, and yes, you can run it on open-source software. Cisco’s original tac_plus daemon lives on in Shrubbery Networks’ tac_plus and in Marc Huber’s tac_plus-ng, which also supports TACACS+ over TLS and RADIUS. Plenty of teams run these in production.
What you take on is everything around the daemon: high availability, directory and MFA integration, patching, monitoring, and the 3 a.m. phone call. The real decision for most teams is whether to keep operating it themselves.
Now that Cisco Secure ACS is well past its August 2022 end of support (Cisco’s successor is ISE), many organizations are weighing a maintained daemon against a dedicated AAA platform. We take up that decision in a separate guide.
Common TACACS+ Use Cases
1. Replacing Shared Device Passwords
Engineers log in with their own Active Directory credentials, so offboarding someone means disabling one account rather than rotating a password on 400 devices and hoping nobody missed one.
2. Passing Compliance Audits
PCI DSS, SOC 2, and ISO 27001 all expect unique user IDs and a record of privileged activity. TACACS+ accounting gives you that audit trail, provided it is forwarded (typically over syslog) to a SIEM (security information and event management) system rather than left on the server.
3. Separating Teams Without Separating Networks
Command authorization lets the network team and the security team each manage their own area on shared devices, without giving either one full admin rights over the other’s area.
4. Running Device Administration at Carrier Scale
Service providers manage thousands of devices from several vendors, and engineers need access most when part of the network is down. That calls for geo-redundant TACACS+ servers, one policy store, and capacity that grows with the estate, which is why more operators are running AAA on Kubernetes.
TACACS+ Best Practices and Security Considerations
The following practices matter most in an audit.
1. Migrate to TACACS+ over TLS
Plan the move now. Run TLS servers on port 300 on separate hosts from the legacy port 49 servers, never allow fallback, and keep the migration window short, because a mixed estate is a downgrade target.
2. Harden What Stays on Port 49
Keep legacy TACACS+ on a dedicated management network, and allow port 49 only from known devices. Give every device its own shared secret, and make it long. RFC 8907 requires servers to support a dedicated secret per client, so use it.
3. Least Privilege, MFA, and SIEM Alerting
Deny by default. Block configuration and disruptive commands unless a role explicitly needs them; it is far easier to grant a command later than to explain why a contractor could run reload. Put MFA in front of TACACS+ authentication and insist on individual accounts, since shared accounts defeat the purpose of accounting. Forward accounting to your SIEM and alert on high-risk commands, odd-hour logins, and repeated TACACS+ authorization failures from one source. Finally, design for the server being down: run at least two servers in different locations, keep a monitored break-glass account, and test the fallback order before you need it.
This is zero trust applied to device administration. No session is trusted because of where it came from, every login is checked against a central identity store, and every command is authorized on its own merits. TACACS+ is the enforcement point at the device. Privileged access management (PAM) tools cover the adjacent problem of credential vaulting and session recording, and the two work best together.
Where to Go From Here
The protocol is more than 30 years old and still being updated. Its purpose has not changed: individual logins, per-command policy checks, and a full record of activity. Whether you are retiring shared passwords, replacing Cisco Secure ACS, or moving toward AAA protocol consolidation with RADIUS, Diameter, and TACACS+ on one platform, those three principles are the place to start.
Explore Alepo’s TACACS+ Server to see how command authorization works across a multi-vendor estate, or request a demo.
Frequently Asked Questions
Q1. What does TACACS+ stand for?
Terminal Access Controller Access-Control System Plus. It is a protocol for controlling and logging administrative access to network devices such as routers, switches, and firewalls.
Q2. What makes TACACS+ different from RADIUS?
It handles device administration over TCP and can authorize individual commands. RADIUS handles network access over UDP and combines authentication with authorization in a single exchange. Most networks use both.
Q3. Is TACACS+ still Cisco-proprietary?
No. The IETF documented the protocol in RFC 8907 (2020), and RFC 9887 (2025) defined the TLS 1.3 profile as a Standards Track specification.
Q4. Does TACACS+ use TCP or UDP?
TCP, on port 49 by default or port 300 with TLS. Only the original TACACS and Cisco’s XTACACS used UDP.
Q5. Is TACACS+ encrypted?
Not in the traditional form. The protocol obfuscates the packet body with an MD5-based method, which covers more than RADIUS does but is not true encryption. The RFC 9887 profile encrypts all traffic with TLS 1.3.
Q6. Is there an open-source TACACS+ server?
Yes. Shrubbery Networks’ tac_plus and Marc Huber’s tac_plus-ng are widely used open-source daemons. The trade-off is that your team owns high availability, integrations, and patching.
Q7. What are TACACS+ privilege levels?
Numbers from 0 to 15 that set what a user can do on a device. Level 1 is a standard session and level 15 is full administrative access; command authorization refines what each role can run.
