What was wrong with the old DAP model?

Delegated Admin Privileges granted a partner’s Admin Agents group standing Global Administrator access to every customer tenant the partner had a relationship with, all at once, with no expiry. One compromised partner credential was a path into every customer the partner managed, with no way to scope or time-limit what that access could touch.

What does GDAP actually change?

Access is defined per customer relationship, scoped to specific Entra ID roles rather than blanket Global Administrator, and time-bound with a defined expiry that requires renewal. A technician can be granted exactly the roles a task needs, for one customer, for a set period, instead of standing administrative access to everything.

Does the customer have to approve GDAP access?

Yes. The customer reviews and approves the specific roles being requested before the relationship becomes active, and can see exactly what access exists at any time. This is a meaningful shift from the old model, where a customer had limited visibility into what a partner’s standing access actually covered.

What happens to GDAP roles when a technician leaves the MSP?

The role assignment itself is not tied to a specific technician—it is tied to a security group in the partner’s own tenant. Removing someone from that security group removes their access to every customer relationship using it immediately, which is the practical reason to build GDAP role assignment around groups rather than assigning roles to individual people directly.

Is a read-only security platform the same as a GDAP relationship?

Not exactly — GDAP is Microsoft’s specific partner-relationship mechanism for CSP-model access. But the underlying principle is the one to demand from any tool touching customer tenants: least-privilege, per-customer, and revocable access, rather than one broad credential covering everything. That is the same standard SecurityScore.me’s own tenant connections are built to, through delegated read-only Graph permissions scoped and consented per customer.

Identity and Access

GDAP Explained: What MSPs Need to Know About Microsoft's Delegated Admin Model

Granular Delegated Admin Privileges replaced the old model where an MSP's standing access to a customer tenant meant Global Administrator, indefinitely, across every customer at once. GDAP is narrower, per-customer, and time-bound — and understanding what it actually changes matters whether you administer customer tenants directly or evaluate any tool that touches them.

What DAP got wrong

Under Delegated Admin Privileges, once a customer accepted a partner relationship, members of that partner's Admin Agents security group received Global Administrator rights in the customer's tenant. Not a scoped role — the top-level role, with no built-in expiry, applying uniformly across every customer relationship the partner held.

The risk this created was structural, not hypothetical: a single compromised credential inside the MSP's Admin Agents group was a path into every customer tenant the MSP managed, all at the same privilege level, with no time limit forcing a review. The blast radius of one incident scaled with the size of the MSP's customer book, which is exactly backwards for a security model.

What GDAP changes: scoped roles, per relationship

GDAP replaces the single blanket grant with access defined per customer relationship and scoped to specific Entra ID roles. A relationship set up for password resets and license management can be granted exactly those roles — nothing close to Global Administrator — and a relationship that genuinely needs broader access can be granted that separately, for that one customer, without extending to every other relationship the partner holds.

The second change is expiry. Every GDAP relationship has a defined duration and requires renewal, which forces a periodic point where access gets reviewed rather than accumulating indefinitely in the background.

The customer sees and approves what they are granting

A GDAP relationship request specifies the exact roles being asked for, and the customer reviews and approves that specific request before it takes effect — not a generic "grant this partner administrative access" approval with no detail behind it. The customer can also see what access currently exists, which is a meaningfully different conversation than the DAP era, when most customers had little practical visibility into what their partner relationship actually granted.

For an MSP, this means the access you request is now something you have to be deliberate about and able to explain — asking for broader roles than a task needs is now a visible decision, not a default that came bundled with the relationship.

Practical GDAP hygiene for a growing customer book

Assign roles to security groups, not individuals. Map GDAP roles to security groups in your own tenant rather than to specific people. Removing someone from the group removes their access to every relationship using it, immediately — reassigning dozens of individual grants when someone leaves does not scale and gets missed.
Request the minimum role a task needs. Most day-to-day MSP work does not require Global Administrator. Password resets, license assignment, and Exchange administration each have narrower roles that cover the actual task.
Treat renewal as a real review, not a formality. Expiry only reduces risk if the renewal step actually reconsiders whether the relationship still needs the roles it was granted, rather than reflexively renewing the same request.
Audit relationships against your active customer list. A GDAP relationship for an offboarded customer is standing access with no remaining business reason to exist.

Applying the same standard to every tool that touches a tenant

GDAP formalizes a specific mechanism for Microsoft's CSP partner relationships, but the underlying question is worth asking about anything that connects to a customer tenant: is access scoped to what the tool actually needs, is it per customer, and can it be revoked without touching every other customer relationship? A tool that requests broad, standing access because it is simpler to build that way is asking for exactly the risk profile GDAP was introduced to move away from.

SecurityScore.me connects each customer tenant through its own consent flow, requesting only the delegated read-only Graph permissions the assessment needs, scoped to that customer workspace, and revocable at any time without affecting any other connected tenant. See Microsoft Graph security for the exact scopes requested and how per-customer consent works, and customer workspaces for how that access model maps onto a multi-customer portfolio.

Frequently asked questions

Learn more

Microsoft Graph security
Least-privilege, read-only, per-customer consent for the Graph API.
Customer workspaces
How per-customer access and data isolation work across a portfolio.
Entra ID & Conditional Access review
Reviewing privileged roles and standing access inside the tenant itself.
MSP security monitoring: what to track across every tenant
Where access-model hygiene fits alongside the rest of tenant monitoring.

See how per-customer, read-only access works in practice

Request a demo Microsoft Graph security →