Replace standing Microsoft partner administration with granular, time-bound GDAP

Source facts: GDAP is designed for granular, time-bound partner access

Microsoft’s introduction to granular delegated admin privileges describes GDAP as a least-privileged, time-bound way for partners to administer customer workloads. A GDAP relationship identifies the Microsoft Entra roles requested, its duration, and the customer that must approve the relationship. After approval, the partner assigns security groups to the roles made available by that relationship.

That design is materially different from treating one broad partner relationship as permanent authority. Microsoft’s task-to-role guidance maps common Partner Center and service tasks to supported least-privileged roles, while its Cloud Solution Provider security guidance calls for multifactor authentication, least privilege, removal of unneeded access, logging, and protection of privileged accounts. The documents make clear that access is assembled from several objects: the relationship, its roles and dates, partner-side groups, and the users or service principals placed in those groups.

GDAP does not automatically decide what every technician needs. It also does not cover every possible administrative path into every customer resource. Workloads, role support, Azure access, customer-created local accounts, application consent, and vendor portals can have separate authorization models. Expiration limits future use of a relationship, but it is not a substitute for promptly removing a person who changes roles or leaves the provider.

DSE recommendation: operate GDAP as a privileged-access lifecycle

Move from “our support team needs admin” to a catalog of specific support outcomes. Give each relationship, role assignment, group, and exception a business owner and an evidence trail.

Inventory the work. List actual activities such as password reset, license administration, Exchange troubleshooting, device management, security investigation, service health review, and support escalation. Record which customers buy each service and which actions require customer participation.

Map tasks to roles. Start with Microsoft’s least-privileged role guidance, validate the role in a nonproduction tenant, and document any task that still requires broader authority. Do not use a high-privilege role merely because it reduces dispatch friction.

Design groups by function. Assign roles to narrowly named security groups rather than one all-technician group. Separate routine operations, identity support, messaging, endpoint administration, and emergency work. Govern group owners and prevent technicians from approving their own membership.

Set deliberate duration. Choose a relationship term that matches the customer agreement and review cycle. Track approval, start, and expiration dates in the PSA or governance register. Begin renewal early enough for customer review, but never let renewal become an unexamined automatic process.

Control operator elevation. Where supported by the provider’s identity design, use time-limited group membership or activation, strong phishing-resistant authentication, compliant privileged devices, and conditional access. Separate day-to-day collaboration identities from customer administration identities.

Monitor and review. Correlate Partner Center, partner-tenant, and customer-tenant evidence where available. Alert on new relationships, privileged role additions, unexpected group membership, dormant access, unusual locations, and administration outside a ticket or approved change.

Prepare for expiry and emergencies. Test what stops when a relationship expires. Maintain a documented customer-approved path for urgent access, including who authorizes it, how it is activated, what is logged, and how it is removed after the event.

Factual boundary: GDAP provides Microsoft partner-access controls; it does not prove that an MSP’s role catalog, operator identities, customer approvals, or monitoring are correct. Supported roles and workloads can change. Validate current Microsoft documentation and the exact customer service before relying on a role assignment.

Useful measures include relationships nearing expiration, high-privilege roles, users per privileged group, dormant assignments, emergency activations, administration without a related work item, and time to remove an operator. The objective is not simply to have GDAP. It is to make every partner action traceable to a current customer relationship, a justified role, an approved operator, and a bounded period.

Official references

Microsoft Learn, Introduction to granular delegated admin privileges (GDAP).

Microsoft Learn, Least-privileged roles by task in Partner Center.

Microsoft Learn, Security best practices for Cloud Solution Provider partners.