Security best practices

More than 30,000 customers use Zendesk as a customer service and support system worldwide. Zendesk prides itself on providing a range of security options that you can use to ensure that private information is protected and secure. By following these ten best practices, you can increase the security of your Zendesk.

Note: If you are ever in doubt about the security of your Zendesk system, feel free to contact Zendesk directly. In the event of a suspected security breach, you should submit a ticket with the subject “Security” along with the details. Alternatively, you can send email to [e-mail] or call the customer support line at 415-418-7506 (Americas, US), [phone] (Europe, UK), [phone] (Asia-Pacific, Australia).

By following the best practices listed in this document, you will reduce the risk of a security breach. However, even the best security policies will fall short if they are not followed. Zendesk strongly recommends that agents and administrators be trained to follow the best practices and ensure a secure environment.

Increase password security for your agents

Zendesk provides several levels of password security: low, medium, and high. If you're an Enterprise customer, you can specify your own custom password security level. An administrator can set one password security level for end-users and another for agents and admins.

Increasing the password requirements for agents can help to prevent unauthorized users from guessing your agents' passwords. At the highest level of security, agents are required to choose a new password every 90 days. For more information, see Setting the password security level for your Zendesk.

You should also require your administrators and agents to select unique passwords for their Zendesk account. In other words, they should use a password that they are not also using for external systems such as Salesforce, GoodData, and so on. If one account is hacked and a password is discovered, the hacker's access will be limited to just that one account.

Never give out user names, email addresses, or passwords

While there is a fine line between meeting the needs of your users and maintaining security, best practices are that Zendesk agents and administrators should never give out user names, email addresses or passwords.

If you're using standard Zendesk login authentication, the only secure way to reset a password is for the user to click the link to create a new password (Help! I don't know what to enter here!) from the login screen of your Zendesk. This prompts the user to enter a valid email address (one already verified as a legitimate user in your account) and they receive an email at that address prompting them to reset their password themselves.

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 in a similar fashion through those services.

Be aware that hackers sometimes use social engineering techniques to pressure people into helping them out by giving them a password for an account. In some cases, they do this by contacting customer service personnel during evenings or weekends when they suspect there are fewer senior staff working. They may even claim that there's been a security breach and that the password needs to be reset immediately to some new text that they provide.

Some hackers have tools that enable them to spoof email addresses to impersonate users from legitimate email domains. As a result, even what appears to be a legitimate email request from a user may not be from that actual address. If someone who claims to be an administrator or user of an account contacts you, you should note the IP address (this is shown in the events and notifications view in tickets), and independently verify his or her identity (for example, by calling them at the phone number in their user profile). If in doubt, never provide any sensitive information or make account changes on someone else's behalf. Legitimate users should be able to change their account settings using the methods described above.

We recommend that you educate your agents about these types of security risks and 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 that regular agents do not. For example, all of the security features described in this document are only available to administrators. By limiting the number of agents who have administrator access, you reduce your security risk. The agent role provides the access that typical agents need to manage and solve tickets.

In the Enterprise version of Zendesk, you can select pre-defined agent roles that grant additional permissions to agents. You can also create your own custom agent roles and decide what parts of your Zendesk that the agent role can access. These permissions however are limited to the user, ticket, forum, and workflow management parts of Zendesk. 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. To prevent that access, set the following two permissions:

• What access does this agent have to end-user profiles? Set to Read-only.
• May this user view lists of user profiles? Set to Cannot browse or search end-users.

For more information, see Custom agent roles.

Routinely audit your Zendesk account

If you follow all of the above techniques, your Zendesk account should always be private and secure. However, it is still considered best practice to routinely check for suspicious activity. We suggest that you use the following checklist once a month (or more frequently) to ensure that no mistakes have been made that may leave your system vulnerable.

• Review agent access and roles from the People page to look for unknown agents, administrators, or unusual email addresses not in your company domain.
• If you are using the email archiving feature in the Enterprise version of Zendesk, make sure that email address is legitimate. See Archiving email notifications.
• Make sure that the URL to your logo in the Branding page is correct and has not been changed.
• Verify that all targets you use are valid and point to known and correct addresses. See Notifying external targets.
• Review all targets and automations that send notifications and check that they are notifying the correct people.

