Zammad's user access tokens are convenient for automations that create tickets, read customer conversations, or update knowledge-base content. They also inherit permissions that may include administration. A token created for a narrow service account is easier to contain than a token copied from an administrator who happens to own the integration.
The Zammad API documentation shows token creation with a permission array and an optional expiry. A token value is returned once at creation and is not retrievable later. The documentation examples include ticket.agent and admin, which should be read as distinct risk levels. The API introduction describes HTTP token authentication and endpoint-specific requirements.
Create a token inventory
Record the user, action, label, permissions, expiry, last use, and consuming integration for every access token. Include tokens stored in chatops, monitoring, ticket forms, and local scripts. If the application has an API endpoint to list tokens, protect that endpoint with the appropriate preference permission and avoid printing full token values in the response.
Use dedicated users for integrations. An automation account should have only the roles needed for its tickets, groups, and knowledge-base actions. Keep administrator tokens short-lived and out of routine code paths. A token that can list users or change system settings should have a stronger storage and approval process.
Review the helpdesk data path
A helpdesk contains customer identities, attachments, internal notes, and perhaps authentication details in ticket text. A token that can read tickets may expose a wide data set even if it cannot administer the system. Check group visibility, role assignments, and whether the integration can read all tickets or only a subset.
Review public ticket forms, email intake, and web chat as separate entry points. An unauthenticated customer may be able to create a ticket or upload a file. Apply rate limits, file-size limits, malware scanning, and content moderation where appropriate. Do not assume that a token-based API inventory covers these unauthenticated paths.
What the ZoomEye observation shows
This count-only run used sub_type=all, page 1, and page size 1. app="Zammad" returned 12,764, title="Zammad" returned 5,135, and http.body="Zammad" returned 852,317. The application fingerprint is substantial and the title count is lower, which suggests that custom branding or reverse-proxy behavior can hide the product title. The body count includes references and should not be used as a deployment total.
For owned instances, compare the public fingerprint with the certificate names and helpdesk domains that the organization actually operates. A public helpdesk may be intentional, but its admin path, API documentation, and integrations require separate exposure review.
Verify token behavior
Test an expired token, a revoked token, a token with a missing permission, and a token from another user. Confirm that the error does not disclose ticket contents. Check that the token cannot reach admin endpoints beyond its permission array. Run the test against a staging instance before rotating production credentials.
When a token owner leaves, disable the user and revoke the token. When an integration is retired, remove its scheduled job, stored secret, and downstream account. The API credential is only one part of the lifecycle.