Support Access
What this screen is for
On a SaaS-hosted deployment a platform operator cannot enter your tenant: the exchange that would let them act as your organisation is refused. This screen is where you lift that refusal, for a bounded time, so that ANKA support can sign in as your tenant — an impersonation session — and where you read what was done during every such session. It is written for the moment you have asked ANKA for help with something they cannot resolve from their side.
The panel states one of three facts about your tenant: nobody from ANKA can act as your organisation; an authorisation is live and nobody is inside; or a support session is open right now. A fourth state says the status could not be read, which is not a claim that nothing is authorised.
What must exist first
Both SIMPLE and STANDARD tenants use this screen. It applies to SaaS-hosted deployments only: on a customer-operated deployment the platform administrator is your own organisation's engineer, reaches your tenant without any grant, and the screen says so instead of offering a control that would gate nothing. The sidebar entry is hidden there. If your session does not say how the platform is operated, the screen asserts nothing in either direction.
Before you work here:
- The permission to read support access, which shows the state panel. The built-in tenant administrator, access administrator, auditor, key manager and viewer roles hold it. That is who may read your grant; which platform roles it admits is answered under Authorising support access below.
- The permission to manage support access, held by the built-in tenant administrator role, for both authorising and withdrawing. The two deliberately share one permission: a role that could authorise but not withdraw would depend on the platform to undo its own decision. Without it the buttons are shown disabled and say why.
- An audit-reading role, for the session history at the foot of the page. A viewer who holds the read permission but not that role sees the state panel and a history that says it cannot be loaded for that reason.
An operator already inside your tenant under a support session cannot authorise support access from there: the request is refused, because it would extend their own window.
Decisions you make here
Authorising support access
Authorise support access asks For how long, between 1 and 24 hours with 8 proposed, and Why, a note of up to 512 characters that is required. A window above 24 hours is refused rather than shortened. The note is kept for your own record: it is never shown on the platform's list of authorising tenants, never carried in an audit event, and withheld from an operator reading your grant from inside a session.
An authorisation names no person. It admits the platform roles PLATFORM_SUPER_ADMIN, PLATFORM_OPERATOR, PLATFORM_AUDITOR and PLATFORM_VIEWER, and each session is mirrored to the tenant role that matches the operator's own: TENANT_ADMINISTRATOR, TENANT_ACCESS_ADMINISTRATOR, TENANT_AUDITOR or TENANT_VIEWER. The grant never raises what a session may do above that role.
Only one authorisation exists at a time. Declaring a second while one is live is refused; withdraw the first. A lapsed one is cleared and the new declaration proceeds. The declaration is written to your audit log, and an email notice is sent to you — the administrator who declared it — when it is authorised, when a session starts and when a session ends.
What a support session can and cannot do
Inside the window, each session token lives at most 15 minutes and never beyond the moment your window ends; re-entering requires the authorisation to still be live. Before entering, the operator must have confirmed their identity within the last few minutes with a passkey or an identity provider ANKA approved; a password never suffices. Every action is written to your audit trail as the operator's, marked as done through support access, and the history below lists them per session.
The session also ends when the operator signs out of the platform, or when ANKA withdraws their authority (their platform account suspended, removed or reset, or their platform role taken away). You receive the session-ended notice.
A session mirrored to TENANT_ADMINISTRATOR can do most of what your own administrator can, including creating, rotating, revoking, suspending and archiving keys, and completing the removal of a key you had already marked for destruction once its waiting period has passed. On a SaaS deployment it is refused, by the platform and as the first thing each request checks, on the operations that would move key material or outlive your window:
- Importing keys or keystores, analysing a keystore, and marking a key for destruction or cancelling that marking.
- Creating or changing users, regenerating an activation, assigning roles to users or actors, creating or editing roles, creating a capability grant or activating an exchange.
- Issuing or rotating actor credentials, creating an internal use case, and binding or trusting workload identities.
- Declaring or changing identity providers, email domains, federated links, notification providers, observability backends and SIEM/XDR destinations.
- Authorising support access itself, and enrolling or verifying the impersonated account's own second factor.
Withdrawing an authorisation
Withdraw authorisation asks you to confirm and always succeeds, including when nothing is authorised. Every session still open under the authorisation is ended at once: its token is blacklisted first, so the operator's very next request is refused, and the end is written to your audit trail. If the platform cannot blacklist a token, nothing is withdrawn and the dialog reports the refusal so you can retry — a withdrawal that left a working token is the one outcome this control never produces.
The record of what was done is kept and stays readable below. A session whose own token had already expired when you withdrew is recorded as ended because The window closed, not as withdrawn by you: that is what happened to it.
If you never withdraw, the authorisation ends by itself when the window closes, and a sweep the platform runs every few minutes closes any session that outlived its token.
Reading the session history
Support sessions is read from the signed audit events, not from the authorisation, so it survives withdrawal and stays readable afterwards. Choose the last 7, 30 or 90 days. Each session shows the Operator who actually entered, the Window it was open, whether it is still Open, why it ended — the operator ended it, you withdrew the authorisation, or the window closed — and the Actions taken, each as an entity type, an operation and a time. A session with no recorded action says so.
On this deployment the operator appears as Platform operator followed by a short reference, never by name. The reference is the same for every session and action of one operator, so it tells operators apart, and ANKA can answer for each one when you quote it.
An authorisation that lapses with nobody entering leaves no session and no row here. The evidence that nothing happened is the declaration in your audit log with no session beside it.
How it relates to other screens
Your tenant's Settings screen shows on its Access & policies tab whether a support window is open, and opens this screen:
The same actions a session took are in the full trail of your tenant, and a support session cannot create a user or change anyone's roles: