Tenant Isolation

Every tenant in its own context.

Roots HQ is designed so that each business operates in a fully scoped environment — separate data, separate files, separate security policies, and separate reporting. Platform administration does not share the tenant login path.

Roots HQ admin — per-tenant management and isolation. — Admin · per-tenant management

Design intent

The descriptions below reflect how the system is designed and built. They are not a claim of independent certification or a guarantee of any specific compliance posture.

Data isolation

One tenant's data does not touch another's.

Records — contacts, orders, products, campaigns, and reports — are associated with a tenant identifier at creation. Queries that would cross tenant boundaries are not permitted by the data access layer.

All records associated with a tenant identifier
Data access layer enforces tenant scope on queries
No shared tables that cross tenant boundaries without filtering
File storage is scoped per tenant

Data scope — example

Contactstenant A only

Orderstenant A only

Filestenant A only

Security policy isolation

Each tenant controls its own security posture.

GeoIP rules, IP allowlists/blocklists, brute-force thresholds, MFA requirements, and session timeouts are configured per tenant and stored per tenant. One tenant's security settings are invisible to another.

GeoIP, IP rules, and brute-force settings per tenant
MFA and session policy per tenant
Settings stored in tenant-scoped configuration
No tenant can read or affect another's policy

Security config — example

GeoIP: US onlyTenant A

MFA: requiredTenant A

Brute-force: 5 attemptsTenant A

Host resolution

Unknown hosts are rejected at the edge.

Incoming requests are resolved to a tenant by hostname. If a hostname cannot be matched to a valid tenant, the request is rejected before reaching any application logic. This prevents host-header attacks and accidental data exposure.

Every request resolved to a tenant by hostname
Unresolvable hostnames return a rejection
Prevents host-header probing
No default fallback to a shared tenant context

Host resolution — example

shop.example.comTenant A · resolved

unknown.example.comrejected · no match

Platform administration

Platform admin is a separate context from tenants.

The platform master-admin — used for provisioning tenants, system-level configuration, and cross-tenant oversight — operates on a different authentication path. Tenant admins cannot elevate to platform-admin, and platform-admin actions do not run in a tenant context.

Platform-admin has a separate login path
Tenant admins cannot escalate to platform-admin
Platform-admin actions logged separately
No route from tenant context to platform-admin

Admin context — example

Tenant A admintenant context only

Platform adminseparate path, separate log

Back to Security overview →

See how Roots HQ fits your business.

A guided walkthrough of the platform, mapped to how you sell.

See Roots HQ in action Compare with your current tools