Concept
Security And Isolation
How the SCA keeps backup data out of the control plane, isolates tenants, binds identity and leaves enforcement with each tenant appliance.
Overview
The SCA is a control plane. Customer backup data never passes through it, and that separation is the foundation of its security posture: the appliance that brokers provider access is never the appliance that holds or moves protected data.
In the CSP edition every tenant is structurally isolated, and enforcement always sits at the tenant's own appliance. The guarantees below are described by what they mean for a customer; the internal mechanisms behind them are not needed in order to rely on them.
Control Plane Only
Backup data flows directly from the appliance to its repository and never transits the SCA. The SCA carries control-plane metadata and telemetry only — enrollment, health, usage, and the requests that coordinate work — never the contents of any backup.
Data does not pass through the control plane
Because protected data never crosses the SCA, an outage or compromise of the control plane cannot expose or corrupt backup contents. Backups and restores move on the appliance's own data path.
Structural Isolation
In the CSP edition, every tenant runs on its own dedicated, single-tenant appliance with its own database and its own authentication realm. The isolation is structural: it comes from separate appliances, not from filtering a shared store.
One tenant cannot reach another
A tenant's appliance has no access to any other tenant's appliance, so cross-tenant data leakage cannot occur through the platform. Each tenant's data and identity stay within that tenant's own appliance.
Tenant Binding And Default-Deny
In the CSP edition, a tenant can only ever reach their own appliance. The instance is resolved from the authenticated session, never from a value supplied in the request path, so there is no request that can name and reach another tenant's appliance.
Access is default-deny. Only an approved set of tenant actions can reach an appliance at all; anything outside that set is refused rather than forwarded.
The Appliance Enforces
Authorization for a tenant's own users is enforced at that tenant's appliance, not at the SCA. A tenant user acts with the role and permissions defined on their appliance, and the control plane cannot widen them.
Every action is attributable
Every delegated and tenant action is recorded in an audit trail that ties it to a tenant, a user, and a request, so provider and tenant activity can be reviewed after the fact.
Federated Identity
Tenant sign-in can be handled by the SCA directly or federated to the provider's own identity provider, depending on the provider's setup.
Central License Signing
License signing stays central. The SCA never signs a license itself.
Where the SCA needs an entitlement of its own, it activates that entitlement against the central signer, which validates and records the activation; the authority to sign is never delegated to the appliance.
A tenant's quota is tracked operationally as a sub-allocation of the provider's entitlement, rather than issued to the tenant as a separately signed license.
Revocation Levers
Access can be withdrawn quickly, and by both sides of the relationship depending on the operating model:
- A provider can suspend or offboard a tenant. Suspension is re-checked on every request, so it takes effect immediately rather than lasting until a session expires.
- A provider can revoke a tenant's entitlement, revoke tunnel and credential access, and, for a provider-owned appliance, stop the appliance itself.
- In the MSP edition the customer owns the appliance, so the customer can revoke delegation, revoke tunnel or credential access, or revoke the enrollment at any time.
Related Docs