Scoping an MSP Identity Security Review Across Customer Tenants

One customer permits an MSP to read identity logs. Another permits account containment after named approval. A third has delegated administrative access that expires next week. A common dashboard can display all three, but it cannot make their operating permissions interchangeable.

Scope an identity review per customer before consolidating its findings. The review needs a customer authorization record, a manifest of identities and delegated permissions, a telemetry map, and an agreed handoff. “All managed tenants” is too imprecise when customers have different access, data handling and response terms.

My KevinBytes identity-coverage article describes a Microsoft Entra evaluation method and its local synthetic correlation limits. The companion query exercise supplies reproducible invented records. I write KevinBytes and am affiliated with TKOResearch. This article defines a review engagement, without claiming a provider pilot or an operated managed security service.

Make the customer manifest the scope boundary

Use immutable tenant IDs and workspace resource IDs as the authoritative mapping. Keep display names and domains as readable labels. Identify the customer owner who can approve the review and the MSP contact responsible for access and operational coordination.

For each tenant, record permitted data sources, identities the reviewer may use, authorized read and test operations, excluded changes, collection window, retention requirements and stop conditions. Identify whether customer data can enter the MSP's ticketing system or another external analysis environment. Access to a portal does not authorize copying its contents wherever convenient.

Microsoft documents granular delegated admin privileges, or GDAP, as granular, time-bound partner access that customers explicitly grant. That capability is relevant to Microsoft partner arrangements; it does not establish the particular roles assigned in a customer environment. Inspect the actual delegation and its expiry rather than treating GDAP enrollment as sufficient scope.

The manifest should also distinguish the reviewer's privileges from operational privileges already held by the MSP. A reviewer reading configuration doesn't need every permission the response team possesses. Where a necessary observation requires broader access, document the narrow operation and the customer authorization before performing it.

Separate people from software identities

A workforce review typically follows employee and administrator access, delegated roles, sign-in conditions, privileged role changes and account lifecycle. A workload review follows applications, service principals, managed identities, credential or federation configuration, ownership and resource permissions.

Microsoft's workload identity overview, reviewed September 9, 2026, identifies applications, service principals and managed identities as workload identities in Entra. Their lifecycle and available telemetry require separate treatment. A successful employee sign-in exercise does not establish coverage for unattended automation.

For a service principal, ask who owns it, which customer resources it can reach, how it authenticates, where its credentials or trust configuration are managed, and how it is disabled. Record identifiers and configuration references without exporting secrets. Separate the application definition from its representation and permissions in each customer tenant.

Draw telemetry custody through the handoff

List each required source, its originating tenant, destination, expected freshness, retention, license dependency and owner. Separate missing source data from an empty query result. A detector returning no matches may simply have no current inputs.

Microsoft's Azure Lighthouse guidance for Sentinel workspaces describes an architecture with workspaces in customer tenants and delegated management. That provides a useful documented custody pattern. Review exports, centrally stored tickets and playbook outputs separately because they may create additional copies outside the customer workspace.

Define who receives a finding and how the recipient confirms ownership. A handoff should include the customer ID, affected subject and resource, source timestamps, supporting record references, known collection gaps, recommended next step and the authority required to take it. Avoid placing unrelated customer details in a shared attachment.

Test routing with harmless labeled fixtures. A successful delivery means the intended authorized team can access the materials and recognize the action required. It doesn't establish that a containment operation occurred or that a service-level commitment was met in production.

Walk through two customers with different authority

Assume invented customer Cedar allows read-only assessment and requires its own administrator to approve any change. Birch authorizes a separate, bounded lab exercise for account containment using designated test identities. Neither permission extends to the other's tenant.

A synthetic signal for Cedar enters the MSP queue. The analyst can review its supporting records, but the response interface must identify the customer approval requirement. Selecting a Birch response playbook should not silently redirect Cedar's incident to Birch or reuse Birch's authority.

For the separately authorized Birch exercise, verify the target tenant and test identity before execution. Record the approval, executing principal, downstream acknowledgement and observed state. If delegation expires before the command runs, the expected outcome is a visible failed or rejected action. The case must not close as contained solely because the playbook was launched.

Also create identical local user IDs in both tenants. Query joins, suppression keys, ticket deduplication and response parameters must preserve tenant identity. The KevinBytes fixture demonstrates one correlation method over invented records; adapting it to real telemetry requires verifying source fields, ingestion behavior and available privileges first.

Accept results per customer

A useful acceptance sheet has one row per requirement and customer, with the observed result, unresolved gap, owner and next decision. Avoid reporting “all tenants covered” when one tenant lacks workload logs or another has an untested response path.

Cedar might accept a read-only review with a documented customer-owned response handoff. Birch might accept its bounded exercise only after the target mapping, approval and revocation cases pass. These are different deliverables, and their limitations should remain visible in the consolidated report.

At closeout, return the scoped configuration and findings package, confirm the recipient can use it, remove temporary reviewer access through the agreed process and record retained materials and disposal dates. Record any exceptions the customer accepts and the changes that require renewed review, such as a new delegation, automation identity or telemetry destination.

For scoped MSP support, define those outputs and boundaries before scheduling the work. Continuous monitoring, round-the-clock response and customer containment authority require explicit operating arrangements; they should never be inferred from a completed assessment or an illustrative detection exercise.