What is the difference between a platform administrator and a customer administrator in delegated administration?

A platform administrator owns global capabilities, delegation rules, and non delegable actions across the SaaS service. A customer administrator works only inside one tenant and can manage the permissions, roles, and settings the provider has explicitly allowed. The distinction matters because delegated administration is not shared ownership. It is controlled local administration under a provider defined boundary.

What the Delegation Boundary Actually Means

delegated administration is a boundary model, not a shared control plane. The platform administrator sits above that boundary and defines what can be delegated, what remains global, and which actions are reserved to the provider. The customer administrator operates inside the tenant boundary and can only exercise the permissions the platform exposes to that tenant.

That difference matters because the two roles answer different questions: who governs the service, and who governs one customer environment within it. A platform administrator can shape the rules of delegation itself, while a customer administrator can only work within those rules. If the boundary is misunderstood, teams tend to overestimate their ability to change global settings or understate provider control.

The provider-defined boundary is also what keeps delegated administration from becoming uncontrolled administrative sprawl. One useful way to think about it is that the platform role sets the guardrails, and the customer role manages local operations, roles, and settings inside those guardrails. Ultimate Guide to NHIs — What are Non-Human Identities reinforces the broader principle that access boundaries, ownership, and lifecycle control determine who can safely administer what.

Why Platform and Customer Admins Have Different Powers

A platform administrator typically owns service-wide configuration, delegation policy, tenant structure, and any action that would affect multiple customers or the provider’s security model. That can include enabling or disabling administrative capabilities, setting global restrictions, and managing non delegable actions that are too sensitive to be handed to a tenant.

A customer administrator is narrower in scope. They usually manage users, roles, settings, and delegated permissions inside one tenant, but they cannot alter the platform’s underlying guardrails. In practice, this means the customer admin may be powerful within the tenant, yet still unable to touch the provider’s global controls or another tenant’s environment.

The practical consequence is that the same label, “administrator,” does not imply the same authority. Delegation creates a controlled subset of admin power, not equivalence. For teams used to shared infrastructure or traditional on-premises admin models, that distinction is easy to miss until an expected change request is blocked by the platform boundary.

Delegated Administration Fails When Ownership Is Assumed Instead of Scoped

Misunderstanding the split between platform and customer administration creates operational and security risk. If customer teams assume they control global policy, they may design workflows around permissions they do not actually have. If platform teams assume tenants understand the limits, they may expose capabilities that are broader than intended or fail to document which actions remain reserved.

The most common failure mode is privilege confusion: a tenant administrator is treated as if they can manage everything relevant to the service, when in fact they can only manage a delegated subset. That can lead to access requests being routed to the wrong team, unsafe workarounds, or incorrect assumptions about who can approve, revoke, or override settings.

For practitioners, the real control question is not “who is an admin?” but “which actions are delegated, which are tenant-local, and which remain provider-only?” Treating delegated administration as if it were shared ownership almost always produces governance gaps, especially when escalation paths and exception handling are not clearly documented.

Risk and Threat Considerations

Delegated administration concentrates authority at the boundary between provider control and tenant control, so mistakes there can create privilege creep, misconfiguration, or overreach. The risk is not only unauthorized access, but also false confidence, when a tenant believes it can enforce a control that only the platform can actually change.

Failure mechanism: delegated roles are granted broader operational power than intended, or customer administrators are left with unclear limits on what they can approve, modify, or override. That can produce control bypass, inconsistent policy enforcement, and administrative actions that exceed the delegated trust model.

Impact: the provider may lose consistency across tenants, and the customer may mismanage local access or settings under an assumption of authority it does not have. At scale, this can turn a clean delegation model into a governance and security problem rather than a convenience feature.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organizational Context	Delegated admin depends on clear service and tenant ownership boundaries.
	PR.AA-01 — Identity and Access Management	The question is about who can administer what within a scoped access model.
Recommendation — Define which administration rights belong to the provider versus the tenant. Enforce role boundaries so customer admins only receive explicitly delegated permissions.
CIS Controls v8	6 — Access Control Management	Delegated administration is fundamentally a control over administrative access and scope.
Recommendation — Review administrative roles regularly and remove any rights beyond the delegated boundary.
NIST Zero Trust (SP 800-207)	5 — Identity and Access Management	Zero trust requires explicit, policy-based authority boundaries for administrative actions.
Recommendation — Bind admin actions to explicit policy and tenant context before granting execution authority.

Practitioner Guidance

What to verify: confirm the exact action set for each role, especially the line between tenant-local administration and provider-only operations. If a task affects multiple tenants, global policy, or delegation itself, it should not sit in the customer admin scope unless the service explicitly says so.

Common mistake: teams often document titles instead of privileges. “Customer administrator” sounds broad, but what matters is the actual permission boundary, the escalation path for out-of-scope tasks, and whether non delegable actions are clearly excluded from tenant control.

Decision rule: if the action changes the service model, delegation rules, or another tenant’s security posture, treat it as platform-owned. If it only changes one tenant’s users, roles, or approved settings, it belongs in the customer-admin domain.

Practitioner takeaway: delegated administration is safe only when the boundary is explicit, tested, and documented, because the difference between platform and customer administration is authority scope, not job title.