Zendesk Now Puts a Passcode on Email Attachment Links. What Do Yours Require?

When a support email links to a file, who can open that link? Most support leads have never had to answer that. Zendesk has just made it a setting. On 28 and 29 October 2026 it rolled out one-time passcodes for email ticket attachments, and on 14 December the same protection extends to inline images. It is a useful prompt to check how your own helpdesk handles files, and we checked ours.

What changed

Zendesk's announcement says: "A new One-time passcode (OTP) setting lets admins require anonymous recipients to verify their email address before accessing eligible Zendesk-hosted attachments."

How it works, in Zendesk's words: "When a recipient opens an eligible attachment link, they enter their email address and request a six-digit passcode. If that email address belongs to a user on the ticket, Zendesk sends the passcode to that address." After that, Zendesk checks that the person has access to the ticket. "Admins can configure an access duration. During that period, the verified email can continue accessing eligible attachments in the same browser across tickets in the same account where it is authorized."

Who gets it: "OTP is enabled by default for new accounts. Existing customers can opt in." Existing accounts turn it on in Admin Center under Objects and rules > Tickets > Settings > Downloads and attachments.

It is not finished. "While inline images can currently be viewed without entering a one-time passcode, this security setting will extend that protection to inline images starting December 14th."

Zendesk's stated reason: "Many businesses share sensitive documents with customers, external participants, and people added later to a ticket. Requiring every recipient to sign in can interrupt these email-based workflows."

What it doesn't change

Zendesk lists the limits itself, and they matter for reading this fairly:

• "This feature doesn't apply to messaging attachments."
• "Forwarding a ticket email does not, by itself, authorize a new recipient to access its hosted attachments."
• "Files delivered as standard email attachments can still be opened directly in the recipient's inbox. OTP verification applies when a recipient accesses an eligible Zendesk-hosted link."
• "Allow secure downloads, attachment expiration, and private end-user attachments remain separate settings and can be enabled at the same time as OTP."

So this is a new layer on top of attachment controls Zendesk already had, not the first one. The announcement also says "eligible" throughout without defining it there. Its Configuring attachment security article is the place to check which files your account covers.

One thing worth noticing: the passcode is on by default for new accounts, but existing accounts have to opt in. Zendesk states this plainly. If your account predates October 2026, it is worth checking which way yours is set.

This is a different feature from the one-time passcodes Zendesk rolled out on 2 November for messaging conversations with AI agents, which we mentioned in our post on auto assist and internal notes. That one checks who an AI agent is talking to. This one controls who can open a file.

Questions to ask your own helpdesk

• Do our emails carry files, or links to files? A file attached to the email is in the recipient's inbox for good. A link is only as private as the check behind it.
• What does a link require? Nothing, a hard-to-guess URL, a sign-in, or a passcode? A hard-to-guess URL works like a password that travels with every forwarded email.
• Who counts as allowed? Only the requester, anyone on the ticket, or anyone with the link?
• How long does access last, and does it carry across tickets?
• What about images inside the message body? Zendesk is only adding these in December, so ask about them separately.
• Can a customer reach a file attached to an internal note? Agents attach things to notes that were never meant for the customer.

How DeskLeap handles ticket files

We checked our own code on 5 November 2026:

• No bare links. DeskLeap stores ticket files itself, and every download checks who is asking. A file opens for a signed-in agent of the organization that owns the ticket, or for the ticket's requester signed in to the customer portal. Anyone else gets a not-found response, whether or not the file exists.
• Our emails don't carry files. Ticket notification emails don't attach files and don't link to them. A customer opens files in the portal.
• Portal sign-in is a one-time code. Customers sign in to the portal with a code sent to their email address, and that sign-in lasts up to 30 days.
• The cost is reach. Only the requester can open the files. DeskLeap has no CCs on tickets, so a customer's colleague, or anyone added to the conversation later, can't open them through the portal. That is exactly the workflow Zendesk's passcode was built for, and we don't serve it.

Asking the last question on our own list turned up a gap. The portal never showed customers files attached to internal notes, but the download route didn't check for internal notes itself. A customer who somehow had a note-file's internal ID could have downloaded it. That ID was never shown to them. We closed the gap on 5 November, and the route now refuses those files outright. It was a reminder that hiding a file from a list does not by itself control who can open it.

Zendesk's change is a reasonable answer to a real tension between keeping files private and not making every recipient sign in. The useful step for any team is to know what its own links require before a forwarded email answers that question for them.

DeskLeap is a ticketing, live chat and knowledge base platform. The platform is 100% free with unlimited human agents; an optional AI Agent add-on is $29/mo each.

Sources

Zendesk, Announcing one-time passcodes to access email ticket attachments (announced 28 October 2026; rolled out 28–29 October 2026; edited 4 November 2026; read 5 November 2026). Zendesk, Configuring attachment security. Quotations are verbatim from the announcement. DeskLeap's behaviour is described from our own code as of 5 November 2026.