Sending a password in a normal chat message is convenient, but it creates a long-lived copy of the credential. The message may remain searchable, appear in notifications, be included in backups, or become accessible to anyone who later gains access to the account. A better process is to separate the sensitive value from the normal conversation.
Avoid putting the password directly in the message
The first rule is simple: do not paste a reusable password into an email, SMS, support ticket, or team chat unless there is no safer option. Even if the conversation is encrypted in transit, the message often remains stored after delivery. Encryption protects transport, but it does not automatically remove old copies from mailboxes, archives, exports, or backups.
Use a temporary delivery method
A one-time link allows the password to be stored separately from the message used to notify the recipient. The recipient receives a URL, opens it once, and the underlying secret is removed. This reduces the value of the old chat message because the URL no longer reveals the password after it has been consumed.
For temporary credentials, this model is particularly effective. An administrator can create a temporary password, deliver it through a one-time link, and require the user to change it after the first successful sign-in.
Use separate channels for high-value secrets
For more sensitive access, do not place every required piece of information in the same channel. You can send the one-time URL by email and communicate an additional passphrase by phone, voice call, or another trusted channel. An attacker who compromises only one channel then has incomplete information.
This is sometimes called out-of-band verification. It is useful for administrator credentials, recovery codes, emergency access information, or situations where identity assurance is important.
Prefer temporary credentials over permanent ones
Whenever possible, generate a password or token specifically for the task instead of sharing a permanent credential. A short-lived token, temporary password, or limited-scope API key has less impact if it is exposed. After the recipient has completed the task, revoke or rotate it.
This principle is especially important for technical teams. Sharing a single permanent administrator password with multiple people makes auditing difficult and increases the consequences of accidental disclosure.
Set a reasonable expiration
A secret that has not been opened should not remain available indefinitely. Use an expiration period that matches the expected workflow. If the recipient is available now, an hour may be enough. If the recipient is in another time zone, a day or several days may be more practical.
Expiration protects against forgotten links. It also reduces the chance that an old notification containing the link can be used much later.
Verify the recipient before sending
Secure delivery does not help if the secret is sent to the wrong person. Confirm the email address, chat account, or phone number before sending. For privileged credentials, verify the request through an established process instead of relying only on an unexpected message asking for access.
Change or revoke credentials after suspicious exposure
If you accidentally post a password in a public or widely accessible channel, deleting the message is not enough. Someone may already have seen it, copied it, received it in a notification, or captured it in a log. Treat the credential as exposed and rotate it as soon as possible.
Choose the right tool for long-term storage
A one-time link is a delivery tool, not a replacement for a password manager. Passwords that teams need repeatedly should be stored in an approved vault with access control, auditing, and credential rotation. Use one-time delivery when the goal is to transfer a secret without creating another persistent copy in conversation history.