← All news
ARTICLE
14 October 2026 Updated on 26 September 2026 2 min read

MSP FAQ: how to govern access across tenants without a god admin

Standing global-admin access across every customer tenant is a single point of failure. Microsoft's GDAP model shows how to scope access per customer instead.

In this article
  1. What GDAP changes
  2. Applying the same model beyond Microsoft 365
  3. A practical checklist

A common failure mode in MSP operations is a technician or automation account with permanent administrator rights across every customer tenant — a "god admin" that turns one compromised credential into a breach of the entire customer base. Microsoft's Granular Delegated Admin Privileges (GDAP) model, built for its own partner ecosystem, illustrates the alternative.

A lobby turnstile gate with badge readers on each side, elevators visible behind
Photo: Globetrotter19 (CC BY-SA 4.0), Wikimedia Commons.

What GDAP changes

Before GDAP, a partner's admin agents could assume a Global Administrator role in a customer's tenant indefinitely. GDAP replaces that with access that is both granular — scoped to specific administrative roles — and time-bound, and it requires the customer to explicitly grant that access rather than inherit it automatically. Microsoft's own role guidance goes further, mapping each administrative task to the least-privileged built-in role that can perform it, rather than defaulting to a broad admin role because it is convenient.

Applying the same model beyond Microsoft 365

The GDAP pattern generalises to any SaaS stack an MSP manages on a customer's behalf: each customer tenant should be its own governance boundary, technician and automation identities should be distinct, and elevated access should expire rather than persist. An MSP forum thread from the Non-Human Identity Management Group frames the underlying risk plainly: weak tenant isolation turns operational convenience into shared risk across every customer on the platform.

A practical checklist

  • No standing Global Administrator or equivalent role spanning every customer tenant.
  • Scope partner/technician roles per customer and review them on a fixed schedule.
  • Keep a separate break-glass path with time-bound elevation tied to a ticket.
  • Give automation its own least-privileged identity, distinct from any technician's.
  • Retain per-tenant audit logs that are searchable by customer.

The lesson generalises past Microsoft 365: whatever platform an MSP uses to reach customer tenants, access should be scoped, time-bound and per-customer — not a single admin identity that opens every door.

Sources: Microsoft Learn — Introduction to GDAP, Non-Human Identity Management Group — multi-tenant SaaS management for MSPs.