Guide
TACACS+ vs RADIUS: Which One Do You Use, and When?
One secures who gets on the network; the other secures who gets to change it. The classic comparison every network engineer is asked — settled properly.
RADIUS for access to the network; TACACS+ for access to the devices that run the network. That design rule settles the classic comparison in practice, and mature enterprises end up running both — commonly from the same Cisco ISE deployment. The supporting detail is still worth knowing cold, because the two protocols differ in transport, in what they protect on the wire, and in how they divide the three A’s — and every one of those differences traces back to the job each protocol was built to do.
What the Two Protocols Share
Both are AAA protocols: authentication establishes who is asking, authorization decides what they may do, accounting records what they did. Both move those decisions off individual devices and onto a central server, so a thousand switches do not each carry a local password file that nobody rotates. In a Cisco network that server is typically Identity Services Engine, which speaks RADIUS for network access and — with a Device Administration license — TACACS+ for device administration on the same deployment.
Transport: TCP 49 vs UDP 1812 and 1813
TACACS+ runs over TCP port 49. A connection-oriented transport suits its work: an administrative session is a sequence of exchanges where each one matters, and TCP carries the reliability. Classic RADIUS runs over UDP, with port 1812 assigned for authentication and 1813 for accounting — the older 1645 and 1646 still surface in legacy configurations — and handles retransmission itself at the application layer. That keeps the protocol light for its job: thousands of short authentication decisions rather than long administrative dialogues.
Protection on the Wire: Obfuscation, Not Encryption
Classic RADIUS protects only specific sensitive attributes — the User-Password field is the canonical case, masked with an MD5-based mechanism keyed by the shared secret, and a few others such as tunnel passwords carry their own attribute-level hiding. Identity, endpoint, and authorization metadata travel in cleartext. With its shared-secret obfuscation in use — the normal case — classic TACACS+ covers the entire packet body, though not the header, with an MD5-derived pad, which is why “TACACS+ encrypts the whole payload” became the standard interview answer. The current specification is more honest: RFC 8907 pointedly terms that mechanism obfuscation rather than encryption, and recommends confining unprotected TACACS+ to an isolated management network. The broader coverage still matters — the body is where every administrative command travels — but neither classic protocol meets modern cryptographic expectations. The standards-based answer on both sides is a protected transport where platform support exists: the IETF standardized TACACS+ over TLS 1.3 in RFC 9887, and RADIUS over TLS, known as RadSec, is the equivalent on the RADIUS side. Where neither is available, RFC 8907’s isolated-management-network guidance stands.
Separation of Duties and Per-Command Control
In its normal network-access flow, RADIUS carries authentication and authorization in one conversation — a single Access-Request/Access-Accept pair for simple methods, several Access-Request/Access-Challenge round trips for EAP — with the authorization result — VLAN, downloadable ACL, Security Group Tag — riding on the final Access-Accept as attributes. That is efficient for “let this laptop onto VLAN 20.” TACACS+ separates authentication, authorization, and accounting into independent exchanges, and that separation enables its signature feature: per-command authorization. The device can ask the server about each command before executing it, so a junior engineer holds show access on the core while a senior engineer holds configure — enforced centrally rather than by promises. Accounting follows the same grain, producing a per-command audit trail: who typed what, on which device, at what time. With command accounting configured and collected, the question of who issued which command on the data-center core last March is answered from that log in minutes.
The Design Rule
Network access — 802.1X, MAB, wireless, VPN, guest — is RADIUS territory: high volume, fast decisions, rich authorization results, and dynamic session changes through Change of Authorization (RFC 5176). Device administration — SSH into the routers, switches, and firewalls themselves — is TACACS+ territory: lower volume, higher stakes, command-level control, and an audit trail that supports compliance and investigation. RADIUS can carry administrative logins too, but it has no standardized per-command authorization model — which is why device administration lands on TACACS+. The protocols are not competitors; they are adjacent tools, and the design rule assigns each to the surface it was built for.
Where the Exam Meets the Job
On the SISE 300-715 blueprint this is domain 7, Network Access Device Administration, weighted at 10%: describe AAA protocols, and configure TACACS+ device administration, command authorization, and accounting. It is a small domain that maps to a large slice of real operational work — device administration is often the first thing a new security team is asked to clean up. The SISE course builds the configuration on real gear, and if you are mapping the certification path itself, start here.
Frequently Asked Questions
Can Cisco ISE do both TACACS+ and RADIUS?
Yes. ISE speaks RADIUS for network access — 802.1X, MAB, guest — and, with a Device Administration license, TACACS+ for controlling who can log into and configure network devices. Running both on one deployment is the common enterprise design.
Why does TACACS+ use TCP while RADIUS uses UDP?
TACACS+ uses TCP port 49, a connection-oriented fit for an administrative session where every command authorization matters. Classic RADIUS uses UDP — 1812 for authentication, 1813 for accounting — and handles retransmission at the application layer, a lighter-weight fit for high-volume network-access decisions.
Is TACACS+ really more secure than RADIUS?
Its protection covers more of the packet: classic TACACS+ obfuscates the whole body when its shared-secret protection is in use, while classic RADIUS hides only specific attributes such as the password field. But RFC 8907 calls the TACACS+ mechanism obfuscation, not encryption, so neither classic protocol meets modern cryptographic expectations. Where supported, the answer for both is a TLS-protected transport — RFC 9887 for TACACS+, RadSec for RADIUS.