Delegated Administration

The governance model that distributes scoped admin rights to teams who need them, without handing over full control of the environment.

Last Updated date: June 2026

What is delegated administration?

Delegated administration is a security and governance model that distributes specific administrative privileges to designated users, teams, or partners, scoped to a defined set of resources, tasks, or organizational units, without granting them full administrative control over the broader environment.

It's least privilege applied to administration itself, not just to end users, but to the people who manage them.


Quick Summary

Quick Summary
FieldDetail
CategoryIdentity governance (IGA) · IAM design · Privileged access
Related toRBAC, PAM, access lifecycle management, Just-in-Time access, least privilege
Primary useEnabling IT, helpdesk, app owners, and business units to manage their scope without requiring global admin rights
Key benefitReduces the blast radius of compromised or abused admin credentials while accelerating routine operational tasks

The governance tension at the center of delegation

Every organization runs into the same administrative scaling problem: IT can't be the sole bottleneck for every password reset, every user provisioning request, and every application configuration change. Delegation is the solution, but delegation without governance creates a different problem.

Distributed administrative authority means distributed risk. A helpdesk technician with password reset rights for the wrong scope can reset a privileged account. A partner with delegated admin access into a customer tenant can, if misconfigured, reach further than intended. A department manager given user management rights for their team retains those rights long after they've left the department.

The principle of delegated administration is sound. The failure mode isn't in the delegation itself. It's in the absence of governance around what was delegated, to whom, and for how long.


Forms of Delegated Administration

Delegated administration takes different structural forms depending on the environment and the scope of the task being distributed.

Scoped role delegation A named role like Helpdesk Administrator, Application Owner, or Security Auditor is defined with explicit permission boundaries and assigned to specific users or groups. The role determines what actions are permitted and on which resources. This is the most governable model: permissions are defined once, assigned explicitly, and revocable by removing the role assignment.

Azure Granular Delegated Admin Permissions (GDAP) and AWS IAM Identity Center delegated administrator accounts are enterprise implementations of this model. GDAP replaced the older Delegated Admin Permissions (DAP) model precisely because DAP granted too broad a scope: partners received tenant-wide admin rights rather than service-specific permissions.

Organizational unit (OU) delegation Common in Active Directory environments, OU-based delegation assigns administrative control over a directory subtree to a designated user or group. A regional IT admin manages users and groups within their geography. An HR admin manages the HR OU. The scope is defined by the directory structure rather than a named role.

This model is administratively efficient but governance-challenging. OU boundaries can shift, users move between OUs, and the delegation itself often isn't surfaced in standard access review tooling.

Custom object and resource delegation Platform-specific delegation models like Salesforce delegated groups, SAP authorization objects, and application-level admin roles grant management rights over specific objects or configurations within a single system. These are common in complex enterprise SaaS environments and are frequently the least visible to central IAM governance teams.


Where delegated administration goes wrong

The failure modes of delegated administration are well-documented and consistently repeated across organizations. They share a common root: delegation was treated as a provisioning decision, not a lifecycle decision.

Over-delegation at creation

Delegated roles are often scoped too broadly at initial assignment, with "just in case" permissions that exceed what the role actually requires. A helpdesk admin given the ability to manage security group memberships alongside password resets. A partner given tenant-wide read access when service-specific access would have been sufficient.

Over-delegation at creation is a least-privilege failure. It's also harder to remediate than it looks, because reducing scope after the fact tends to encounter operational resistance.

Ghost administrators

Users who held delegated admin rights for a project, a role, or a temporary assignment, and were never deprovisioned when the need ended. These accounts retain full administrative scope indefinitely. They appear in no active headcount. They clear no access review. They're discovered either during an audit or after a breach.

Ghost administrators are the most common consequence of treating delegation as a provisioning event rather than a lifecycle.

No visibility into delegated actions

Delegated administrators acting outside central IT's monitoring scope. Password resets, group membership changes, and user provisioning events initiated by delegated admins often flow through different audit trails, or none at all, compared to central admin actions. Organizations that believe they have full administrative audit coverage frequently discover, on investigation, that delegated admin events were never captured in the first place.

Partner delegation without lifecycle controls

External partners or managed service providers granted delegated access into a customer environment represent the highest-risk delegation pattern. The relationship ends. The partner offboards the consultant who held the access. The delegated permission persists. No internal process triggers review because the account belongs to an external organization.


What secure delegated administration requires

Delegation is safe when it's governed across the full lifecycle, not just at the point of grant.

  • Explicit scope definition: Every delegation should specify which resources, which actions, and which organizational units are in scope. Implicit scope ("manages the HR team") needs to be translated into explicit permission sets before assignment.
  • Time-bounded grants: Delegated admin rights should carry expiry by default, with renewal requiring explicit re-approval. Permanent delegation is a governance liability.
  • Inclusion in access certification: Delegated admins must appear in the same access review cycles as standard users. A certification workflow that covers end-user entitlements but excludes delegated admin roles is certifying the wrong risk tier.
  • Unified audit logging: Administrative actions taken by delegated admins must be captured in the same audit trail as central admin actions. A SIEM or identity governance platform that can't correlate delegated admin events has blind spots in its administrative oversight.
  • Just-in-Time elevation for high-risk tasks: For delegated admins who occasionally need elevated scope (not routine password resets, but high-impact changes), JIT access workflows require explicit justification and time-limit the elevation. Standing elevated scope shouldn't be the default.
  • Partner delegation as a formal relationship: External delegated access should be governed as a third-party access relationship: documented, time-bounded, subject to review when the engagement ends, and tied to offboarding triggers on both sides.

