Handling credentials safely in support tickets
The support ticket credential problem
Every support team has seen it: a customer or colleague pastes a username and password directly into a support ticket. It is a natural impulse — they need help, they need to share access to demonstrate the problem, and the ticket is right there.
The result is a credential stored in your ticketing system indefinitely. Most ticketing systems keep full ticket history forever. The credential is now searchable, exportable, and accessible to every support agent with access to the ticket — now and in the future.
Why ticketing systems are a poor home for credentials
Support ticketing systems are designed for communication history, not security. They typically:
- Store all content permanently by default
- Grant broad read access to support staff
- Generate email notifications (copies of the ticket content, including any credentials)
- Allow data exports that include full ticket content
- Have limited fine-grained access control
A credential in a ticket is effectively a credential shared with your entire support organization, plus anyone who gains access to your ticketing system through a breach, an employee departure, or an export.
The reactive scenario: a customer has already shared credentials in a ticket
This happens. When it does, act quickly:
- Immediately ask the customer to change the password and note in the ticket that the old credential should be considered compromised
- Remove or redact the credential from the ticket if your system allows editing of ticket content (many do not, which makes step 1 more important)
- Do not forward the ticket or reply-all in a way that propagates the credential further
- Use a one-time link for any follow-up credential sharing needed to complete the support case
The proactive scenario: building credential handling into your support workflow
Train your support team to redirect credential requests before they happen. This means:
In your ticket intake: Include a note in your support portal or auto-reply: "For security reasons, never share passwords directly in tickets. If we need access to your account, we will send you a secure link."
In your support response templates: When a support agent needs customer credentials, the response should be: "Please share access using this secure link: [one-time link created specifically for this ticket]." The customer enters their credential into the one-time link, you retrieve it, and it is deleted after retrieval.
In your agent training: Make redirection a reflex. When a customer pastes a password in a ticket, the first response is always a request to change it, not to use it.
Using one-time links within support workflows
One-time links work in both directions for support:
- Customer to agent: Create a one-time link and ask the customer to share credentials via that link, so they never appear in the ticket thread
- Agent to customer: After resolving an issue that required a password reset, share the new credential via a one-time link rather than in the ticket reply
This keeps your ticketing system clean and your customers' credentials out of a system that was not designed to protect them.
