Three things decide most TACACS+ server evaluations: how granular the command authorization is, whether the server works with every device you own, and whether there is a supported migration path off what you run today. The other nine criteria matter differently depending on the size of your device estate. This checklist weights all twelve, gives you a test for each, and says which ones a smaller estate can skip.
Three vendor decks are open on your second screen. Each says the same four things: standards-based, granular authorization, high availability, works with any device. The mandate was short “be off the old device-administration server by year end” and the decks have not made the decision easier, because every feature list is built to make its own gaps invisible.
This is the document you would want a colleague to hand you before that evaluation started. Twelve criteria for comparing a TACACS+ (Terminal Access Controller Access-Control System Plus) server, each with a weight and a way to verify it during a proof of concept (POC) plus the three that usually decide the outcome and the ones a small estate can ignore. Lift it into your request for proposal (RFP) and send it to every vendor on the shortlist, including the one publishing it.
Before you compare anything: three questions that set your requirements
A TACACS+ server is the central system that decides who may log in to network devices, which commands they may run, and what gets recorded. Routers, switches and firewalls forward each administrative login and command to it, and it returns an allow or deny decision from one centrally managed policy.
The job is the same for a 200-device internet service provider (ISP) and a 5,000-device multinational; the requirements are not. Three questions set the weights below.
How many devices, and how many are outside your primary region?
Count every router, switch, firewall, wireless controller and broadband network gateway (BNG) that will authenticate administrators, then count how many sit in a second data center, country or jurisdiction. The first number tells you whether scale is a real constraint. The second decides whether geo-redundancy and data residency are requirements or nice-to-haves.
How many distinct roles do you actually need?
List the groups who touch devices: network operations center (NOC) staff, field technicians, security engineers, contractors, automation accounts. Most operators land between four and eight roles. If you need twenty, or roles that differ per device group, authorization granularity decides everything.
Are you migrating off something, and what is on it?
Nearly every evaluation is a brownfield migration: off an end-of-life commercial product, an open-source daemon nobody owns anymore, or local passwords an auditor has just written up. Inventory what exists today accounts, command sets, device groups, accounting history because the migration criterion is scored against it. The same inventory feeds the business case for modernizing device administration procurement will ask for.
The 12-criteria TACACS+ server evaluation worksheet
The twelve criteria, in worksheet order:
- Standards conformance and TLS roadmap
- Command authorization granularity
- Identity store and MFA integration
- Multi-realm and tenant isolation
- Device interoperability across your estate
- Accounting depth, retention and queryability
- SIEM integration and threat detection
- Availability and geo-redundancy
- Deployment model flexibility
- Scale and performance headroom
- Migration path and coexistence
- Commercial model, support and vendor viability
Weights are a starting point. Adjust them using your answers to the three questions above.
| # | Criterion | Suggested weight | How to verify it |
| 1 | Standards conformance and TLS roadmap | High | Ask for RFC 8907 conformance in writing and a dated RFC 9887 roadmap commitment |
| 2 | Command authorization granularity | Critical | Have the vendor model three of your real roles during the POC, not a demo role |
| 3 | Identity store and MFA integration | High | Point the server at your actual directory in the POC, not a sample directory |
| 4 | Multi-realm / tenant isolation | Situational | Only critical if you have separate teams, regions or client estates |
| 5 | Device interoperability across your estate | Critical | Hand over your device inventory by vendor, OS and version; ask for known caveats |
| 6 | Accounting depth, retention and queryability | High | Ask for a sample export and try to answer a real audit question with it |
| 7 | SIEM integration and threat detection | Medium–High | Ask what detections ship out of the box versus what you build |
| 8 | Availability and geo-redundancy | Critical for anyone with an SLA | Fail a node during the POC while a session is open |
| 9 | Deployment model flexibility | Medium | Match against your current infrastructure standard, not a future one |
| 10 | Scale and performance headroom | Situational | Small single-region estates are rarely throughput-constrained |
| 11 | Migration path and coexistence | Critical in any brownfield | Ask for a cutover plan for one device group before signing |
| 12 | Commercial model, support and vendor viability | High | Model three-year total cost of ownership (TCO) under your growth assumptions |
Want this as a working document? Download the TACACS+ datasheet while the evaluation worksheet is being prepared.
Criteria 1–3: standards, authorization, identity
Standards conformance is nearly a checkbox for classic TACACS+: any serious server implements RFC 8907. What separates vendors now is RFC 9887, published December 2025, which runs TACACS+ over Transport Layer Security (TLS) 1.3 on TCP port 300 instead of the obfuscated classic transport on TCP port 49. Device support is still arriving, so you are buying a dated commitment to ship it because “we are watching the standard” is the answer you will regret in a 2028 audit.
Per-command authorization is where demos mislead by omission. Every server can show a read-only role and an admin role. Ask instead for a role that permits show and interface-level shutdown on access switches but denies both on core routers, and a contractor role that can run one change script and nothing else. A product that cannot model three of your real roles in the POC will not model twenty in production. If you have not defined those roles yet, start with how to design least-privilege roles and command authorization.
Identity integration is a verification problem, not a feature-list one. Every vendor lists Lightweight Directory Access Protocol (LDAP) and Active Directory. Point the server at your real directory, with your real group nesting and multi-factor authentication (MFA) on the privileged roles. The vendor’s sample directory will work. Yours may not.
Criteria 4–6: isolation, interoperability, accounting
Multi-realm isolation lets one server hold separate policy domains for different teams, regions or client estates, each invisible to the others. A managed service provider (MSP) administering devices for twelve customers needs it. If you run one network for one organization in one region, you may not need this at all.
Device interoperability is asserted on every product page and verified on almost none. The protocol is standard; the attribute-value pairs (AVPs) each network operating system sends for authorization and accounting are not, and that is where deployments break. Give each vendor a spreadsheet of your estate by vendor, operating system and version, and ask for known caveats in writing. A vendor that replies “none” for a mixed Cisco IOS, Juniper Junos and Nokia SR OS estate has not read the spreadsheet.
Accounting depth determines whether the server produces evidence or a log file. Ask for a sample export, then answer a real question from your last audit with it: who changed the access control list (ACL) on the border router that day, and what else did they do in the session? If the answer needs a vendor engineer, that is your queryability score. Retention requirements come from your regulator and from frameworks such as NIST SP 800-53 (AU-2, AU-11, AU-12), not from the server’s defaults.
Criteria 7–9: detection, availability, deployment
Security information and event management (SIEM) integration is table stakes; what matters is what happens between the log leaving the server and an analyst noticing it. Ask which detections ship out of the box repeated authorization denials for one user, service accounts opening interactive sessions, failed-login bursts across many devices and which you build yourself. The difference is weeks of security engineering.
Availability is a security property here, because the service exists to be used during the incidents most likely to take it down. Require active-active operation across two sites if you carry a service-level agreement (SLA). The test most evaluations skip: fail a node during the POC while an engineer has a live session open, then watch the session, the next command and the accounting record.
Deployment flexibility – containers, virtual machines (VMs), bare metal, public cloud, managed service – matters exactly as much as your infrastructure standard says it does. If your team runs VMs on premises and will for the life of this contract, a container-native story is not a point in anyone’s favor.
Criteria 10–12: scale, migration, commercial
Scale is the criterion vendors most enjoy discussing and buyers most often overweight. Load is set by how many humans are typing, not by how many devices exist: with per-command authorization enabled, one authorization request per command entered, plus logins and accounting records. For a single-region estate of a few hundred devices, throughput is almost never the constraint – our rule of thumb, worth testing against your own peak. Above a few thousand devices, or with heavy automation issuing commands through the same path, headroom becomes real. Ask for transactions-per-second (TPS) figures, but weight them by your own estate.
Migration path is treated in detail below, because it decides more evaluations than anything except authorization and interoperability. The worksheet test is specific: before signing, ask for a written cutover plan for one device group, covering how command sets carry across and how old and new servers coexist while devices move.
Commercial model covers more than the price. Licensing may be per device, per administrator, per transaction rate, per site or unlimited, and the model that looks cheapest today can be the most expensive at year three. Model three years under your own growth assumptions, and weigh support terms and vendor viability alongside them. One consolidation question belongs here: if you already run Remote Authentication Dial-In User Service (RADIUS) or Diameter for subscriber access, ask whether device administration can run on the same platform one vendor and one support contract is a real TCO line. The framework for evaluating an AAA vendor for long-term growth applies here too.
The three criteria that usually decide it
Three criteria decide most TACACS+ evaluations: how granular the command authorization is, whether it genuinely works with every device you own, and whether there is a migration path off what you are running today. Everything else is verifiable in an afternoon, or situational.
Command authorization decides because it is the reason you are buying the product. Take a 200-device single-region ISP with five roles: NOC, field, security and two contractors. The server that matters is the one that can express “this contractor may run this maintenance script on these eight devices between 02:00 and 04:00 on Tuesdays” not the one with the better dashboard. That rule removes a standing privilege an auditor would otherwise write up.
Device interoperability decides because it surfaces deal-breakers late. A 3,000-device operator running Cisco, Juniper and Nokia platforms across four countries will find that one of them sends authorization attributes the server does not parse the way the vendor expected. Finding that in the POC costs a week. Finding it in month two of production can stall the rollout.
Migration path decides because every evaluation is a brownfield. An MSP with fourteen client estates on a mix of open-source daemons and an end-of-life commercial product cannot cut everyone over in one weekend. It needs a server that coexists with the old ones, imports command sets client by client, and rolls one estate back without touching the others. Ask each vendor what the first Monday looks like. The ones who have done this before will have a specific answer.
Free and open-source TACACS+: where the line actually is
The difference between a free and a commercial TACACS+ server is rarely capability at small scale. It is support during an incident, a dated roadmap for TACACS+ over TLS, a supported migration path when the estate changes, and the removal of key-person risk. A team that can absorb all four in-house has no reason to switch.
Open-source daemons run a great many device estates, and “open source does not scale” is the wrong reason to leave them. Scale is rarely the problem. Ownership is.
When open source is the right answer
A free TACACS+ server is the right choice when four things are true at once:
- The estate is small and in one region.
- The organization has in-house Linux and network expertise that will still be there in three years.
- No regulator or auditor requires supported software with a defined patching commitment.
- The team is willing to own upgrades, backups and high availability itself.
Teams that meet all four are well served by open source. For them, a commercial server is a cost without a matching benefit.
The four conditions where it stops working
The boundary is not a device count. It is the first moment one of these becomes true:
- The daemon is down during an incident and there is no one to call.
- An auditor asks for the TLS roadmap and there is none.
- The estate has to move and there is no supported migration path, so command sets are rebuilt by hand.
- The one engineer who understood the configuration leaves.
Any one of those is the signal to start an evaluation.
What has to be carried across
Four things: user and group definitions, or better, the mapping to the directory that already holds them; the command sets and shell profiles that define each role; device groups and shared secrets; and the accounting history your retention policy requires. Inspect the command sets closely years of accretion leave overlapping roles, forgotten exceptions and an oversized privilege-15 group, and migration is the one moment you can clean that up without a change-control fight.
Coexistence during cutover
Most network operating systems try their configured TACACS+ servers in order and fall through to the next only when one is unreachable not when one returns a deny so that ordering is the usual coexistence mechanism. Confirm the fall-through behavior and timeout on each platform in your estate before you rely on it, because this is one of the places implementations differ.
For a pilot device group, place the new server first with the old one behind it as fallback, then confirm authentication, per-command authorization and accounting all work on live sessions. Move groups in change windows, keep the old server reachable until the last one is done, and keep a local emergency account on every device throughout. If a group misbehaves, reordering the server list is the rollback: the change itself takes minutes, so budget for how your estate pushes configuration. The same sequence applies when moving off an enterprise network access control suite rather than a dedicated TACACS+ server.
A two-week proof of concept that tells you something
Two weeks is enough if the tests are chosen for what they reveal rather than what they demonstrate. Run these five against every shortlisted server, on your infrastructure, with your devices.
| # | Test | What a pass looks like |
| 1 | Model three of your real roles, including one contractor role scoped to a device group and a command subset | Each role behaves as specified on at least two device platforms; denied commands appear in accounting |
| 2 | Authenticate against your production directory (a read-only account is fine), with MFA on the privileged role | Group membership maps to roles without manual duplication; MFA challenge appears on privileged login only |
| 3 | Fail a server node while an engineer has a live session open and is issuing commands | Next command authorizes within the device timeout; no session drop; accounting shows no gap |
| 4 | Export accounting and answer one real question from your last audit | Answer produced from the export alone, without vendor help, in under an hour |
| 5 | Cut one device group over from the current server, run it for 48 hours, then roll it back | Both directions complete inside a change window using only the device server-list ordering |
Tests 3 and 5 are the ones most evaluations skip, and the two most likely to change your ranking.
Where a TACACS+ server sits alongside subscriber access
TACACS+ governs the engineers who administer the network; RADIUS governs the subscribers and devices that use it. The full comparison is in our guide to how TACACS+ differs from RADIUS and Diameter in Communications Service Provider (CSP) environments.
| TACACS+ | RADIUS | |
| Population | Network administrators | Subscribers and endpoints |
| Job | Device administration | Network access |
| Authorization | Separate, per command | Combined with authentication |
| Transport | TCP 49 / TCP 300 (TLS) | UDP 1812/1813 |
| Accounting | Command-level audit trail | Usage and billing records |
Most operators need both. Running them on one platform, as Alepo does with RADIUS, Diameter and TACACS+ on a single AAA (authentication, authorization, and accounting) server, is the consolidation trade-off from criterion 12: one vendor and one support contract, against the counter-case that a point product is simpler if device administration is your only AAA workload.
Running an evaluation now? Bring your three hardest criteria and your device list. We will work through them on your own device types with the Alepo TACACS+ Server. Book a demo
FAQs
Q1. What should I look for in a TACACS+ server?
Twelve criteria matter, but three usually decide the outcome: command authorization granularity (can it model your real roles, not demo roles), device interoperability (does it handle the attributes every platform in your estate actually sends), and migration path (can it coexist with your current server during cutover). Verify each in a proof of concept, not from a datasheet.
Q2. What is the difference between a free and a commercial TACACS+ server?
At small scale, rarely capability. The differences are support during an incident, a dated roadmap for TACACS+ over TLS (RFC 9887), a supported migration path when the estate changes, and protection from key-person risk. If your team can absorb those four in-house for the life of the deployment, an open-source daemon is a defensible choice.
Q3. Can I replace Cisco Secure ACS with a TACACS+ server?
Yes. Cisco Secure ACS is retired, and an RFC 8907-conformant TACACS+ server can take over the device-administration function from it. What carries across is the user and group mapping, command sets and shell profiles, device groups and shared secrets, and the accounting history your retention policy requires. Migrate one device group at a time, using the device server-list ordering for coexistence and rollback.
Q4. Do I need a carrier-grade TACACS+ server for a small estate?
Often not. A single-region estate of a few hundred devices with a handful of roles rarely needs multi-realm isolation, geo-redundancy or high transaction throughput. It still needs per-command authorization, integration with the real directory, usable accounting and a supported upgrade path. Score criteria 4, 9 and 10 low, and spend the evaluation time on 2, 5 and 11.
Q5. Will a TACACS+ server work with my Juniper and Nokia devices?
In principle, yes: TACACS+ is a standard protocol and Junos and SR OS both implement it. In practice, each network operating system sends its own authorization and accounting attributes, and that is where implementations differ. Give the vendor your inventory by platform and version, ask for known caveats in writing, and test at least two platforms in the proof of concept.
Q6. Should a TACACS+ server support TACACS+ over TLS?
Ask for a dated roadmap now, even if none of your devices can use it yet. RFC 9887, published December 2025, moves TACACS+ onto TLS 1.3 on TCP port 300 with mutual certificate authentication. Device support will arrive through operating-system releases and refresh cycles, and a server bought today will still be in service when it does.
Q7. How are TACACS+ servers licensed?
Common models are per managed device, per administrator, per transaction rate, per site, and unlimited or platform-based. Each behaves differently as the estate grows: per-device pricing tracks network expansion, per-administrator pricing tracks headcount, platform pricing is flat. Model three years under your own growth assumptions before comparing quotes; the cheapest option today is often not the cheapest at year three.
Q8. Should TACACS+ run on the same platform as RADIUS?
It is a trade-off. Consolidating device administration and subscriber access on one AAA platform gives you one vendor, one support contract and one operational model, which matters when you already run RADIUS or Diameter at scale. If device administration is your only AAA workload, a dedicated TACACS+ server may be simpler. Decide on your own estate, not the vendor’s preference.
