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
See how Roots HQ fits your business.
A guided walkthrough of the platform, mapped to how you sell.