Zendesk provides a range of security options that you can use to ensure that private information is protected and secure.
By following the best practices in this article, you can increase the security of your Zendesk and 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.
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 email@example.com.
- Increase password security for your agents
- Never give out user names, email addresses, or passwords
- Limit the number of agents with administrator access
- Routinely audit your Zendesk account
- Monitor account audit logs
- Encourage agents to monitor their user account
- Remotely authenticate users with single sign-on
- Restrict access to your Zendesk Support using IP restrictions
- Limit access or follow secure coding practices if using the REST API
- Redact credit card numbers from tickets
- Enable private attachments
- Prevent forum spam
Increase password security for your agents
Zendesk provides several levels of password security: low, medium, and high. 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.
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.
Finally, you can require 2-factor authentication for agents and admins. See Managing 2-factor authentication. We recommend sending a message to your support team with a link to the Using 2-factor authentication article in the Agents guide.
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 Forgot my password link on 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 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 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.
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 Zendesk Support that the agent role can access. These permissions however are limited to the user, ticket, forum, and workflow management parts of Zendesk Support. 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 Creating custom roles and assigning agents.
Routinely audit your Zendesk account
- Review agent access and roles from the Team members page to look for unknown agents, administrators, or unusual email addresses not in your company domain.
- If you're using
sure that email address is legitimate. See Archiving ticket email
.Note: Email archiving is available on Enterprise plans and above.
- 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
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 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 devices and applications that accessed your 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 Help Center sign-in 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 Help Center sign-in page. Instead, they typically log in to a corporate network and then access Zendesk Support by simply clicking a link and are automatically logged in. All user management and authentication happens outside of your Zendesk. Zendesk supports single sign-on using Secure Assertion Markup Language (SAML) and JSON Web Token (JWT).
It's important to remember that when you use JWT- or SAML-based SSO, you take on the responsibilities of verifying the identity of your users, including verifying their email addresses. If you do not verify your users and their email addresses, your account is at risk of unauthorized access and Zendesk cannot guarantee or warrant the security of your account.
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:
Restrict access to your Zendesk Support using IP restrictions
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 Zendesk Support.
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.
Limit access or follow secure coding practices if using the REST API
If you don't anticipate using these tools to extend Zendesk Support, leave the API disabled. In Admin > Channels > API, deselect the Token Access and Password Access options.
If you want to extend your Zendesk, 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.
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.
Redact credit card numbers from tickets
End users sometimes include their credit card numbers in support requests when they shouldn't. In addition to being visible to anybody with access to the ticket, the credit card number automatically gets stored in a database with the rest of the ticket. You can redact, or remove, digits from credit card numbers so that the numbers are no longer useful. See Automatically redacting credit card numbers from tickets.
Enable private attachments
Attachments use links in Zendesk Support. Without enabling private attachments, any link found by an individual can be accessed without first authenticating into Zendesk. Enable private attachments unless there's strong business reason not to. See Enabling ticket attachments.
Prevent forum spam
You can turn on a filter for the Help Center that prevents 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 Using the spam filter to prevent spam in Help Center.