Protected accounts and delegation
Protected identities prevent routine tenant administration from becoming an ownership or platform takeover path. Treat a hidden action or refused update as an authorization decision, not a broken form.
Protection matrix
| Target/action | Current boundary |
|---|---|
| Administrator-target discovery/read | Needs admin.view; ordinary user lists can omit these targets |
| Administrator-target update/delete/lock/unlock | Corresponding administrator authority is checked |
| Create a user with an administrator role | Additional admin.create checks apply |
| Newly assign an administrator role | Additional admin.update and delegation checks apply |
| ADMIN role name/code | Fixed; tenant rename/delete is refused |
| ADMIN description/permissions | Bounded management with role.update, admin.update, tenant.permission.grant |
| SUPER_ADMIN role or owner/platform-bearing role | Tenant edit/delete/assignment restrictions apply |
| SUPER_ADMIN account identity, enabled state, deletion, demotion or manual lock | Operator-only boundary; tenant account administration cannot change these |
| Owner business-unit scope | Separate scope-management surface; requires administrator target authority |
An administrator target is broader than a role named ADMIN: administrator powers and owner/platform-bearing roles also matter. Renaming a custom role does not remove its protection.
Owner access example
Sara can manage approved permission delegation, but Ali cannot turn an ordinary user into Sara's replacement by assigning SUPER_ADMIN. The platform operator uses the owner replacement procedure, which disables the old owner and preserves history. The replacement must complete a new invitation.
When an owner cannot sign in
Automatic failed-login locking can still apply to an owner. An authorised unlock operation may be possible with the corresponding authority, but if no authorised tenant account can log in, use operator recovery. Do not attempt to remove protection or create an unapproved duplicate owner.
The tenant Authorization detail page does not present every backend authentication operation. Administrative lock/unlock endpoints exist under /api/v1/auth/lock/{username} and /api/v1/auth/unlock/{username} for authorised support integrations. This guide does not invent a lock button in the Authorization Users register. Password recovery uses the verified operator setup-link workflow.
Record who requested and approved sensitive access changes in your internal process. This recommendation does not imply a generic two-person approval queue is built into role editing.