A Zendesk Security Checklist That Grades Itself

Start with the page Zendesk already built

It lives at Account → Security → Security overview, or go straight to /admin/account/security/overview. Zendesk's plan box for the page lists it across all Suite tiers from Team upward; Support-only accounts should check their own admin before planning around it. It needs an admin role.

The page does two things. It gives you an overall health donut, and on our instance it grouped settings into four categories: Authentication, Account access controls, Tickets and attachments, and Auditing and monitoring. There's an Export CSV button, which is the fastest way to get a posture snapshot you can diff month over month.

We ran it against a Zendesk Suite Enterprise demo instance of our own, not a production desk. That distinction matters in both directions: the findings below are not a report on anyone's real security posture, and a sandbox is exactly the kind of account that gets configured once and never revisited, which is what makes it a useful specimen rather than a good example.

On that instance the summary read: 4 Critical, 9 Recommended, 8 Healthy, 0 Unavailable.

Zendesk attaches a caveat to all of it, and it's worth quoting because it sets the right expectation: "These recommendations reflect general best practices and do not guarantee security; you are responsible for determining and implementing controls appropriate to your organization."

How the four ratings work, and which one is left out of the score

Three of the four ratings behave how you'd expect. Critical means fix it. Recommended means it increases exposure. Healthy means it matches Zendesk's guidance.

The fourth is Informational, and it's the one to understand properly, because Informational settings are not counted in the health score at all. Our instance had 21 rated settings adding up to the 4 / 9 / 8 summary. Everything marked Informational sat outside that arithmetic entirely.

Excluding them is defensible, because settings like "how many admins should you have" have no universally correct answer. It's worth naming the incentive underneath it, though: Zendesk built the page and Zendesk decides the grading, so the score is bounded by what a vendor is willing to flag as a problem inside its own product. Nothing here is dishonest. The effect is simply that the number you're shown reads better than your actual exposure, and the gap between the two is made of settings nobody is being prompted to check.

What Critical actually looked like

Four settings were rated Critical, and the pattern is worth recognizing because it's common to accounts that were set up quickly and never revisited.

Two-factor authentication (agent): "Two-factor authentication is not required for agents." This is the fix that closes the most risk for the least effort. Every agent account is a route to every ticket in the instance, and agents are the population most likely to be phished, because they read mail from strangers all day as their actual job.

Zendesk authentication (agent): "Enabled - Low. Admins and agents can sign in to Zendesk with an email and password." The rating sits at Critical while native password sign-in is enabled at the "Low" security level, which is what the status string reports. Zendesk's own guidance is to centralize on single sign-on and then switch native password auth off, so there is one place to revoke access when somebody leaves.

Zendesk authentication (user): the same setting for end users. Whether this matters depends on what your Help Center exposes.

Security contact email: "Not set. There is no contact identified to notify about security incidents." This is the one almost nobody knows exists. It costs thirty seconds and determines whether a security notice from Zendesk reaches a human who can act on it, or an inbox nobody reads.

The nine Recommended, grouped by what they protect

Rather than march through them, it helps to see what each group is actually defending.

Reaching your account at all. IP restrictions, Support mobile app access, and API token access. That last one is a common gap: API tokens bypass SSO entirely, so an account with perfect SSO and loose token policy is not locked down.

What leaves in a ticket. Private attachments was rated Recommended on our instance with the status "Anyone with the attachment link can view the file." That's the sort of default that surprises people. Redact credit card numbers was disabled. Customers can attach files was enabled, which is usually correct but worth a deliberate decision.

What you keep, and for how long. Deletion schedules disabled means "archived tickets are not ever automatically deleted," which is a compliance question disguised as a storage setting.

Second-factor for end users. Two-factor authentication (user), which depends entirely on what your Help Center lets a signed-in customer see.

What the score does not count

Here's where the Security overview is worth reading against the grain. Several settings on our instance were rated Informational, so none of them affected the health score. These four are the ones we'd actually act on:

Marketplace apps deserve the same treatment and do not get it from the score. An installed app holds whatever access it was granted at install time, that grant survives the person who approved it, and nothing on this page counts it. Work through Admin Center → Apps and integrations → Zendesk Support apps, and for each one ask who installed it, whether the tool is still in use, and whether it needs to be visible to every agent or can be role-restricted. Uninstall is the only revocation.

The numbers on our instance make the point better than the argument does. API token review reported 2 active tokens, 1 of them older than six months. OAuth token review reported 67 active tokens across 1 client. Both were rated Informational, so neither moved the health score by a single point.

