Zendesk provides a range of security options that you can use to ensure that private information is protected and secure. This article covers general security best practices to help you get started. We strongly recommend that you train your agents and administrators to follow the best practices to ensure a secure environment.
See the Zendesk Suite Actionable Security Guide for a detailed list of security best practices we recommend implementing in your instance.
If you have questions about the security of your Zendesk instance, contact Zendesk directly. In the event of a suspected security breach, submit a ticket with the subject “Security” along with the details. Alternatively, you can send an email to firstname.lastname@example.org.
Increase password security for your agents
Zendesk provides three password security levels: low, medium, and high. You can also specify a custom security level. An administrator can set one password security level for end users and another for agents and admins.
Increase the password requirements for agents to help prevent unauthorized users from guessing your agents' passwords. You should also require administrators and agents to select unique passwords for their Zendesk accounts and avoid reusing passwords for external systems.
Encourage agents to monitor their own accounts. Zendesk will send agents an email notification when their password is changed. Also, agents can conveniently monitor their accounts by enabling email alerts for logins from new devices. If you see a new login from a suspicious device, remove the device to end the user's session, then choose a new password.
Never give out user names, email addresses, or passwords
Zendesk agents and administrators should never give out user names, email addresses, or passwords.
If you're using standard Zendesk sign-in authentication, the only secure way to reset a password is for the user to click the Forgot my password link on the Zendesk sign-in screen. This prompts the user to enter a valid email address (one already verified as a legitimate user in your account). After submitting it, they will receive an email containing a link to reset their password.
If you're using a third-party single sign-on authentication system such as Active Directory, Open Directory, LDAP or SAML, passwords can be reset similarly through those services.
Hackers sometimes use social engineering techniques to pressure people into giving them a password for an account. Some hackers use tools that spoof email addresses to impersonate users from legitimate email domains. As a result, what appears to be a legitimate email request from a user may not be from that actual address.
If someone who claims to be a user or administrator contacts you, note the IP address (shown in the events view in tickets) and independently verify their identity (for example, by calling the phone number in their user profile). If in doubt, never provide sensitive information or make account changes on someone else's behalf. Legitimate users can change their own account settings.
Educate your agents about these types of security risks. Also, create a security policy that everyone knows and can refer to when these incidents occur.
Limit the number of agents with administrator access
Administrators have access to parts of your Zendesk account that regular agents do not. You can reduce your security risk by limiting the number of agents who have administrator access. The agent role provides access that typical agents need to manage and solve tickets.
You can select predefined agent roles that grant additional permissions to agents. You can also create your own custom agent roles and decide what parts of Zendesk the agent role can access and manage. These permissions are limited. Only account owners and administrators have access, for example, to security settings.
If you're concerned about your agents accessing information about your end users, you can create a role that does not allow them to edit end-user profiles or view the list of all your end users.
Remotely authenticate users with single sign-on
In addition to the user authentication provided by Zendesk, you can also use single sign-on, which authenticates your users outside of Zendesk. There are two SSO options: social media single sign-on and enterprise single sign-on.
Social media single sign-on allows your customers to sign in with either their Zendesk account or one of their social media accounts, such as Google or Microsoft. While these options are convenient, we recommend inactivating unnecessary social logins.
Enterprise single sign-on bypasses Zendesk and authenticates your users externally. When users navigate to your Zendesk sign-in page or click a link to access your Zendesk account, they can authenticate by signing into a corporate server or a third-party identity provider, such as OneLogin or Okta.
When providing either enterprise or social media single sign-on, we recommend taking advantage of the two-factor authentication (also known as multi-factor authentication) that these services provide. This adds another layer of protection by requiring additional proof of identity. If you're using JWT or SAML, you'll need to set this up for your Zendesk account. For social media single sign-on, your users will need to set this up themselves. All of these services provide the necessary documentation to set it up.
Agents and end users can have different ways to authenticate themselves. You can secure Zendesk Support by creating a stricter authentication policy for agents while providing easy access to your customers and end users.
Monitor account audit logs
The audit log tracks important changes to your account. Using the audit log, you can monitor various security events such as user suspensions, password policy changes, exports of customer data, changes to custom role definitions, and many more.
Limit access or follow secure coding practices if using the REST API
If you want to extend your Zendesk instance, we strongly recommend that you follow secure coding best practices. A good reference for this is the Open Web Application Security Project (OWASP), which you can find here.