Last Platform Super Administrator

URI: https://docs.ankatech.co/errors/last-platform-super-admin-would-lock-out
HTTP Status: 409 Conflict

When you see this

The platform always keeps a PLATFORM_SUPER_ADMIN who can sign in. The change you sent would leave none: every platform administrator holding the role who can sign in today would be unable to sign in after it.

A holder counts when all of the following are true after the change:

their platform membership is ACTIVE, holds PLATFORM_SUPER_ADMIN, and their identity is not deleted;
they are not a designated break-glass administrator: a designated administrator signs in through the emergency-access entry only, and the break-glass entry does not count;
they still have at least one ordinary route the platform authentication posture admits after the change: password + TOTP where the platform admits it, a usable passkey carrying the properties the platform requires, or a link to an identity provider that is approved for platform sign-in, enabled and part of the platform's federated entry.

The change is refused only when at least one holder can sign in now and none could after it. Every write that can take the role or a route away from a holder asks the same question, whoever the caller is, the holder included. The check is made while the platform's authentication settings are held, so two administrators demoting each other, or removing the last two routes, at the same time cannot both succeed.

The one exception is removing the trust anchors of a deployment identity provider, the remediation of a compromised or misconfigured provider. It is applied even when it ends the last ordinary route of every holder, as long as a designated break-glass platform administrator who also holds PLATFORM_SUPER_ADMIN holds the authenticators to sign in through emergency access. A designee without the role could sign in but could not administer the platform, so it does not admit the removal; without such a designee it is refused with this error. When it is applied that way, its audit record carries entryGuardBypassed: break-glass-remediation and superAdminsWithoutRoute, the number of holders left without an ordinary route, and the platform security alert PLATFORM_FEDERATED_ENTRY_LOST is raised with the same count in its details.

Common Causes

Replacing the roles of the last platform super administrator with a set that leaves out PLATFORM_SUPER_ADMIN (assignUserRoles on the platform tenant).
Suspending (updateHumanUser) or removing (deleteHumanUser) that administrator's platform membership, or deleting their identity (deletePlatformIdentity).
Cancelling the pending activation of that administrator's platform membership (deletePlatformPendingActivation on the platform tenant). This check comes before the activation check, so the last holder's cancel answers this error rather than activation-not-cancellable.
Unlinking that administrator's federated identity when the link is their only way in (unlinkFederatedIdentity on the platform tenant).
Editing, disabling or deleting the deployment identity provider they sign in through, or withdrawing its approval for platform sign-in.
Narrowing the admission of the deployment identity provider they sign in through: deleting a group→role mapping (deletePlatformMapping) or an admission rule (deletePlatformAdmissionRule), or adding a login domain guard (createPlatformDomainGuard). A linked administrator keeps that route only while the domain of their stored address passes every domain guard of the provider, and an EMAIL rule matches the address, a DOMAIN rule matches its domain, or the provider still holds at least one group→role mapping (the groups a provider asserts are known only at sign-in, so any remaining mapping counts). Only a change that ends a route the current admission gives is refused; adding a mapping or a rule, and deleting a domain guard, are never refused.
Changing the platform authentication posture or the deployment authentication allowance so that their passkey or password + TOTP is no longer accepted.
Removing their last usable passkey, their authenticator app or their password, by an administrator or by the person on their own Security page (deleteAccountAuthenticator, deleteAccountPassword).
Designating that administrator as a break-glass identity, which leaves them the emergency-access entry only.
Removing the trust anchors of the provider they sign in through while no designated break-glass platform administrator who also holds PLATFORM_SUPER_ADMIN holds the required authenticators.

Response Example

{
  "type": "https://docs.ankatech.co/errors/last-platform-super-admin-would-lock-out",
  "title": "Last Platform Super Administrator",
  "status": 409,
  "detail": "This would leave the platform without a PLATFORM_SUPER_ADMIN who can sign in. Give another active platform member PLATFORM_SUPER_ADMIN and a way to sign in first; nothing was changed.",
  "instance": "/api/v3/admin/tenants/00000000-0000-0000-0000-000000000001/users/9c8b7a65-4321-4def-9876-0123456789ab/roles",
  "extensions": {
    "requestId": "6a2f9c1e-3d4b-4e8a-b5c7-0f1e2d3c4b5a"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details. The detail is fixed and names nobody.

Nothing is changed, and the refusal is recorded in the platform's administrative audit trail as a DENIED change with the reason last-platform-super-admin.

How to Resolve

Give another ACTIVE platform administrator PLATFORM_SUPER_ADMIN, and make sure they can sign in with a passkey, password + TOTP, or an approved platform identity provider.
Retry the change.

To replace an authenticator of the only super administrator, register the new one first, then remove the old one.

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.