The first two are the ones we'd act on first. An API token or OAuth grant is a credential that survives an employee leaving, a vendor being churned, and a password reset. Neither shows up as a problem in your score, and both answer a question the seed of every security review asks: what still has access that shouldn't?

You can enumerate both from the API rather than the interface:

GET /api/v2/api_tokens.json
GET /api/v2/oauth/clients.json
GET /api/v2/oauth/tokens.json?all=true

The ?all=true matters: without it an admin gets only their own tokens, sees nothing to revoke, and concludes the account is clean. Cross-reference the results against your current team list and your current vendor list. Anything you can't attribute to a person or a system still in use is a revocation candidate.

Running the check without clicking through

Two API calls give you a posture snapshot for scripting or a monthly cron.

GET /api/v2/account/settings.json

Read active_features for what's switched on and the api block for token policy. Note that api_password_access, api_password_access_end_users and api_token_access are separate switches, so check all three; one does not cover the others.

There is no security block on that response. The posture object lives on its own admin-only endpoint:

GET /api/v2/security_settings

which is where settings like assumption duration and password policy actually live.

GET /api/v2/users.json?role=admin

That's your admin review, in one request. Pair it with the Export CSV from the Security overview page and you have a monthly diff that takes about five minutes.

If you already run webhooks or triggers against sensitive fields, add those to the same review. A webhook posting ticket bodies to an endpoint nobody owns any more is the same category of problem as a stale token, and the Security overview doesn't look at them.

An order to work through it

1. Security contact email. Thirty seconds, and it's rated Critical for a reason.
2. Pick one of two authentication paths, and do not stack them. Zendesk's two-factor authentication applies only to native email-and-password sign-in: "It's not available for users who sign in using third-party authentication, such as Google authentication services, JWT, or SAML." So either enforce 2FA on native auth, or move to SSO and enforce MFA at your identity provider. Enrolling agents in Zendesk 2FA and then switching them to SSO wastes the enrolment.
3. If you chose SSO, disable native password auth after it works, not before. In that order, or you will lock yourself out.
4. Disable password access to the API, and review existing tokens and OAuth grants.
5. Private attachments, if your tickets carry documents.
6. Deletion schedules and PII deletion, matched to whatever your retention policy actually says. Check the ceiling first: without the Advanced Data Privacy and Protection add-on, which is Suite and Support Enterprise only, you get one active deletion schedule per type, so a policy with several retention rules will not fit. If you are acting on the card-redaction row too, note it needs Suite Growth or Support Professional and above.
7. Export the CSV and put a recurring reminder in the calendar. Posture drifts; a snapshot you can diff is worth more than a one-off audit.

Common questions

Where is the Zendesk Security overview page? Admin Center → Account → Security → Security overview, or /admin/account/security/overview. You need an admin role, and it's available on Suite plans from Team upward.

Does a Healthy score mean my Zendesk is secure? No, and Zendesk says so on the page itself. The score covers rated settings only. Informational items, including API and OAuth token review, are excluded from it, and nothing in the score looks at your webhooks, apps or trigger configuration.

Should I turn off Zendesk password authentication? Once SSO is working for everyone who needs access, yes — that's Zendesk's own recommendation, and it's why native password sign-in is rated Critical while it's enabled. Confirm SSO works first.

Do API tokens respect SSO? No. A token authenticates on its own, which is why token policy and token review matter independently of how good your SSO setup is.

How often should I review this? Monthly is a reasonable default, using the CSV export as your diff. Review immediately after anyone with admin access leaves.

Where an AI layer fits

Security settings decide who can reach your data. They have no effect on how much work arrives, which is a different problem with a different answer.

Macha sits on top of the Zendesk you already run. It reads the ticket, including custom field values and attachments, and can classify it, add an internal note, or post a public reply, using the triggers and webhooks you already configured as its entry point. Two things worth knowing in a security context: it connects through the Zendesk integration rather than requiring a shared agent password, and customer-facing actions run behind confirmation gates and do not fire unattended by default. It suits teams already committed to Zendesk who want agents working inside the ticket. Billing is per ticket, so one thread with one person is one charge however many replies it takes.

That screen is worth reading the way this post reads the Security overview. Each connector is a standing grant, and the credential column is exactly the kind of thing an audit should account for. Ours is redacted here for the obvious reason, which is also the reason to check yours.

Start your free trial and connect your Zendesk in a few minutes.