TACACS+ Security: Hardening Device Administration AAA and Moving to TLS 1.3

TACACS+ decides who can log in to your routers, switches and firewalls and which commands they may run, yet its classic wire protection is an MD5-based obfuscation that the protocol's own specification says gives no meaningful integrity, privacy or replay protection. That makes the TACACS+ path, its shared secrets and its server addresses a high-value target, as the Salt Typhoon telecom intrusions showed. This guide goes deeper than the general AAA overview: it explains what RFC 8907 actually protects, what changed with TACACS+ over TLS 1.3 (RFC 9887, December 2025), and how to harden, migrate and monitor a device administration estate. It is written for network engineers, identity teams that own privileged access to infrastructure, and the security architects who review them. For the wider picture of RADIUS, Diameter and the three As, see the AAA Security Guide.

Source note: protocol requirements below are summarised from IETF RFC 8907 and RFC 9887 as checked in November 2026; vendor behaviour varies. Confirm against the official text before relying on it.

Key takeaways

• Obfuscation is not encryption. RFC 8907 Section 10.1 states that classic TACACS+ body obfuscation gives no meaningful integrity, privacy or replay protection, and lists MD5 brute force, known-plaintext and chosen-plaintext attacks and the lack of forward secrecy.
• TLS 1.3 is now a standard option. RFC 9887 is a Standards Track document that runs TACACS+ over TLS 1.3 only, on TCP port 300 (service name tacacss), forbids obfuscation inside TLS and forbids fallback to plaintext.
• The shared secret is a credential. Treat each TACACS+ key like a privileged password: unique per device or group, at least 16 characters, rotated, never logged and never left readable in configuration backups.
• Per-command authorisation and accounting are the point. TACACS+ separates authentication, authorisation and accounting, so the server can approve each command and record it. Use that, rather than handing out privilege level 15 at login.
• Watch the AAA configuration itself. Attackers who reach a device change its AAA server address or add local accounts. Alert on any change to TACACS+ server, key or method list lines.

How TACACS+ works, and what its protection really covers

TACACS+ is a client-server protocol over TCP. The network device (the client) talks to a TACACS+ server, which checks the administrator against a directory and returns decisions. RFC 8907 (September 2020) documents the protocol as an Informational RFC: it describes the common subset of the long-used vendor draft rather than creating a new standard, and it deprecates the FOLLOW redirection status.

Every packet carries a 12-byte header: a major version of 0xc, a type (0x01 authentication, 0x02 authorisation, 0x03 accounting), a sequence number (odd from the client, even from the server), flags, a session_id that must come from a cryptographically strong random source, and the body length. The body is then XORed with a pad built from chained MD5 hashes of the session_id, the shared key, the version and the sequence number.

That design has three consequences that drive everything else on this page:

• Anyone on the path can read and alter traffic: RFC 8907 says so directly. With known plaintext in the header and body, an attacker can recover content or flip fields. Section 10.3 gives the example of altering authen_method so a request appears to come from a different method and bypasses policy.
• The key protects everything: if the shared key leaks from a configuration file, a backup or a captured exchange that is brute forced, every recorded session for that key can be read.
• Accounting can be poisoned: Section 10.4 warns that accounting data can be altered in transit, and that some clients log sensitive values such as passwords in accounting records.

Two header flags matter for hardening. TAC_PLUS_UNENCRYPTED_FLAG (0x01) turns obfuscation off; RFC 8907 says it must not be used in production and servers must drop requests that set it. Under TLS the rule flips, as described below. TAC_PLUS_SINGLE_CONNECT_FLAG (0x04) negotiates several sessions over one TCP connection, which reduces connection churn but should only be enabled where the server supports it.

The three exchanges in practice

The separation of the three As is what makes TACACS+ the usual choice for device administration, where RADIUS is the usual choice for network access. The table summarises each exchange and the hardening choice that matters most.

Privilege levels run from 0 to 15, each a superset of the level below: 0 is the unauthenticated default, 1 is a regular user and 15 is full control. A common anti-pattern is to authorise the session at level 15 and skip command authorisation, which wastes the main benefit of the protocol. Mandatory arguments use "=" and optional ones use "*"; a client that receives a mandatory argument it does not understand must fail the request rather than ignore it.

TACACS+ over TLS 1.3: what RFC 9887 requires

