GDAP and MSP Delegated Admin Access Guide: Least Privilege for Partners

A managed service provider with standing administrator rights in hundreds of customer tenants is a single point of compromise for all of them. Microsoft's Granular Delegated Admin Privileges (GDAP) replaced the old all-or-nothing Delegated Admin Privileges (DAP) model with per-customer, time-bound, role-scoped partner access, and Azure Lighthouse gives a parallel path for Azure resources. This guide explains how both work, which roles to grant for which tasks, how to roll GDAP out without losing access, and how customers can see and control what their partners hold. It is written for MSP security and operations leads, and for customer IAM teams who need to govern the delegated administrative path into their own tenant. Wider contractor and B2B access is covered in the Third-Party Access Guide.

Key takeaways

• Delegated admin is a supply chain attack path. Microsoft described NOBELIUM's 2021 campaign against cloud and managed service providers as a "compromise-one-to-compromise-many" approach that used delegated privileges to reach downstream tenants.
• GDAP is time-bound by design. Relationships last at most two years, permanent relationships are not allowed, and auto extend (180 days at a time) cannot be applied to a relationship that includes Global Administrator.
• Grant roles to security groups, per task. Microsoft publishes a least-privileged role for each common partner task: a help desk that resets non-admin passwords needs Password Administrator, not Global Administrator.
• The partner tenant is now part of your attack surface. MFA for every partner user, the Secure Application Model for automation, and Entra ID P2 for Admin Agents are Microsoft partner security requirements, and customers should check them contractually.
• Customers must look, not just trust. Review partner relationships, filter sign-in logs for service provider cross-tenant access, and remove relationships that are unused or unfamiliar.

Why delegated admin access is a high-value target

MSPs, cloud solution providers (CSPs) and resellers hold administrative access to many customers at once, usually from a small number of technician identities and automation accounts. Compromise one technician, one remote tool or one API credential, and the attacker inherits every relationship that identity can use. MITRE ATT&CK models this as T1199 Trusted Relationship for initial access, followed typically by T1078.004 Cloud Accounts and, for persistence, T1098.003 Additional Cloud Roles.

• NOBELIUM (2021): Microsoft reported from May 2021 that the actor behind the SolarWinds compromise targeted providers holding customer administrative access, stole provider credentials, and moved into customer tenants. In one chain the actor linked access across four providers to reach its final target, and used Azure RunCommand with admin-on-behalf-of (AOBO) access to move from cloud to on-premises systems. Microsoft noted that delegated privileges were "often neither audited for approved use nor disabled" after use, and that the attacks did not rely on a product vulnerability. See the APT29 (Midnight Blizzard) Threat Actor Profile.
• Provider tooling: the BeyondTrust breach shows the same pattern with a remote support service: a stolen API key let the attacker reset local application account passwords and reach US Treasury workstations. Remote tools are covered in the RMM Tool Security Guide.
• Provider help desks: in the Marks and Spencer cyberattack, reporting ties the entry point to impersonation of a third-party user through an outsourced help desk. Delegated technicians who can reset credentials are a social engineering target as well as a technical one.

DAP, GDAP and Azure Lighthouse compared

Under legacy DAP, a CSP partner's Admin Agents effectively held Global Administrator in every customer tenant they resold to, with no expiry. Microsoft phased DAP out for new customers in 2023: from 25 September 2023 in sandbox (API), from 10 October 2023 in production, with general availability of "Default GDAP" completing on 2 December 2023. DAP and GDAP can coexist during migration, and GDAP takes precedence for Microsoft 365, Dynamics 365 and Azure workloads.

Microsoft states that Lighthouse and GDAP are decoupled: a customer can block the GDAP path without affecting Lighthouse, and the reverse. Many MSPs use GDAP for Microsoft 365 and Entra administration and Lighthouse for Azure operations. Azure RBAC design is covered in the Azure RBAC and Service Principals Guide.

How GDAP relationships work

• Relationship: a named, per-customer object created in Partner Center (or by API) listing the Microsoft Entra roles requested and the duration. The customer receives an invitation link; only a customer Global admin can approve. A request not acted on expires after 90 days, and a partner cannot terminate one in Approval Pending.
• Access assignment: after approval, an Admin Agent in the partner tenant assigns partner security groups to the relationship and picks which of the approved roles each group gets (Customers, Admin relationships, the relationship, Add security groups). A yellow warning icon in Partner Center means a relationship has no access assignments.
• Expiry and auto extend: maximum duration is two years. Auto extend adds 180 days at each end date until disabled or terminated, and can be enabled without fresh customer consent, so customers should not assume the original end date holds. Relationships containing Global Administrator cannot auto extend.
• Termination: either side can terminate. Notification emails go to partner Admin Agents and customer Global admins. Existing subscriptions are unaffected; the security groups simply lose access. A terminated or expired relationship name can be reused only after 365 days.
• Azure via GDAP: partners managing Azure through GDAP place an Azure managers group under Admin agent; Microsoft's introduction page notes that group receives Owner RBAC on that customer's subscriptions, which is broad and worth challenging or replacing with Lighthouse delegations.
• Guests: guest accounts do not work with GDAP, so technicians must be members of the partner tenant, which keeps their authentication under partner Conditional Access.

