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.
- Increase password security for your agents
- Never give out user names, email addresses, or passwords
- Limit the number of agents with administrator access
- Remotely authenticate users with single sign-on
- Monitor account audit logs
- Limit access or follow secure coding practices if using the REST API
- Provide an email address for security notifications
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 email@example.com.
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.
Require two-factor authentication for agents and admins for another layer of security. We recommend sending a message to your support team with a link to the Using 2-factor authentication article.
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.
Limit access to private information in tickets
On Enterprise plans, administators can designate a group as private. This generally restricts access to agents within the group, although admins and team leaders have access by default and agents can be granted permission to view private tickets. Agents working private tickets are prevented from @mentioning or opening side conversations with team members outside the private group. Using private ticket groups can significantly reduce visibility into the content of tickets.
If you're concerned about agents accessing sensitive information in tickets, you can create private groups and assign appropriate agents to the group to handle those tickets.
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
You can use the Zendesk REST API and the Zendesk Apps framework to extend the functionality of your Zendesk Support instance.
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.
Provide an email address for security notifications
If a security incident impacts your Service Data, it is Zendesk's top priority and legal obligation to notify our customers within the required time period. Add the email address of your organization's security contact or group who should receive security incident notifications. See Designating an email address to receive required security notifications.
Would you be able to call out whether you recommend configuring a VPN or not? Historically I believe this was required from a best practices security perspective. But is this still the case? Does VPN work with Talk and Zendesk in general?
Talk will not work with a VPN setup due to a service that runs in the background called GLL. This service decides on the best network path to run the call through. If you use either of these it will not give the true location of your agents and as such cannot route the call efficiently, potentially leading to latency and other call quality issues. If you must use a VPN or Proxy or MPLS, please exclude traffic for the Zendesk / Twilio domains (including your FQDN subdomain.zendesk.com) and the IP addresses listed in this article to run through VPN. Note: Zendesk Talk is not compatible with virtual desktop environments. For more information, you may check Talk network requirements.
All the best!
Hi @... if that's the case, can you please update the original post above and call that out specifically? FYI @...
Please sign in to leave a comment.