Technical Brief: Multi-Tenant Security Architecture — Data Isolation, RBAC, and API Keys

Overview

A multi-tenant IoT platform operates with a fundamental security requirement: every tenant’s data must be invisible to every other tenant. This is not a configuration option or a best practice — it is an architectural property. If data isolation can be violated through a misconfiguration, a shared system with access controls that can fail is the result.

VX-Olympus’s multi-tenant architecture enforces isolation at multiple layers simultaneously. This brief covers the tenant hierarchy model, data isolation mechanisms, role-based access control, API key scoping, white-label deployment security considerations, and audit logging.

The audience for this brief is managed service providers operating VX-Olympus as a multi-customer platform, system integrators building white-label IoT services, and security-conscious enterprise customers deploying VX-Olympus for internal multi-site or multi-division deployments.

Tenant Hierarchy Model

VX-Olympus organizes its data model around a hierarchical tenant structure:

Platform Operator (root): The top-level entity — the managed service provider or enterprise deploying VX-Olympus. Platform Operators can see across all tenants in their instance for administration purposes. They cannot see tenant data unless explicitly granted access.

Customer Tenants: Independent logical units within the platform. Each customer tenant contains its own devices, dashboards, rule chains, users, and API keys. No data crosses tenant boundaries at the storage or API layer.

Sub-tenants / Sites: Customer tenants can create sub-tenants (typically representing sites, facilities, or organizational divisions). Sub-tenant data is visible to the parent tenant, but not to sibling sub-tenants.

This hierarchy enables use cases like:

• A managed service provider whose customers never see each other’s data
• A multi-site enterprise where site managers see only their site, while the VP of Operations sees all sites
• A white-label IoT service where end customers have a fully branded experience with no visibility to the underlying platform or other customers

Data Isolation Architecture

Storage Layer Isolation

Every record in VX-Olympus’s data stores — telemetry readings, device records, rule chains, dashboards, users, API keys — carries a tenant_id field. All queries at the storage layer include a tenant scope filter that is injected server-side, not supplied by the user or API caller.

This means:

• A tenant cannot query another tenant’s data by guessing device IDs or modifying API parameters
• Storage layer isolation is enforced independently of the API layer
• Even if an API authentication bug allowed a cross-tenant request to reach the storage layer, the storage query would return only the requesting tenant’s data

API Layer Isolation

VX-Olympus’s REST API authenticates every request with either a user JWT token or an API key. Both token types carry embedded tenant scope. The API layer validates the requested resource’s tenant_id against the caller’s tenant scope before executing the query. A request for a device that exists in Tenant B, made with a Tenant A credential, returns a 404 — not an authorization error. This prevents tenant enumeration attacks where an attacker learns which tenant IDs exist by probing for 403 vs 404 responses.

Dashboard and UI Isolation

Dashboard data binding in VX-Olympus resolves device and telemetry references through the tenant-scoped API layer. A dashboard widget configured with a device ID from Tenant A will not render data if accessed with a Tenant B session — the API returns 404 for that device in the Tenant B context.

White-label deployments add an additional layer: the platform’s branding, domain name, and UI present only the customer tenant’s identity. Users of the white-labeled service have no indication that the underlying platform is VX-Olympus.

Role-Based Access Control (RBAC)

Role Structure

VX-Olympus defines roles at two levels:

Platform-level roles (assigned to Platform Operator users):

• System Administrator: Full access to platform configuration, tenant management, and billing
• Support Administrator: Read access to all tenants for support purposes; cannot modify tenant data

Tenant-level roles (assigned within a tenant):

• Tenant Administrator: Full access within the tenant — create/modify/delete devices, dashboards, rule chains, users, API keys
• Operator: Read/write access to devices and dashboards; cannot modify users or rule chains
• Viewer: Read-only access to dashboards and device status; cannot see raw telemetry history or rule chain configurations
• Device Manager: Can add/modify/remove devices and gateway configurations; cannot access dashboards or user management
• Custom Role: Tenant Administrators can define custom roles with granular permission sets

Permission Granularity

RBAC in VX-Olympus applies permissions at the resource type level:

Permissions can be restricted to specific device groups, sites (sub-tenants), or dashboard collections within a tenant. An Operator role scoped to a specific site sub-tenant sees only that site’s devices and dashboards.

Multi-Site Role Assignment

For enterprise deployments with multiple site sub-tenants, RBAC supports role assignments that span sub-tenant boundaries:

• Site Manager: Operator role scoped to a specific sub-tenant — sees one site
• District Manager: Operator role scoped to a sub-tenant group — sees all sites in their district
• VP Operations: Tenant Administrator scoped to the parent tenant — sees all sites
• Maintenance Tech: Device Manager role scoped to specific device groups — sees assigned equipment across all sites