Least-privileged roles by task

Design security groups around jobs, not people, and map each to the smallest Microsoft Entra role Microsoft lists for the task. The table below uses Microsoft's least-privileged-roles-by-task guidance.

Microsoft's FAQ advises against replacing Global Administrator by requesting every Microsoft Entra role. Where a task genuinely needs Global Administrator, agree a separate, short, time-bound relationship with the customer and let it expire. For tiering principles behind these groups, see the Tiered Administration and Enterprise Access Model Guide.

Securing the partner side

GDAP narrows what a technician can do in each tenant, but the technician's identity still lives in the partner tenant, and that tenant's controls decide whether the identity can be stolen.

• MFA everywhere: Microsoft's partner security requirements mandate MFA for all user accounts in the partner tenant, using security defaults or Entra ID P1/P2 Conditional Access. Technical enforcement for AOBO, Partner Center and Partner Center API calls started on 18 November 2019, and non-compliant partners can lose the ability to manage delegated customer tenants. Prefer phishing-resistant methods for anyone in a privileged GDAP group. See the Conditional Access Guide.
• Entra ID P2 for Admin Agents: Microsoft lists it for sign-in logs, Privileged Identity Management and risk-based Conditional Access. Use PIM for groups so technicians activate membership of a privileged GDAP group only when working a ticket. See the Privileged Identity Management (PIM) Guide.
• Secure Application Model: required for apps integrating with Partner Center APIs and recommended for Microsoft Graph, Azure Resource Manager and PowerShell automation. Billing integrations, control panels and scripts that sign in with user credentials are non-human identities in practice: inventory them, give each its own identity, and store their tokens in a secrets manager. See the Secrets Management Guide.
• Admin agent hygiene: the Admin agent role controls who can create relationships and assign groups. Keep it to a handful of named people with separate admin accounts, and do not use it for day-to-day ticket work.
• Joiners, movers, leavers: because access flows through group membership, removing a technician from the partner security group removes their access to every customer at once. Tie group membership to HR events and review it monthly.
• Help desk verification: any group that can reset passwords or authentication methods needs a documented caller verification process, since that is the path social engineering crews use.

Customer-side governance of partner access

• Inventory relationships: review partner relationships in the Microsoft 365 admin center and Azure Lighthouse delegations on the Service providers page in the Azure portal. Remove any partner you do not recognise or no longer use, and any remaining DAP relationship.
• Approve deliberately: only Global admins can approve a GDAP request. Before approving, check every requested role against the contract scope and reject Global Administrator unless it is a short, specific engagement.
• Watch auto extend: because a partner can enable auto extend on an active relationship without new consent, put relationship end dates and auto extend status into your quarterly access review. See the Access Reviews Guide.
• Log partner activity: Microsoft recommends filtering Entra sign-in logs with "Cross-tenant access type: Service provider" to see partner sign-ins, reviewing audit logs for role assignments and new privileged users, and agreeing log retention with providers. Lighthouse actions appear in the delegated subscription's Azure activity log. See the Cloud Logging and Audit Trail Guide.
• Contract for controls: require the provider to state which roles it holds, how technicians authenticate, how quickly leavers are removed, how it will notify you of a provider-side incident, and how access ends at contract exit. CSF 2.0 GV.SC-10 covers the post-relationship provisions.
• Keep your own break-glass: never rely on a partner as your only route to Global Administrator. See the Break-Glass Account Guide.

Beyond Microsoft: other delegated administrative paths

The same questions apply wherever a provider administers your estate. In AWS Organizations, the management account can delegate policy management to member accounts through a resource-based delegation policy; AWS advises using the management account only for tasks that must run there, partly because service control policies do not restrict users or roles in the management account. Provider access into AWS should land in member accounts through roles you define, not management account credentials. See the AWS Security Guide. RMM agents, remote support tools, PSA integrations and backup consoles held by MSPs are also delegated administrative paths, often with broader reach than any directory role; the RMM Tool Security Guide covers them.

Rolling out GDAP: a phased approach

