Zendesk Security Guide: SSO, Roles, API Tokens, Audit Log

A Zendesk account holds years of customer conversations, identity documents and attachments, and the credentials that reach it through the API are often less protected than the agents who sign in to it. Support platforms sit at the junction of customer data, email and third-party integrations, which makes them an attractive target for anyone who wants bulk personal data or a trusted channel for phishing. This guide covers the Zendesk controls that matter for security: sign-in and SSO, team member roles, API tokens and OAuth clients, the audit log, session and IP settings, and the misconfigurations that keep recurring. It is written for Zendesk administrators, SaaS security teams and identity engineers. It goes deeper than the general SaaS Security Guide, which it does not repeat. Setting names and API fields were checked against Zendesk documentation on 27 October 2026; Zendesk changes plans and menus regularly, so confirm on your own account.

Key takeaways

API tokens are being retired. Zendesk documentation states that API tokens unused for 30 days are deleted automatically from 28 July 2026 and that all API tokens stop working by 30 April 2027, so every integration needs an OAuth migration plan now.
An API token is an admin password. Zendesk says API tokens act as passwords and can be used to impersonate any user in the account, including admins, so one leaked token exposes the whole ticket history.
Enforce SSO and two-factor for team members. The enforce_sso and two_factor_enforce settings close the email and password route, and the SSO bypass should be limited to the account owner.
Least privilege needs custom roles. Custom roles (Enterprise) control ticket access, end-user profile editing, ticket deletion and the manage_api_credentials permission that governs who can mint credentials.
The audit log is the detection source. On Enterprise plans the audit log records create, destroy, exported, login and update actions indefinitely, and API token events appear with source type apitoken.

How identity and access work in Zendesk

Zendesk separates two populations. Team members (admins and agents, plus light agents, contributors and billing admins) work tickets. End users are the customers who raise them. Each population has its own sign-in configuration in the security settings, so hardening agents does not automatically harden the customer side, and the reverse.

Sign-in route	Setting (security settings API)	Security notes
Zendesk email and password	`authentication.agent.zendesk_login`	Governed by the password security level: Low, Medium, High, Recommended or Custom. Zendesk recommends Recommended; Custom is for team members only.
Google sign-in	`google_login`	Convenient, but any Google account allowed by the setting can be a route in unless SSO is enforced through one primary method.
Microsoft sign-in	`office_365_login`, `office_365_enforce_tid`, `office_365_allowed_tids`	Turn on tenant ID enforcement so only your Microsoft Entra ID tenants can sign in.
Enterprise SSO (SAML or JWT)	`remote_login`	Lets your identity provider apply conditional access and phishing-resistant MFA. See the Identity Provider and SSO Security Guide.
Enforced SSO	`enforce_sso`	Disables email and password sign-in, so a password reset email can no longer be used to take over a team member account.
SSO bypass	`remote_bypass` (1 = owner, 2 = all admins)	One-time access link if the identity provider is down. Restrict to the owner so a compromised admin mailbox cannot bypass SSO.
Two-factor authentication	`two_factor_enforce`	Required for any account that can still sign in with a Zendesk password, including the owner's break-glass path.

When SSO is enforced, joiner and leaver handling moves to the identity provider. Disabling a user there stops new sign-ins, but existing sessions and tokens can survive. The Sessions API (DELETE /api/v2/users/{user_id}/sessions) signs a user out of all sessions, and should be part of the leaver and incident runbook alongside OAuth token revocation. See the Employee Offboarding Security Guide.

Admin roles and privileged access

Zendesk role types in the API are custom agent (0), light agent (1), chat agent (2), contributor (3), admin (4) and billing admin (5). Admins can change security settings, create API credentials and export data, so the admin count is the first number to reduce. Every Zendesk account also has one account owner, who should be a named, monitored identity with two-factor enforced and an SSO bypass path that is tested.

Custom roles (Enterprise plans and above) are where least privilege actually lives. The permissions with the largest security effect are below.

Custom role permission	Values	Least-privilege setting for most agents
`ticket_access`	all, assigned-only, within-groups, within-groups-and-public-groups, within-organization	within-groups, so an agent account compromise exposes one queue, not the whole history
`end_user_profile_access`	readonly, edit-within-org, edit, full	readonly; editing a customer's email address is the classic account takeover step in support desks
`user_view_access`	none, readonly, manage-personal, manage-group, full	none or readonly, since customer lists are bulk personal data
`manage_api_credentials`	true or false	false; this allows creating, editing and deleting OAuth clients, API tokens and Conversations API credentials
`ticket_deletion` and `view_deleted_tickets`	true or false	false for agents; deletion destroys evidence and should sit with a small group
`explore_access`	none, readonly, edit, full	readonly for team leads only; reporting gives cross-queue visibility

