Tenant Management
What this screen is for
A tenant is an organisation, a business unit or a purpose that owns its own keys, people, applications and policies, isolated from every other tenant on the installation. This screen, opened by the Tenants entry of the sidebar, lists the tenants of your deployment and is where you create one, hand it its first administrator, decide which policies it inherits and which it may change, move it through its lifecycle — activate, suspend, reactivate — enter it as its administrator, and close it.
The four tiles count the tenants listed, those ACTIVE, those SUSPENDED and those still PROVISIONING. Your own platform tenant is not in the list, and a closed tenant leaves it.
What must exist first
This is a platform screen: it is reached in the platform context, and opening it while you are working inside a tenant sends you to that tenant's dashboard instead. Before you work here:
- The permission to read tenants, which shows the sidebar entry, and the permission to list them, which fills the table. The built-in platform administrator, operator, auditor and viewer roles hold both.
- A platform whose first-run setup is complete. Until the key-protection backend has been set up, Create Tenant is disabled and says so, and a request that reaches the platform anyway is refused.
- Separate permissions for each act: creating a tenant, activating, suspending and reactivating one, toggling its policy override, renaming it and closing it. Only the built-in platform administrator holds them. Create Tenant is shown whether or not you hold its permission and the request is refused without it; the lifecycle and close controls are hidden when you do not, and the override switch is shown disabled and says why.
Decisions you make here
Reading the list
Each row shows the tenant's name, its identifier, how many keys and users it holds, its policies, its type, its status and its creation date. Search matches the name and the identifier; the filter narrows by status, Maintenance included. The Type column is Simple or Standard; a tenant created before types existed shows a dash.
The Policies (A/R) column shows the algorithm and rotation templates in force, abbreviated, with a pencil when the tenant's administrator may change them and a lock when only you may. A row reads Locked in place of the template names only when the deployment's policies are locked and that tenant holds no policy of its own; a tenant that has been given one of its own reads its own templates there, on a locked deployment as on any other. When the deployment's policies are locked a banner above the list says so. Clicking the badge opens the full template names and a link into the tenant's detail.
Creating a tenant
Create Tenant opens the Provision Tenant dialog. Two choices in it are permanent: the Tenant Name, which you may change later, and the Tenant Type, which you may not. Standard gives the tenant the full control plane — applications, cryptographic actors, exchange contexts, capability grants, constraint policies, counterparty types, key inventory. Simple gives it applications, internal use cases, key inventory, audit log and settings, and lets the platform compose the rest. To change a tenant's type later you create a new tenant and move the workload; the dialog says so.
You name the first administrator by Admin Email, with an optional Admin Display Name. The administrator is always invited: you never choose their password. For a new address the account is created with no credential, and the dialog shows you a single-use activation link with its expiry and queues an email carrying it; the dialog warns you first when your deployment's email delivery is not ready. The administrator opens the link and enrols their own authenticators.
An address that already has an account — the person belongs to another tenant — is not given a new one: the person becomes this tenant's pending administrator, receives an invitation by email and accepts by signing in with the authenticators they already hold. No activation link is shown. The address of a platform administrator is refused: a platform administrator is never a member of a tenant.
When the deployment's policies are not locked, the dialog also asks which Algorithm Policy and Rotation Policy templates the tenant starts with. Each select opens on Follow deployment policy: leave it there and the tenant is bound to the deployment's policy of that type — to its template when the deployment is on one, or to a snapshot of its effective policy when it was written by hand — and follows it from its first operation; pick a template, DEFAULT included, and the tenant carries that template instead, checked against the deployment policy as a ceiling.
The dialog also carries the checkbox Allow tenant admin to modify these policies after creation, off by default. The checkbox is offered whether or not the deployment's policies are locked. When they are locked, the dialog shows the deployment's templates read-only and no template you could send is used — but the checkbox is: ticking it records the grant that lets the tenant hold a policy of its own, and the tenant is provisioned on the deployment's policy all the same.
On a customer-operated install the dialog also carries Integrations this tenant may configure: the integration families the tenant's own administrators may declare, change and remove for themselves. Nothing is ticked at first, and a family you leave unticked stays yours to configure. The key-protection edition selector is not offered on a customer-operated install: every tenant here uses the backend the environment declares.
Provision Tenant commits the following, in one transaction: the tenant record, its first administrator holding the built-in TENANT_ADMINISTRATOR role, the policy rows when the deployment is unlocked, and the delegated set. It does not provision a key-encryption key: that is created on the tenant's first key operation, so creating a tenant never touches the key-protection backend. It also does not activate the tenant.
Activating a tenant
Every tenant this dialog creates lands in PROVISIONING. In that state nobody in the tenant can sign in, and no cryptographic operation is authorised for it — but you can enter it to configure applications, actors, keys and policies, and its administrator can open the activation link and set a password, which will work once the tenant is active.
Open the tenant's detail and, under Lifecycle, press Activate tenant. From that moment its users can sign in and its actors can operate. Until you do, the Provisioning tile counts it and the row says so.
Suspending and reactivating a tenant
Suspend tenant, offered on an ACTIVE tenant, asks for a Reason for suspension, which is required, recorded in the audit trail against your account and shown to anyone reviewing the suspension later. It stops the tenant using the platform without freezing what it owns:
- Nobody in the tenant can sign in or renew a session, and every cryptographic operation — encrypt, decrypt, sign, verify, re-encrypt, re-sign — is refused on the very next request, including for a token that is still valid.
- Sessions are not ended and administrative reads continue for the rest of a token's life. Key custody stays administrable: a suspended tenant's keys can still be rotated, revoked and archived, so a compromise does not have to wait for reactivation.
Reactivate tenant, offered on a SUSPENDED tenant, asks for no reason and restores everything the suspension withdrew. Both transitions reach the services that enforce them immediately. A transition the tenant's state does not allow is refused, and the refusal deliberately does not say which state the tenant is in.
A tenant in MAINTENANCE is in a key custody window: its keys are moving to another key protection backend. Its applications' cryptographic requests are answered with a retry hint, while its administrators can still sign in. Only the window enters and leaves that state, so neither suspend, reactivate nor close is offered until it ends; suspending a tenant whose window is scheduled but not started cancels the window. Suspending a tenant for non-payment never moves its keys.
Following and planning a tenant's key custody
In the tenant's detail, Key protection ends with Key custody: where the tenant's keys are protected, its open custody move and its progress, how its key-encryption key is rotated, the retired ones still retained, and the history. On an ANKA-hosted deployment, changing the Edition of a tenant that holds keys records a pending move you plan here; a start earlier than the proposed notice needs a reason. A window can be cancelled before it starts and aborted until the keys are live on the destination. On a customer-operated install, custody is changed from HSM / Cloud KMS › Per tenant.
A retired key-encryption key past its retention, with nothing wrapped under it, offers Destroy…. On a Cloud KMS its provider destroys the key object once its waiting period ends, and until then Cancel destruction… returns it to retired; the list shows the date the provider destroys it. On an HSM the key object is destroyed at once, so it is normally already gone and its cancel is refused; the list shows it destroyed on its HSM, awaiting confirmation. If the HSM gave no answer and the object is still on it, Cancel destruction… returns the key to retired. Either way it reads Destroyed once the provider confirms it. After that nothing still wrapped under the key, including in older backups, can be decrypted. A tenant's own key is never destroyed.
Letting the tenant change its policies
In the tenant's detail, Policies shows the algorithm and rotation templates in force and where each comes from, with the switch Let the tenant admin change these policies. On, the tenant's administrator may pick different templates from the catalog or return to the deployment policy; off, only you may do either.
A policy-locked deployment does not change this section: it shows the same templates and their sources, and the switch is offered there too — the lock freezes the deployment's own policies, not whether a tenant may be given one of its own. The same detail lets you rename the tenant, and on a customer-operated install change the delegated integration families.
Entering a tenant
The person icon on an ACTIVE or PROVISIONING row opens Confirm Impersonation, and confirming puts you inside the tenant with the tenant role that mirrors your platform role: PLATFORM_SUPER_ADMIN acts as TENANT_ADMINISTRATOR, PLATFORM_OPERATOR as TENANT_ACCESS_ADMINISTRATOR, PLATFORM_AUDITOR as TENANT_AUDITOR, PLATFORM_VIEWER as TENANT_VIEWER. A custom platform role cannot enter a tenant at all: the icon is withheld, and the dialog says so if you reach it.
Every action inside is written to that tenant's audit trail under your own name, the session token lives 15 minutes, and you can leave at any time. On a customer-operated install no authorisation from the tenant is involved: you enter under your own roles. The icon is not offered on a suspended tenant.
Closing a tenant
With the permission to close tenants, the trash icon opens Close Tenant. Read it literally: closing is permanent and cannot be reversed by anyone, and it is not an erasure. Access is revoked the moment you confirm — its users cannot sign in, its actors cannot obtain tokens, its keys cannot be used — and its keys, applications, actors, credentials and key-encryption key are preserved for audit.
Before you can confirm, the dialog reads what closing affects and shows it to you: what is removed (capability grants, exchange contexts, cryptographic exchanges, actor–issuer bindings, trusted issuers, email domains, the support-access consent), what is disabled but kept (users, applications, cryptographic actors), what is retained (key aliases, by purpose and exportability, and custody records), and how much cryptographic activity is on record.
A figure that could not be read says Not measured, never zero, and the confirm button waits for the read to settle. Key material that cannot be exported is flagged, because there is no way to take it out afterwards.
You type CLOSE, press Close Tenant, and a second dialog asks once more — Yes, close it permanently — with no field to fill. The platform first stops authorising the tenant everywhere, then disposes of its dependents step by step; a step that fails is logged and does not undo the closure. The platform tenant itself cannot be closed, and the dialog says so.
How it relates to other screens
The people and roles of a tenant are administered from inside it. What the platform plane adds — its own operators, appointing an extra tenant administrator, correcting a login identity — lives on the platform users screen:
The templates a tenant inherits, and whether the deployment locks them, are decided on the platform policies screen. What a tenant sees of its own policies is its policies screen:
Inside a tenant you are on the tenant screens with the mirrored role, and the tenant's own settings, users and audit log describe what you see there: