Security
Designed for tenant-level isolation.
Each tenant's data is scoped to that tenant, with its own geographic and IP access rules. Two-factor login is available to any user. Platform administration runs on a completely separate identity from tenant operations.
Multi-tenant security architecture
The architecture is designed so that each tenant's data and settings are isolated from every other tenant, with per-tenant access policies for geography and IP allow-listing. One deliberate exception: an address auto-blocked for brute-force login attempts is blocked platform-wide, not only for the tenant it targeted. The features below describe how the system is built — not a claim of certification or compliance.
Tenant isolation
Each tenant's data scoped to that tenant.
The multi-tenant architecture is designed so that one tenant cannot access another's data, files, or settings. Tenant context is enforced at the request level — requests without a valid tenant context are rejected.
- Data scoped to the tenant at the database level
- Files and media scoped per tenant
- Unknown or unresolvable hosts are rejected
- Platform admin is a separate security context, not a super-tenant
Access control
Per-tenant GeoIP and IP allow-listing, plus platform-wide brute-force blocking.
Each tenant sets its own geographic restrictions and its own allow-list of admin IP addresses — one tenant's rules have no effect on another's. Failed-login lockout is tracked per account, and an address responsible for heavy failed-login volume is blocked automatically across the whole platform, not only for the tenant it targeted.
- Per-tenant GeoIP restrictions
- Per-tenant admin IP allow-list, with a guard against locking out the last allowed address
- Per-account lockout after repeated failed logins
- Automatic IP blocking after heavy failed-login volume — enforced platform-wide
Authentication
Two-factor login, and a separate path for platform admins.
Any user can turn on two-factor authentication (TOTP) for their own account; once enabled, it's checked at every login. Resetting or changing a password immediately signs that account out everywhere. The platform's own support administrators sign in through a completely separate identity — that login cannot open a tenant's workspace as if it were a member.
- Two-factor authentication (TOTP), available to any user and enforced at login once turned on
- Password reset or change signs out all of that account's active sessions
- Platform support administrators use a separate login, not tenant membership
- A login is only ever valid for the workspace it belongs to
Audit & credentials
Audit logging. Encrypted integration credentials.
Sign-in failures, staff changes, password resets, two-factor changes, IP blocks and unlocks, security-setting changes, and discount changes are all written to an audit trail. A settings entry records which setting changed — never its value. Integration credentials — API keys, tokens, and payment secrets — are encrypted at rest, per tenant.
- Audit trail covers sign-in failures, staff changes, password resets, 2FA changes, IP blocks/unlocks, security settings, and discounts
- Settings entries record what changed, never the value
- Integration and payment credentials encrypted at rest, per tenant
- Payment webhook signatures verified on receipt
- Role-based access controls who can take which actions
Root here. Branch everywhere.
Tell us about your business.
Roots HQ is currently welcoming selected businesses into the beta. Every business applies the same way: tell us where you sell and what takes too much of your time — that is how we learn whether Roots HQ fits, and where your setup should start.
What the application is for
- Tell us how you sell, not why you deserve it
- Your application is reviewed by our team
- Standard onboarding is included with every Roots HQ plan.