Port 49: TACACS — The Gatekeeper of Network Infrastructure

Port 49 is where trust is negotiated at the infrastructure layer. When a network engineer logs into a router to reroute traffic around a failing link, when a security admin locks down a firewall during an active attack, when anyone with privileged access touches the devices that keep the Internet running, their credentials flow through port 49.

This is TACACS: the Terminal Access Controller Access-Control System. It's the protocol that guards the guardians.

What TACACS Does

TACACS is a family of protocols that centralize the decision of who gets to do what on network devices. Instead of storing usernames and passwords on every router and switch (a maintenance nightmare and security liability), network devices forward authentication requests to a TACACS server. The server makes the decision. The device enforces it.

The protocol handles three distinct functions, known as AAA:

Authentication determines who you are. You claim to be a network engineer. Prove it.

Authorization determines what you're allowed to do. You've proven who you are, but can you run configure terminal? Can you modify routing tables? Can you view the running config?

Accounting records what you did. Every command, every login, every action gets logged. When something breaks at 4am, the accounting trail shows exactly who touched what.

The critical insight is separation. TACACS+ treats these as three independent functions. A network admin might authenticate once at the start of a session, but authorization happens on every single command. Type show running-config? That's an authorization request. Type reload? Another authorization request. The TACACS server can approve one and deny the other based on your role, the time of day, or any policy the organization defines.¹

The Origin Story

In 1984, BBN Technologies (the same company that built the original ARPANET routers) faced a problem. ARPANET and the newly split-off MILNET were growing. More hosts meant more users, and more users meant a credential management nightmare.

Brian Anderson at BBN wrote the first formal description of TACACS in December 1984 as RFC 927.² The problem he was solving: how do you let someone who's already logged into one host on the network connect to another without re-authenticating? The solution was to pass a unique user identifier (UUID) between hosts, allowing the receiving system to trust the sending system's authentication.

This was elegant but naive. The original TACACS transmitted usernames and passwords in cleartext across the network. On a small, trusted network of research institutions and military bases, this seemed acceptable. The security model assumed physical control of the wire.

That assumption wouldn't survive contact with a larger, less trusted Internet.

The Protocol Evolution

TACACS (1984): The original. UDP-based, cleartext credentials, basic authentication. RFC 927 described the Telnet option; RFC 1492 documented the full protocol.³

XTACACS (1990): Cisco's extended version. Added support for authorization and accounting, but remained proprietary and maintained the cleartext weakness.

TACACS+ (1993): A complete rewrite by Cisco, incompatible with its predecessors. TCP-based for reliability, encrypts the packet body (though not the header), and fully separates AAA functions. This is what runs on port 49 today.⁴

The "+" in TACACS+ isn't an incremental improvement. It's an entirely new protocol that happens to share a name and a port number. Cisco released it as an open standard in 1993, and it was finally documented by the IETF in RFC 8907 in 2020, nearly three decades after its creation.⁵

How TACACS+ Works

When a network device needs to authenticate a user, here's what happens:

1. Connection: The device (the "client") opens a TCP connection to the TACACS+ server on port 49.

2. Authentication Start: The client sends a START packet containing the username and the type of authentication being performed.

3. Challenge-Response: The server may request additional information (like a password) through REPLY packets. The client responds with CONTINUE packets.

4. Decision: The server sends a final REPLY with PASS (authenticated), FAIL (denied), or ERROR (something broke).

5. Authorization: If authentication succeeds and the user attempts an action, a separate authorization exchange occurs. The client sends an authorization REQUEST; the server responds with PASS-ADD, PASS-REPL, or FAIL.

6. Accounting: The client sends accounting START, WATCHDOG, and STOP records throughout the session, creating an audit trail.

Each of these is a separate session. A single administrative session might involve one authentication, dozens of authorization requests, and continuous accounting records.⁶

The Encryption Problem

TACACS+ encrypts the body of each packet using MD5-based XOR obfuscation. The header remains in cleartext. This was considered acceptable in 1993.

It's not acceptable now.

The encryption has known weaknesses. There's no integrity checking, an attacker who can intercept traffic can flip bits in the encrypted body without detection. Replay attacks are possible because there are no ephemeral keys or timestamps. The shared secret between client and server is often stored in device configs with weak (or no) encryption.⁷

In 2024, the Salt Typhoon campaign demonstrated these vulnerabilities in the real world. State-sponsored attackers used stolen credentials and protocol weaknesses to access network infrastructure at major telecommunications providers.⁸

The fix exists: RFC 9887, published in December 2024, defines TACACS+ over TLS 1.3, providing proper encryption, integrity, and authentication.⁹ But deployment of the fix across the world's network infrastructure will take years.

Why TACACS+ Instead of RADIUS?

Both protocols provide centralized AAA. Why does TACACS+ exist alongside RADIUS?

The answer is command authorization.

RADIUS (port 1812/1813) was designed for user access authentication, the "can this person connect to the network?" question. It combines authentication and authorization in a single exchange and uses UDP for speed.

TACACS+ was designed for administrative access, the "can this person configure the network?" question. Network administration is interactive. An engineer might issue hundreds of commands in a session, each with different privilege requirements. TACACS+ can authorize (or deny) each command individually.¹⁰

A hospital might use RADIUS to authenticate doctors connecting to the wifi and TACACS+ to control which network engineers can modify the firewall rules protecting patient data.

The Weight of What It Carries

Every major network has a TACACS+ server. Every router, switch, and firewall in a properly managed infrastructure points to that server. When you make a phone call, your voice traverses equipment that was configured by someone who authenticated through TACACS+. When you load a webpage, the BGP routes that guide your packets were set by someone whose commands were authorized through TACACS+.

This is the protocol that decides who gets to touch the infrastructure. If TACACS+ fails or is compromised, either nobody can manage the network or the wrong people can.

Port 49 carries that responsibility.

Related Ports

Security Considerations

Classic TACACS+ vulnerabilities:

• MD5-based encryption is cryptographically weak
• No packet integrity verification
• Susceptible to replay attacks
• Shared secrets often poorly protected in device configurations

Mitigations:

• Deploy TACACS+ over TLS 1.3 where supported (RFC 9887)
• Restrict TACACS+ traffic to management VLANs
• Use dedicated, encrypted management networks
• Rotate shared secrets regularly
• Monitor for authentication failures and anomalous command patterns

Modern best practice: Treat the TACACS+ server as crown jewels. If attackers compromise your TACACS+ server, they effectively have credentials for your entire network infrastructure.