Innovexus is the TACACS+ and RADIUS AAA server your switches and routers point to — with FIDO2 hardware authentication, a centralised policy decision point, and a signed audit chain from the hardware tap to the CLI prompt. The device never has to understand WebAuthn or PIV; the platform does, and it terminates the AAA exchange itself. Vendor-agnostic. NIST 800-207 aligned. Phishing-resistant on day one. Replaces ISE, ACS, and FreeRADIUS for device-admin AAA.
Every Zero Trust framework — NIST 800-207 in particular — assumes the policy decision point lives in a centralised, intelligent controller. A 1990s-era TACACS+/RADIUS server bolted onto a switch fleet does not meet that bar. Standard AAA servers also have no idea what FIDO2 is.
A Cisco IOS, NX-OS, or Juniper Junos device has no idea how to evaluate a WebAuthn assertion or validate a PIV certificate from an SSH client. FIDO2 was published in 2018; the AAA stack on a Catalyst 9000 was designed in the era of TACACS+/RADIUS shared secrets. The protocols don't bridge — unless something modern terminates the AAA conversation on behalf of the device.
Every credential that authenticates against a vanilla TACACS+ or RADIUS server is a credential that can be phished, replayed, or stolen via a man-in-the-middle. NIST SP 800-63B AAL3 explicitly requires hardware-backed authentication. ISE, FreeRADIUS, and OSS TACACS+ on their own do not meet that bar.
NIST SP 800-207 is explicit: the Policy Decision Point (PDP) belongs in a centralised, intelligent controller — not on the asset being protected or in a flat AAA server that just compares passwords. When the AAA server has no awareness of the engineer's hardware-rooted identity or current organisational context, the audit chain is fragmented and the architecture is structurally non-Zero-Trust.
Some vendors expose modern auth proxies (Cisco DUO, vendor-specific WebAuthn agents, etc.) — but none of them work across a multi-vendor fleet, and most don't cover devices more than five years old. A working retrofit requires the same architectural lift on every vendor, every model, every firmware version. That is not a programme; it is a tax.
Innovexus runs the policy decision in a centralised, identity-aware control plane — the platform — and terminates the TACACS+ / RADIUS exchange in the per-tenant pod. Your devices point `tacacs-server host` / `radius-server host` at the pod. The pod is the AAA server: it authenticates the brokered session, authorises commands, and emits accounting, with every decision tied back to a FIDO2 hardware tap. ISE / ACS / FreeRADIUS are no longer in the path for device-admin AAA.
The per-tenant pod runs a hardened TACACS+ (RFC 8907) and RADIUS (RFC 2865) server. Network devices target it directly. Authentication, per-command authorization (TACACS+), session attributes (RADIUS), and accounting are all produced by Innovexus — not a third-party box behind it.
WebAuthn and PIV evaluation happen in the Innovexus control plane — the layer that's actually equipped to handle them. By the time the device sends its TACACS+/RADIUS request to the pod, the engineer's identity has already been hardware-attested. The pod's AAA decision is informed by that attested identity, not a raw password.
WebAuthn handles "proof of presence" (something you have plus biometric). PIV certificate signing on the YubiKey handles "proof of hardware" (a non-extractable hardware-bound RSA/ECC key). Both must succeed before a session is authorised. Phishing a single factor is insufficient.
Device-side AAA configuration accepts TACACS+/RADIUS only from the per-tenant pod's outbound IP, enforced via ACL on the management interface or VRF. A leaked shared secret used from anywhere else is unusable. The pod is also the only authorised SSH/Telnet/console source.
A 1995-vintage IOS switch, a 2018 Junos MX, a FortiGate firewall, an Arista 7280R, an HPE/Aruba CX, an Extreme EXOS box — all point at the same TACACS+/RADIUS endpoint (the pod) and benefit from the same identity layer. No per-vendor MFA proxy. No per-vendor agent on the device.
The platform is the Policy Decision Point. The per-tenant pod — which is also the AAA server — is the Policy Enforcement Point boundary. The PDP and PEP are explicitly separated. The audit chain is signed, hash-chained, and tamper-evident across both. Every privileged session is authenticated, authorised, and logged through a centralised intelligent controller.
The signed proof of FIDO2 + PIV becomes an Innovexus-issued JWT. The pod's AAA service uses that JWT to authorise the TACACS+/RADIUS ACCEPT and to scope per-command authorization. Every step is cryptographically verifiable; an auditor can reconstruct the full path from a single hardware tap to a specific keystroke at a specific device at a specific time.
The six steps below are what happens in production when an engineer authenticates and lands in a session. Steps 1–3, 5, and 6 are shipped today. Step 4 (full PIV hardware attestation via bridge-agent) is in active development — Phase 8 — and labelled accordingly throughout the platform.
Engineer opens innovexus.io/dashboard. The platform serves a WebAuthn challenge. Engineer taps their YubiKey-class hardware key. The browser returns a signed FIDO2 assertion. The platform validates against the registered credential set scoped to the engineer's organisation. Status: shipped.
On successful WebAuthn validation, the platform issues a JWT bound to the engineer's organisation, role, and scope. This token is the authority for any subsequent privileged action — vault retrieval, device session, configuration change. Status: shipped.
Engineer clicks into a device they're authorised to reach. The platform consults RBAC, validates the request against the device's allowed-source list (the per-tenant pod), and prepares the brokered connection. Status: shipped.
The bridge-agent reaches into the engineer's YubiKey PIV slot, signs a platform-issued challenge using the non-extractable hardware-bound key, and returns the signed assertion to the platform. Combined with the WebAuthn proof from step 1, this constitutes the dual-trust validation. Status: in development — Phase 8. Until shipped, FIDO2 alone is the entry-point factor.
The per-tenant pod opens SSH/Telnet/console to the device. The device sends its TACACS+ (or RADIUS) authentication request back to the pod — the pod is its configured AAA server. The pod validates the JWT context, returns ACCEPT, and proceeds with per-command authorization (TACACS+) or session attributes (RADIUS). Status: shipped.
Recording starts at session open. The signed audit record links: hardware key → WebAuthn assertion → platform JWT → pod identity → AAA decisions (auth, authz, accounting) → device session ID → keystroke timeline. Single chain, no two systems to reconcile. Status: shipped.
Several products and patterns address parts of the Zero Trust network access problem. Honest read on where Innovexus's integrated AAA + IAP fits and where another tool is the better choice.
ISE handles AAA, DUO adds MFA for Cisco environments. Strong combo if the entire fleet is Cisco and you're willing to license both. Trade-off: doesn't cover Juniper, Arista, Fortinet, or any non-Cisco device; the per-vendor MFA proxies don't aggregate into a single audit trail; and you're running two products that have to stay in sync. Innovexus collapses the AAA server and the identity-aware MFA layer into one and works across multi-vendor fleets natively.
A self-hosted FreeRADIUS or open-source TACACS+ server does the AAA decision. Operationally workable for small fleets; widely deployed. No FIDO2, no signed audit chain, no session recording, no integrated credential vault. The architectural Zero Trust pieces (PDP separation, centralised attested identity) require additional tooling on top. Innovexus replaces the AAA server with one that has those built in.
CyberArk PSM brokers privileged sessions with hardware-rooted MFA at the Vault — but does not act as the device's TACACS+/RADIUS server. You still need ISE or equivalent behind it. Cost is materially higher (typically $30K+/yr starting) and deployment is partner-led over 6–12 weeks. Best fit when an organisation already runs CyberArk Vault enterprise-wide.
A jump host with PAM library + custom WebAuthn integration + a self-managed FreeRADIUS box is achievable for a 50-device fleet with one motivated engineer. Falls apart above ~200 devices, lacks the cryptographic audit chain, and has no maintainable upgrade path. Most teams that adopt this end up replacing it within two years.
These products excel at Zero Trust for HTTP applications and modern cloud-native infrastructure. They are weaker on legacy network devices that speak only SSH/Telnet/console with TACACS+/RADIUS — they don't terminate those AAA protocols at all. Innovexus is purpose-built for that legacy-network-device boundary. Many teams run both — Cloudflare Access for the web stack, Innovexus for the network device fleet.
Direct answers to the questions teams ask when evaluating this workflow.
It is the server. The per-tenant pod runs a hardened TACACS+ (RFC 8907) and RADIUS (RFC 2865) implementation. Network devices set `tacacs-server host <pod-ip>` / `radius-server host <pod-ip>` and authenticate directly against the pod. There is no ISE / ACS / FreeRADIUS behind it for device-admin AAA — Innovexus replaces that role. What Innovexus adds on top of a plain AAA server is the FIDO2-rooted identity attestation, the signed audit chain, the credential vault, full session recording, and the NIST 800-207 PDP/PEP separation.
An IAP architecture means the policy decision (who is allowed in, with which factors, against which target) happens at a centralised, identity-aware control plane — not at the device being protected. NIST SP 800-207 frames Zero Trust around this pattern: the Policy Decision Point lives in an intelligent controller, the Policy Enforcement Point sits in front of the protected resource, and the two are explicitly separated. Innovexus is the IAP for your network device fleet, and because it is also the AAA server, the PDP-to-PEP path is a single integrated system rather than two products you have to keep in sync.
800-207 calls for a centralised PDP that evaluates every access request against the full identity context (user, hardware, role, scope, time, source). Innovexus does that evaluation in the platform; the per-tenant pod is the PEP and also the AAA server enforcing the decision at the device boundary. Every decision is logged, signed, and tamper-evident. Several specific 800-207 controls (PE-AC.1, PE-AC.4, ZTA-3) map directly to features Innovexus already ships. Custom mapping documents are available under NDA via [email protected].
For device-admin AAA (TACACS+ for switch/router CLI access), yes — Innovexus replaces that role. You point your devices' `tacacs-server host` at the pod and decommission the ISE TACACS+ side. ISE may still earn its keep for things Innovexus does not yet do: 802.1X endpoint NAC, posture assessment, dynamic VLAN/ACL assignment for wired/wireless supplicants, profiling. Those are on our roadmap (see below). Most teams run the two side-by-side during transition, then drop ISE's TACACS+ role once they're comfortable.
Three things are explicitly roadmap, not shipped today. (1) 802.1X — port-based network access control with EAP termination at the pod for endpoint supplicants. (2) NAC — endpoint posture assessment, dynamic VLAN / ACL assignment, RADIUS Change-of-Authorization (RFC 5176). (3) Comply-to-Connect — DoD-style posture-gated admission with continuous compliance attestation. All three ride on the AAA foundation already in the pod, which is why they're a sensible roadmap rather than a greenfield build. We will not pretend any of them are shipped before they are.
Shipped today: TACACS+ and RADIUS server (device-admin AAA), FIDO2/WebAuthn at platform login, JWT-mediated AAA decisions, IP-pinned device connectivity (pod is the only allowed source), AES-256 vault with automatic shared-secret rotation, full session recording with cryptographic integrity, RBAC-scoped device discovery, signed audit chain across all of the above. In active development (Phase 8): bridge-agent for YubiKey PIV hardware attestation, completing dual-trust. Roadmap (not shipped): 802.1X, NAC, Comply-to-Connect.
Yes — the dual-trust factor will be configurable per-organisation. Some environments will need it for compliance reasons (FedRAMP, NERC CIP, IEC 62443 highest tiers); others will run on FIDO2-only entry. The roadmap delivers both as policy options. We will not push customers toward the more invasive option than their compliance requirements demand.
Service-account access uses a separate path: vaulted credentials with rotation, scoped to the service account's role, with short-lived bearer tokens issued through the platform API. Service-account AAA still goes through the pod and lands in the same audit chain as human access; it does not require interactive WebAuthn — that's structural, not a security trade-off (a service account has no human present to tap a hardware key). For service accounts that need stronger guarantees, integrating with HashiCorp Vault or AWS IAM via the customer's own infrastructure is the recommended pattern.
A 5-day trial is the fastest way to see the integrated AAA + IAP against your real fleet. Pod deploys in minutes, no card required. We will walk through which components are shipped today, what's in active development, and what's on the roadmap (802.1X, NAC, C2C) on the discovery call so you can plan your Zero Trust path honestly.