TACACS+ runs over TCP port 49; RADIUS runs over UDP 1812 for authentication and 1813 for accounting, with 1645 and 1646 as the older assignments. TACACS+ separates authorization from authentication and can approve individual commands, which is why it is used for administrator logins to network devices.
RADIUS combines them, which fits network access through 802.1X, VPN and Wi-Fi. Neither protocol’s original cryptography belongs on an untrusted network: TACACS+ over TLS is TCP 300 and RADIUS over TLS is TCP 2083.
- TACACS+: TCP port 49. RADIUS: UDP 1812 and 1813, formerly 1645 and 1646
- RFC 8907 calls the TACACS+ body protection obfuscation, not encryption
- RADIUS hides only the password field, with a method based on MD5
- RFC 9887, December 2025, defines TACACS+ over TLS 1.3 on TCP port 300
- CVE-2024-3596 forges RADIUS responses with an MD5 collision, CVSS 9.0
On this page
The portsThe ports, and where each protocol runs
The port question is the one most people arrive at a TACACS vs RADIUS page with, so here it is with the sources.
TACACS+ is TCP 49. RFC 8907, the Informational document that described the protocol in September 2020, states that TACACS+ uses TCP for its transport and that TCP server port 49 is allocated by IANA for TACACS+ traffic.
RADIUS is UDP 1812 and 1813. RFC 2865 says the officially assigned port number for RADIUS is 1812, and notes that early deployment used UDP port 1645, which conflicts with the "datametrics" service. RFC 2866 does the same for accounting: the assigned port is 1813, where early deployment used 1646. Plenty of equipment still defaults to the old pair, so check both ends before blaming a firewall.
The TLS versions have their own ports. RADIUS over TLS, known as RadSec, uses TCP 2083 for everything, with no separate ports for authentication, accounting and dynamic authorization. TACACS+ over TLS 1.3 is newer: RFC 9887, published in December 2025, assigns TCP port 300 and requires the TLS service to listen on a port distinct from the non-TLS one.
The transport difference matters beyond the port number. TCP gives TACACS+ a connection, an acknowledgment and a clean failure when a server is down. RADIUS on UDP retransmits and moves to the next server, which is why RADIUS deployments are usually configured with more than one server address and a retry count.
What is protectedWhat each protocol actually protects
Nearly every TACACS vs RADIUS comparison online carries the same sentence: TACACS+ encrypts the entire packet, RADIUS encrypts only the password. The first half of that is wrong, and the primary sources are unambiguous about it.
TACACS+ obfuscates, and its own standard says so. RFC 8907 section 4.5 is titled Data Obfuscation, and it explains the choice of word directly: in the original draft the process was referred to as encryption, "but the algorithm would not meet modern standards and so will not be termed as encryption in this document".
The mechanism XORs the packet body with a pseudo-random pad derived from the shared secret using MD5. It covers the body rather than only a password field, which is a genuine advantage over RADIUS, and it is not encryption in any modern sense.
RADIUS hides the password only. RFC 2865 describes the Access-Request carrying the user's name and password, and says that when a password is present it is hidden using a method based on the MD5 message digest algorithm. Everything else in the packet, including the username, travels in the clear.
RADIUS has a documented forgery vulnerability. CVE-2024-3596, published in July 2024 with a CVSS base score of 9.0, describes RADIUS under RFC 2865 as susceptible to forgery by an attacker who can modify a valid response, using a chosen-prefix collision attack against the MD5 Response Authenticator.
An attacker positioned between the network device and the RADIUS server can turn an Access-Reject into an Access-Accept. The fix is not a patch to the packet format; it is to stop sending RADIUS over the open network in plain UDP.
Read those three together and the honest summary is that neither protocol's original cryptography belongs on an untrusted network in 2026. Both should be carried inside TLS, or at minimum kept on a management network nobody else can reach.
AAA separationAAA separation, and why TACACS+ owns device administration
The three As are authentication, who you are; authorization, what you may do; and accounting, what you did. How a protocol splits them decides how much access control it can express.
TACACS+ separates them. RFC 8907 defines a TACACS+ session as a single authentication sequence, a single authorization exchange, or a single accounting exchange, which is the protocol-level statement of that separation.
The practical consequence is command-based authorization, which the RFC spells out: the client asks the server whether a command is allowed by making an authorization request for each command, with the command name carried in the "cmd" argument.
That is how an organization gives a junior engineer show commands and nothing else, and how it produces an audit trail of what was typed on a router. No other widely deployed protocol gives that level of administrative access control on network equipment.
RADIUS combines authentication and authorization. The Access-Accept that says who you are also carries the attributes a switch can act on, such as the VLAN to place a port in.
That design fits network access, where the decision is made once when the session starts, and fits device administration poorly, because there is no natural place to ask about the next command.
This is the reason the two protocols coexist rather than compete. A single organization commonly runs RADIUS for 802.1X, Wi-Fi and VPN access, and TACACS+ for logging administrators into the switches, routers and firewalls that make those things work.
TLS versionsThe modern versions, and what they change
TACACS+ over TLS 1.3, RFC 9887. Published December 2025, it updates RFC 8907, states that the security mechanisms of section 4.5 are extremely weak, and obsoletes obfuscation: peers must not use obfuscation with TLS.
Clients connect to TCP port 300 and begin the TLS negotiation before sending any TACACS+ data. The author list, from NTT, Cisco and Google, is itself a useful fact for anyone who still believes the protocol belongs to one vendor.
RADIUS over TLS, RFC 6614. RadSec carries RADIUS inside a TLS connection on TCP 2083, with no separate ports for authentication, accounting and dynamic authorization. The RFC is Experimental, dates from May 2012, and names the eduroam roaming federation as an example of it in use. A datagram variant, RADIUS over DTLS, is RFC 7360, also Experimental, from 2014.
For most companies the near-term answer is neither RFC: it is to keep both protocols on a management network, restrict which devices may talk to the AAA servers, and plan the TLS migration with the vendor's roadmap, because support for TACACS+ over TLS is new enough that both the network devices and the AAA server have to implement it before it can be switched on.
Which oneWhich protocol for which job
Administrator logins to network devices: TACACS+. Per-command authorization and a per-command audit trail are the reasons, and no amount of RADIUS attribute engineering reproduces them cleanly.
Users and devices getting onto the network: RADIUS. 802.1X authentication on wired and wireless, VPN authentication, and the attribute exchange that assigns a VLAN or an access control policy to the port.
Cloud identity in front of both. Modern deployments usually put the AAA server behind the company directory, so the accounts and groups come from one place. That does not change which protocol the network device speaks.
Small networks. A company with three switches does not need either protocol to start with. Local accounts with a password manager and multi-factor authentication on the jump host it is managed from is a defensible arrangement; centralized AAA becomes worth its complexity when there are enough devices and enough administrators that local accounts drift.
PitfallsWhere people go wrong
Calling TACACS+ encrypted. Its own standard declines to. Treat it as obfuscated, and design the network accordingly.
Leaving RADIUS on the open network after CVE-2024-3596. A forged Access-Accept is an authentication bypass. Keep it off shared paths, or move to RadSec.
Opening the wrong ports. TCP 49 for TACACS+, UDP 1812 and 1813 for RADIUS, and the legacy 1645 and 1646 on older gear. A device that silently uses the legacy pair against a server listening on the new pair looks exactly like a shared-secret mismatch.
Using RADIUS for device administration and rebuilding per-command control. It can be approximated with privilege levels and vendor attributes, and the audit trail is never as good.
Forgetting the shared secret is the whole security model. Both protocols derive their security from it, and the authentication server has no other way to tell a legitimate network device from an impostor. One secret reused across every device means one compromised device exposes the rest.
Assuming TACACS+ is Cisco-only. It began at Cisco, and it is now an IETF-documented protocol implemented by many vendors, with RFC 9887 written by authors from NTT, Cisco and Google.
ComparisonTACACS+ and RADIUS, on ports, cryptography and AAA
| Criterion | TACACS+ | RADIUS |
|---|---|---|
| Transport and port | TCP 49 | UDP 1812 and 1813 |
| TLS version | TCP 300, RFC 9887, December 2025 | TCP 2083, RFC 6614 |
| What the original protects | The packet body, by obfuscation | Only the password field |
| Cryptography in the base standard | Not called encryption by RFC 8907 | MD5, with CVE-2024-3596 against responses |
| AAA separation | Full, three independent exchanges | Authentication and authorization combined |
| Per-command authorization | Yes | Not natively |
| Typical use | Device administration | Network access, 802.1X, VPN |
| Vendor support | Broad, and once Cisco-specific | Universal |
The first two rows answer the question most readers came for, and the TACACS vs RADIUS choice rarely turns on them. The middle rows are the ones worth taking to the person who designed your AAA setup.
FAQFrequently asked questions
What port does TACACS use?
TCP port 49. RFC 8907 states that TACACS+ uses TCP for its transport and that TCP server port 49 is allocated by IANA for TACACS+ traffic. TACACS+ over TLS 1.3 uses TCP port 300 instead.
What ports does RADIUS use?
UDP 1812 for authentication and UDP 1813 for accounting. Older deployments used 1645 and 1646, and plenty of equipment still defaults to them. RADIUS over TLS uses TCP 2083.
Is TACACS+ encrypted?
Not in the sense the word usually carries. RFC 8907 calls the mechanism obfuscation and says the algorithm would not meet modern standards, which is why RFC 9887 defines TACACS+ over TLS 1.3 and obsoletes obfuscation.
Does RADIUS encrypt the username?
No. Only the User-Password attribute is hidden, using a method based on MD5. The username and the rest of the attributes travel in the clear unless the traffic is inside TLS.
What is CVE-2024-3596?
A vulnerability in RADIUS under RFC 2865, published in July 2024 with a CVSS base score of 9.0, that lets an attacker who can modify a valid response forge a different response using a chosen-prefix MD5 collision against the Response Authenticator.
What is the difference between TACACS+ and RADIUS?
Transport and ports, what is protected in the packet, and whether authorization is separate from authentication. TACACS+ separates the three AAA functions and can authorize individual commands, which suits device administration. RADIUS combines authentication and authorization, which suits network access.
Is TACACS+ only for Cisco devices?
No. It started at Cisco, was documented as an IETF protocol in RFC 8907 in 2020, and its TLS profile, RFC 9887, was written by authors from NTT, Cisco and Google. Many vendors implement it.
Can I run both protocols at once?
Yes, and most organizations of any size do: RADIUS for user and device access to the network, TACACS+ for administrator access to the network equipment.
Which is better for 802.1X?
RADIUS. It is the protocol 802.1X is built around, and the Access-Accept carries the attributes that assign a VLAN or policy to the port.
Does TACACS+ work over UDP?
No. It uses TCP, which is part of why a failed TACACS+ server produces a clean failure rather than a timeout and retry.
What happens if the shared secret is wrong?
Authentication fails in a way that often looks like a network problem. Check the secret and the port pair together, because a device using the legacy RADIUS ports against a server listening on 1812 and 1813 produces the same silence.
Should we migrate to the TLS versions?
Eventually, yes, and check both sides first. RadSec has been published since May 2012; TACACS+ over TLS arrived in December 2025, so device and server support for it is still arriving.
Are TACACS+ and RADIUS both AAA protocols?
Yes. Both are AAA protocols, covering authentication, authorization and accounting. RADIUS combines authentication and authorization, runs over UDP, and encrypts only the password. TACACS+, the current form of TACACS, uses TCP port 49, separates the three functions, and encrypts the whole payload, which is why it is preferred for administering network devices.
Keep readingRelated concepts
Read next · Network security What Is a Firewall? The device whose administrator logins TACACS+ usually authorizes. Open this next14 min- Cryptography · 11 min Hash Functions, and Why the Right One Depends on the Job Why MD5 collisions matter, which is the root of both protocols’ weakness.
- Switching · 14 min What Is a VLAN? What a RADIUS Access-Accept commonly assigns to a switch port.
- Wireless security · 11 min WPA2-PSK, and Why the Password Is the Whole Security Model What replaces the shared passphrase when a network needs per-user identity.