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
  • Configurable maintenance windows

Enterprise Tier

[Enterprise]

On the Enterprise tier, your application runs on dedicated infrastructure with an expanded resource profile:

  • Separate Kubernetes namespace with network-level isolation
  • Dedicated compute resources (CPU, memory), sized above the Dedicated tier
  • Your own dedicated database instance
  • Additional isolation and infrastructure arrangements can be scoped as part of an Enterprise agreement

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 Full access to all portal features including billing, settings, and user management
Admin Administrative access to the instance and team, without billing ownership
User Day-to-day portal access, can launch OpenBoxes

These roles govern portal access. OpenBoxes itself has its own role system for controlling access to supply chain features.

IP Allowlisting

IP allowlisting is not available on any plan today. Organizations that require network-level access restrictions can raise them as part of an Enterprise agreement --- 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.
  • HTTP access log --- the last 30 days of requests to your instance, in the portal.

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.

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 --- target completion Q3 2026
HIPAA Planned --- available for Enterprise accounts
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:

  1. Our monitoring systems detect and alert the on-call team
  2. The incident is triaged and contained
  3. Affected customers are notified within 72 hours (or sooner as required by applicable regulations)
  4. 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 and will respond within 48 hours.

Questions

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