Evaluating TACACS+ Solutions for Multi-Vendor Networks

Most organisations do not discover the limits of a TACACS+ solution until they need to support a new vendor, enforce a new policy, or migrate a complex environment. This guide explains how to evaluate TACACS+ solutions for real-world multi-vendor networks, where standards compliance alone is not enough to guarantee a smooth deployment. 

By Arran Cudbard-Bell, CTO, and Nick Porter, Director of Engineering. 

If your environment includes Cisco, Juniper, Arista, or inherited infrastructure from acquisitions and refresh cycles, TACACS+ flexibility matters more than most feature checklists suggest. The protocol itself is straightforward, but deployment complexity comes from vendor diversity, documentation gaps, different authorisation models, MFA support limitations, and years of accumulated configuration debt. 

Paper Outline (Download the PDF for more information)

Key takeaways 

• TACACS+ complexity usually comes from vendor implementation differences, not from the protocol itself. 
• New equipment support should be handled through configuration, policy, and testing workflows whenever possible, not slow software release cycles. 
• MFA requirements should be validated against actual equipment behavior, especially where ASCII authentication is required. 
• Cisco ISE migration projects often involve more cleanup of legacy access rules and documentation than protocol translation work. 
• Standards compliance does not guarantee the same authorisation model, attribute format, or deployment behaviour across vendors. 
• The best TACACS+ evaluation questions focus on adaptation, discovery, and operational flexibility, not just feature lists. 

Why TACACS+ flexibility matters 

Multi-vendor environments are normal in mature networks because they reduce vendor lock-in, preserve negotiating leverage, and let teams choose the best platform for each use case. The problem is that many TACACS+ solutions work well in homogeneous environments but become operational bottlenecks when administrators need to support new devices, new attribute patterns, or new authorisation models. 

RFC 8907 standardised TACACS+ in 2020, but many vendors had shipped TACACS+ implementations long before that specification was published. As a result, two vendors can both be standards compliant and still behave very differently in production, especially around authorisation behavior, attribute formats, and authentication flows. 

The real multi-vendor challenge

The hardest TACACS+ questions usually appear after product selection, not before it. What happens when you inherit equipment in an acquisition, introduce a new switch vendor, or need a policy model your TACACS+ product has never been explicitly tested against? 

The most important evaluation question is not simply whether a vendor supports Cisco, Juniper, or Arista. It is whether the TACACS+ platform can adapt to undocumented or partially documented implementations through configuration, dictionary updates, policy logic, and log-driven discovery instead of waiting for new product code. 

How vendor implementations differ

TACACS+ authorisation is not implemented the same way across vendors, and the paper highlights three common patterns: command-by-command authorisation, privilege-level authorisation, and local-equivalence models. Each approach changes what the TACACS+ server must return and how policies need to be written. 

Vendors can also differ in attribute names, timestamp formats, username restrictions, privilege representations, and request-response behavior. These differences are often under-documented, which is why successful TACACS+ deployments rely on testing, traffic inspection, and operational experience rather than documentation alone. 

Why documentation is not enough

Vendor documentation often explains how to point a device at a TACACS+ server, but not how the device actually behaves once authentication and authorisation begin. In practice, teams still need to discover which authorisation model is in play, what attributes are expected, what values are valid, and how a full request-response sequence behaves during real login and command execution. 

That gap is especially important in inherited or brownfield environments, where no one may fully understand what the current TACACS+ deployment is doing. In those cases, packet capture, log analysis, and policy reconstruction are not edge-case activities; they are part of the normal deployment process. 

Supporting new vendors and new devices

Introducing new equipment into a TACACS+ environment usually requires an iterative process: configure the device, test authentication and authorisation, review TACACS+ logs, adjust policies or dictionaries, and repeat until the behavior matches requirements. The timeline can range from hours to days for straightforward cases, or extend to weeks where documentation is poor and authorisation behavior is more complex. 

A TACACS+ platform that supports new vendor behavior through text-based configuration and policy changes will usually adapt much faster than one that depends on product releases for each implementation variation. 

