TACACS+ ran for two decades on an expired Internet-Draft with no formal standard behind it. RFC 8907 (IETF, September 2020) documents the protocol as deployed, but as an Informational RFC rather than a Standards Track one, and it describes the protocol’s packet protection as obfuscation, not encryption. RFC 9887 (9 December 2025, Proposed Standard) updates RFC 8907 by defining TACACS+ over TLS 1.3 on TCP port 300, with mutual certificate authentication and the legacy obfuscation obsoleted. Support for RFC 9887 is emerging, not universal, as of September 2026.
TACACS+ (Terminal Access Controller Access-Control System Plus) is the protocol most service providers use to control administrator access to routers, switches, and firewalls. For most of its life it had an odd status. Nearly every network device shipped with a client for it, yet there was no standard to point to. That changed in September 2020, and again on 9 December 2025. This article explains both documents.
TACACS+ before RFC 8907: two decades on “The Draft”
TACACS+ began at Cisco as the successor to the original TACACS protocol. In January 1997, two Cisco engineers, David Carrel and Lol Grant, submitted it to the Internet Engineering Task Force (IETF) as an Internet-Draft. The document was titled “The TACACS+ Protocol Version 1.78,” identifier draft-grant-tacacs-02. An Internet-Draft is a working document with a six-month shelf life; the normal path is revision and eventual publication as a Request for Comments (RFC). This one was never revised again. It expired, and the industry kept building on it for the next 23 years. RFC 8907 later gave it the name that stuck, “The Draft,” a document that “was originally intended for IETF publication, but was never standardized.” Because the only specification was a vendor’s expired draft, TACACS+ was widely described as Cisco proprietary long after other vendors and open-source projects had implemented it.
What RFC 8907 actually documented (September 2020)
RFC 8907, “The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol,” was produced by the IETF’s Operations and Management Area Working Group (OPSAWG) and published in September 2020. Its authors were Thorsten Dahm and Andrej Ota of Google, Douglas Medway Gash of Cisco Systems, and the two authors of The Draft, David Carrel and Lol Grant. A protocol long treated as Cisco’s was formalized across vendor lines. Three points about the document matter more than the rest.
It documents, rather than designs.
RFC 8907 describes the subset of The Draft “which is common to implementations supporting Device Administration.” It removes features that had no place in a device-administration protocol. SENDPASS, an action that let a device request a password from the server, is removed explicitly for security reasons. The normative text for legacy protocols such as ARAP (AppleTalk Remote Access Protocol) is dropped. The intent was to document what interoperable implementations already did, not to require changes.
It is Informational, not Standards Track.
Most summaries get this wrong. A Standards Track document (Proposed Standard, then Internet Standard) carries IETF consensus that this is how the protocol should work. An Informational RFC records something for the community without that endorsement. RFC 8907 says so in its Status of This Memo section: “This document is not an Internet Standards Track specification; it is published for informational purposes.” So the accurate sentence is not “TACACS+ became an IETF standard in 2020.” It is “TACACS+ was formally documented by the IETF in 2020, in an Informational RFC.” Loose usage is harmless in a hallway conversation. In a tender response or a security review, an assessor who knows the RFC categories will notice.
It fixes the wire details. TCP (Transmission Control Protocol) port 49 and the packet header are pinned down. So are the separate authentication, authorization, and accounting exchanges, the attribute names (service, cmd, cmd-arg, priv-lvl), and the accounting record types. After 2020, “does your server implement RFC 8907?” became a meaningful procurement question.
Why RFC 8907 calls TACACS+ encryption “obfuscation”
Is TACACS+ traffic encrypted? Most vendor pages, including some of ours, have historically said yes, on the grounds that TACACS+ protects the whole packet body rather than a single field. The coverage claim is accurate. The word “encrypted” is where it goes wrong.
Section 4.5 of RFC 8907 describes the mechanism. The packet body is XORed, byte by byte, with a pseudo-random pad. The pad is built from chained MD5 (Message Digest 5) hashes of the session ID, the shared secret, the protocol version, and the sequence number. MD5 is a hash function with well-known weaknesses, long considered unsuitable for security use. Section 10.1 says what the authors think of the result. The mechanism “would be best referred to as ‘obfuscation’ and not ‘encryption’,” and it provides “no meaningful integrity, privacy, or replay protection.” The RFC names the exposures: brute-force attacks made practical by efficient MD5 computation, and known-plaintext attacks that lower the cost of brute force. The cleartext option, TAC_PLUS_UNENCRYPTED_FLAG, is “deprecated and MUST NOT be used in production.”
Section 10.5 then sets the deployment requirement. A network administrator “MUST NOT rely on the obfuscation of the TACACS+ protocol.” TACACS+ “MUST be deployed over networks that ensure privacy and integrity of the communication and MUST be deployed over a network that is separated from other traffic.” Read together, the two sections make the 2020 position clear. The document did not fix the transport problem; it described it accurately and told operators to compensate with network design. Fixing it took five more years.
RFC 9887: TACACS+ over TLS 1.3 (9 December 2025)
RFC 9887, “Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3,” was published on 9 December 2025 from the same OPSAWG working group. Unlike RFC 8907, it is a Standards Track document with Proposed Standard status, and it formally updates RFC 8907. Its authors are Thorsten Dahm, John Heasley of NTT, Douglas Medway Gash of Cisco Systems, and Andrej Ota of Google; three of the four also wrote RFC 8907.
Its introduction states the problem RFC 8907 left open. TACACS+ “lacks effective confidentiality, integrity, and authentication of the connection and network traffic between the TACACS+ server and client.” RFC 9887 resolves it by wrapping the existing protocol in Transport Layer Security (TLS) rather than redesigning it. The TACACS+ packets are unchanged; the connection they travel in is not. The requirements:
- TLS 1.3 minimum. “A minimum of TLS 1.3 MUST be used for transport. Earlier versions of TLS MUST NOT be used.”
- A new port. TCP port 300, registered with the Internet Assigned Numbers Authority (IANA) under the service name tacacss. Classic TACACS+ stays on port 49, so a connection’s protection is unambiguous from its port.
- Mutual authentication. Implementations must support certificate-based mutual authentication, meaning the device and the server each present a certificate. Pre-shared keys and raw public keys are optional extensions.
- Obfuscation is obsoleted. RFC 9887 calls the RFC 8907 mechanism “weak” and states that TLS “replaces this former mechanism, so obfuscation is hereby obsoleted.” A client must set TAC_PLUS_UNENCRYPTED_FLAG over TLS. A server that sees it unset must return an error and terminate the session.
- No silent downgrade. Clients “MUST NOT fail back to a non-TLS connection if a TLS connection fails,” and TLS servers must not accept non-TLS connections.
- New deployments should use it. “New TACACS+ production deployments SHOULD use TLS authentication and encryption.”
What the December 2025 document adds is a standards-defined path off MD5 obfuscation, and a reason to require that path in procurement. It does not withdraw classic TACACS+ on port 49.
RFC 8907 vs. RFC 9887 at a glance
| RFC 8907 | RFC 9887 | |
| Title | The TACACS+ Protocol | TACACS+ over TLS 1.3 |
| Published | September 2020 | 9 December 2025 |
| Category | Informational | Standards Track (Proposed Standard) |
| Working group | OPSAWG | OPSAWG |
| Relationship | Documents The Draft (January 1997) | Updates RFC 8907 |
| Transport | TCP port 49 | TCP port 300 (tacacss) over TLS 1.3 |
| Packet protection | MD5-based obfuscation; the RFC itself says it is not encryption | TLS 1.3 confidentiality and integrity; obfuscation obsoleted |
| Peer authentication | Shared secret | Certificate-based mutual authentication (pre-shared keys and raw public keys optional) |
| Deployment stance | Must run on a separated network that provides privacy and integrity | New production deployments should use TLS |
A worked example: one login, before and after
An engineer in a service provider’s network operations center (NOC) opens a session on a core router.
Under RFC 8907 alone, the router connects to the TACACS+ server on TCP port 49, and every packet body is XORed with an MD5-derived pad keyed on the shared secret. Anyone holding a capture of the management network and the secret (from a config backup, a Git repository, or a former employee’s notes) can strip the pad from every packet, including packets captured last year. Nothing beyond that same secret proves the router is talking to the real server. Whatever confidentiality the session has, the surrounding network is providing.
Under RFC 9887, the router connects on TCP port 300 and completes a TLS 1.3 handshake first: it checks the server’s certificate, and the server checks the router’s. Only then does the same TACACS+ exchange begin, inside the tunnel. A capture yields ciphertext. There is no obfuscation secret to leak, and a host without a valid certificate cannot complete the handshake. The network isolation RFC 8907 demands remains good practice; it is no longer the only protection.
What this means for your TACACS+ deployment
- Be precise about what you have.
If a TACACS+ server is described as “encrypted,” ask whether that means RFC 8907 obfuscation or RFC 9887 TLS. An auditor or penetration tester will know the difference. If a report flags MD5 in your device-administration path, RFC 8907 Section 10.1 is what it found.
- Calibrate expectations on RFC 9887 adoption.
As of September 2026 the document is nine months old. Server support is arriving. Support in the installed base of network devices will track operating-system releases and hardware refresh cycles, which in an operator estate are measured in years. Get each vendor’s answer in writing.
- Act on the parts you control now.
Require RFC 9887 support in every TACACS+ server procurement and device RFP (request for proposal). Keep classic TACACS+ on a separated management network, as RFC 8907 Section 10.5 requires. Start planning the certificate lifecycle that mutual TLS makes part of the control. If that plan includes centralizing device administration on one server, here is what a TACACS+ server should provide.
Ready to require RFC 8907 in your next RFP?
Bring a session, we will walk through what a TACACS+ server should provide for device administration, command authorization, and accounting, and map it to the standards this article covers.
FAQs
Q1. Is TACACS+ an official standard?
Partly. RFC 8907 (September 2020) formally documents TACACS+ in the IETF RFC series, but as an Informational RFC, which records existing practice without Standards Track consensus. RFC 9887 (9 December 2025) is the first Standards Track TACACS+ document, and it covers only the TLS 1.3 transport. The transport is now standardized; the base protocol is documented but Informational.
Q2. Is TACACS+ still Cisco proprietary?
No. Cisco created it, and two Cisco engineers wrote the 1997 Internet-Draft it ran on. But RFC 8907 (2020) was published by the IETF with authors from Google and Cisco alongside the original draft’s two authors, and RFC 9887 (2025) adds an author from NTT. Several commercial and open-source servers implement RFC 8907, and any vendor can implement RFC 9887.
Q3. What is RFC 9887?
RFC 9887 is the IETF Proposed Standard, published on 9 December 2025, that defines how to run TACACS+ over TLS 1.3. It assigns TCP port 300, requires certificate-based mutual authentication, obsoletes the MD5-based obfuscation described in RFC 8907, and forbids clients from falling back to a non-TLS connection. It updates RFC 8907; it does not replace it.
Q4. Is TACACS+ traffic encrypted?
Not under RFC 8907 alone. Section 10.1 of RFC 8907 (September 2020) describes the MD5-based packet protection as “obfuscation” and not “encryption,” and Section 10.5 requires deployment on a separated network that provides privacy and integrity. RFC 9887 (9 December 2025) adds real encryption by running TACACS+ over TLS 1.3 on TCP port 300.
Q5. Do current TACACS+ servers and network devices support RFC 9887 yet?
Unevenly, which is expected for a document published in December 2025. Ask each vendor which models and operating-system versions support TCP port 300 with TLS 1.3 and mutual certificates, and write RFC 9887 support into new procurement rather than assuming it.
Q6. Who wrote RFC 8907 and RFC 9887?
RFC 8907 (September 2020): Thorsten Dahm and Andrej Ota of Google, Douglas Medway Gash of Cisco Systems, and David Carrel and Lol Grant, the two authors of the original January 1997 draft. RFC 9887 (9 December 2025): Dahm, John Heasley of NTT, Medway Gash, and Ota.