RFC 9887, published in December 2025 as a Standards Track document that updates RFC 8907, wraps TACACS+ in TLS 1.3. It does not redesign the protocol: authentication, authorisation and accounting still work as above. What changes is the transport.

Other requirements worth building into your design:

• Certificate validation: each peer must validate the other's certificate path, including revocation. Servers must let operators choose which certificate fields identify a client, and must support dNSName and iPAddress subjectAltName matching. Clients validate the server identity following RFC 9525 and must support SNI with a configurable server name.
• Pre-shared keys: if you use TLS PSKs, both the key and the PSK identity must be at least 16 octets, and the PSK must not be the same as any old obfuscation secret.
• Wildcards: the RFC warns that wildcard certificates create a single point of failure and requires operators to limit them to a dedicated TACACS+ subdomain.
• Availability: certificate checks depend on reaching revocation information. Section 5.1.4 notes that isolation from the CA can cause authentication failures, so plan revocation reachability for the management network.
• Migration is an insecure period: Section 6.1 asks that the time a client is configured with both TLS and non-TLS servers be kept short, and treats the deployment as insecure until migration is complete.

Device and server support for RFC 9887 is still arriving, so confirm it in each vendor's current documentation before planning dates. Where devices cannot yet speak TLS, the protections in the next section carry the load.

Hardening classic TACACS+ where TLS is not yet available

RFC 8907 Section 10.5 is clear that obfuscation must not be relied upon, and that TACACS+ should run over networks that give privacy and integrity, separated from other traffic. In practice that means:

1. Isolate the path. Carry TACACS+ only on an out-of-band or dedicated management network, or inside an IPsec tunnel between management segments and the AAA servers. Bind the client to a fixed management source interface so server-side allow lists stay simple. See the Network Device Management Plane Hardening Guide.
2. Restrict who can talk to the server. Servers must accept connections only from defined clients and must reject any connection with the unencrypted flag set. Filter TCP 49 at the server host and on the network so only device management addresses reach it.
3. Use strong, unique keys. Servers and clients must support keys of at least 32 characters, and administrators should configure keys of at least 16 characters; use a unique key per client and rotate it regularly. Servers must not log secrets.
4. Store keys in a reversible-only-by-the-device form. Use the device's strongest supported configuration encryption for stored keys and never keep keys in weak reversible formats in configuration backups. Treat backups as secret material.
5. Turn off FOLLOW. RFC 8907 deprecates FOLLOW redirection, says it leaks keys outside a secured deployment, and asks clients to treat FOLLOW as FAIL.
6. Prefer challenge-based authentication types where your clients and directory support them, and do not reuse the same credential across challenge and non-challenge types, as Section 10.5.3 advises.

On Cisco IOS XE, for example, the documented building blocks are aaa new-model, server definitions with per-server key, port (default 49), timeout and single-connection options, and aaa group server tacacs+ groups referenced by method lists. Other vendors offer equivalent settings; use each vendor's own configuration guide for exact syntax.

Where identity fits: shared secrets, service accounts and break-glass

A TACACS+ deployment contains several non-human credentials that are easy to forget because they never log in interactively:

• Device-to-server shared keys: machine credentials, often copied into hundreds of configurations. Inventory them, map each to the devices that hold it, and rotate on a schedule and after any device compromise.
• TLS client certificates and PSKs: under RFC 9887 each device gets a certificate or PSK identity. Issue them from a dedicated CA or sub-CA, with lifetimes and renewal automation, and revoke on decommission.
• Server bind accounts: the TACACS+ server usually queries LDAP or a directory with a service account. Give it read-only rights, a vaulted credential and monitoring for use from anywhere other than the AAA servers. See the Secrets Management Guide.
• Automation accounts: configuration management and backup tools often log in through TACACS+. Give them their own identities with command sets limited to what the job needs, rather than sharing an engineer's account.
• Local break-glass accounts: devices fall back to local accounts when servers are unreachable. Keep one per device, with a unique strong password held in a vault, and alert on every use.

Human administrators should reach devices through a privileged access workflow with MFA at the jump host or at the TACACS+ server, since most network operating systems cannot run a modern MFA prompt themselves. See the Privileged Access Management Guide.

Choosing a deployment approach

PSKs are simpler than certificates for small estates but bring back a shared-secret problem. Certificates scale better and give per-device revocation, at the cost of running a CA. Larger organisations with existing device PKI should choose certificates.

