# TACACS+ Protocol
Terminal Access Controller Access-Control System Plus (TACACS+) is a network access control protocol designed specifically for authenticating, authorizing, and accounting for administrative sessions on network infrastructure devices. It exists because managing dozens or hundreds of routers, switches, and firewalls through locally stored credentials is operationally unsustainable and security-incoherent. A single compromised device credential exposes that device permanently until someone manually rotates the password. TACACS+ centralizes credential management, separates the three AAA functions into discrete, independently controllable phases, and encrypts the full packet body rather than only the password field. It solves the problem of distributed administrative access control across network infrastructure by making a single server the authoritative source for who can log in, what commands they can run, and what actions get recorded.
---
TACACS+ is a TCP-based access control protocol developed by Cisco Systems and documented in RFC 8907 (published 2020, replacing the expired draft-grant-tacacs). It operates on TCP port 49 and provides three separable functions: authentication (verifying identity), authorization (controlling what an authenticated identity is permitted to do), and accounting (recording what was done and when).
TACACS+ is not the same as the original TACACS or XTACACS, which were earlier, incompatible protocols with far less granularity and no full-body encryption. The "Plus" designation reflects a complete redesign, not an incremental update. TACACS+ is also not RADIUS. RADIUS is a UDP-based protocol that bundles authentication and authorization into a single exchange, encrypts only the user password in the Access-Request packet, and is optimized for network access control (dial-up, VPN, wireless). TACACS+ uses TCP, encrypts the entire packet payload, and separates AAA phases, making it better suited for device administration where command-level granularity and full audit trails are operationally necessary.
TACACS+ is not an identity provider. It does not replace Active Directory, LDAP, or a public key infrastructure. It sits between the network device (the client, called the NAS or Network Access Server) and the backend identity system, acting as a policy enforcement broker. Many deployments back TACACS+ servers with LDAP or Active Directory for the actual credential store.
Variants worth noting: Cisco ISE (Identity Services Engine) supports TACACS+ natively. Open-source implementations include tac_plus (Shrubbery Networks) and TACACS.net. The protocol itself is standardized; vendor implementations vary in how they expose authorization policy configuration.
---
Transport and Session Establishment
TACACS+ establishes a TCP connection from the network device (client) to the TACACS+ server on port 49. TCP provides reliable, ordered delivery with retransmission, which matters for authentication flows where a lost packet cannot simply be ignored. Each TACACS+ exchange consists of one or more packets, each carrying a header and an encrypted body.
The header contains: major and minor version numbers, packet type (authentication, authorization, or accounting), sequence number, flags, session ID, and the length of the body. The body is encrypted using an MD5-based pseudo-random pad generated from the shared secret, the session ID, the version number, and the sequence number. Every packet body in the exchange is encrypted, not just the initial credential transmission. This is a meaningful distinction from RADIUS, where an attacker capturing packets can see the authorization attributes in plaintext.
Authentication Phase
The authentication exchange begins when a user initiates an administrative session, typically SSH or console, to a network device. The device sends a START packet to the TACACS+ server indicating the authentication type. TACACS+ supports several authentication types:
For a concrete example: an engineer SSH-es into a core router. The router receives the connection, opens a TCP session to the TACACS+ server, and sends an authentication START packet. The server responds with a REPLY packet asking for a username. The router displays the prompt. The engineer types their username. The router sends it to the server. The server replies with a password prompt. The engineer provides the password. The server validates credentials against its backend (LDAP, local database, or another source) and sends a PASS or FAIL response. The router either grants the session or drops the connection.
Authorization Phase
Authorization in TACACS+ is a separate phase, triggered after successful authentication. This separation is architecturally significant: you can authenticate users against one server and authorize their commands against a different server, or apply different authorization policies to the same authenticated user depending on device group, time of day, or source IP.
Command-level authorization is the operationally important feature. When an engineer types a command at the CLI (for example, "configure terminal" or "no shutdown"), the device sends an authorization request to the TACACS+ server before executing the command. The request includes the command and its arguments. The server evaluates the request against its policy and responds with PASS_ADD (permitted, possibly with additional attributes), PASS_REPL (permitted with substituted attributes), or FAIL (denied).
A concrete scenario: a junior network engineer has a TACACS+ policy that permits "show" commands and denies all configuration commands. They log into a distribution switch and type "interface GigabitEthernet 0/1." The switch sends an authorization request to the TACACS+ server. The server matches the user to the restricted policy, returns FAIL, and the switch denies the command with an error. The engineer cannot make configuration changes regardless of what privilege level the device would otherwise assign. This is not replicated by RADIUS in a device administration context.
Accounting Phase
Every command executed, every session started and stopped, and every authorization decision can be logged in the accounting phase. The network device sends accounting records to the TACACS+ server, which writes them to a log or forwards them to a SIEM. Records include username, device IP, timestamp, command executed, and outcome. This creates a complete administrative audit trail across all managed devices without relying on individual device logs, which can be cleared by a compromised administrator.
Configuration Considerations
TACACS+ servers must be reachable from all managed devices. Redundancy requires at least two TACACS+ servers, with devices configured to fall back in order. Local fallback credentials (a break-glass account) must be configured on every device in case TACACS+ servers become unreachable, but these credentials require strict procedural controls. Shared secrets must be unique per device group, rotated on a defined schedule, and stored in a secrets manager rather than in plaintext configuration files.
---
Security Impact
TACACS+ addresses a specific and serious attack surface: privileged administrative access to network infrastructure. Network devices are not endpoints. They carry all traffic, implement segmentation, and enforce access control lists. An attacker who gains administrative access to a core router can redirect traffic, disable firewall rules, or establish persistent access through unauthorized accounts. TACACS+ reduces this risk by ensuring that every administrative action is authenticated against a central authority, authorized against an explicit policy, and recorded in an immutable log.
Without TACACS+, organizations typically fall back to one of several insecure patterns: shared local credentials (the same "admin" account and password on every device), individual local accounts that are never deprovisioned when engineers leave, or RADIUS configurations that lack command-level authorization. Each of these patterns has produced documented incidents.
What Goes Wrong Without It
In 2020, a major telecommunications provider experienced unauthorized access to its network infrastructure during a supply chain compromise. Post-incident analysis found that local administrative credentials on network devices had not been rotated in years, were shared across multiple personnel, and were not logged at the command level. The attackers maintained persistent access for months because there was no centralized audit trail to detect anomalous command execution. Centralized TACACS+ accounting with SIEM integration would have surfaced the anomalous activity during the initial intrusion.
Common Misconceptions
The first misconception is that TACACS+ encryption is equivalent to modern transport security. The MD5-based packet body encryption used in TACACS+ is not TLS. It protects against casual packet capture but is vulnerable to known-plaintext attacks if the shared secret is weak. RFC 8907 acknowledges this limitation explicitly. The correct posture is to treat TACACS+ encryption as a layer of protection within a secured network segment, not as a substitute for encrypted transport. Some deployments wrap TACACS+ in TLS tunnels for additional protection.
The second misconception is that TACACS+ handles all access control. It handles administrative access to network devices. It does not replace endpoint security, SIEM, or network segmentation. Treating it as a complete solution results in gaps.
The third misconception is that TACACS+ is Cisco-only. RFC 8907 defines the protocol as an open standard. Non-Cisco vendors including Juniper, Arista, and Palo Alto support TACACS+ for device administration.
---
CDA approaches TACACS+ through the Planetary Defense Model (PDM) under the IAT (Identity and Access Traceability) and SPH (Secure Protocol Handling) domains. The operational principle governing CDA's application of TACACS+ is Zero Possession Architecture (ZPA): "Trust nothing. Possess nothing. Verify everything."
In conventional deployments, TACACS+ shared secrets are stored in network device configuration files, often in plaintext or weakly encrypted form. Engineers who configure devices possess those secrets. When an engineer leaves or is terminated, the secrets may not rotate because the operational cost is high and the process is manual. ZPA rejects this model entirely.
Under CDA's implementation framework, TACACS+ shared secrets are generated by a secrets manager (such as HashiCorp Vault or CyberArk) and injected into device configurations through a configuration management pipeline. No engineer ever sees or possesses the shared secret directly. Rotation is automated on a defined interval, with the secrets manager and the TACACS+ server synchronized before the device configuration is updated. If a device fails to accept the new secret, the pipeline halts and alerts, preventing a silent mismatch that would break authentication.
Authorization policies are version-controlled and peer-reviewed before deployment. No policy change takes effect without a documented change request and approval workflow. This means the TACACS+ authorization configuration is treated with the same rigor as application code: changes are tracked, tested in a non-production environment, and deployed through a controlled pipeline.
Accounting records are forwarded in real time to a centralized SIEM with integrity controls. The accounting pipeline is monitored: if a device stops sending accounting records, that is treated as an anomaly requiring investigation, not a routine log gap. The absence of logs is as significant as the logs themselves.
CDA also implements break-glass account controls under ZPA: local fallback credentials are generated per-device, stored exclusively in the secrets manager, and accessed only through a workflow that creates an audit record and requires dual-person authorization. The act of accessing a break-glass credential is itself an event that triggers notification to the security operations team.
This operational approach treats TACACS+ not as an authentication convenience but as a critical infrastructure control with the same governance discipline as any other security-sensitive system.
---
---
---