Cisco has recently announced the end-of-sale and end-of-life for ISE software versions 3.1 and 3.2, with a last order date of November 3, 2026. Once that date passes, engineering support – development, repair, maintenance, testing – ends.
Now the question is for organizations, what next they need to do, how TACACS+ can seamlessly migrate without operational risk and how does it actually protect your network.
This guide answers those questions, walks through what to look for when evaluating alternatives.
What Is TACACS+?
TACACS+ stands for Terminal Access Controller Access-Control System Plus. It is an open IETF standard (RFC 8907) designed specifically for one job: controlling who can log into your network devices, what they can do once they’re in, and keeping a complete record of every action they take.
Every time a network engineer logs into a router, switch, firewall, or load balancer – to troubleshoot a configuration, apply a change, or investigate an incident – TACACS+ is the protocol that verifies their identity, determines what commands they’re allowed to run, and writes a log of what they actually did.
TACACS+ is not about end users joining a network. It is not about Wi-Fi authentication or VPN access. It is specifically and intentionally designed for the control plane that governs your engineers’ access to network infrastructure itself.
What Does TACACS+ Actually Do? The Three Functions Explained
TACACS+ separates its work into three distinct, independently managed functions. This separation is by design – it gives network security teams precise control over each layer.
- Authentication confirms who the engineer is. When someone attempts to log into a managed device, TACACS+ verifies their credentials against an identity source – typically Active Directory or LDAP. Only verified engineers get past this gate.
- Authorization determines what the authenticated engineer can do. This is where TACACS+ becomes genuinely powerful. It supports per-command authorization: not just “this person can log in” but “this person can run show commands on access switches but cannot run no shutdown on core interfaces.” Command sets, shell profiles, and privilege levels are all managed here, and they can be as granular as your operational requirements demand.
- Accounting records everything. Every command issued, on every device, by every engineer, with a timestamp – this is your full audit trail. For compliance frameworks including SOC 2, PCI DSS, ISO 27001, and CIS Controls, this per-command audit log is not optional. It is the evidence that a controlled, auditable privileged access program exists.
The separation of these three functions is what makes TACACS+ the right protocol for device administration. You can have strict authentication, flexible authorization tiers by role, and complete accounting – all independently configured.
Why Use TACACS+ Instead of RADIUS for Network Device Administration?
A question that comes up often: why not just use RADIUS for device administration? It is already deployed, already authenticating users for Wi-Fi and VPN – why run a second protocol?
The answer is that RADIUS and TACACS+ were built for fundamentally different use cases, and mixing them produces weaker security and less precise audit logs.
| Feature | TACACS+ | RADIUS |
|---|---|---|
| Primary use case | Network device administration | Network access control (Wi-Fi, VPN, 802.1X) |
| Transport | TCP — connection-oriented, reliable | UDP — connectionless |
| Encryption | Full session payload encrypted | Password field only (standard RADIUS) |
| Authorization model | Per-command — granular | All-or-nothing access |
| Accounting | Full per-command audit trail | Session-level accounting |
| Protocol separation | Auth / Authz / Acct are separate functions | Combined in single exchange |
The security difference is material. RADIUS encrypts only the password field; TACACS+ encrypts the entire session payload. For a session where an engineer is issuing privileged commands to core infrastructure, full session encryption is the appropriate control.
Per-command authorization is the other critical distinction. RADIUS does not support it natively. TACACS+ was designed around it. Using RADIUS for device administration means accepting blanket access at the privilege level – a significantly weaker control posture.
For device administration, TACACS+ is the correct tool. For endpoint and user network access, RADIUS is the correct tool. Use each for its intended purpose.
For a deeper protocol-level comparison, see Alepo’s guide to RADIUS vs Diameter vs TACACS+ in CSP environments.
Why Network Device Administration Deserves a Dedicated Control Plane
Network device administration is one of the highest-risk access vectors in any organization’s infrastructure. The engineers who manage your routers, switches, and firewalls have the access to reconfigure traffic paths, disable security controls, and alter network behavior at the most fundamental level.
The security and compliance requirements that follow from this are specific:
- Privileged access control.
Not every engineer should have access to every device, or every command on every device. Role-based command authorization – restricting junior NOC staff to read-only commands while giving senior engineers change authority – is a baseline control for any mature operations team.
- Unbroken audit trails.
When an incident occurs, the question is always the same: who was on the device, when, and what did they change? A per-command accounting log answers this definitively. Gap-free audit logs are also a direct compliance requirement for SOC 2 Type II, PCI DSS, and ISO 27001 audits. TACACS+ generates this record natively.
- Multi-vendor device support.
Most network estates run equipment from multiple vendors. TACACS+ is an IETF open standard. Every compliant network device speaks it to any compliant TACACS+ server. Vendor-neutrality in the device administration layer reduces dependency on any single vendor’s architecture.
- Break-glass access and emergency procedures.
A well-configured TACACS+ environment includes documented local fallback accounts and break-glass procedures for every device class, so that if the TACACS+ server is unavailable, emergency console access is always available through a tested, controlled path.
These requirements exist whether your TACACS+ server is a large platform add-on or a purpose-built system. What changes is how much overhead you carry to meet them.
What Is RFC 9887 and Why Does TLS 1.3 Matter for TACACS+?
For years, TACACS+ used MD5-based obfuscation, a legacy mechanism from the original RFC 8907 specification. It was functional but limited: not true encryption, and an obstacle for organizations operating in FIPS-aligned or zero-trust environments.
In December 2025, the IETF published RFC 9887, which defines TACACS+ over TLS 1.3 as a Proposed Standard. This retires the MD5-based obfuscation in favor of modern transport security. The specification has contributors from Cisco, Google, and NTT – this reflects broad industry alignment on the direction, not a single vendor initiative.
For any organization evaluating a TACACS+ platform in 2026, RFC 9887 adoption should be an explicit evaluation criterion. A migration made now should be aligned with where the protocol is going. Ask every vendor – incumbent or challenger – where they stand on TLS 1.3 transport and what their roadmap looks like.
What to Look for in a Purpose-Built TACACS+ Server
Not every TACACS+ implementation is designed with device administration as the primary use case. When evaluating platforms, these are the capabilities that matter:
- Per-command authorization as a first-class feature.
Command sets, shell profiles, and privilege levels should be managed through a clear, reviewable policy model – not buried in a broader platform with competing feature priorities.
- Full per-command accounting.
The audit log must capture every command, on every device, by every engineer. Confirm that accounting records flow to your SIEM or log management platform from day one.
- Multi-vendor device support by design.
The server should treat heterogeneous device estates – Cisco, Juniper, Nokia, Huawei, Aruba, Ruckus, Fortinet, Mikrotik – as the primary use case, not an afterthought.
- Availability architecture.
Device administration is mission-critical. Active-active geo-redundant deployment – so that no single server failure disrupts network management access – is the appropriate architecture for production environments.
- RFC 9887 roadmap.
As noted above, TLS 1.3 transport is where the standard is heading. Confirm the vendor’s position.
- Deployment flexibility.
Container (Kubernetes), VM, bare-metal, private cloud, on-premises, or managed service – the deployment model should match your infrastructure strategy, not constrain it.
Explore the Alepo AAA platform, including its Alepo TACACS+ device administration module.
Alepo TACACs : Built for Multi-vendor Network estates
Alepo TACACS+ is a purpose-built, carrier-grade platform for network device administration – designed specifically for organizations that need granular command authorization, privileged access control, and per-command audit across multi-vendor network estates.
Unlike platforms that treat TACACS+ as a secondary feature within a broader product, Alepo TACACS+ is built with device administration as its primary mission.
- Vendor-neutral multi-device support — out-of-the-box policy support for Cisco, Juniper, Nokia, Huawei, Aruba, Ruckus, Fortinet, Mikrotik, and other major network equipment vendors.
- Granular command authorization — command sets, shell profiles, and privilege levels managed through a config-driven policy model built specifically for device administration.
- Full per-command accounting — complete audit trail for every command issued on every device, feeding your SIEM for compliance and security investigation workflows.
- Carrier-grade availability — designed for 99.999% uptime, with active-active geo-redundant deployment. The TACACS+ module inherits the same reliability architecture validated across Tier-1 carrier deployments across the Middle East, Europe, LATAM, Africa, and North America.
- Deployment flexibility — containerized (Kubernetes), VM, bare-metal, private cloud (AWS, Azure, GCP), on-premises, or fully managed service. The deployment model matches your infrastructure, not ours.
The Alepo AI Agent for TACACS+ adds a security and performance control plane on top of the TACACS+ infrastructure: real-time anomaly detection, privilege-escalation alerts, brute-force detection, and SIEM integration – turning TACACS+ logs into active threat intelligence, not just a compliance archive.
How to Migrate TACACS+ Without Operational Risk
The right approach to any TACACS+ migration is a parallel run – never a flag-day cutover. The device administration plane is not something you switch on a Friday night and hope for the best.
Step 1: Inventory your device estate. Document every device class, device group, and administrator role currently authenticating through TACACS+. This inventory is your migration specification.
Step 2: Export your policy configuration. Command sets, shell profiles, and privilege levels from your current server are the acceptance criteria for the new one. Command-authorization parity is the test – not just connectivity.
Step 3: Map your identity sources. Confirm how the new TACACS+ server connects to Active Directory or LDAP. Validate realm routing for multi-domain and multi-site environments before any cutover.
Step 4: Stand up in parallel. The new server runs alongside the existing one. No production traffic moves yet. Validate connectivity and directory integration at this stage.
Step 5: Pilot on a low-risk device group. Select a subset – a lab environment, a single remote site, or an access-layer group – and point those devices at the new server. Validate authentication, per-command authorization, and accounting against the parity specification.
Step 6: Phase the cutover by device class. Migrate access layer first, then distribution, then core – once pilot validation is complete. Maintain the existing server as a fallback throughout.
Step 7: Validate accounting continuity. Confirm per-command records are flowing to your SIEM before retiring any existing TACACS+ infrastructure. Never cut compliance logging.
Step 8: Retire the old infrastructure. Once migration is fully validated and accounting continuity is confirmed, decommission the old TACACS+ nodes. This is when the operational and commercial savings materialize.
Frequently Asked Questions
Q. What is TACACS+ used for?
TACACS+ is used for network device administration – controlling and auditing which engineers can log into routers, switches, and firewalls, and what commands they can execute. It is distinct from RADIUS, which is used for end-user network access (Wi-Fi, VPN, 802.1X).
Q. Is TACACS+ more secure than RADIUS for device administration?
For device administration specifically, yes – TACACS+ encrypts the full session payload, while standard RADIUS encrypts only the password field. TACACS+ also supports per-command authorization, producing a granular audit record that RADIUS cannot provide for this use case.
Q. Can TACACS+ run without Cisco ISE?
Yes. TACACS+ is an open IETF standard (RFC 8907). Any compliant server communicates with any compliant device. ISE is one of several platform options. The protocol has no technical dependency on any specific vendor.
Q. What is RFC 9887?
RFC 9887, published by the IETF in December 2025, defines TACACS+ over TLS 1.3 as a Proposed Standard. It retires the legacy MD5-based obfuscation from RFC 8907 in favor of modern transport security – addressing a longstanding obstacle for FIPS-aligned and zero-trust environments.
Q. How long does a TACACS+ migration take?
Timeline varies by environment size and complexity. A parallel-run migration for a mid-size network estate can typically be completed in 4–8 weeks from initial inventory to final cutover, with phased device-group migration reducing risk at each step.
Conclusion
If your organization is evaluating a TACACS+ migration – whether from Cisco ISE or another platform – Alepo’s team can run a 30-minute TCO comparison and a command-authorization parity review for your environment.
