Origin-bound cryptography
The YubiKey signs challenges that include the exact origin of the site. Phishing pages cannot reproduce that origin, so the key refuses to authenticate to them — no user decision, no override.
A single YubiKey touch is the only credential a NOC engineer ever handles. Innovexus takes that one phishing-resistant authentication and turns it into the front door to your entire network — with the actual device passwords locked inside an AES-256 vault that the user never sees and that rotates on its own.
From the moment you touch your YubiKey to the moment you're connected to a device, every step is designed to keep credentials out of your environment — and out of the reach of attackers.
When a NOC engineer navigates to the Innovexus login page, they enter their username — resolved against either the local user database inside Innovexus or a federated directory via AD/LDAP — and touch the YubiKey plugged into their laptop. Behind the scenes, the browser issues a cryptographic challenge that includes the exact origin of the page. The YubiKey signs the challenge with a private key that never leaves its secure element — a physical chip inside the key that is not addressable by software.
There is no email to type, no code to enter, no push notification to approve, no SMS to intercept. If the origin is wrong by a single character, the key refuses to sign. Phishing stops at the cryptographic layer.
YUBICO
Hardware Key
Username
jmartinez
What the attacker sees
“Phishing page loaded, but the key refused to sign.”
Core Router
Cisco ISR 4451 · 10.0.0.1
Edge Firewall
Palo Alto PA-850 · 10.0.0.2
Dist Switch
Juniper EX4300 · 10.0.0.3
Finance VLAN Switch
Restricted
Exec WiFi Controller
Restricted
Once authenticated, the dashboard presents the inventory of network devices this user is permitted to manage. A NetOps Engineer sees the routers, switches, firewalls, and load balancers in their scope. The HR database router? The executive WiFi controller? Not on the list. Not discoverable. Not reachable.
RBAC is enforced at the API layer, not in the UI — so even an engineer who inspects the network traffic from the dashboard cannot surface devices outside their permissions. The server simply never returns them.
When you click Connect on a device, nothing happens in your browser except a request going out. The Innovexus server receives the request, checks your permissions, and fetches the device's actual credentials from an AES-256-GCM encrypted vault. The vault is keyed by an HSM-backed master key that the application servers cannot read directly.
Credentials are used for the duration of your session and are never rendered to your browser, written to your terminal history, or included in any log the user can read. And every 24 hours, the platform rotates them automatically — generating a fresh credential, pushing it to the device, confirming acceptance, and atomically updating the vault.
Automated Rotation
Every 24 hours by default. Rotation is triggered by the platform, confirmed by the device, and updated atomically in the vault. Failed rotations raise alerts rather than silently drifting.
Credential Vault
AES-256-GCM
Previous credential
Active credential
Rotated every 24 hours · User never sees either value
$ innovexus connect core-router-01
> Authorizing session...
> Resolving credentials from vault...
> Establishing SSH session...
> Connected to Core-Router-01 (10.0.0.1)
core-router-01#
Credentials
••••••••••••••••
The session opens in seconds. A fully interactive terminal, a live NetConf channel, a CLI prompt — whatever the device expects. You run commands, push configs, inspect state, and troubleshoot exactly as you would through any jump host. The difference is that the credential in use was pulled from the vault by the platform, inserted into the protocol stream by the server, and will be forgotten the moment your session ends.
Meanwhile, the device itself is configured with an ACL that only accepts inbound connections from the Innovexus server's IP range. Even if a credential were somehow exposed, it would be unusable from any other origin. Zero-trust at the session layer, zero-knowledge at the human layer.
Every guarantee on this page — the vaulted credentials, the rotating passwords, the zero-trust ACLs — all of it relies on one thing being unphishable: the initial login. That's the job a YubiKey does that nothing else can.
The YubiKey signs challenges that include the exact origin of the site. Phishing pages cannot reproduce that origin, so the key refuses to authenticate to them — no user decision, no override.
Private keys are generated and stored inside a tamper-resistant hardware chip. No malware, no process dump, no memory inspection can extract them. They exist only on the physical device you hold.
SMS, TOTP, and push notifications can all be relayed through an attacker-in-the-middle. A hardware key cannot. The origin check breaks the replay attack at the cryptographic layer.
No cloud service, no cellular signal, no battery. The key signs locally and works in air-gapped environments, during outages, and inside restricted networks where software MFA fails.
The YubiKey At Each Layer
Phase 1 — Authenticate
The YubiKey IS the first factor. A compromised password is worthless without a physical touch on the key.
Phase 2 — Discover
The session token issued after YubiKey auth is bound to your identity. Every RBAC check traces back to that hardware-validated login.
Phase 3 — Broker
The vault will only release credentials for sessions authenticated at AAL3. A software authenticator does not qualify — a YubiKey does.
Phase 4 — Connect
Every command you run inside a device session is attributable to a hardware-backed identity in the audit trail. No shared accounts, no ambiguity.
Every key supports the same core protocols — FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP, OATH-HOTP, Smart card (PIV), and OpenPGP. The FIPS series adds NIST 140-2 validation for federal and regulated workloads.
USB-A + NFC · FIDO Certified
Multi-Factor Authentication (MFA) Security Key and passkey. Connect via USB-A or NFC. FIDO Certified.
USB-C + NFC · FIDO Certified
Multi-Factor Authentication (MFA) Security Key and passkey. Connect via USB-C or NFC. FIDO Certified.
NIST Certification · FIPS 140-2 Validated
The YubiKey 5 FIPS Series is validated under FIPS 140-2 at Overall Level 2 with Physical Security Level 3 — the certification federal agencies, CJIS-regulated organizations, CMMC-compliant defense contractors, and FedRAMP-authorized cloud providers require for hardware-based authenticators.
FIPS 140-2 Level 2
Cryptographic module validation
Physical Security L3
Tamper-evidence and response
NIST 800-63B AAL3
Highest authenticator assurance
FIPS 140-2 validated Multi-Factor Authentication key. Connect via USB-A or NFC. For government and regulated organizations.
FIPS 140-2 validated Multi-Factor Authentication key. Connect via USB-C or NFC. For government and regulated organizations.
FIPS 140-2 validated Multi-Factor Authentication key. USB-C connector, no NFC. Rugged keychain form factor.
FIPS 140-2 validated nano-form-factor key designed to stay in your USB-A port for permanent, always-on hardware authentication.
FIPS 140-2 validated nano-form-factor key designed to stay in your USB-C port for permanent, always-on hardware authentication.
Nano form factor
The "nano" keys are designed to stay seated in your USB port permanently, delivering always-on hardware authentication without a keychain to lose.
Versatile compatibility
Works with Google, Microsoft, identity providers, password managers, and hundreds of other services across Windows, macOS, Chrome OS, Linux, Chrome, and Edge.
Multi-protocol
FIDO2/WebAuthn (hardware-bound passkey), FIDO U2F, Yubico OTP, OATH-TOTP, OATH-HOTP, Smart card (PIV), and OpenPGP — all on one physical key.
Durable and reliable
Resistant to tampering, water, and crushing. No batteries, no network dependency. Securely manufactured in the USA and Sweden.
Start a 5-day free trial or go directly to checkout. Hardware keys can be added to any subscription at purchase time.
Direct answers to the questions most NOC and compliance teams ask first — sized for AI-engine citation.
The zero-knowledge access model means operators never see or handle the passwords for the network devices they manage. When an authorized user opens a session to a router, switch, or firewall through Innovexus, the platform retrieves the current credential from an AES-256-GCM vault, injects it into the session transport, and discards it at session close. Users prove identity with a FIDO2 hardware key at the platform entry point and receive scoped device access through role-based access control — the device credential itself is never displayed, copied, or exportable from the UI. This design closes the two most common credential-exfiltration paths: screenshot capture and offline sharing of plaintext passwords.
Innovexus enforces FIDO2/WebAuthn at the platform entry point. Every user logs in with their username, then completes a hardware-backed challenge by touching a YubiKey or equivalent FIDO2 authenticator. The authenticator signs the challenge with a private key that never leaves the hardware, making the flow phishing-resistant, SIM-swap-resistant, and push-fatigue-resistant. FIPS 140-2 Level 2 YubiKey variants are available for customers with CJIS, PCI DSS 4.0, CMMC Level 2/3, or FedRAMP requirements. All authentication events are bound to the hardware identity and written to the tenant audit trail, producing the attributable chain of custody that SOC 2 and NIST SP 800-63B AAL3 auditors require.
Device credentials in Innovexus are stored in an AES-256-GCM envelope-encrypted vault backed by HSM-protected master keys. Automated rotation occurs every 24 hours with atomic commit semantics: the new credential is pushed to the device, verified with a live test connection, and only then does the vault entry cut over. Rotation failures trigger alerting so the NOC can intervene before the device drifts out of the managed identity. Every rotation event is written to the tenant audit trail with the identity that approved the policy, the device affected, and the timestamp. Customers requiring CJIS or PCI DSS evidence can export the rotation log directly without building a custom pipeline.
Innovexus manages any network device that supports SSH, console, SNMP, or NETCONF — the standard management-plane surface for Cisco, Arista, Juniper, Fortinet, Palo Alto, Aruba, MikroTik, Ubiquiti, and most enterprise-grade hardware. IP address management, configuration backup with drift detection, and session recording apply uniformly across vendors. The managed fleet is secured with IP-locked pod sessions — devices only accept management-plane connections from the Innovexus server address range, which eliminates the lateral-movement path used by most post-compromise attackers. Bring-your-own-PKI lets customers import existing Root or Intermediate CAs so machine identities on imported devices stay valid during migration.