Managed Security Across Tenants Needs More Than a Single Sign-In

A managed security provider may need to investigate incidents across dozens of customer environments. Giving every technician a broad administrator account in every tenant is difficult to govern; asking customers to approve an opaque, permanent relationship is difficult to trust. Delegated access can make that relationship easier to operate, but only if the permissions remain understandable to both sides.

In a November 12, 2026 update for security partners, Microsoft said granular delegated admin privileges (GDAP) for Microsoft Sentinel and Defender XDR are generally available in the Microsoft Defender portal, including custom roles in unified role-based access control. Microsoft describes partner technicians signing in from their own tenant and accessing customer environments through their own security groups, without guest or admin accounts in each customer tenant. Customers approve the roles requested. [^[1] ]

The announcement is aimed at partners. Its practical significance for customers is that cross-tenant access can be structured around explicit roles and partner-side groups. This is not the same as unrestricted access disappearing: a delegated relationship still grants authority, and the exact effects depend on role definitions and workload permissions.

Two sides of the trust boundary

Microsoft’s GDAP documentation describes a relationship request that identifies the partner tenant, the roles requested and an expiration date, with customer approval required. That is a more reviewable model than an unbounded grant, but the customer still needs to understand what each role permits and whether it matches the contracted service. [^[2] , ^[3] ]

Microsoft’s cross-tenant delegated administration documentation describes two layers: the relationship-level permissions that establish which roles are delegated, and workload-specific permissions that a service may require through its own role system. A role assignment in one layer does not automatically answer every question about access in another. Security teams should check the current configuration in the relevant portal and service documentation rather than infer scope from the label “delegated.” [^[4] ]

This matters especially when teams customize roles. A narrow-sounding role can still expose sensitive data or enable consequential actions depending on the permissions it contains. A partner’s security group may also include more technicians than the customer expects. Review who can join the group, how membership changes are approved, what activity is logged, and how access is removed when staff or service responsibilities change.

Review access like a working control

Before approving a relationship, ask the provider to map each requested role to a task: triage alerts, investigate incidents, change detection rules, manage users, or administer the security platform. Remove permissions that are not needed for the contracted work. Set an expiry or review date and assign an internal owner who can confirm that the service still requires access.

Then check group membership in the partner tenant and determine how privileged membership is protected. A customer may approve the relationship, but the partner controls which of its technicians enter the delegated group. That makes the provider’s identity governance part of the customer’s security boundary. Require strong authentication, limited privileged groups, auditable changes and prompt removal of departing technicians.

Microsoft’s Sentinel documentation explains how Sentinel and Defender XDR incidents and data can be integrated across the Defender and Azure portals, with incidents remaining synchronized in supported configurations. That product integration is distinct from delegated administration: data visibility, portal integration and authority to take actions are related but separate controls. Verify both the operational workflow and the permission model. [^[5] ]

Test what the provider can actually do

Use a non-production tenant or a carefully chosen low-risk customer environment to confirm the provider can complete intended tasks and cannot perform unrelated actions. Check whether a technician can view sensitive incident details, modify rules or close an investigation. Record the expected behavior, test it with the relevant role and review audit logs afterward. Repeat when roles, groups or service scope changes.

Also agree on the offboarding path. Who revokes the delegated relationship? Does the customer receive notice when group membership changes? How quickly can access be suspended during an incident? Make sure the customer can obtain a current list of active relationships and identify an accountable contact on both sides.

A shared portal can make multi-tenant security work more manageable. The durable trust comes from being able to explain the access: which customer approved it, for which tasks, which technicians can use it, when it expires and how the customer can inspect or revoke it. Delegation reduces account duplication; explicit governance keeps that convenience from becoming invisible privilege. For a related look at access boundaries in AI systems, see our guides to personal-agent permissions and Microsoft’s agent security model.