Security architecture.Stated in full, in public.

Self-hosted appliance architecture

Innovexus is a single self-contained appliance you run on your own infrastructure — compute, storage, and network are entirely yours, not shared with anyone. The appliance hosts the credential vault, session broker, audit chain, and identity surface for your organisation. There is no vendor control plane and no remote-access path: Innovexus cannot reach into, administer, or observe your deployment. The appliance does make a small set of outbound requests to innovexus.io — threat-intelligence feed pulls and update checks — and every one of them is listed below, because a security product that is vague about its own network behaviour has not earned a place on yours.

Outbound connections — the exact list

With feeds enabled, the appliance makes pull-only HTTPS requests to innovexus.io. This is the complete list:

• CVE catalogue sync — GET /hub-api/api/cve-hub/sync
• CISA KEV catalogue — GET /hub-api/api/cve-hub/kev
• IOC / threat-IP feed — GET /hub-api/api/ioc-hub/feed, /api/ioc-hub/sync
• Appliance update check — GET /hub-api/api/hub/release/latest
• Bridge-agent update check & download — GET /hub-api/api/hub/agent-release/latest, …/download

Each request authenticates with a per-appliance API key minted at activation (the hub refuses pulls without one) and carries an appliance identifier plus ordinary HTTP metadata — source IP and user agent. These endpoints return data; they do not accept it. Your configuration, credentials, AAA decisions, device inventory, logs, and session recordings are never transmitted: the appliance has no endpoint to send them to.

Air-gapped operation is supported. Block outbound HTTPS to innovexus.io at your firewall and AAA, the vault, session brokering, recording, and the audit chain keep running unchanged — the threat-intelligence feeds go stale and appliance updates are side-loaded instead.

Authentication and identity

FIDO2/WebAuthn hardware authentication (YubiKey-class devices) at the platform login. SAML 2.0 and OIDC SSO with any standards-compliant IdP (Okta, Azure AD, JumpCloud, Google Workspace). SCIM 2.0 provisioning. Local-username authentication available as a fallback against organisation-managed databases or AD/LDAP.

Credential vault

AES-256-GCM encryption at rest for all vaulted credentials. The appliance mints its own encryption key on first boot; it never leaves the appliance and is not shared across deployments, so one extracted image cannot decrypt another organisation's vault. Credential rotation is automated (default 24-hour cycle) and atomic with respect to the AAA decision point.

Session brokering

Engineer endpoints connect to the appliance; the appliance brokers the SSH, Telnet, console, RDP, or web-admin session to the target. It is the only authorised source for management connections to enrolled devices (IP allowlisting). Engineers never possess the device-side credential.

Audit chain integrity

Every audit event is hash-chained and signed by the appliance's signing key. Tampering with a session record breaks the signature chain and is detectable on audit. Audit retention default: 90 days for full session video, 7 years for signed audit metadata. Both retention windows are configurable.

Encryption in transit

TLS 1.3 with mutual authentication where supported. SSH protocol versions hardened to current OpenSSH defaults; legacy ciphers disabled. The certificate authority for ephemeral SSH cert issuance is local to your appliance; there is no cross-organisation CA trust.

Threat model — boundary diagram

These are the trust boundaries the appliance is designed around. Each one is the subject of a specific control set described on this page.

• Engineer endpoint ↔ appliance: TLS 1.3, FIDO2 platform login, role-based device discovery
• Appliance ↔ vault storage: AES-256-GCM, per-appliance keys, no plaintext at rest
• Appliance ↔ target device: SSH/Telnet/console with rotated short-lived credentials, full session recording
• Appliance ↔ innovexus.io (feeds & updates): pull-only HTTPS with a per-appliance key — the exact request list above; no customer data crosses this boundary
• Appliance ↔ external AI providers (only when you enable AI features with your own key): scoped prompts only, no vault contents, no full session bodies
• Your administrators ↔ appliance: RBAC with least privilege, audited break-glass workflow, notification on every privileged session — all under your control, with no vendor access

Vulnerability disclosure

We accept responsible vulnerability reports via [email protected]. PGP key available on request. Standard 90-day coordinated disclosure window. We do not pursue legal action against good-faith security researchers following the disclosure policy.