A TACACS+ server answers three questions every time an engineer touches a network device. Who is this? What may they do? Why should we believe either answer right now? Multi-factor authentication settles the first, per-command authorization the second, and a zero-trust posture the third. Alepo has covered each in depth. This TACACS+ security checklist is the short version of all three, with a way to test your deployment against each.
TACACS+ (Terminal Access Controller Access-Control System Plus) is the protocol operators commonly use to control administrative access to routers, switches, and firewalls.
Multi-factor authentication
Question one: who is this? TACACS+ authentication is a multi-round exchange between device and server, so after the password is accepted the server can still ask for a one-time code or a push prompt. Multi-factor authentication (MFA) adds seconds to each login, and during an outage those seconds belong to people under pressure, so tier it. Change-capable roles always face the second factor; read-only roles can be exempt. A documented emergency route (break-glass) means nobody is tempted to switch MFA off during an incident.
Signs MFA is working
- The second factor is enforced by the TACACS+ server for change-capable roles, not configured device by device.
- The emergency route is a local account per device, with credentials held in a secrets manager. Every use raises an alert and is reviewed.
- Nobody logs in with a shared enable password (one privileged-mode password the whole team knows). Each engineer has one credential of their own.
Full article: MFA is practice 3 of TACACS+ Security Best Practices for Telecom and Service Provider Networks. It also covers the shared secret, RFC 9887 transport encryption, and the four attack patterns your security information and event management (SIEM) platform should alert on.
Privilege levels and command authorization
Question two: what may this person do? TACACS+ carries a privilege level from 0 to 15. On Cisco IOS, only three of them mean anything: 0 is a handful of basic commands, 1 is read-only, and 15 is everything, so most people end up at 15. Custom levels 2 to 14 do not rescue the model: each must be defined on every device, and definitions diverge across vendors. Per-command authorization replaces the buckets: the device asks the server whether this user may run each command here, and the server checks the user’s role against the device group before it executes.
Signs command authorization is working
- Login sets only the starting context. Each command is checked against an explicit list on the server, so a change to the list reaches every device on the next command.
- Roles are scoped by device group as well as by command, and the role that makes routine changes cannot edit the TACACS+ configuration itself.
- Every authorized command is recorded with who ran it, on which device, and when, and the record lives where no administrator role can delete it.
Full article: TACACS+ Privilege Levels and Command Authorization: Building Role-Based Access Across Network Devices provides a seven-role template, from network operations center (NOC) tiers to field technicians, contractors, and automation accounts. Each role is mapped to NIST SP 800-53, ISO/IEC 27001:2022, PCI DSS (Payment Card Industry Data Security Standard) v4.0, and CIS Controls v8.
Zero-trust administrator access
Question three: why should we believe the first two answers right now? Older network security answered it with location: if you were on the management network, you were trusted. Zero trust removes that shortcut. Each session must prove who is asking, each command must pass policy, and each action leaves a record, whichever network the request arrives from. Zero-trust administrator access is, in practice, what a fully deployed TACACS+ estate already does.
Signs zero-trust access is working
- Every management path that can go through the TACACS+ server does. The ones that cannot, such as a serial console, are on a written exception list.
- Behavior when the server is unreachable is designed and tested. A device that permits everything when it cannot reach the server is trusting the network again.
- Accounting is streamed off the device to a SIEM, and someone is alerted on brute force, credential stuffing, privilege escalation, and misuse of automation accounts.
Putting the TACACS+ security checklist together
Three questions, three controls, one server. MFA establishes who is at the keyboard. Command authorization turns that identity into a bounded set of actions. Zero trust is the decision to ask both questions on every session and every command, and to remove every path that skips them.
What the three produce together is evidence: attributable identities, enforced authorization, and complete accounting records. That is what an auditor asks for, and no product supplies it on its own.
Start with the section where you found the most gaps; the linked posts go deeper, and the TACACS+ datasheet has the command-authorization and accounting detail. To compare notes with a team that runs TACACS+ for operators, bring your privilege-level assignments and the finding you are answering to a short walkthrough. The Alepo TACACS+ solution page shows how per-command authorization and per-user session records work, and how to reach the team.