Delegated admin rights need the same governance as any other entitlement

Identity Confluence includes delegated administrative roles in access certification workflows, surfaces ghost admin accounts during lifecycle reviews, and provides unified audit coverage across central and delegated admin actions.


Platform implementations: what differs, what stays the same

The governance principles above apply universally. The implementation mechanics vary by platform.

Microsoft Entra ID (Azure AD) Entra supports both traditional role assignments and GDAP for partner scenarios. GDAP is the current standard for partner delegation: it grants service-specific, time-limited roles rather than the tenant-wide access that its predecessor (DAP) provided. Access reviews for delegated admin roles are available natively in Entra ID Governance.

AWS IAM Identity Center AWS supports delegated administrator accounts within AWS Organizations. Specific member accounts can be granted management responsibilities for AWS services like Security Hub, GuardDuty, and Config without requiring direct access to the management account. Permission sets define the scope, while service control policies (SCPs) provide the outer boundary.

Active Directory OU-based delegation via the Delegation of Control Wizard is the classic enterprise model. The challenge: delegation assignments are stored in ACLs on directory objects, which makes them difficult to enumerate, report on, and include in access certification tooling without purpose-built IAM integration.

Salesforce Delegated admin groups allow specified users to manage user records, unlock accounts, and assign roles and profiles within a defined scope. These are platform-native controls and frequently operate outside an organization's central IAM governance visibility.

The common thread across every platform: the platform provides the mechanism, but the identity governance layer provides the lifecycle visibility and review cadence that makes the mechanism safe.


Delegated administration vs. privileged access management

Delegated administration and PAM are related but distinct disciplines. Conflating them leads to governance gaps.

DimensionDelegated AdministrationPrivileged Access Management (PAM)
FocusDistribution of admin scope to non-central ITControl and monitoring of high-privilege accounts
Primary riskOver-delegation, ghost admins, uncertified scopeCredential theft, session hijacking, privilege abuse
Access modelStanding scoped role or permissionOften Just-in-Time; session-based
Governance toolAccess certification, role design, lifecycle managementCredential vaulting, session recording, JIT workflows
Who it coversDepartment admins, app owners, partners, helpdeskDomain admins, root accounts, DBA accounts, service accounts

In practice, the highest-risk delegated admins, those with broad scope or external access, should also be governed within a PAM framework. Scoped delegation and privileged access management are complementary layers, not alternatives.


Challenges to plan for

Role design is harder than it looks. Creating delegated roles that are genuinely scoped, rather than "admin-lite" variants of global admin, requires detailed task analysis and stakeholder negotiation. Most organizations default to broader roles than necessary because precise scoping demands more upfront work.

Access review resistance for admin roles. Business stakeholders often push back on certifying administrative roles with the same scrutiny applied to standard user access. "Of course they still need those rights" is the default answer, not the result of an actual review. Certification workflows must surface the specific permissions a delegated role holds, not just the role name.

Tooling gaps across platforms. Delegated admin assignments in Active Directory ACLs, Salesforce delegated groups, and AWS permission sets live in different systems with different reporting capabilities. Building a unified view of all delegated administrative access across an enterprise requires deliberate integration. It doesn't emerge from any single platform's native reporting.

Frequently Asked Questions

RBAC is the underlying mechanism. It defines permissions by role rather than by individual user. Delegated administration is a governance pattern that uses RBAC to distribute administrative tasks. All delegated administration uses RBAC (or should), but RBAC also applies to standard end-user access. Delegated administration specifically addresses the distribution of admin-level tasks.

Granular Delegated Admin Permissions (GDAP) is Microsoft's current model for partners managing customer Entra ID tenants. It replaced the older DAP model, which granted partners tenant-wide admin access. GDAP restricts partner access to specific services and roles, with defined time limits, making it a direct implementation of scoped, time-bounded delegation. Organizations using Microsoft CSP partners should confirm their partners have migrated from DAP to GDAP.

AWS delegated administrators are member accounts in an AWS Organization that have been given management responsibility for specific AWS services on behalf of the organization. This is distinct from IAM roles, which govern individual user or workload access within an account. Delegated administrators operate at the organizational level. IAM roles operate at the account level.

Delegated admins with broad scope, like partner accounts with tenant-wide access, domain-level OU admins, and global app owners, should be governed within a PAM framework in addition to standard access certification. Helpdesk-level delegated roles (password resets, profile updates) typically fall below the PAM threshold, but they still require access review and lifecycle management.

More frequently than standard user access. Quarterly certification is the minimum appropriate cadence for delegated admin roles. Monthly is reasonable for high-scope delegations. Partner and external delegated access should be reviewed at every contract renewal and immediately upon engagement closure, not on the standard internal calendar.

Related Terms

Delegated admin rights need lifecycle governance — not just initial assignment

Identity Confluence surfaces delegated admin roles in access certification cycles, identifies ghost admin accounts during lifecycle reviews, and provides unified audit coverage across central and distributed administrative actions.