Support Access Reference

What a support grant allows, how long it lasts, how it ends, and what is recorded. The steps on screen are in Give Zonitix support temporary access.

What A Grant Is

This page is about access to your Zonitix app. Hosting your server gives us two other kinds of access, to the server itself and to the hosting-provider account; both are described under What Zonitix Can Reach On Your Server.

A grant is not a separate record. It is stored on one dedicated user account, the support account, which is created the first time an administrator grants access and is reused by every later grant. Until then no support account exists on your instance. There is no built-in support address: the invitation goes only to the address the administrator types.

The Diagnostics Bundle

The bundle is a JSON file an administrator can download and attach to a ticket without granting any access. It is returned to the browser that asked for it and is not sent anywhere else. Its sections are listed in the technical part below.

Before the file is served, any value stored under a name that looks like a credential (a password, key, token, secret, certificate or recovery code) is replaced, and every piece of text has email addresses, IPv4 addresses, key blocks, credentials inside URLs and long random-looking strings replaced with a marker that says the value was redacted. Read the file before you send it.

If something here is not working as you expect, start with When something goes wrong.

Endpoints

All five are session routes on your own instance’s API address, https://<your-instance>-api.zonitix.com. Granting, revoking and saving the address need the administrator role itself; holding a permission is not enough.

The Grant Object

While a grant is live it is the grant field of the status reply. When it ends it moves to history with three more fields: endedAt, endReason (revoked or expired) and endedBy. The latest 20 past grants are kept.

What A Grant Allows

• Read-only (the default). The support account is given eight permissions and nothing else: view_dashboard, view_system, view_logs, view_users, view_groups, view_roles, view_devices and view_reporting. It is put in no group and holds no role.
• Read-only is enforced twice. Apart from the permissions, the gateway lets a read-only support session send only GET, HEAD and OPTIONS, plus refreshing and ending its own session. Any other request answers 403 with "error": "Support session is read-only" and is written to the audit log. A session whose scope cannot be read is treated as read-only.
• Act with a role. With scope: "role" the support account holds that one role and can do what the role allows. The administrator role needs acknowledgeAdministrator: true, and nobody can grant a role they could not assign themselves.
• Fresh credentials for every grant. Each grant sets the password to one that cannot be used, removes the account’s authenticator, recovery codes, passkeys and trusted devices, and ends its old sessions. Support then receives a set-password link that expires after 72 hours, and must set up MFA before signing in. The support account is always asked for MFA and is never offered the trusted-device skip.
• The account cannot be managed any other way. Deleting, offboarding or terminating it from Users or through SCIM answers 409. Its only lifecycle is grant, revoke and expiry.

The Window And How It Ends

• Length. A whole number of hours from 1 to 72. A window cannot be extended: a second grant while one is live answers 409, so the administrator revokes and grants again, which issues new credentials.
• Expiry is checked on every request. Each request the support account makes is checked against expiresAt. After that moment, or after a revoke, the next request answers 401 with "code": "SESSION_NOT_ACTIVE", and the account cannot sign in again.
• Clean-up. A revoke, and a check that runs every 5 minutes for expired grants, do the same thing: suspend the account, remove its roles, permissions and group memberships, end its sessions, cancel an unused invitation, and remove its password, passkeys and trusted devices. Access has already stopped by then; the clean-up is what moves the grant to history.
• Emails. Everyone who holds manage_security is emailed when access is granted, revoked or expires. These emails need a mail server; see Outgoing Email (SMTP). The audit entries below are written either way.
• No mail server. If the invitation cannot be emailed, the reply carries invite.sent: false and a one-time invite.link for the administrator to pass on. The grant itself still stands.

What Is Audited

Every audit entry caused by the support account is tagged source: "support" with supportGrantId and supportScope, whichever part of Zonitix wrote it. How to read and export the log is on Audit Log & Log Forwarding.

Refusals And Error Codes

Diagnostics Bundle Sections

The diagnostics bundle described in the plain part above, under The Diagnostics Bundle, has these top-level sections:

A redacted value is replaced with a [REDACTED…] marker.