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 rename needs the permission to update your tenant, held by the built-in tenant administrator role. 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 Changes 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 Changes 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, and what is 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 in these panels is written to your audit log under its own event type.

Claiming your email domains

The Identity federation panel lists your tenant's Verified email domains, each marked Verified or Unverified. A domain routes a sign-in to your identity provider only once verified, and your own provider can be enabled only once at least one domain is. With the permission to configure identity federation you enter a domain, such as example-bank.com, and press Claim domain, or remove a claim with Remove domain after confirming it.

A claim is created unverified, and your tenant cannot verify it: on a SaaS deployment a platform administrator does, once your organization's ownership is established. On a customer-operated deployment a tenant's email domains take no part in sign-in, which uses the deployment's verified domains, declared by the platform operator; your provider can be enabled once the deployment holds one. There the panel reads Email domains have no effect on this deployment, offers no field to claim one, and keeps Remove domain for those listed. A refusal shows where you acted, keeping what you typed.

Deciding who may enter through your identity provider

Below the domains, Who may enter through your identity provider has three blocks. Email to role grants a role to one address, Domain to role to every address of a domain, and Domain guard grants nothing. Each block adds an entry with Add rule and removes one after a confirmation (Remove email rule, Remove domain rule, Remove permitted domain).

Domain guard is an allowlist per provider. A provider with no permitted domain lets every domain past the guard; its first permitted domain narrows sign-in through it to that domain, each further one admits its own domain as well, and removing the last one lets past again every domain it had kept out. Past the guard, the rules and group mappings still decide who is admitted.

The section needs the permissions to read your providers and your federation mappings. Rules need the permission to manage federation mappings, and permitted domains the permission to configure identity federation; without them the lists show no control. You can grant only a role whose every permission you hold, and a domain rule offers no role with a platform or wildcard permission. Every change applies from the next federated sign-in. On a SaaS deployment, a platform operator in a support-access session cannot add a rule, nor add or remove a permitted domain; your administrator does.

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.

The credential of your own key must be able to read the key's state and its versions, besides wrapping and unwrapping: the key custody check reads them after a restore or an upgrade, so binding the backend and rotating the credential prove them against the declared key. Grant it:

AWS KMS: kms:DescribeKey, plus kms:ListKeyRotations for a key with imported key material (origin EXTERNAL).
Google Cloud KMS: cloudkms.cryptoKeys.get and cloudkms.cryptoKeyVersions.list. The role roles/cloudkms.cryptoKeyEncrypterDecrypter includes neither.
Azure Key Vault and Managed HSM: nothing new; the get key permission already required serves it.

On AWS KMS the key is declared by its key ARN; an alias ARN is refused. A key this deployment created or uses for its own key custody is refused too. The full list of grants, with why each is needed, is in Per-cloud client prerequisites, in the customer documentation. A refused credential or key changes nothing:

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 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 platform-side actions are not shown, except those taken inside your tenant through support access, marked Platform-mediated and naming the operator by a reference, not 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.