Common implementation risks

MFA compatibility 

Many MFA workflows depend on ASCII authentication so the TACACS+ server can send prompts and receive challenge responses during login. If a device only supports PAP or implements ASCII authentication incorrectly, MFA plans may fail even when TACACS+ is otherwise working. 

Legacy configuration debt 

In long-running environments, TACACS+ rules often accumulate over many years without consistent cleanup or documentation. During migration, the technical work of translating policies is often easier than deciding what access should still exist, who needs which privileges, and how to document the new model cleanly. 

Poor vendor documentation 

Minimal TACACS+ documentation shifts discovery work into the implementation phase, which is exactly when timeline pressure is usually highest. This makes vendor experience and a disciplined discovery process more valuable than broad but vague claims of compatibility. 

Internet-connected device security 

The paper notes that TACACS+ obfuscation is dated and may not be sufficient for public internet transport, especially when audit and command logs contain sensitive operational information. For internet-facing deployments, additional transport protection such as IPSec should be part of the design discussion. 

The Cisco ISE migration question

The paper frames Cisco ISE migration as a shift in operating model as much as a product replacement. Cisco ISE uses a more declarative, GUI-driven approach, while FreeRADIUS-based TACACS+ implementations rely on policy logic and deeper integration with existing infrastructure. 

The guide argues that user groups, device groups, command authorisation, service authorisation, and accounting functions can all be translated, but the project often becomes an opportunity to rationalise legacy rules, simplify access design, and improve integration with directories and automation systems. 

How to evaluate TACACS+ solutions 

When comparing TACACS+ options, the most useful questions are the ones that reveal how a solution behaves under uncertainty. Good evaluation criteria include how a vendor handles untested equipment, how discovery works for new devices, how different authorisation models are supported, how much policy flexibility is available, and what a typical ISE migration actually involves. 

Strong answers are specific. They describe log analysis, dictionary updates, policy adjustment, validation steps, and real examples of handling vendor-specific behavior rather than generic claims that everything is standards compliant and should work automatically. 

Why InkBridge

InkBridge Networks engineers, supports, and deploys TACACS+, RADIUS, DHCP, and DNS solutions for organisations that rely on secure, flexible network infrastructure. The team behind InkBridge contributed to RFC 8907 and continues to participate in TACACS+ standards work, while bringing decades of experience deploying AAA systems in complex environments. 

For teams managing Cisco, Juniper, Arista, and other mixed-vendor infrastructure, InkBridge combines technical depth with a vendor-neutral architecture that can adapt through policy and configuration instead of forcing network changes to wait on product release cycles. 

FAQ

What is the biggest mistake teams make when evaluating TACACS+ solutions? 

The biggest mistake is assuming that standards compliance guarantees smooth multi-vendor support. In practice, the harder question is how a TACACS+ platform adapts when vendor implementations differ, documentation is incomplete, or a new device introduces unfamiliar behavior. 

Why do TACACS+ projects get delayed? 

They are often delayed by undocumented vendor behavior, legacy configuration cleanup, and the time required to test and refine policies against real devices. In some cases, delays also come from TACACS+ products that require software releases instead of configuration changes to support new vendor behavior. 

Does TACACS+ support multi-factor authentication? 

It can, but MFA depends on the authentication methods supported by the network equipment as well as the TACACS+ server. If your design requires challenge-response flows, you need to verify correct ASCII authentication support on the actual devices you plan to use. 

Is Cisco ISE migration mostly a technical translation exercise? 

Only partly. The technical translation is usually manageable, but the larger effort often comes from cleaning up inherited policies, redefining access structures, improving documentation, and integrating the new TACACS+ model with existing systems. 

What should we ask a TACACS+ vendor before choosing a platform? 

Ask how they handle vendors they have not explicitly tested, how they discover and validate new device behavior, how they support different authorisation models, and whether adaptation happens through configuration or software releases. Those answers reveal far more than a feature checklist.