This hierarchy maps directly to real operational org structures without requiring multiple platform accounts.

API Key Management

Key Scoping

API keys in VX-Olympus are scoped at creation time:

• Tenant scope: The key can access resources within its tenant only (inherited tenant isolation)
• Permission scope: The key carries a permission set (equivalent to a role) — read-only keys cannot modify data even if compromised
• Resource scope (optional): Keys can be restricted to specific device groups, endpoints, or data types — a key used for a specific integration can be limited to the resources that integration needs

Key Rotation

VX-Olympus supports key rotation without service interruption:

1. Create a new key with the same scope as the existing key
2. Update the integration to use the new key
3. Revoke the old key

Both keys are valid during the transition window. A revoked key returns 401 immediately on the next request — there is no grace period.

Key Audit Trail

Every API request authenticated with a key is logged with: timestamp, key ID (not the key value), action performed, resource accessed, source IP address, and response status. This audit log is available to Tenant Administrators for their tenant’s keys and to System Administrators for all keys.

Authentication and Session Security

User Authentication

VX-Olympus supports multiple authentication methods:

• Username/password: With configurable password policy (complexity, minimum length, rotation period)
• SSO/SAML 2.0: Enterprise SSO integration with identity providers (Active Directory, Okta, Azure AD, Google Workspace). Users authenticate through their corporate IdP; VX-Olympus validates the SAML assertion and issues a session token
• TOTP MFA: Two-factor authentication using authenticator apps. Can be required for specific roles (System Administrators, Tenant Administrators)

Session Management

JWT tokens issued on successful authentication carry an expiration time (configurable: default 24 hours for regular sessions, 1 hour for administrative sessions). Refresh tokens allow session extension without requiring re-authentication. Token revocation is immediate upon logout or administrative invalidation.

Failed login policy: Configurable account lockout after N failed attempts (default: 5). Lockout duration configurable. Locked accounts require administrative unlock or a time-based reset.

Audit Logging

VX-Olympus maintains an audit log of security-relevant events for each tenant:

The audit log is:

• ==positive:Immutable: Existing log entries cannot be modified or deleted by any user including System Administrators==
• Tenant-scoped: Tenant Administrators see their tenant’s log; System Administrators can see all logs
• Exportable: Logs can be exported to CSV or via API for external SIEM integration
• Retained: Minimum 1-year retention; configurable for longer retention periods in regulated deployments

White-Label Deployment Security

White-label deployments run VX-Olympus under a custom domain, with custom branding, presenting the platform as the MSP’s own product. Security considerations specific to white-label deployments:

Custom domain TLS: White-label deployments use the MSP’s domain (e.g., monitoring.acme-services.com) with TLS certificates issued for that domain. VX-Olympus manages TLS termination. The VX-Olympus domain never appears in customer-facing URLs.

Email and notification branding: Alert emails, user invitation emails, and SMS notifications use the MSP’s sender identity. Customers receive alerts from “Acme Monitoring System” — not from VX-Olympus. The underlying platform is not disclosed.

API namespace isolation: APIs served at the custom domain expose only the tenant’s resources. There is no path or parameter that reveals the existence of other tenants or the VX-Olympus platform structure.

Subdomain customer isolation: For MSPs who provision sub-domains per customer (e.g., customer-a.monitoring.acme.com), each subdomain maps to a specific tenant. A user logging into one customer’s subdomain has no navigational path to another customer’s subdomain.

Penetration Testing and Security Posture

VX-Olympus cloud deployments undergo periodic third-party penetration testing. The test scope includes:

• Tenant isolation boundary testing (cross-tenant data access attempts)
• API authentication bypass testing
• Injection attack testing (SQL injection, XSS, CSRF)
• Privilege escalation testing (attempting to access resources beyond a role’s permission set)

On-premises deployments of VX-Olympus carry the same security architecture as cloud deployments. The customer is responsible for the network security of the deployment environment, but the application-layer security model (tenant isolation, RBAC, API scoping) operates identically in both deployment modes.

Conclusion

Multi-tenant security in IoT platforms requires more than access controls on a shared database. It requires isolation enforced at every layer — storage queries, API responses, dashboard rendering, notification delivery, and audit trails — so that no code path, misconfiguration, or compromised credential can cause one tenant’s data to be visible to another.

VX-Olympus’s architecture enforces tenant isolation at the storage layer, not just at the API layer. RBAC maps to the hierarchical organizational structures that real operations teams use. API keys are scoped at creation, audited at every use, and rotatable without service disruption. The audit log captures every security-relevant event and retains it for compliance review.

For managed service providers building multi-customer IoT services on VX-Olympus, these properties are the foundation that makes the platform trustworthy for customer deployments where data confidentiality and access control are non-negotiable requirements.

Talk to our team about multi-tenant deployment architecture for your VX-Olympus instance.