Tenant Settings

What this screen is for

This screen is your tenant's own record: its name, identifier, status and size, the integrations it has declared or inherits, where its access controls live, and the administrative changes made to it. It is opened by the Settings entry of the sidebar and has four tabs: General, Integrations, Access & policies and Activity.

It is a tenant-plane screen and holds no platform setting. Rate limits, audit retention, delivery defaults and every other value declared for the whole deployment belong to the platform operator and are not shown here, not even read-only. The one value on this screen that you can change is the tenant's name; everything else is a fact reported by the platform or a door to another screen.

What must exist first

Both SIMPLE and STANDARD tenants use this screen. A platform operator working inside your tenant reaches it too, and sees your tenant's name, never the platform's. Before you work here:

The permission to read your tenant's record, which is what issues the read. Without it the sidebar entry may still appear if you can update the tenant, but the General tab says that reading the record is not part of your access and requests nothing.
The permission to update your tenant, held by the built-in tenant administrator role, for the rename. Without it the name is shown as a fact, not as a disabled control.
Each tab beyond General gates itself: the integration rows follow their own read permissions, the Activity tab needs a role that can read the governance trail, the support-access state on Access & policies needs the permission to read support access, and its sign-in requirements need the permission to read the authentication policy, held by every built-in tenant role; changing them needs the permission to manage it, held by the tenant administrator and the access administrator.

Decisions you make here

Renaming the tenant

On General, the Identity zone shows Tenant Name as a field with a Save button, which is enabled only once the trimmed value differs from the current name and is not empty. The name is one to 255 characters, with single spaces between words; another tenant's name, compared regardless of case, is refused, and the refusal is shown under the field with what you typed still there.

The change is applied when you press Save and this page re-reads the record at once, so the heading and the breadcrumb show the new name. The name shown in the console's own header is read when your session starts and follows at your next sign-in or page reload. The change is written to your audit log. Audit events identify your tenant by its identifier; the name is not among the fields they carry.

The rest of the zone is read-only: the Tenant ID with a copy button that reports whether the copy succeeded, the Created and Last changed dates, and the Administrative contact, which is the address of your administrator user or says none is configured. A status chip beside the name reports PROVISIONING, ACTIVE, MAINTENANCE, SUSPENDED or CLOSED exactly as the platform did, or says the record carried none. Suspending or closing a tenant is a platform-operator action and is not offered here.

Usage reports the number of cryptographic keys and of human users your tenant holds, excluding deleted ones, with the time the figure was measured. A figure the read did not carry is shown as Not available, with the note that it is not zero.

Reviewing integrations

Integrations lists six surfaces — Identity federation, Trusted issuers, Delivery providers, SIEM/XDR forwarding, Observability export and Key protection — each with a verdict read from the platform: how many are declared here, that the configuration is inherited from the deployment, that nothing is declared, or that the surface was not read. The action of a row, Manage, Declare or Review, opens that surface in a panel over this page; the panel is the same one the surface has elsewhere and says which tenant it is about.

A row you cannot act on keeps its control and says why: your access does not include it; the capability belongs to a higher edition, or only partly, in which case what is already declared can be reviewed; the surface does not apply to this kind of deployment; or, on a customer-operated deployment only, the platform operator has not delegated that family to your tenant. Delegation is never asked on a SaaS deployment, where your edition decides. Nothing already configured is withdrawn by any of these.

Every declaration, change and deletion made through these panels is written to your audit log under its own event type.

Changing what protects your keys

Once your tenant holds keys, what protects them changes only through a key custody move, shown under Key custody in the Key protection panel: where your keys are protected, the open move and its progress, how your key-encryption key is rotated, the retired ones still retained, and the history. A move that waits for you — a destination to choose after an upgrade, or your consent to a downgrade — opens the panel with Review, even while your current Edition does not include your own KMS.

On an ANKA-hosted deployment you choose between the ENTERPRISE tier managed by ANKATech and your own key management service, accept a move off your own KMS with Accept and schedule…, or bring or change your own KMS. Your key is declared with its service, key identifier and credential, which is never shown again, and is tested before the move is recorded. Nothing moves until you schedule the window, which may start at once. On a customer-operated deployment these actions need the platform operator's delegation.

