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 working inside a tenant sends you to that tenant's dashboard instead. Before working here you need the permission to read tenants, which shows the sidebar entry, and the permission to list them, which fills the table; the built-in platform super administrator, operator, auditor and viewer roles hold both. You also need a platform whose first-run setup is complete: until the key-protection backend is set up, Create Tenant is disabled and says so, and a request that reaches the platform anyway is refused.
You need 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 super 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 nothing is sent until the tenant is active: activating it emails the administrator a single-use activation link, which they open to enrol their own authenticators. The dialog warns you first when your deployment's email delivery is not ready.
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 once the tenant is active and accepts by signing in with the authenticators they already hold. A person who belongs to another tenant but has never activated holds none yet, so they are emailed an activation link instead. 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.
The result then reads Tenant created, not active yet. With the permission to activate tenants it offers Activate and send invitation, which activates the tenant now, and Keep in provisioning, which closes the dialog and leaves it as it is. It warns you first when email delivery for this tenant is not ready. On a deployment that activates tenants on creation, the tenant is ACTIVE at once: the email leaves, and the dialog shows a new administrator's single-use activation link with its expiry.
Activating a tenant
A tenant this dialog creates lands in PROVISIONING, unless your deployment activates tenants on creation. In that state nobody in the tenant can sign in, no cryptographic operation is authorised for it, and no invitation or link exists for its members, so its administrator has nothing to open yet. You can still enter it to configure applications, actors, keys and policies.
Open the tenant's detail and, under Lifecycle, press Activate tenant. From that moment its users can sign in and its actors can operate, and everyone waiting for an invitation receives it by email; each link's validity starts now, however long ago the tenant was created. Until you do, the Provisioning tile counts it and the row reads Invitation waiting for tenant activation.
The outcome says what was sent. When the first administrator is new to the platform and belongs to no other tenant, you are also shown their single-use activation link with its expiry, so you can hand it over if the mail does not arrive; no other member's link is ever shown. When there is no link to show, it says the invitation was sent, and when nobody was waiting, only that the tenant is active. A refused activation changes nothing: the tenant stays PROVISIONING, nobody was sent anything, and the message says why.
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. No new invitation or activation link is mailed while the tenant is suspended: a person added then, or whose link expires then, waits for the reactivation. A link sent before the suspension stays valid; opened during it, it tells the person that the organization is not available right now and that the invitation is still valid.
Reactivate tenant, offered on a SUSPENDED tenant, asks for no reason and restores everything the suspension withdrew. It also mails a link to every member still waiting, and the confirmation states how many invitations were sent. 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…. The platform holds every destruction for the deployment's waiting period (30 days by default) without calling the key's provider or HSM: the list shows Destruction due on with the date the period ends, and until then Cancel destruction… returns the key to retired.
When the period ends the platform checks the key again. If it wraps key material again, shares its key object with a key in use, belongs to a tenant whose custody is moving, or the object under its name is not the recorded one, nothing is destroyed, the key is retired again and a platform alert is raised; destroying it then takes a new request, and after an object that is not the recorded one, only once the token or key service has been investigated.
Otherwise the platform sends the destruction to the key's provider. Until the provider's answer is recorded, the list shows Sent to the provider and Cancel destruction… is disabled. An HSM then destroys the key object: the list shows Destroyed on the HSM, awaiting confirmation, with no cancel.
A Cloud KMS starts its own waiting period, which adds to the platform's: the list shows At its provider with the provider's date, and Cancel destruction… cancels it at the provider until then. 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.
On a deployment ANKATech operates, the same detail's Details tab lists the domains the tenant claimed under Verified email domains. Only a verified one routes a sign-in to its identity provider, and the tenant cannot verify its own. With the permission to manage platform identity providers, Claim domain adds a claim, Verify opens Verify this domain?, and Remove domain asks first. A domain verified for one tenant cannot be verified for another.
A customer-operated install has no such section: there the platform does not claim, verify or remove a tenant's domains, and federated sign-in is admitted against the deployment's own verified domains, kept on the Verified domains tab of Platform Settings.
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 at most 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 give a reason, which is required and recorded in the audit trail, type the tenant's name exactly as shown, 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: