Sendense Documentation

MSP-Managed Customer SHA

In the MSP edition the customer's own SHA stays the independent hub while SCA provides central estate visibility and a delegated, appliance-enforced operation model.

Documents Home

Concept

MSP-Managed Customer SHA

In the MSP edition the customer's own SHA stays the independent hub while SCA provides central estate visibility and a delegated, appliance-enforced operation model.

ReadyCurrentscamspproviderdelegated-operationstelemetry

Relationship

In an MSP-managed model, the customer SHA remains the hub appliance for the customer environment. SCA sits above independent customer SHAs for estate telemetry and for agreed operations the customer has delegated to the MSP.

MSP operating model

Each customer SHA remains the hub for its own estate. SCA gives the MSP estate-wide visibility from telemetry the SHAs send, and performs operations only where the customer has delegated them.

MSP operating modelMSP PROVIDERCUSTOMER ACUSTOMER BCENTRAL APPLIANCESCAEstate telemetry + oversightHUB APPLIANCECustomer SHARemains the customer hubHUB APPLIANCECustomer SHARemains the customer hubEstate telemetryAgreed operationsEstate telemetryAgreed operations
Estate telemetry (customer SHA to SCA)Customer-delegated operations (SCA to customer SHA)

Customers keep control

Customers retain their own SHA GUI control where their deployment model allows it, and separately grant the MSP a defined set of actions through SCA.

Enrollment

Enrollment can be customer-led or MSP-led depending on the relationship. Either way, the customer SHA confirms the proposed access level locally before enrollment completes.

SHA Remains The Hub

The customer SHA is an independent organization's appliance, not a tenant of the provider. In the MSP edition it remains the hub for that customer's protection, recovery, EBA, SNA, snagent, controller, reporting, and health workflows. The MSP does not take it over.

SCA adds oversight, it does not replace SHA

SCA adds estate visibility and customer-delegated control on top of an independent SHA. It never becomes the hub for the customer environment, and the customer SHA does not become a tenant of the provider.

Estate Visibility

Through SCA, provider staff get central estate visibility across enrolled customer SHAs: fleet health, capacity, alerts, and a read-through view of live detail on demand.

This estate-visibility surface is edition-neutral, so its behavior is described once in the SCA overview and the provider operating models concept rather than restated here.

Enrollment

Enrollment connects a customer SHA to the MSP SCA. It can be customer-led or MSP-led depending on the relationship, and follows a benefit-level sequence:

  • The appliance pairs with the SCA through a short-lived pairing step, then proves a cryptographic device identity that the SCA verifies.
  • Before enrollment completes, the customer SHA shows its administrator the proposed access level and requires explicit local confirmation. The customer can downgrade the proposal, so the effective access level is always customer-set.
  • A provider administrator approves the appliance after reviewing its identity, then the SHA connects outbound over a secure tunnel and sends a periodic heartbeat.
  • Enrollment and connectivity are revocable. Either side can sever the connection, and the provider can revoke a tunnel, a credential, or the enrollment at any time.

MSP-led enrollment is not auto-provisioning

Even when the MSP leads enrollment, the customer SHA is an independent, customer-administered appliance and the local confirmation step is mandatory. Fully provider-driven, auto-approved enrollment of provider-owned appliances is the CSP-provisioned tenant SHA model, not the MSP model.

Delegated Operations

The MSP acts only through operations the customer has granted. The customer sets the provider's access level during the enrollment consent step and can change it afterward from the SHA GUI.

The access levels range from a billing-only level that is limited to usage metering for invoicing and excludes estate visibility, through a read-only estate-visibility level, up to broader operational levels. The default proposed level is read-only estate visibility. Both read-only levels deny every write; backup, restore, and replication actions are available only where the customer grants a broader level or a per-action override.

Sensitive operations additionally require approval and action- and user-scoped step-up re-authentication enforced at the customer SHA. Every delegated operation is idempotent and recorded in an audit trail of tenant, user, and request.

Enforced at the appliance

The approval queue and step-up re-authentication run on the customer SHA, which is the enforcement point. SCA records the request, advisory-checks its cached copy of the grant to keep its interface truthful, and reconciles state; it does not host the approval workflow or perform step-up itself.

Access Control

The delegation boundary is narrow and customer-controlled.

  • MSP actions are limited to the specific operations the customer has delegated. Anything outside the granted level and its per-action overrides is denied.
  • The customer can revoke the delegation, the tunnel or credential access, or the enrollment itself at any time.
  • The customer SHA is the enforcement point for every delegated action. SCA's own grant checks are advisory and exist only to keep its interface accurate.

What It Is Not

  • The customer SHA is not a tenant of the provider. MSP delegation does not make the SHA provider-owned.
  • MSP-led enrollment is not automated provider provisioning. Fully provider-driven, auto-approved enrollment of provider-owned appliances is the CSP-provisioned tenant SHA model.
  • SCA does not host the approval workflow or perform step-up re-authentication. Those run on the customer SHA; SCA records, advisory-checks, and reconciles.
  • The MSP edition has no tenant proxy, resale pricing, or capacity sub-allocation. Those are CSP capabilities.

Related Docs