Multi-Tenant Utility SaaS Security Architecture
How isolation, authorisation, key management and identity are implemented — mechanism, not posture.
Isolation as an architectural property
This page describes mechanism: how tenant isolation, key management, authorisation and identity are implemented. If you are reviewing smoc.cloud for procurement, compliance or audit sign-off, the evidence and posture you need is on the Security page instead.
A platform that holds operational data for multiple utilities has to treat isolation as an architectural property, not a configuration setting. Every request in smoc.cloud carries a tenant context that is derived from the authenticated identity and enforced below the application layer, so a defect in a feature cannot become a cross-tenant data exposure.
Isolation at every layer.
Tenant data is separated at the platform, the query, the action and the record. Nothing crosses a boundary without an identity, a role and a log entry.
The mechanisms in detail
Eight implementation concerns that together make multi-tenant utility operations safe to run on shared infrastructure.
Tenant context binding
Tenant identity is resolved at authentication and attached to every subsequent operation. Application code cannot widen its own scope, and a request without a resolvable tenant is rejected rather than defaulted.
Row-level authorisation
Access rules are evaluated per record on read and on write, so authorisation does not depend on a query being written correctly. Write paths are constrained as tightly as read paths.
Data partitioning
Tenant data is partitioned so that bulk operations, exports, backups and analytical jobs inherit isolation rather than re-implementing it.
Key and secret management
Credentials for head-ends, carriers, APIs and enterprise systems are held in managed secret storage, scoped per tenant and per integration, never in application configuration or source.
Identity and access model
Custom role-based access control per tenant, with enterprise identity federation, so utility staff, integrators and vendors each see only the surface their role requires.
Boundary and transport controls
Network boundaries, encrypted transport and constrained egress paths between the platform, head-end systems and enterprise integrations.
Audit as a mechanism
Every state change and privileged action emits an immutable record carrying actor, tenant, target and before/after state — the mechanism behind the audit evidence reviewers see.
Isolation under multi-vendor integration
Integrations run per tenant with per-tenant credentials and quotas, so one utility's head-end behaviour cannot affect another's operations.
Reviewing smoc.cloud for procurement, compliance or audit?
The Security page carries the evidence and posture a reviewer signs off: control coverage, audit trail, access model and answers to the questions reviewers ask most.
See your estate in smoc.cloud.
A demo walks through your utility types, your vendors and your compliance obligations — not a generic slide deck.