First ask whether the password should be shared
Shared credentials weaken accountability: logs show the account, not the person. Modern systems often support invitations, roles, temporary access, service accounts, or a password manager that can grant access without revealing the underlying value.
Use those options when available. A one-time link is a safer delivery channel, not a substitute for proper identity and access management.
The recommended workflow
When a password genuinely must travel from one person to another, use a short process that creates multiple independent barriers:
- Generate a unique temporary password rather than reusing an existing personal password.
- Create an encrypted one-time Relay with a short expiry.
- Protect the Relay with a unique passphrase of at least 12 characters.
- Send the Relay link in one channel and the passphrase in another.
- Confirm the recipient through a known phone number or established account.
- Require a password change at first login and revoke the temporary credential if unused.
Why email and ordinary chat are weak defaults
Both systems optimize for availability and history. Messages can appear in previews, exports, backups, mobile notifications, search indexes, retention archives, and administrator tooling. Deleting your copy does not reliably delete every synchronized copy.
A one-time link does not make email private, but it keeps the actual password out of the message body and limits the server-side lifetime of the encrypted payload.
What to do after delivery
Record that access was granted without recording the password. Ask the recipient to confirm the change, then invalidate the temporary credential or secret. For shared infrastructure, review audit logs and ensure the new owner has multi-factor authentication configured.
If the link was opened unexpectedly, assume exposure. Revoke or rotate the password immediately; one-time deletion cannot reverse a retrieval that already happened.