GDAP

Granular Delegated Admin Privileges (GDAP) is the modern access model for Microsoft partners (CSPs, MSPs) managing customer Microsoft 365 tenants. GDAP replaces the older Delegated Admin Privileges (DAP), which gave partners broad Global Administrator access across every customer tenant. With GDAP, partners are granted specific Entra ID roles with time-bound durations (typically renewed annually), scoped to specific tasks. Microsoft mandated GDAP migration for all CSP customer relationships during 2022–2023. Result: partners can only do what they need to do, customers retain control, and the audit trail is per-action. Configured by the customer in the Microsoft 365 admin center under partner relationships.

Why DAP was a liability

Under the old DAP model, every CSP partner with a customer relationship held standing Global Administrator rights in that customer's tenant — indefinitely, until explicitly revoked. That meant a single compromised partner account (or a disgruntled former partner employee) was a path into every customer tenant that partner had ever onboarded. It also meant a customer auditing "who has admin access to our tenant" had to trust the partner's own internal controls, with no native way to see which specific partner staff were actually using the access day to day. GDAP was Microsoft's structural fix: partner access is now an explicit, expiring, role-scoped relationship that the customer tenant itself can see and revoke.

Worked example

An MSP onboards a new customer to provide help-desk support (password resets, license assignment) and separately runs quarterly security reviews (reading Conditional Access policies and Secure Score, never changing them). Instead of one broad relationship, the MSP creates two GDAP relationship requests: one scoped to Helpdesk Administrator and License Administrator with a 1-year duration for the day-to-day support team, and a second scoped to Security Reader and Reports Reader for the quarterly review team, also time-bound. The customer approves both requests once, and thereafter the MSP's staff are added to or removed from each relationship's assigned security group without needing a new customer approval for every staff change — but neither group can do anything outside its granted roles, and both relationships expire and must be explicitly renewed rather than persisting indefinitely by default.

Relationship to PIM

GDAP roles can additionally be made eligible rather than standing-active for partner staff, layering Privileged Identity Management on top of the GDAP relationship itself — so even within an approved, scoped, time-bound relationship, an individual partner technician still has to activate a role (with MFA and justification) before using it, rather than carrying it permanently. Microsoft's guidance treats this combination — GDAP scoping plus PIM activation — as the baseline for partner access done properly.

Common pitfalls

The most common GDAP migration mistake was recreating the old DAP model inside GDAP by requesting Global Administrator as the single scoped role "to be safe," which defeats the point of the granular model and re-creates the same blast-radius problem with extra steps. The second is letting relationships expire unnoticed — because GDAP relationships lapse on their end date rather than persisting, a partner that doesn't track renewal dates can find support access silently cut off mid-engagement, which is disruptive for both sides if it isn't proactively monitored.