Most Cisco environments use TACACS+ for AAA — and most have at least one ten-year-old shared secret in a `running-config` somewhere. Innovexus vaults TACACS+ shared keys, brokers admin credential lifecycles, and ties every TACACS+ session back to a FIDO2 hardware-authenticated identity. Works with Cisco ISE, the legacy Cisco ACS install you can't kill, and open-source TACACS+ servers.
TACACS+ has been the dominant network device AAA protocol since the 1990s for good reason — it does command authorization and accounting in ways RADIUS does not. But the protocol is also the source of credential storage problems most network teams have never properly solved.
Every Cisco device with TACACS+ has the line `tacacs-server key <secret>` (or `tacacs server SOMENAME key 7 <obfuscated>`). The secret protects the AAA channel — and ends up in every config backup, every paste-bin, every screenshot. Most operators have never rotated theirs. Cisco type 7 obfuscation is reversible in seconds.
Best-practice AAA configurations include local fallback for when the TACACS+ server is unreachable. The local user typically has a static password that nobody rotates because the fallback path is rarely exercised. A network outage that kills TACACS+ reachability is exactly when an attacker would want to hit those fallback credentials.
When an engineer leaves, removing them from TACACS+ is one step. Removing them from the IdP backing TACACS+ (often Active Directory) is another. Removing local fallback users from device configs is a third — and most teams skip it. Attribution gaps follow.
TACACS+ accounting captures every command an engineer typed. It does not capture the device's response. For a real audit question — "what config was applied," "what diagnostic output did the engineer see" — TACACS+ logs alone are insufficient.
Innovexus does three things to your TACACS+ environment. Vaults the shared secret and the local fallback credentials so they never live in human-readable form on a device or in a Git repo. Brokers every device session through the per-tenant pod with hardware-rooted attribution at the platform. And captures the full session — including device responses — alongside the TACACS+ command log.
The TACACS+ shared key lives in the AES-256 vault, never in a config repo. Rotation is automated on schedule (default 24 hours). When the vault rotates, the new secret is pushed to the device via the per-tenant pod and to the TACACS+ server simultaneously — atomic update, no service window.
The local-user fallback credentials on every device go into the vault. They rotate on the same schedule as the shared secret. Engineers never see or possess them; if TACACS+ goes down and fallback is needed, the credential broker provides one-time access through the emergency-access workflow with full audit.
Engineers authenticate to Innovexus with a FIDO2 hardware key. The pod opens the SSH session to the device, which authenticates against TACACS+ using the role-mapped account. The audit chain is: hardware key → Innovexus identity → TACACS+ user → device session. Attribution survives even if the TACACS+ user is shared.
The pod records the complete session video — both engineer input and device output. TACACS+ command-level accounting still happens at the device; both logs are consolidated in the Innovexus audit trail with the session video. One place to look during incident review.
No replacement of your existing TACACS+ server. Cisco ISE remains the AAA decision point for command authorization. The legacy ACS install nobody wants to migrate stays. Innovexus sits at the credential and session layer, not the AAA decision layer.
Most teams have TACACS+ secrets vaulted and sessions brokered within 1–2 days. Here's the actual sequence.
Pull the current TACACS+ shared key from one device per group (most fleets have 1–3 distinct keys, not one per device). Pull the local fallback users from a sample of devices. These go into the vault.
Per-tenant pod provisions in your region. Pod outbound IP is allowlisted on devices for SSH; pod is reachable from the TACACS+ server for shared-secret distribution.
On the first rotation, the vault generates a new shared secret. The pod pushes it to the TACACS+ server (Cisco ISE API or SSH) and to every device simultaneously. Existing sessions stay open; new sessions use the new secret. Rotate again on the configured schedule (default daily).
For each device, the existing local fallback user's password is replaced by a vault-generated value. Engineers cannot retrieve it; the emergency-access workflow allows one-time retrieval with elevated approval and full audit.
Engineers connect to devices through the Innovexus pod. TACACS+ AAA continues at the device level; Innovexus adds hardware-rooted identity, full session video, and atomic credential lifecycle on top.
Several products and patterns address parts of this. Honest take on each.
Cisco ISE is the right tool for the AAA decision (which user, which command, which device). It does not address shared-secret rotation, local fallback credential rotation, or full session recording. Innovexus runs alongside ISE — they solve different layers.
CyberArk's privileged session manager handles vaulting and session recording for network devices. Capability parity is real for the recording feature itself. Cost is materially higher (typically $30K+/yr starting) and deployment is partner-led. Best fit when an organisation already runs CyberArk Vault enterprise-wide.
Most network teams have a written policy that says "rotate TACACS+ shared secrets annually." In practice this happens once when a security audit forces it, and never again. Manual rotation does not survive contact with operational reality on a fleet of more than 50 devices.
Vault can store the TACACS+ shared secret and rotate it on schedule. It does not broker SSH sessions to network devices, record them, or tie identity to a hardware key. For pure secret-storage with no session layer, Vault works. For the integrated workflow, Innovexus is purpose-built.
Direct answers — written so each passage stands alone for AI-engine citation.
No. Innovexus does not replace the AAA decision point. ISE, Cisco ACS, or open-source TACACS+ continues to handle command authorization and accounting at the device level. Innovexus adds the credential vaulting layer (rotating shared secrets and fallback credentials), the session brokering layer (hardware-rooted identity, full session recording), and the unified audit. The two systems are complementary.
On rotation, the vault generates the new secret and pushes it to the TACACS+ server first (which now accepts both old and new keys for a brief window via secondary-key support — Cisco ISE supports this natively). Then the pod pushes the new secret to each device. Existing engineer sessions remain authenticated through the prior secret until they close; new sessions use the new secret. After all devices are confirmed updated, the secondary-key window closes. Total rotation time across a 500-device fleet is typically 5–15 minutes; no service interruption.
The vault tracks rotation state per device. Unreachable devices stay on the prior secret; the pod retries on the next rotation cycle. Devices that have been unreachable for over 24 hours raise a NOC alert so the operator can investigate. The TACACS+ server keeps the prior key in its secondary-key window until all devices are confirmed updated.
No. The shared secret is generated inside the vault and pushed directly to the TACACS+ server and the devices. Engineers never retrieve or view it. The emergency-access workflow allows a vault administrator to retrieve a current secret with multi-party approval and a fully audited retrieval event — but routine operations never require seeing the secret.
Yes. TACACS+ is implemented by Juniper, Arista, FortiGate, Palo Alto, HPE/Aruba, Extreme, and others. The protocol is standardised in RFC 8907. Innovexus's shared-secret rotation and session brokering work across any TACACS+-capable device. The only vendor-specific work is the SSH command syntax for pushing the new shared secret, which is a per-vendor template the pod ships with.
Cisco DNA Center has device credential management as a feature for Cisco-only environments operating under DNAC orchestration. It rotates SNMP and CLI credentials, pushes them to managed devices. Different scope: DNAC is a full network management platform; Innovexus is privileged access focused. For mixed-vendor environments or teams that don't run DNAC, Innovexus fits more naturally. For pure-Cisco DNAC-managed fleets, you may already have credential rotation covered and Innovexus adds session recording, vaulting of TACACS+ shared keys (which DNAC doesn't handle), and unified PAM/NOC/SOC.
Pull your current TACACS+ shared key during the trial, vault it, set rotation. Brokered sessions and full recording come along for the ride.