Implementing or migrating: a phased approach

1. Inventory. Export every device's AAA configuration: server addresses, keys (as hashes or identifiers, never in clear), method lists, local accounts and whether command authorisation and accounting are on. Record which devices and server versions support RFC 9887.
2. Fix the basics first. Enable command authorisation and accounting everywhere, remove shared engineer accounts, reduce local accounts to one break-glass account per device, and give each device or small group a unique key.
3. Prepare TLS. Stand up the TLS server instance on port 300, issue device certificates, decide which certificate field identifies each client, and make revocation information reachable from the management network.
4. Pilot. Move a small ring of lab and low-risk devices. Test login, per-command authorisation, accounting records, server failover, certificate expiry and the break-glass path with the servers deliberately unreachable.
5. Roll out by ring. Migrate device groups, keeping the period with both TLS and non-TLS servers configured as short as possible. Rollback is a configuration change back to the classic server group, so keep the old configuration staged but not active.
6. Close plaintext. Once a group is migrated, remove the classic server entries and keys from those devices, and finally shut the TCP 49 service and its firewall rules.

Detection and measurement

Feed TACACS+ server logs and device syslog into the SIEM and correlate them. See the Network Device Syslog and Configuration Change Detection Guide. Monitor for:

• Any configuration change to TACACS+ server addresses, keys, method lists or local users, especially changes not tied to a change ticket.
• Authentication or command activity that appears in device logs but has no matching TACACS+ accounting record, which suggests local fallback or a redirected server.
• Logins with local accounts while the TACACS+ servers were reachable.
• Connections to TCP 49 or 300 on the servers from addresses outside the device management ranges, and TACACS+ traffic leaving the management network.
• Packets rejected for a bad secret or for a missing or unexpected unencrypted flag, which point to misconfiguration or tampering.
• Bulk configuration exports, which may precede key theft.

Framework mapping

Common failure patterns

• One key everywhere, never rotated. In the Salt Typhoon telecom intrusions, investigators reported that the group captured TACACS and RADIUS traffic including the shared keys, and used them to gain further access. A single reused key turns one capture into estate-wide exposure.
• AAA server redirection unnoticed. The same campaign changed AAA and TACACS+ server addresses to infrastructure the attackers controlled. Without alerts on AAA configuration lines, that persistence can last years. See the Salt Typhoon Threat Actor Profile.
• Configuration backups as a key store. Backups sent over TFTP or FTP and stored in shared folders hold keys and local passwords in weak reversible formats that can be decoded offline.
• Level 15 at login, no command authorisation. Every administrator gets full control, and accounting shows sessions but not intent.
• Silent fallback to local accounts. Method lists that fall back to local on any error, combined with shared local passwords, give an attacker who can block the AAA path an easy way in.
• Endless dual running. TLS is deployed but the classic server on TCP 49 stays configured on devices as a backup, which RFC 9887 treats as an insecure migration state.

Practitioner checklist

• Inventory every TACACS+ client, server, key, method list and local account, and record RFC 9887 support.
• Enable per-command authorisation and command accounting on every device.
• Give each device or small group a unique key of at least 16 characters, stored with the strongest device encryption, and rotate it.
• Restrict TCP 49 and 300 on the servers to device management addresses, and reject the unencrypted flag on classic servers.
• Disable FOLLOW redirection on servers and treat it as FAIL on clients.
• Plan TACACS+ over TLS 1.3 with mutual certificates, no fallback, no 0-RTT and reachable revocation data.
• Keep one vaulted break-glass account per device and alert on every use.
• Alert on any change to AAA server, key or method list configuration.
• Protect configuration backups as secrets and stop using TFTP or FTP for them.
• Retire classic TACACS+ entries and the TCP 49 service once each device group is migrated.

Standards and references

• IETF: RFC 8907 The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol
• IETF: RFC 9887 TACACS+ over TLS 1.3
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Network Device Authentication (T1556.004)
• MITRE ATT&CK: Network Device Configuration Dump (T1602.002)
• MITRE ATT&CK: Network Sniffing (T1040)
• Cisco: Configuring TACACS+ (IOS XE 17)

Related NHI Mgmt Group resources: AAA Security Guide · RADIUS Security Guide · Network Device Management Plane Hardening Guide · Salt Typhoon Threat Actor Profile