versus{ networks }
Security & Trust

On-Premise Hardening Guide

How to deploy and operate a self-hosted Versus instance securely — and who is responsible for what. When Versus runs in your environment, you operate it: this guide covers the customer-side controls that harden your instance and that a SOC 2 report references as Complementary User Entity Controls.

Shared responsibility

Versus is responsible for building the software securely and shipping signed, verifiable releases. You are responsible for the infrastructure, access, network, and data protection around your instance. A SOC 2 report formalizes this split as Complementary User Entity Controls (CUECs) — the controls this guide helps you implement.

Versus is responsible for…You are responsible for…
Secure development (code review, CI, SAST / dependency / secret scanning)The servers / VMs / cluster the software runs on
Signed, verifiable releases & a tamper-evident build pipelineAccess management & MFA to your instance
Vulnerability management & disclosure for the productNetwork segmentation and firewalling
Product security features (encryption, RBAC, audit, MFA support)Backups, disaster recovery, and monitoring of your data
Secure defaults & this hardening guidanceHost / OS patching and physical security

1 · Choose a deployment model

Versus ships three self-hosted form factors. Harden the one you use:

  • Virtual appliance (OVA / qcow2) — a pre-built, minimized image with the full stack. Fastest to deploy; the OS is already trimmed.
  • Kubernetes / Helm — the versus Helm chart for existing clusters. Use for HA and scale; you own cluster security (RBAC, network policies, secrets).
  • Docker Compose — a single-host install behind a TLS reverse proxy (Caddy). Good for small or lab deployments.
NoteTreat Versus as management-plane infrastructure: it reaches your network devices and holds credentials, so it belongs in your most protected zone.

2 · Host & OS hardening

  • Deploy on a minimal, patched OS; apply a recognized baseline (CIS Benchmark).
  • Enable full-disk encryption (LUKS / BitLocker) on every node and data volume.
  • Run services under dedicated, non-root service accounts with least privilege.
  • Remove/disable unused packages, services, and ports; enable the host firewall.
  • Enforce time synchronization (NTP) — signed dispatch, tokens, and audit timelines depend on accurate clocks.
  • Restrict and log host SSH access (key-based auth, no password login, bastion where possible).

3 · Network segmentation

  • Place Versus in a dedicated management/security VLAN, isolated from user and guest networks.
  • Expose only the HTTPS application port to the users who need the UI/API.
  • Never expose the database, the collector gateway's internal ports, or admin/identity backends to untrusted networks.
  • Apply egress rules: allow only what's needed (managed device IPs, DNS, NTP, and — if online — license/update endpoints).
  • Collectors connect outbound-only (see §11), so no inbound firewall holes are needed to reach devices.

4 · TLS everywhere

  • Terminate TLS at the bundled reverse proxy (Caddy) or your ingress with a valid certificate — internal or public CA.
  • Require TLS 1.2+ with modern ciphers; enable HSTS; automate renewal.
  • Internal service-to-service traffic (collector gateway) already uses bearer-authenticated TLS on 443 — keep those trust materials protected.

5 · Identity & access

  • Versus authenticates through its bundled IdP (Zitadel) with OIDC SSO and mandatory MFA (TOTP). Optionally federate to your corporate IdP.
  • Apply least privilege via RBAC; keep the set of full administrators small.
  • Enforce a strong password and session policy (length, lockout, timeout).
  • Limit who holds host, cluster, and database admin — that's separate from, and more powerful than, application roles.
  • Review access on a schedule and revoke promptly on personnel changes.
CautionImmediately after install, change the default administrator credentials and remove or rotate any seed/bootstrap accounts. This is the single most common on-premise finding.

6 · Secrets & encryption

  • Versus protects stored credentials with envelope encryption (Versus Vault: per-secret data keys wrapped by a master key). Your job is to protect the master / field-encryption key:
    • Store it in a secrets manager or sealed store, never in a plaintext file or committed config.
    • Back it up securely and rotate it on a defined cadence — losing it means losing access to encrypted data.
  • Enable encryption at rest for the database and all persistent volumes.
  • Keep release/signing trust material intact so update verification works (see §8).
  • If required, run Versus with the FIPS mode flag to restrict cryptography to approved algorithms.

7 · Data protection — backups & DR

  • Configure automated, encrypted backups of the database and any object/media storage.
  • Keep at least one off-host / off-site copy; protect backups from deletion (immutability / object-lock).
  • Test restores on a schedule — an untested backup is not a backup — and document your RTO/RPO.
  • Define data retention and secure disposal for backups and logs.

8 · Patching & updates

  • Stay current. Versus releases are signed, and the platform verifies the signature before applying an update — so what you install is authentic and untampered. Keep the pinned release public key in place.
  • Collectors auto-update from a signed release channel (manifest + signature verification + health-check + automatic rollback).
  • Subscribe to security advisories and apply critical patches within your remediation SLA; test in staging where practical.

9 · Logging, monitoring & audit

  • Ship all logs — application, authentication (Zitadel), database, and collector gateway — to your SIEM / log platform, with ≥12-month retention and restricted access.
  • Versus writes a tamper-evident, hash-chained audit trail for sensitive actions (secret access, privileged sessions, configuration changes) — forward and monitor it.
  • Alert on: repeated authentication failures, new privilege grants, MFA changes, configuration changes, and backup failures.
  • Monitor availability (health checks, uptime) and set up on-call for your instance.

10 · Licensing & connectivity

  • Versus supports online activation with a periodic heartbeat, or fully offline / air-gapped licensing (signed license file, no phone-home).
  • For air-gapped installs, Versus operates with no outbound connectivity — nothing is sent to Versus — and updates are applied from signed artifacts you import.
  • If online, restrict egress to only the license/update endpoints.

11 · Collector security

  • Collectors reach your ADCs, firewalls, and network devices from inside your network and connect outbound-only to Versus over a bearer-authenticated TLS channel on 443 — no inbound firewall exceptions to your devices.
  • Device credentials can be resolved locally on the collector (Mode A — a sealed on-prem vault) so they never leave your network; cloud-relayed (Mode B) and external-secret-manager (Mode C) options exist for other trust models.
  • Deploy collectors in the device network segment, under the same host-hardening rules (§2), and keep their sealed vault material protected.

12 · Pre-production hardening checklist

13 · On-premise & SOC 2

Versus's SOC 2 report attests to the service and development/release process Versus operates — secure SDLC, signed releases, and vulnerability management. It does not certify a customer's self-hosted instance, because you operate that. This guide provides the customer-side controls a SOC 2 report references as CUECs.

For an on-premise security review, pair three things: (1) Versus's SOC 2 report (development & release assurance), (2) an independent product penetration test, and (3) this hardening guide plus the shared-responsibility matrix above. Together they cover both halves — the software Versus builds and the environment you operate.

← All docsOpen a support case