Plan requirement
| Subscription | Suite Enterprise or higher, Support Enterprise |
| Also required | Advanced Data Privacy and Protection |
| Access | Admin |
Advanced encryption puts specific user fields under a key you hold yourself, and it comes with restrictions to check first.
What you already have without it
Every Zendesk account encrypts service data at rest in AWS with AES-256, and everything in transit runs over HTTPS with TLS 1.2 or higher. This add-on is not the difference between encrypted and not encrypted, and answering a questionnaire rarely requires it.
What it changes
Who holds the key. With customer managed keys, the data is encrypted against a key in your own key management service rather than one Zendesk holds alone. You can use AWS KMS, Azure Key Vault, Google Cloud KMS, or Thales CipherTrust Manager, which is the one to look at if the requirement is that the key stays with a European provider.
What it covers, and what it does not
It encrypts user fields: name, alias, signature, details, notes, email address, and social channel identities, across Support, knowledge and voice.
It does not encrypt ticket content. In email, only the address is covered: the subject line, the body and the HTML source are not. If your reason for wanting this is to protect what customers wrote to you, this add-on does not do that.
Two places hold the covered fields in plain text anyway, and both are worth naming before somebody signs off on this. Explore's user datasets are stored unencrypted, and bulk import and export files sit in plain text for thirty days before they are deleted. A control that stops at the database does not stop at the spreadsheet.
The warning that matters most
Key rotation and revocation are not supported. Rotating or revoking a key can make the encrypted data unrecoverable, permanently. Whatever key policy your organisation applies elsewhere, it cannot be applied here yet, and that has to be agreed with whoever owns key management before you start.
What else it breaks
- Sandboxes. Creating one is disabled while this is on. Zendesk asks you to test in a sandbox before switching it on in production, so create that sandbox first or you will not have one.
- Ticket sharing. Not supported.
- Search. Wildcard and phrase searches degrade over the encrypted fields, which agents will notice before anyone tells them why.
- Messaging triggers with a condition on an end user's name stop working.
- Moving your account to another region. An encrypted account is no longer eligible, so if that move is ever going to happen, ask for it first.
What it does not protect against
Anything happening through the normal interface. An agent who can open a ticket reads it; a compromised agent account still reaches whatever that account could reach. Most real incidents are of that kind, so this is a control to add alongside access hygiene rather than instead of it.
Deciding whether you need it
Key ownership belongs with whoever handles it elsewhere in your organisation, normally IT security, not a support admin. Before buying, check that the fields it covers are the ones your obligation names, because that is where this most often disappoints.
Talk to us before you start. The setup has consequences that are awkward to reverse, and the restrictions above are easier to accept before you have built around them.
Comments
0 comments
Article is closed for comments.