Security

OpenBoxes Lift is built with security at every layer. From data isolation to encryption to infrastructure hardening, we take a defense-in-depth approach to protecting your supply chain data.

Data Isolation#

Every Lift tenant's data is isolated from all other tenants. The level of isolation depends on your plan.

Shared Tier#

On the Shared tier, your data lives in its own dedicated database schema. This means:

Your tables and data are completely separate from other tenants
No tenant can query or access another tenant's schema
Database-level access controls enforce schema boundaries
Shared infrastructure (database server) keeps costs low while maintaining strict separation

Dedicated Tier#

[Dedicated]

On the Dedicated tier, your data lives on a dedicated database instance:

Your own database server, not shared with anyone
Full performance isolation — other tenants cannot affect your query performance
Independent backup and recovery
The same weekly maintenance window as every plan (Sunday 02:00--04:00 US Pacific, announced on the status page)

Enterprise Tier#

[Enterprise]

Enterprise agreements include everything in Dedicated, on infrastructure sized above it:

Its own server (4 vCPU / 16 GB) with guaranteed CPU and memory
Separate Kubernetes namespace with network-level isolation
Its own SSD-backed database instance
Backups every 6 hours, kept 90 days, with copies in a second region

Encryption#

In Transit#

All data transmitted to and from Lift is encrypted using TLS 1.2 or higher:

Portal (app.openboxes.cloud) — HTTPS enforced
OpenBoxes instances (*.openboxes.cloud) — HTTPS enforced
Authentication (auth.openboxes.cloud) — HTTPS enforced
Internal service traffic stays on the private cluster network and never crosses the public internet

HTTP requests are automatically redirected to HTTPS. There is no way to access Lift over an unencrypted connection.

At Rest#

All stored data is encrypted at rest:

Data Type	Encryption
Database storage	AES-256 (Google Cloud managed keys)
Backups	AES-256 (Google Cloud managed keys)
File uploads	AES-256 (Google Cloud managed keys)
Secrets and credentials	Encrypted Kubernetes Secrets

[Enterprise] Customer-managed encryption keys (CMEK) are not part of any plan today. Organizations with key-management requirements can raise them as part of an Enterprise agreement — contact sales@openboxes.cloud.

Access Controls#

Authentication#

All access to Lift is authenticated through Keycloak, our identity management system:

Passwords are hashed using industry-standard algorithms (bcrypt)
Multi-factor authentication (MFA) is available on all plans
Account lockout after repeated failed login attempts
Session tokens expire after inactivity

Sign in with Google, Microsoft, or GitHub is available for individual accounts. Organization-managed SSO (SAML / your own identity provider) is not available on any plan today; organizations that require it can discuss it as part of an Enterprise agreement. See Single Sign-On for how platform sign-on works.

Role-Based Access#

The Lift portal uses role-based access control (RBAC):

Role	Capabilities
Owner	The account holder — full access to every portal feature including billing, backups and restores, account closure, and user management
Admin	Full administrative access to the portal and the instance
Manager	Manage operations — day-to-day administration without account-level settings
User	Standard access — can launch OpenBoxes and use the portal day to day
Viewer	Read-only access

The Owner is the person who signed up; the other four roles are assigned when you invite someone from the Users page. These roles govern portal access only. OpenBoxes itself has its own, separate role system (Admin, Manager, Browser, Assistant, and so on) for controlling access to supply chain features, managed inside the OpenBoxes application.

IP Allowlisting#

IP allowlisting is not available on Shared or Dedicated. On Enterprise it is part of the agreement, managed by our team on request — it is not a self-serve setting. Contact sales@openboxes.cloud.

Activity Visibility#

Every plan includes two built-in visibility surfaces:

Platform log — 12 months of instance events (sign-ins, backups, imports, health changes), in the portal.
Access Log — the last 30 days of HTTP requests to your instance (who accessed it, when, and what happened; static assets and successful polls of the instance's /api/status health endpoint — which the platform checks every few minutes — are excluded, while a failing health check is still recorded), under Instance > Access Log. Visible to the account owner only.

These are operational visibility tools, not formal audit logs. Comprehensive admin-action audit trails (SIEM-exportable, tamper-evident) are not available on any plan today; organizations with audit requirements can raise them as part of an Enterprise agreement.

Session Replay and Analytics#

The Lift portal uses FullStory session replay and product analytics to help us improve the portal. It is never active on your OpenBoxes instance — only on the portal itself — and credential fields are excluded from capture. You can opt out for your own account at any time under Settings > Profile > Session replay & analytics; turning the toggle off stops session replay immediately for that account.

Infrastructure Security#

Lift runs on Google Cloud Platform (GCP) with the following security measures:

Google Kubernetes Engine (GKE)#

Automatic node updates — Security patches applied automatically by GKE
Namespace isolation — Platform services and each dedicated tenant run in separate namespaces with RBAC
Network policies — Dedicated-tenant namespaces are provisioned with default-deny network policies

Network Security#

Edge protection — Google Cloud's network-level DDoS protections, plus bot protection (Cloudflare Turnstile) and per-IP rate limiting on public endpoints
Ingress controllers — All external traffic routed through hardened nginx ingress with TLS termination
Internal networking — Services communicate over internal cluster networking only
Secrets management — Credentials stored in encrypted Kubernetes Secrets, never in code or config files

Operational Security#

Automated deployments — All changes go through CI/CD pipelines with automated testing
Infrastructure as code — Deployments are defined in version-controlled Helm charts and Kubernetes manifests, applied through CI/CD
Least privilege — Service accounts have minimum necessary permissions
Dependency scanning — Automated checks for known vulnerabilities in dependencies

Compliance#

Current Certifications#

Lift runs on Google Cloud Platform, which maintains the following certifications:

SOC 1, SOC 2, SOC 3
ISO 27001, ISO 27017, ISO 27018
HIPAA (with BAA)
PCI DSS

Lift Platform Compliance#

We are actively working toward platform-level compliance:

Standard	Status
SOC 2 Type II	In progress — no attestation report is available to share yet
HIPAA	Not offered — Lift does not sign Business Associate Agreements, so do not store protected health information on the platform
GDPR	Compliant — data processing agreements available

[Enterprise] Enterprise accounts can request a detailed security questionnaire, penetration test results, and data processing agreements. Contact security@openboxes.cloud.

Incident Response#

In the event of a security incident:

Our monitoring systems detect and alert the on-call team
The incident is triaged and contained
Affected customers are notified within 72 hours (or sooner as required by applicable regulations)
A post-incident report is provided to affected accounts

Reporting Vulnerabilities#

If you discover a security vulnerability in Lift, please report it responsibly to security@openboxes.cloud. We take all reports seriously: we acknowledge every report within one business day and give a meaningful triage response within five business days.

Questions#

For security-related questions or to request documentation for your procurement process, contact us at security@openboxes.cloud.