PUBLIC PRODUCT DOCUMENTATIONRelease 56.0.0 · 20 October 2026
Support access, with an accountable record
Cuvena provides organisation-scoped support workspaces for authorised platform staff. Staff use their own platform identity. Platform owners have full support access without an authenticator requirement; other support staff require authenticator verification. They do not sign in with a customer's password or create a hidden customer account.
Two access modes
Standard customer-authorised support
Staff request access with a reason, a read-only or administrator access level, and a duration. Customer approval is required by default. An organisation administrator can approve or decline the request in Organisation settings → Support access. Standard requests default to 30 minutes and can be set from 5 to 120 minutes. The approved period begins at approval. An organisation may explicitly change its preference to allow standard requests without individual approval; that is recorded as approval by policy, not as a named person's approval.
Privileged platform support
Separately authorised staff may open an organisation administrator support workspace without an individual customer approval. Platform owners have this permission by default and do not need an authenticator for support access. Other staff require explicit privileged-support permission and authenticator verification. It follows normal session expiry and inactivity controls. Its record clearly states that customer approval was not required. Organisations considering this product should take this privileged access model into account.
Separate workspaces
Support opens in a new tab and stays bound to one organisation and session. Admin remains signed in. A normal customer login and other support sessions remain separate. The workspace identifies the organisation and support mode and provides an exit action. Closing a tab is not the same as ending access; use Exit support access or end the session from its history.
Main audit logs
Support requests, customer decisions, session entry, activity and session ending are recorded in the organisation's main audit log and the platform's main Admin audit log. Records identify the initiating staff member, the customer approver where applicable, timestamps, organisation and linked request/session references. Revoking approval does not replace the original approver's identity. Session history provides convenient access to the same context.
If delivery to the Admin audit log is temporarily unavailable, a durable delivery record is retained for retry. The organisation audit is recorded before the support action proceeds. Audit entries exclude passwords, sign-in codes and session bearer credentials.
Ending access and ownership
Customer administrators and authorised platform staff can end a session. Revoking a standard approval prevents further access through that grant. Removing privileged permission invalidates sessions that depend on it. Ending a session does not cancel an execution already running on a target. Privileged staff with continuing permission can request a new privileged session.
Persistent schedules require a customer owner with the necessary execution permissions, so they can continue after the temporary support session ends. Customer administrators create persistent API tokens, service accounts and event triggers under their own accounts; temporary support sessions cannot own them. Support does not replace a customer's personal sign-in or billing authority.
Current assurance status
This document describes v54 product behaviour. It is not a SOC 2 report, ISO certification, legal compliance opinion or guarantee of a particular deployment's configuration. Independent assessments and operating evidence are separate requirements.