1. Discover: list every customer, every DAP relationship still present, every GDAP relationship with its roles, end date and auto extend setting, and every automation account using customer credentials.
2. Design groups: define 6-10 job-based security groups using the role table above, with a separate restricted group for privileged roles. Stay well under the 100 groups per customer limit.
3. Harden the partner tenant first: enforce MFA and Conditional Access for all technicians, enable PIM for privileged groups, and move automation to the Secure Application Model before any customer is switched.
4. Pilot: pick two or three customers of different sizes, create GDAP relationships for both Microsoft 365 and Azure, assign groups, and confirm that ticket workflows still succeed. Keep DAP in place during the pilot so GDAP precedence can be tested.
5. Remove DAP: only after Azure GDAP (or Lighthouse) is working; Microsoft warns that removing DAP first can cause loss of access to Azure subscriptions until GDAP setup completes.
6. Roll out in waves of customers, tracking failed tasks to find missing roles rather than adding broad roles pre-emptively.
7. Roll back: if a wave breaks support, add the specific missing role to the relevant relationship or request a short time-bound relationship; do not reinstate DAP or Global Administrator.
8. Operate: run monthly group membership reviews, quarterly relationship reviews with each customer, and use the Expiring Granular Relationships page to renew deliberately.

Decision guidance

• GDAP or Lighthouse for Azure: choose Lighthouse where the provider manages Azure resources at scale, because technicians never sign in to the customer tenant and eligible authorisations give just-in-time elevation with optional approvers. Use GDAP for Entra and Microsoft 365 administration, and for reseller-only customers where Microsoft's FAQ describes a Directory Readers relationship plus AOBO for subscription management.
• Small MSPs: fewer technicians means people do several jobs. Resist one "all technicians" group with every role: two groups (standard and privileged, the latter through PIM) are still a large improvement.
• Large MSPs: automate relationship creation and group assignment through the API, standardise relationship templates by service tier, and feed relationship data into your own IGA or CMDB.
• Customers with in-house IT: grant narrow, read-heavy roles and keep privileged changes in-house. Customers fully outsourced to an MSP should concentrate on logging, contract terms and break-glass ownership.
• Regulated customers: GDAP is the model Microsoft positions for customers with regulatory requirements for least-privileged partner access; map it to supplier and access controls in your framework (table below).

Detection and measurement

• Monitor: service provider cross-tenant sign-ins in the customer tenant; role assignments and new privileged users created by partner identities; changes to Conditional Access and authentication methods made by partners; Partner Center activity logs on the partner side; PIM activations of privileged GDAP groups; Lighthouse delegation changes in Azure activity logs.
• Alert on: partner sign-ins outside agreed support hours or from unexpected locations; any partner action granting Global Administrator or Privileged Role Administrator; new relationships or auto extend changes the customer did not request.

Framework mapping

Common failure patterns

• Re-creating DAP inside GDAP: one relationship per customer with Global Administrator, or every Entra role, assigned to an "all technicians" group. The model changed, the privilege did not.
• Forgotten DAP: DAP left in place after GDAP migration, which is exactly the unaudited standing access Microsoft saw NOBELIUM exploit.
• Auto extend as autopilot: relationships extended indefinitely for customers the MSP barely serves any more, with no customer review.
• Automation outside the model: a billing or provisioning script signing in as a shared technician account with MFA excluded, giving an attacker a credential that reaches every customer. The BeyondTrust breach shows how far a single provider API key can reach.
• Help desk resets without verification: technicians with Authentication Administrator acting on a phone call, the pattern behind third-party impersonation attacks such as the Marks and Spencer cyberattack.
• Customers not looking: no review of partner relationships and no alerting on service provider sign-ins, so an abused relationship looks like normal support.

Practitioner checklist

• Remove every remaining DAP relationship once GDAP or Lighthouse access is confirmed.
• Define job-based partner security groups mapped to Microsoft's least-privileged roles by task.
• Keep Global Administrator out of standing relationships; use short, separate, time-bound relationships only.
• Enforce phishing-resistant MFA and Conditional Access for all partner technicians, and PIM for privileged groups.
• Move all Partner Center, Graph and PowerShell automation to the Secure Application Model with individual identities.
• Use Lighthouse eligible authorisations with approvers for privileged Azure roles.
• Customers: review partner relationships, end dates and auto extend status every quarter.
• Customers: alert on service provider cross-tenant sign-ins and privileged role assignments by partners.
• Write provider access, incident notification and exit terms into every MSP contract.
• Keep customer-owned break-glass accounts that do not depend on any partner.

Standards and references

• Microsoft Learn: Introduction to granular delegated admin privileges (GDAP)
• Microsoft Learn: GDAP frequently asked questions
• Microsoft Learn: Least privileged roles by task
• Microsoft Learn: Partner security requirements
• Microsoft Learn: Create eligible authorizations (Azure Lighthouse)
• Microsoft Security Blog: NOBELIUM targeting delegated administrative privileges to facilitate broader attacks
• MITRE ATT&CK: Trusted Relationship
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Third-Party Access Guide · RMM Tool Security Guide · Privileged Access Management Guide · Entra ID Security Guide · Third-Party Risk Management Guide