Account assumption: the security settings expose assumable and assumption_duration (off, day, week, month, year, always). This lets Zendesk staff sign in as your account for support. Keep it off by default and grant it for a day when you open a support case.
Admin password setting: admins_can_set_user_passwords lets admins set, not just reset, user passwords. Turn it off so no admin can silently know another user's password.
Review cadence: list admins and agents with manage_api_credentials quarterly, and treat both as privileged accounts in your PAM and access review process. See the PAM Maturity Model.

Integrations, API tokens and service accounts

Most Zendesk exposure comes through non-human access: CRM connectors, chatbots, analytics exports, internal scripts and Marketplace apps. Zendesk supports three credential types for this, and their risk is very different.

Credential	How it authenticates	Scope and lifetime	Status
API token	Basic auth as `{email_address}/token:{api_token}`	No scopes; can impersonate any user including admins; no expiry; up to 256 per account	Deprecated: unused tokens deleted after 30 days from 28 July 2026, all stop working by 30 April 2027
OAuth access token (local client)	Bearer token for one Zendesk instance	Carries a `scopes` array; may have `expires_at` and a refresh token; `used_at` shows last use	Zendesk's recommended method
Global OAuth token	Bearer token issued to an app distributed to many Zendesk customers	Required for apps, integrations or bots used by multiple customers	Required for vendors; ask your vendors whether they use it

Migrating from API tokens to OAuth

Inventory: in Admin Center, go to Apps and integrations, APIs, API tokens. Record every token's description, owner and the system that uses it. Tokens with no description and no known owner are the priority.
Find usage: on Enterprise plans use View audit log on each token, and filter the audit log on source_type apitoken. Correlate with the integration's own logs.
Create a dedicated OAuth client per integration: choose kind confidential only where the secret can be stored server side, set the scope field to the minimum the integration needs (requests outside it fail with invalid_scope), and store the client secret in a secrets manager immediately, because Zendesk returns it in full only at creation.
Use a dedicated integration user: tokens act as the user who granted them, so grant them from a named service user with a custom role limited to the queues the integration needs, not from an admin's personal account.
Cut over and deactivate: switch the integration to the OAuth token, then deactivate (not delete) the API token. API calls with a deactivated token fail immediately, and reactivation is possible if something breaks, which gives you a rollback path.
Delete and switch off: after a quiet period, delete the deactivated token (deletion is permanent) and set api_token_access to false so new tokens cannot be created.

Rotation: rotate OAuth client secrets with the generate secret endpoint and revoke tokens with DELETE /api/v2/oauth/tokens/{id}, or in bulk with POST /api/v2/oauth/tokens/delete_many. Test whether the old client secret stops working immediately before relying on it in an incident.
Token inventory: admins can list every OAuth token with GET /api/v2/oauth/tokens?all=true. Only the first 10 characters are returned, which is enough to match a token to an alert without exposing it.
End-user API passwords: keep api_password_access_end_users off unless a documented use case needs it.
Vendors: Zendesk's developer terms prohibit sharing API credentials with third parties. A vendor asking you to paste a token or admin password into their portal should be asked to use OAuth instead.

Treat every Zendesk OAuth client and token as a non-human identity with an owner, a purpose and an expiry review. See the API Keys vs OAuth Tokens Guide and the NHI Offboarding and Decommissioning Guide.

Logging and detection

The Zendesk audit log (Enterprise plans, admins only) records account changes and keeps them indefinitely. It is available in Admin Center and through GET /api/v2/audit_logs, with an export endpoint limited to one request per minute. Pull it into your SIEM on a schedule using a dedicated read-only OAuth client.

What to detect	Audit log filter	ATT&CK technique
New or reactivated API token, new OAuth client	`source_type` apitoken, `action` create or update	T1528 Steal Application Access Token
Bulk export of tickets or users	`action` exported	T1213 Data from Information Repositories
Admin sign-in from an unexpected IP or country	`action` login, `filter[ip_address]`	T1078.004 Cloud Accounts
Security setting changes (SSO, two-factor, IP restrictions, assumption)	`action` update on account settings	T1078.004 Cloud Accounts
New Marketplace or private app installed	`source_type` zendesk/app_market/app	T1550.001 Application Access Token
Trigger or automation changed to forward or copy tickets	`source_type` rule	T1213 Data from Information Repositories

The audit log shows configuration changes, not every API read. Volume-based detection of a token reading hundreds of thousands of tickets needs the calling system's logs, API usage data (visible to holders of manage_api_credentials) or a SaaS security posture tool. For leaked tokens in code, scan repositories for Zendesk token patterns, since the token is a plain string in basic auth. See the Detection Engineering for Non-Human Identities Guide.

Metrics that show the programme is working:

Number of active API tokens, trending to zero before 30 April 2027.
Percentage of OAuth clients with a named owner, restricted scope and a dedicated integration user.
Number of admins and of custom roles with manage_api_credentials, reviewed quarterly.
Percentage of team members signing in through enforced SSO (target 100 per cent, with the owner as the only bypass).
Time from leaver event to sessions deleted and OAuth tokens revoked.
Audit log export lag into the SIEM (target under one hour).

Hardening baseline

