GDAP Explained for Customers: What Admin Access a Microsoft Partner Asks For, and How to Review It

Granular delegated admin privileges — GDAP — is Microsoft's model for a partner's access to a customer tenant. Instead of a standing, tenant-wide administrative relationship, the partner requests specific Microsoft Entra roles for a stated duration, and an administrator in your tenant approves the relationship by following a link. The roles are the same built-in roles you would assign your own staff; the partner's engineers exercise them by signing in with their own accounts in the partner's tenant, through security groups the partner maps to each role. Microsoft's guidance for partners is direct about the purpose: GDAP keeps customers secure while giving partner staff the permissions their work needs, and no more.

Three properties follow, and they are the ones to hold your partner to. Access is granular: role by role, not all-or-nothing. It is time-bound: every relationship has an end date, after which the roles stop until you approve again. And it is yours to grant and revoke: the relationship is visible in your admin center and you can end it without asking.

A GDAP request has four parts worth reading.

1. The partner. The request comes from a specific Partner Center organization, and the relationship is recorded there and in your Microsoft Entra directory. If the name is not the company you are contracting with, stop.
2. The roles. A list of Microsoft Entra built-in roles. Microsoft documents every one, with the exact actions each permits, in its built-in roles reference.
3. The duration. A relationship runs until its end date. A request without a sensible end date, or one the partner expects to renew silently, deserves a question.
4. The approval. An administrator in your tenant follows the link and approves. Make sure they know they are making an access decision, and record it somewhere other than their inbox.

What you will not see is who at the partner gets the access. That mapping — roles to partner security groups, optionally with just-in-time activation where the partner holds Microsoft Entra ID P2 — is configured on the partner side, and it is fair to ask how. Ours is written on our GDAP access policy page: the default request is Microsoft's standard starter relationship, a largely read-only set with no standing Global Administrator; anything more is a separate, task-scoped request you approve for a bounded period and can revoke at any time.

Role names are precise, so the review is mostly sorting them into three piles. The descriptions are Microsoft's, condensed.

Read-only roles let a partner see enough to advise without changing anything. Global Reader is the read-only counterpart to Global Administrator — settings and administrative information across Microsoft 365, no management actions — which Microsoft suggests for planning, audits and investigations. Directory Readers reads basic directory information. Reports Reader sees usage reports and Microsoft Entra sign-in and audit logs without configuring anything. Service Support Administrator opens support requests with Microsoft and reads service health. A health check, a license review or a security assessment needs these and nothing more; our own license audit runs on Global Reader and Reports Reader and writes nothing.

Workload roles change one service. Exchange Administrator has global permissions inside Exchange Online and can manage Microsoft 365 groups; Exchange Recipient Administrator is limited to recipients and their attributes. License Administrator assigns and removes licenses but cannot buy subscriptions or create users. Intune Administrator manages devices and policy. A migration, a mail-flow change, a device rollout or a license clean-up each map to one of these, and each should come with an end date.

Privileged roles are the pile to slow down on; Microsoft marks them as privileged in its reference. Global Administrator can do everything, including elevating into your Azure subscriptions, and Microsoft recommends that fewer than five people hold it in any organization — a partner's standing account should not be one. Privileged Role Administrator can assign any role, including Global Administrator, to anyone: a role that can grant itself the rest. User Administrator and Helpdesk Administrator can reset passwords and invalidate sessions, which Microsoft's own warning notes is a route to assuming those users' identities.

A privileged role in a request is not automatically wrong; a tenant build may genuinely need one for a fortnight. It is a role that needs a reason, a duration and a name.

The older delegated model treated partner access like a master key: broad, permanent and shared. GDAP treats it like a building pass with a photo, a floor list and an expiry date. If a partner engineer's account is compromised, the attacker inherits exactly what the relationship grants. A read-only starter set gives them a directory listing. Standing Global Administrator gives them your company.

Time limits do a second job: they force the conversation to happen again. An engagement that ended in March should not still carry Exchange Administrator in September. When the relationship expires the roles stop; if the partner needs them again, they ask, and someone on your side decides. That is a control you get without buying anything.

It protects the partner too: a partner holding standing Global Administrator on two hundred customer tenants is a single point of failure for all of them. It is why our policy states no standing Global Administrator by default.

Two Microsoft controls on your side complement GDAP. Microsoft Entra access reviews re-attest partner and internal privileged assignments on a schedule; our managed identity hygiene and access reviews service runs that cycle. And Privileged Identity Management for your own admins means a partner's occasional elevated task is not the only just-in-time access in the tenant — the shape of our PIM and privileged access hardening engagement.

1. Confirm the sender. Match the partner organization on the request to your contract; a request from an unexpected organization or channel is a phishing attempt until proven otherwise.
2. Sort the roles into read-only, workload and privileged. Microsoft's built-in roles reference describes any name you do not recognize.
3. For each workload or privileged role, ask for the task. "Exchange Administrator for the mailbox migration, until the cutover weekend" is an answer. "It makes support easier" is not.
4. Check the end date. It should be bounded to the work, not the contract term.
5. Compare against the partner's published policy. Ours must match what we publish; a partner with no published policy is worth knowing about too.
6. Record the approval and diarize the expiry: who approved, which roles, when they end. When the date arrives, decide again rather than letting a renewal through on autopilot.
7. Look at it once a quarter, alongside your own admin role assignments; your admin center shows the partner relationships you hold and the roles in each.

Does approving GDAP give the partner my users' passwords or MFA?

No. GDAP grants roles, not credentials. Partner engineers sign in with their own accounts in their own tenant, under their own MFA, and reach yours through the security groups mapped to the approved roles.

Can a partner give itself more access after I approve?

Only if you approved a role that can: Privileged Role Administrator or Global Administrator. Every other role is limited to the actions Microsoft documents for it, which is why those two need a written justification and a short duration.

What happens when the relationship expires?

The roles stop working. If the partner still needs access, they send a new request and your administrator approves again. The expiry itself changes nothing in your tenant.

A partner wants Global Administrator "for onboarding". Is that normal?

Common, and rarely necessary: a license review needs read-only roles, a migration needs Exchange Administrator, a device rollout needs Intune Administrator. Ask which task needs Global Administrator and for how long.

Is GDAP the same as the reseller relationship we approved when we bought licenses?

No. A reseller relationship lets a partner transact subscriptions for your tenant through Partner Center; GDAP is administrative access to configure and support it. Microsoft treats them as separate relationships, and you should review them separately.

• Microsoft Learn: Set up GDAP in Microsoft 365 Lighthouse
• Microsoft Learn: Overview of the Delegated access page in Microsoft 365 Lighthouse
• Microsoft Learn: Microsoft Entra built-in roles
• IT Partner: Our admin access policy (GDAP), published at /gdap-access

Microsoft's Partner Center article "Introduction to granular delegated admin privileges" is cited by title; read it for the partner-side mechanics.