On an ANKA-hosted deployment you can also Roll back… to a key-encryption key you left while it is still retained, when the roll back concerns your own KMS: back to an own key you left, or from your own key back to the ENTERPRISE tier you left. A roll back between ANKATech-managed tiers is the platform operator's.

During a window your tenant is in MAINTENANCE: your applications' key operations are answered with a temporary 503 and a retry hint, while you can sign in and follow the progress. A screen whose read the window pauses shows Temporarily unavailable rather than an error; key lists and key details stay readable. You can cancel a move before it starts, and abort it until the keys are live on the destination.

Finding your access controls

Access & policies opens with How members sign in, the one control on this tab that changes your tenant (below).

Under it is a list of six destinations, each a link: cryptographic policies, applications, roles, capability grants, support access and the audit log, with one line saying what each is for. The list is never shortened by your access: a destination you cannot read stays listed, marked with the reason, so that you can see the capability exists and ask for it. The support-access row also states whether a support window is open, or that this could not be read, without your leaving the page.

How members sign in sets which sign-in methods admit a person to your tenant — Passkey, Password and authenticator app, or both — and the Required passkey properties, such as a hardware-backed or attested passkey. It applies to every member and every role, and only after the person's password or passkey is verified, so it never reveals to anyone which tenants a person belongs to.

Where members sign in decides which authority admits them: Here only (the methods below; an identity provider lets nobody in), Here or through the identity provider (the methods below, or the provider a member is linked to), or Through the identity provider only (a member linked to the provider signs in only through it; the members you designated for break-glass access enter through Emergency access with their security keys). With none chosen, your tenant is Here or through the identity provider.

Through the identity provider only needs an active OIDC or SAML provider, your own or the deployment's you inherit, and a ready break-glass identity: an active designated member holding the deployment's minimum of security keys or device-bound passkeys. Without them it is refused with the reason.

Your administrators, anyone whose roles allow a change, carry a second factor through the identity provider too. They enter on the provider's sign-in alone only when the provider is trusted for MFA and its sign-in proves it; otherwise they also confirm with a passkey or an authenticator app code, or add one. Whether your own provider is trusted is chosen when you declare it, and cannot be changed afterwards; a provider you inherit is set by the deployment's operator. While your tenant's quorum approval is on, a trusted declaration waits for your approvers and cannot include the provider's secret, so an OIDC provider cannot be declared trusted with its client secret: declare it not trusted, with its secret, and your administrators confirm with a passkey or code after it. Members who only read keep signing in on the provider alone.

The Break-glass access panel below shows whether it is ready, each designated member with their keys and last break-glass sign-in, and recommends a second key for a member holding one. Here only is refused while members are restricted to the identity provider on the users screen.

In effect for every sign-in shows the result once the deployment's own allowance is applied: your tenant can only restrict what the deployment allows. With nothing selected for your tenant, its members sign in as the deployment allows. Identity providers from says whether the providers are your tenant's own, the deployment's (inherited), or none. When they are inherited, the panel warns that an outage of the deployment's provider stops sign-in through it for the platform and every inheriting tenant at once.

A person whose authenticators no longer meet the requirements is asked, at their next sign-in, to add one that does. Save replaces the requirements. A combination nobody could satisfy — no method at all, a property required while passkeys are not admitted, or a method the deployment forbids — is refused with the reason, and nothing is saved. Every change is written to your audit log with the values before and after.

Reading the governance trail

Activity shows the administrative changes made to this tenant and from which plane they were made — by your own administrators or by a platform operator. It is drawn from the same signed events the audit log holds, limited to the governance actions the platform discloses about a tenant, with a filter by plane.

On an ANKA-hosted deployment the platform operator's own platform-side actions are not shown, except those taken inside your tenant through support access, which are marked Platform-mediated and name the operator by a reference rather than by name. Without a role that can read it, the tab says so.

How it relates to other screens

The destinations of Access & policies are screens of their own, and the support window this page reports is decided on one of them:

The people counted under Usage are managed on the users screen, and the keys on the key inventory: