INNOVEXUS
Trust Center · Security

Security architecture.Public summary. Detailed report under NDA.

The summary below is the public-facing description of how Innovexus is built. The detailed security whitepaper, the most recent third-party penetration-test report, and any SOC 2-style evidence package are available on request under mutual NDA via the trust mailbox.

§ 01 / Public summary

Per-tenant pod architecture

Each Innovexus customer is provisioned a dedicated per-tenant pod on SOC 2 Type II audited Tier 3/4 hosting infrastructure. Pods are isolated at the compute, storage, and network levels — not logical multi-tenancy. The pod hosts the credential vault, session broker, audit chain, and customer identity surface for that customer alone.

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 on Professional and Enterprise tiers. 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. Master keys held in an HSM-backed boundary (AWS CloudHSM with FIPS 140-2 Level 3 modules); key material does not leave the HSM. Vault contents are encrypted with keys that the hosting partner cannot access. Credential rotation is automated (default 24-hour cycle) and atomic with respect to the AAA decision point.

Session brokering

Engineer endpoints connect to Innovexus; the per-tenant pod brokers the SSH, Telnet, console, RDP, or web-admin session to the target. The pod 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 per-tenant pod'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. Certificate authority for ephemeral SSH cert issuance is per-tenant; no cross-tenant CA trust.

Threat model — boundary diagram

The boundary diagram below is a public summary of the trust boundaries the detailed threat model treats in depth. Each boundary is the subject of a specific control set in the full whitepaper.

  • Engineer endpoint ↔ Innovexus pod: TLS 1.3, FIDO2 platform login, role-based device discovery
  • Innovexus pod ↔ vault storage: AES-256-GCM, HSM-backed keys, no plaintext at rest
  • Innovexus pod ↔ target device: SSH/Telnet/console with rotated short-lived credentials, full session recording
  • Innovexus pod ↔ external AI providers (when AI features are active): scoped prompts only, no vault contents, no full session bodies
  • Innovexus operator ↔ customer pod: no plaintext access to vault contents, audited break-glass workflow for emergency support, customer notification on every operator session

Penetration testing

Innovexus engages a third-party penetration testing firm for an annual full- scope test covering the public application surface, authentication and session brokering layers, and the customer pod's audit-chain integrity. The most recent test report and remediation status are available under NDA. Critical and high findings are remediated and re-tested before the report is shared externally.

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.

§ 02 / Available on request

Detailed evidence,on request under NDA.

  • Detailed security whitepaper

    Full architecture document covering control families, key custody specifics, threat model walkthrough, and incident response procedures. ~30-page PDF, shared under mutual NDA.

  • Third-party penetration test report

    Most recent annual pen-test report from our independent testing firm. Includes scope, methodology, findings, and remediation status. Shared under NDA after a brief security review of the requestor.

  • SOC 2-style evidence package

    Innovexus does not independently hold a SOC 2 Type II attestation (see /compliance), but we provide an evidence package mapped to SOC 2 Trust Services Criteria for customer audit purposes — control descriptions, sample evidence, and the inherited hosting attestation references. Shared under NDA.

  • DPA, BAA, and custom data-handling addenda

    Standard DPA template available on request. BAA for HIPAA-scoped deployments handled at the Enterprise tier with [TBD] specific scope per customer use case.

  • Disaster recovery posture

    RPO and RTO targets per tier, multi-region failover topology where applicable. Documented in the detailed whitepaper. Public summary: pod state is replicated to a same-region secondary; cross-region failover is an Enterprise-tier configuration.

Request the detailed package.NDA & response within 1 business day.

NDA REQUIREDSECURITY-REVIEW READY

Email the trust mailbox with a brief description of your use case (a sentence or two — vendor evaluation, security review, etc.). We'll send an NDA template and the requested artifacts within one business day.