Give tenant admins control without platform privileges

Tenant administration should be a bounded delegation inside one tenant, with platform-only powers kept in a separate control plane. Define permissions by action and resource, constrain which permissions may be delegated, and prevent administrators from changing the rules that authorize their own elevation.

Draw the boundary around effects

Start with four principals: platform operator, tenant owner, delegated tenant administrator, and member. Then classify actions by their possible effect. Member invitations, group membership, and ordinary role assignment usually stay within a tenant. Verified-domain ownership, billing liability, identity-provider trust, data export, tenant deletion, and cross-tenant integrations can affect legal, financial, or platform boundaries and deserve separate controls.

The NIST glossary entry for least privilege defines it as restricting users or processes to the minimum privileges needed for assigned tasks. Apply that principle to administration itself. A help-desk administrator may reset a member’s access but should not manage billing. An integration administrator may rotate one connector’s credentials but should not claim a domain. Avoid a single tenant_admin role that quietly accumulates every future capability.

For each permission, record who can hold it, who can grant it, its maximum scope, whether step-up authentication is required, and whether it can be performed on the actor’s own role. This becomes the delegation matrix and the basis for tests.

Prevent self-escalation through indirect paths

Blocking assign platform_owner to self is not enough. Check whether an administrator can create a group that maps to a stronger role, edit the mapping, invite an identity they control, change the tenant’s identity provider, or transfer ownership through a sequence of individually permitted actions. Evaluate the final effect and apply separation of duties to high-impact transitions.

The OWASP Authorization Cheat Sheet recommends least privilege, creating authorization tests, and deny-by-default guidance. Enforce the permission at the service that commits the change, not only in the admin interface. Every new administration endpoint should start denied until its delegation rule is explicit.

Use immutable tenant identifiers in authorization decisions. A custom domain is an attribute, not the security boundary itself. Domain verification should require proof and should not let one tenant claim a domain already bound elsewhere. Treat changing SSO configuration as a trust change: stage it, validate it, and retain a recovery path controlled outside the modified provider.

Make sensitive transitions deliberate

Require step-up authentication and fresh authorization for owner transfer, billing changes, exports, identity-provider changes, and destructive operations. Some transitions may need approval from the current owner or a second administrator. Use short-lived invitations with an explicit target identity, tenant, role, inviter, and expiry. Never let an invitation confer permissions broader than its issuer may delegate.

Audit both successful and denied administrative actions with actor, tenant, target, before-and-after role state, delegation path, and correlation ID. Notify owners about high-impact changes and give them a fast revocation path. Periodically identify roles no longer used and permissions that no workflow can justify.

Turn the matrix into executable checks

Choose ten high-impact tenant actions. Write allowed actor roles, resource scope, delegation rule, step-up requirement, and prohibited self-action for each. Add tests for cross-tenant identifiers, nested groups, ownership transfer, invitation reuse, and role changes performed concurrently. Then expose an explanation in the UI: who granted this administrator the capability and where can it be revoked?

Check concurrent administration

Two administrators can race: one removes a role while another uses it to create an invitation. Bind sensitive changes to a policy revision and re-evaluate at commit. Test owner removal against owner transfer, simultaneous domain claims, invitation acceptance after issuer demotion, and deletion of the final recovery administrator. The invariant is that every committed transition leaves a valid, recoverable tenant state and no action keeps authority that was revoked before commit.

If you are designing this now, pick your ten highest-impact tenant actions first and turn them into a delegation matrix before you add another broad admin role.

Reviewed September 2026.