{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/replace-standing-partner-administration-with-gdap/", "item": { "id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "slug": "replace-standing-partner-administration-with-gdap", "url": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap.md", "json": "https://update.dsesecurity.com/api/v1/posts/replace-standing-partner-administration-with-gdap/" }, "title": "Replace standing Microsoft partner administration with granular, time-bound GDAP", "summary": "Microsoft GDAP can narrow a partner’s access by role and duration. An MSP still needs task-based role design, controlled group membership, customer approval, monitoring, renewal, and a tested emergency path.", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "important", "name": "Important" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/", "type": "Person" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-08-17T13:25:00+00:00", "modified_at": "2026-08-17T19:22:09+00:00", "reviewed_on": "2026-08-17", "reading_minutes": 3, "word_count": 641, "potentially_affected": "Microsoft Cloud Solution Provider relationships; Partner Center; Microsoft Entra roles; partner security groups; customer tenants; support workflows; privileged workstations; access reviews; and emergency administration.", "dse_recommendation": "Inventory every partner-admin task, map each task to the least-privileged supported role, place approved operators in governed groups, set deliberate relationship durations, monitor use, review membership, and remove unused relationships.", "primary_source": { "name": "Microsoft Learn: Introduction to granular delegated admin privileges (GDAP)", "url": "https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

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

\n

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.

\n

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.

\n

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.

\n\n

DSE recommendation: operate GDAP as a privileged-access lifecycle

\n

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.

\n
    \n
  1. 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.
    2. \n
  2. 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.
    3. \n
  3. 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.
    4. \n
  4. 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.
    5. \n
  5. 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.
    6. \n
  6. 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.
    7. \n
  7. 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.
    8. \n
\n

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.

\n

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.

\n\n

Official references

\n", "content_text": "Source facts: GDAP is designed for granular, time-bound partner access\nMicrosoft’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.\nThat 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.\nGDAP 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.\n\nDSE recommendation: operate GDAP as a privileged-access lifecycle\nMove 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.\n\nInventory 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.\nMap 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.\nDesign 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.\nSet 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.\nControl 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.\nMonitor 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.\nPrepare 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.\n\nFactual 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.\nUseful 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.\n\nOfficial references\n\nMicrosoft Learn, Introduction to granular delegated admin privileges (GDAP).\nMicrosoft Learn, Least-privileged roles by task in Partner Center.\nMicrosoft Learn, Security best practices for Cloud Solution Provider partners.", "content_markdown": "## Source facts: GDAP is designed for granular, time-bound partner access\n\nMicrosoft’s [introduction to granular delegated admin privileges](https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction) 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.\n\nThat 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.\n\nGDAP 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.\n\n## DSE recommendation: operate GDAP as a privileged-access lifecycle\n\nMove 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\n- 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.\n\nFactual 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.\n\nUseful 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.\n\n## Official references\n\n- Microsoft Learn, [Introduction to granular delegated admin privileges (GDAP)](https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction).\n\n- Microsoft Learn, [Least-privileged roles by task in Partner Center](https://learn.microsoft.com/en-us/partner-center/customers/gdap-least-privileged-roles-by-task).\n\n- Microsoft Learn, [Security best practices for Cloud Solution Provider partners](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices)." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "url": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-08-17" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Replace standing Microsoft partner administration with granular, time-bound GDAP", "item": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/#article", "identifier": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "url": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/", "headline": "Replace standing Microsoft partner administration with granular, time-bound GDAP", "description": "Microsoft GDAP can narrow a partner’s access by role and duration. An MSP still needs task-based role design, controlled group membership, customer…", "abstract": "Microsoft GDAP can narrow a partner’s access by role and duration. An MSP still needs task-based role design, controlled group membership, customer approval, monitoring, renewal, and a tested emergency path.", "articleBody": "Source facts: GDAP is designed for granular, time-bound partner access\nMicrosoft’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.\nThat 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.\nGDAP 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.\n\nDSE recommendation: operate GDAP as a privileged-access lifecycle\nMove 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.\n\nInventory 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.\nMap 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.\nDesign 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.\nSet 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.\nControl 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.\nMonitor 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.\nPrepare 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.\n\nFactual 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.\nUseful 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.\n\nOfficial references\n\nMicrosoft Learn, Introduction to granular delegated admin privileges (GDAP).\nMicrosoft Learn, Least-privileged roles by task in Partner Center.\nMicrosoft Learn, Security best practices for Cloud Solution Provider partners.", "datePublished": "2026-08-17T13:25:00+00:00", "dateModified": "2026-08-17T19:22:09+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Person", "name": "Gavin Stewart", "url": "https://www.linkedin.com/in/gavin-stewart-0718/" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/replace-standing-partner-administration-with-gdap/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Replace standing Microsoft partner administration with granular, time-bound GDAP" }, "articleSection": [ "Cybersecurity", "IT", "Microsoft 365 & Identity" ], "keywords": [ "Cybersecurity", "IT", "Microsoft 365 & Identity", "Playbook", "Important priority" ], "genre": "Playbook", "about": [ { "@type": "Thing", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "wordCount": 641, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Microsoft Learn: Introduction to granular delegated admin privileges (GDAP)", "url": "https://learn.microsoft.com/en-us/partner-center/customers/gdap-introduction" } } ] } }