Area	Baseline setting	Why
Team member sign-in	`enforce_sso` true, `remote_bypass` owner only, Microsoft tenant ID enforcement on if Microsoft sign-in is used	Moves MFA and leaver handling to the identity provider
Two-factor	`two_factor_enforce` true for team members	Protects any remaining password path
Password level	Recommended, or Custom with a long minimum length and lockout via `failed_attempts_allowed`	For accounts that cannot use SSO
Sessions	Set `agent_session_timeout` and enable `maximum_session_duration_enabled`; set `mobile_app_session_timeout` or turn off `mobile_app_access`	Limits the life of a stolen session cookie
IP restrictions	`ip_restriction_enabled` with `ip_ranges` for your egress and support partner ranges, and `enable_agent_ip_restrictions` so customers are unaffected	A stolen agent session or password is useless from outside the allowed ranges
Account assumption	`assumption_duration` off, enabled per support case	Removes standing vendor access
Attachments	`tickets.private_attachments` true	Attachment links require sign-in, so forwarded links do not expose identity documents
API	`api_token_access` false after migration; `api_password_access_end_users` false	Removes unscoped credentials
Email	Configure SPF and a custom DKIM domain (`custom_dkim_domain`) for your support address; check inbound sender authentication	Reduces spoofing of your support address; see the DMARC, SPF and DKIM Guide
Content Security Policy	`csp_blocking_enabled` true where your help centre theme allows	Limits script injection in the help centre

Rollout order

Turn on audit log export to the SIEM first, so every later change is recorded.
Enforce two-factor for team members, then pilot enforced SSO with one team before switching it on for all, keeping the owner bypass tested.
Introduce custom roles queue by queue, starting with contractors and outsourced support partners.
Apply agent IP restrictions in a staged way: add partner ranges first and confirm with the partner before enabling. If agents are locked out, the owner can remove the restriction.
Run the API token to OAuth migration above, then switch off API token access.

For a small account on a plan without custom roles or the audit log, the priorities are the same but simpler: enforce SSO or two-factor, keep admins to two named people, remove API tokens, and log integration activity on the integration side. Large or regulated organisations should also map Zendesk data retention and deletion to their privacy obligations, since tickets frequently contain identity documents.

Common misconfigurations

Tokens left valid after an incident: in the Internet Archive Breach, Zendesk API tokens stored in source code were not rotated after the first breach, and on 20 October 2024 the attacker replied to past support tickets from the Archive's genuine Zendesk account. The emails passed DKIM, SPF and DMARC because they really came from Zendesk. Any incident involving source code or a developer laptop must include revoking every Zendesk credential.
Integrations running as an admin: a token or OAuth grant created by an admin inherits full ticket and user access. Use a dedicated integration user with a custom role.
SSO enabled but not enforced: agents can still sign in with a Zendesk password, so a password reset sent to a compromised mailbox bypasses the identity provider.
Every agent can edit customer emails: end_user_profile_access set to full lets a social engineered or compromised agent redirect a customer's account recovery. See the Account Recovery and Help Desk Security Guide.
Standing account assumption: assumption_duration left at always gives the vendor permanent access to your instance.
Public attachments and over-retained tickets: identity documents attached to tickets stay accessible for years when private attachments and a deletion schedule are not configured.

Framework mapping

Zendesk control	NIST SP 800-53 Rev 5	NIST CSF 2.0	CIS Controls v8.1	ISO/IEC 27001:2022 Annex A
Enforced SSO and two-factor	IA-2, IA-5	PR.AA-01	6.3, 6.5	A.5.17, A.8.5
Custom roles and admin reduction	AC-2, AC-6	PR.AA-05	5, 6	A.5.15, A.8.2
Session timeouts and IP restrictions	AC-12, AC-17	PR.AA-05	6	A.8.5
API token retirement and OAuth scopes	IA-5, CM-7	PR.AA-01	5	A.5.17
Audit log export and review	AU-2, AU-6	DE.CM-03	8	A.8.15, A.8.16
Vendor and app review	AC-6	GV.SC-07	15	A.5.19, A.5.23

Practitioner checklist

Export the Zendesk audit log to your SIEM and alert on new API tokens, OAuth clients, app installs, exports and security setting changes.
Enforce SSO for team members, restrict the SSO bypass to the account owner and enforce two-factor.
Reduce admins to a named few and move agents to custom roles with group-limited ticket access and read-only customer profiles.
Inventory every API token, migrate each integration to a scoped OAuth client and a dedicated integration user, then set api_token_access to false well before 30 April 2027.
Store OAuth client secrets in a secrets manager and document a revocation runbook using the token and session APIs.
Turn on agent IP restrictions, session timeouts and a maximum session duration.
Keep account assumption off except during an open support case.
Require private attachments and set a retention schedule for tickets containing identity documents.
Add Zendesk credentials to the revocation list for any source code, developer or vendor incident.

Zendesk Security Guide: API Tokens, OAuth Clients and Admin Roles