Delegated Admin Risks

A professional services firm granted their Microsoft 365 implementation partner delegated administrator access to their Microsoft 365 tenant during the implementation project , a standard arrangement that allowed the partner to configure Exchange, SharePoint, Teams, and Azure AD settings on the firm's behalf. The implementation completed successfully after four months. The delegated admin relationship was not formally reviewed or modified at project completion. Eight months later, during a Microsoft Secure Score review, a security analyst noticed the delegated admin relationship was still active. The partner was a global MSP with over three hundred Microsoft partner staff globally. The delegated admin relationship granted admin access to the firm's tenant to any partner organization staff member the MSP designated , a population of several dozen individuals who could administer the firm's Microsoft 365 environment with global administrator privileges. The firm's own conditional access policies did not apply to delegated admin sessions. The firm could not view the partner's staff list, their MFA policies, or their access to the delegated admin capability. They could see in their admin center that the delegated admin relationship was active. They could not see who from the partner organization was using it or how securely those individuals authenticated.

What are Delegated Admin Risks, Really?

Delegated administration is a cloud platform feature that allows one organization (a partner or managed service provider) to administer another organization's cloud environment on their behalf , the partner's staff can access the customer's tenant with administrative privileges using their own organizational credentials, without being created as accounts within the customer's own directory. Microsoft's Cloud Solution Provider and Delegated Administration Privilege models, Google Workspace's reseller access, and similar constructs across major cloud platforms implement this mechanism for partner-managed services.

The governance asymmetry is the fundamental risk. When a customer grants delegated admin access to a partner, the partner's staff who exercise that access authenticate under the partner's security policies , the partner's MFA requirements, the partner's conditional access policies, and the partner's credential lifecycle management. The customer's own security policies do not apply to delegated admin sessions. If the customer requires phishing-resistant MFA for all admin access and the partner uses push notification MFA, the delegated admin access meets the partner's standard rather than the customer's. The customer granted admin access to a population they cannot directly govern.

The access scope and population opacity problem adds a second dimension. In most delegated admin implementations, the customer cannot see which specific individuals from the partner organization have been designated for delegated admin access, cannot review those individuals' security posture, and cannot impose individual-level access controls on the delegated admin relationship. The customer sees the partner organization as the access principal, not the specific individuals exercising the access. The partner designates internally which staff can exercise delegated admin, manages those staff under their own security policies, and the customer has no direct visibility into or control over that population.

• Delegated admin persisting beyond operational need , relationships granted for projects remaining active after project completion
• Partner security policy governs delegated admin sessions , customer MFA and conditional access not applied to partner-administered sessions
• Partner staff population opacity , customer cannot identify specific individuals with delegated admin access
• No customer MFA enforcement for delegated admin , authentication standards governed by partner, not customer
• Broad scope delegated admin , global administrator or equivalent broad permission granted when narrower scope would suffice

Why this matters

Delegated admin risks matter for TPRM because delegated admin relationships represent one of the highest-privilege access grants an organization can provide to a vendor , administrative access to an entire cloud tenant governed under the vendor's security policies rather than the customer's. The combination of elevated privilege, governance bypass, and population opacity makes delegated admin relationships a uniquely high-risk vendor access type that requires specific assessment beyond the standard vendor IAM review.

The cloud provider exploitation scenario is concrete and well-documented. The 2023 Storm-0558 Microsoft breach included abuse of delegated administration relationships , threat actors who had compromised MSP environments used delegated admin access to reach MSP customer tenants. The attack demonstrated precisely the risk that delegated admin governance addresses: the attacker's access to the MSP's environment translated directly into access to customer tenants through the delegated admin trust relationship.

Where most teams get this wrong

The most consistent failure is granting delegated admin for specific projects and never reviewing whether it should persist after the project concludes. Delegated admin is straightforward to grant during onboarding and easy to forget , the access is in the cloud platform's admin center, not in the customer's own identity directory, and it does not appear in standard access review workflows that focus on the customer's own accounts.

• No review of delegated admin at project completion
• Delegated admin not in standard access review scope
• Partner security posture for delegated admin not assessed
• Scope not reduced after initial broad grant
• No customer MFA requirement for delegated admin sessions

What good looks like

Mature delegated admin governance programs review delegated admin relationships at defined intervals, require justification for continued access after projects complete, assess the partner's security policies for delegated admin access, and scope delegated admin grants to the minimum permission level required for the operational need.

