Network devices speak protocols designed thirty years ago. They cannot parse a WebAuthn challenge, validate a PIV certificate, or evaluate a Zero Trust policy on their own. Innovexus moves the policy decision off the device entirely — into a centralised, identity-aware control plane that does what 1990s network gear cannot, then brokers the resulting session to the device through a hardened TACACS+ handshake. Vendor-agnostic. NIST 800-207 aligned. Phishing-resistant on day one.
Every Zero Trust framework — NIST 800-207 in particular — assumes the policy decision point lives in a centralised, intelligent controller. Network device firmware does not. The result is a structural gap that legacy AAA cannot close on its own.
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.
Every credential that authenticates against a device-side AAA layer 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. Standard TACACS+ does 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. When a switch evaluates "should this user be allowed in" using only TACACS+ logic, the PDP and PEP are colocated, 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 brokers the resulting authorised session to the device through a hardened TACACS+ handshake. The device never has to understand FIDO2; the platform does. The chain is cryptographically linked from the engineer's physical hardware key all the way to the CLI prompt.
WebAuthn and PIV evaluation happen in the Innovexus control plane — the layer that's actually equipped to handle them. The device only ever sees a brokered SSH session originating from the per-tenant pod. PDP centralised; PEP at the device retains its existing role.
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.
The device-side TACACS+ configuration is hardened to accept brokered sessions only when they originate from the per-tenant Innovexus pod IP. Even if a TACACS+ shared secret leaked, an attacker outside the pod cannot use it. The callback creates a closed loop that legacy AAA on its own does not provide.
A 1995-vintage IOS switch, a 2018 Junos MX, a FortiGate firewall, an Arista 7280R — all benefit from the same architecture. Each device sees a normal SSH or Telnet session from the pod IP. Modern auth happens above; the device stays where it is.
The platform is the Policy Decision Point. Each per-tenant pod is the Policy Enforcement Point boundary. The audit chain is signed, hash-chained, and tamper-evident. Every privileged session is authenticated, authorised, and logged through a centralised intelligent controller — the literal definition NIST 800-207 calls for.
The signed proof of FIDO2 + PIV becomes an Innovexus-issued JWT. The SSH proxy service uses that JWT to authorise the TACACS+ ACCEPT response. Every step in the chain is cryptographically verifiable; an external auditor can reconstruct the full path from a single hardware tap to a specific keystroke at a specific device at a specific time.
The five steps below are what happens in production when an engineer authenticates and lands in a session. Steps 1–3 and 5 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 session token 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 to broker the connection. The vault provides the device-side credential or short-lived ephemeral cert. 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 the SSH/Telnet/console session to the device, using the vaulted credential. Recording starts at session open. The device-side TACACS+ accepts the connection because it originated from the allowlisted pod IP. The signed audit record links: hardware key → WebAuthn assertion → platform JWT → pod identity → device session ID → keystroke timeline. Status: shipped.
Several products and patterns address parts of the Zero Trust network access problem. Honest read on where Innovexus's Identity-Aware Proxy fits and where another tool is the better choice.
ISE handles AAA decisioning and 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 — and the per-vendor MFA proxies don't aggregate into a single audit trail. Innovexus's IAP works across multi-vendor fleets natively.
CyberArk PSM can broker privileged sessions with hardware-rooted MFA at the Vault. Functional parity for the IAP pattern. 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 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. Innovexus's IAP is purpose-built for that legacy-network-device boundary; the cloud Zero Trust products cover a different surface area. 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.
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. The device sees only the brokered session originating from the IAP. 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.
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 per-tenant pod. The decision is logged, signed, and tamper-evident. The PEP — the device — only accepts brokered sessions from the pod, completing the architectural pattern. 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].
Yes. Innovexus does not replace your AAA decision point at the device level. ISE, free open-source TACACS+, or vendor TACACS+ stays where it is. Innovexus adds the Identity-Aware Proxy layer above: hardware-rooted authentication at the platform, dual-trust validation, and the brokered session boundary. The two systems run together — ISE handles the AAA decision at the device; Innovexus handles the identity evidence and session brokering at the platform.
Shipped: FIDO2 / WebAuthn at platform login. IP-locked pod sessions where the device only accepts connections from the per-tenant pod. AES-256 vault for device-side credentials. 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 that accesses the YubiKey PIV slot and signs platform-issued challenges with the hardware-bound key, completing the dual-trust factor design. Until Phase 8 ships, FIDO2 is the entry-point factor, and the architectural pattern (centralised PDP, brokered PEP, signed audit) is already in place.
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 access is logged in the same audit chain as human access but 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 IAP pattern against your real fleet. Pod deploys in minutes, no card required. We will walk through which components are shipped today versus in development on the discovery call so you can plan your Zero Trust roadmap honestly.