Zendesk automatically notifies all admins when most of these events occurred, but you should ensure these notifications go to the appropriate people. You can create a group in Zendesk that will receive these alerts.

Monitor account audit logs

In the Enterprise version of Zendesk, you can monitor various security events such as user suspensions, password policy changes, user assumption, exports of customer data, changes to custom role definition, and many more using the Audit log. This provides you with a way to track many of the important changes to your account. For more information, see Viewing the Audit log for account, user, and business rule changes.

Encourage agents to monitor their user account

Since agents have a more privileged role, they can be the canary in the coal mine indicating when a hacker has just gained unauthorized access to your Zendesk. To secure future access, an intruder may add a new email address to an admin profile and initiate a password reset.

Zendesk will send agents an email notification when their password is changed. Also, agents can conveniently monitor their user account by enabling email alerts for logins from new devices (see Checking the devices used to access your Zendesk account in the Zendesk Agent Guide). If you see a new login from a suspicious location, remove this device to end the user's session, then choose a new password.

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 your Zendesk. There are two types: social media single sign-on and enterprise single sign-on.

Social media single sign-on are additional login options that you can provide for your customers convenience. For example, you can make the Facebook, Google, and Twitter logins available on your web portal login page. Your customers can then log in with either their Zendesk account or one of their social media accounts.

Enterprise single sign-on is different than social media single sign-on. Instead of being optional and in addition to the Zendesk account login, enterprise single sign-on replaces all other login options. After it's been enabled for your Zendesk account, your customers do not see or use your web portal log in page. Instead, they typically log in to a corporate network and then access Zendesk by simply clicking a link (to Support, for example) and are automatically logged in. All user management and authentication happens outside of your Zendesk. Offered in all Zendesk plans is single sign-on using JSON Web Token (JWT). The Plus and Enterprise plans support single sign-on using Secure Assertion Markup Language (SAML).

In both cases, providing single sign-on to your users via enterprise single sign-on or via social media single sign-on, we recommend that you and your users take 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 set this up for your Zendesk. For social media single sign-on, your users will need to set this up themselves. All of these services provide the documentation needed to set it up.

For more information about single sign-on, see the following:

• Enabling social media single sign-on
• Setting up single sign-on with JWT (JSON Web Token)
• Using SAML for single sign-on (Plus and Enterprise)

Restrict access to your Zendesk using IP restrictions

In the Enterprise version of Zendesk, an administrator can restrict access to specific IP addresses. This means that only users from the IP addresses that you manually add to your account are allowed to sign in to your Zendesk.

This can be applied to all users or just to agents. If you select agents only, this means that agent access is restricted and end-user access is not.

For more information about this feature, see Restricting access to your Zendesk using IP restrictions.

Follow secure coding best practices when extending your Zendesk

You can extend the functionality of your Zendesk by creating widgets (in Zendesk Classic) and Apps (in new Zendesk). When doing so, 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 (https://www.owasp.org/index.php/Main_Page).

Additionally, applications accessing Zendesk APIs should never use your username and password, but should use an OAuth token instead (see Using OAuth authentication with your application). This allows you to isolate actions taken by this application and to revoke the token if you suspect it is compromised.

Turn SSL on for your account

Zendesk can be configured to use Secure Socket Layer (SSL), a cryptographic protocol that provides secure communications over the Internet. By using SSL, all sessions to your Zendesk are encrypted and customers are directed to a secure HTTPS site, e.g. https://youraccount.zendesk.com. For more information, see Providing secure communications with SSL.

By default, SSL is on for new accounts. If you're not currently using SSL and want to, an administrator can enable SSL. You can use either Regular SSL or a Hosted SSL for your custom domain. How you set up SSL depends on how your account is configured. You should contact a Zendesk support agent for more information and assistance with setting this up. 

Prevent forum spam

You can turn on a filter for the Help Center that precents end-user posts that appear to be spam from being published. Suspicious posts are sent to a spam queue where administrators can review and manage them. For details, see Filtering spam posts in Help Center.