• Time-limited delegated admin for projects , relationships granted with defined duration and reviewed at project completion
• Narrowly scoped delegated admin , minimum privilege role granted rather than global administrator
• Partner security posture assessment , MFA and access controls applied to delegated admin sessions assessed
• Regular delegated admin relationship audit , review of all active delegated admin relationships against current operational need
• Granular Delegated Admin Privileges , using GDAP in Microsoft's model rather than DAP for narrower, time-limited access

Tooling

Microsoft GDAP , Granular Delegated Admin Privileges

Microsoft's Granular Delegated Admin Privileges model replaces the legacy Delegated Admin Privileges (DAP) with role-specific, time-limited access , allowing partners to request specific Microsoft 365 admin roles for defined periods rather than receiving global administrator access indefinitely. GDAP requires explicit customer approval for each role requested and each renewal period. For TPRM practitioners, asking whether Microsoft partner access uses GDAP rather than legacy DAP provides a specific delegated admin governance question.

Cloud Tenant Access Review , Microsoft 365 Admin Center, Google Workspace Admin

Cloud platform admin centers provide visibility into active delegated admin relationships , listing partner organizations with delegated access and the permissions they hold. Regular review of the admin center's partner access section surfaces persistent delegated admin relationships from concluded projects. For TPRM practitioners, asking when the customer organization last reviewed active delegated admin relationships in their cloud admin centers provides a governance currency question.

Governance challenges

The governance challenge with delegated admin is the visibility gap and the operational inertia. Visibility gap: delegated admin relationships do not appear in standard identity governance workflows because they are not accounts in the customer's directory. Operational inertia: removing delegated admin access from a partner who still provides ongoing support , even if the original project-specific justification has expired , creates friction that biases toward leaving the access in place.

• Add delegated admin to standard access review scope , cloud admin center review included in periodic access governance
• Require GDAP over DAP for all new Microsoft partner relationships
• Review delegated admin at project completion , explicit review step in project closure
• Assess partner MFA and access policies for delegated admin sessions
• Scope delegated admin to minimum required privilege

If you are a small team

Open your Microsoft 365 admin center and navigate to the partner relationships section. Review every active delegated admin relationship and ask for each: is this relationship for a currently active operational need, and if so, what is that need , or is this a relationship that was granted for a project that has since concluded? For any relationship that cannot be associated with an active operational need, initiate removal. That fifteen-minute review will surface the delegated admin relationships that have persisted beyond their operational justification.

• Review active delegated admin relationships in cloud admin centers immediately
• Require justification for any relationship not associated with an active operational need
• Migrate Microsoft partner relationships from DAP to GDAP
• Add delegated admin review to periodic access governance cycle

What to require

Ask directly:

"For any delegated admin access you hold to our cloud environment, can you describe the specific operational need it supports , and if the access was granted for an initial configuration or implementation project that has concluded, why does the relationship remain active?"

"What security controls apply to your staff when they access our environment through delegated admin , specifically, what MFA standard and conditional access policies govern those sessions on your side?"

Expect as evidence

• Current operational justification for each delegated admin relationship
• Partner staff MFA policy for delegated admin sessions
• GDAP role specification if Microsoft partner relationship
• Delegated admin review cadence

A vendor who confirms delegated admin access for managed services should be asked to describe the specific roles and scope of that access, and whether it could be scoped to the minimum required for the operational need rather than maintained at global administrator level. The delegated admin relationship gives the partner organization administrative access to the customer's cloud tenant. Understanding who within the partner organization exercises that access and under what authentication standards is the governance question the access grant itself does not answer.

How to evidence it

• Delegated admin relationship inventory with operational justification
• Partner MFA and access policy assessment records
• GDAP migration status for Microsoft partner relationships
• Delegated admin periodic review records

Key Takeaway

Delegated admin gives a partner organization administrative access to your cloud tenant under their security policies, not yours. Their MFA, their conditional access, their credential lifecycle , those are the controls that govern admin sessions in your environment when the partner is at the keyboard. You granted admin access to an organization you do not manage, governed by policies you do not set. The configuration project ended eight months ago. The relationship is still active. Thirty-seven partner help desk staff can administer your tenant. You cannot see which thirty-seven. You cannot see their MFA policy. You cannot see their credential hygiene. Review the delegated admin relationships in your admin center. Remove the ones that have no current operational justification. Scope the ones that remain to the minimum required privilege. GDAP over DAP. Time-limited over indefinite. The access you granted to someone else's organisation deserves governance that matches the risk.

More on Security

• API Identity Misuse
• Access Certification Effectiveness
• Access Policy Misconfigurations