How to Send a Password Securely Without Putting It in Email

When someone asks you to “send the password,” the fastest option is often the riskiest: pasting it into an email, Teams message, WhatsApp chat or support ticket. Those systems may keep searchable copies on multiple devices and in long-term archives.

The secure alternative is to send an encrypted secret link and communicate the decryption passkey separately. This guide provides a practical workflow for employees, IT teams, consultants and service providers who need to transfer a credential safely.

The safest sequence for sending a password

1. Verify the recipient and the business need.
2. Create a unique password or rotate the existing one.
3. Encrypt the credential in a secure secret-sharing tool.
4. Set a short expiration period.
5. Send the encrypted link through email or the agreed work channel.
6. Send the passkey separately by phone or secure messenger.
7. Require a password change after first login when possible.
8. Confirm completion without asking the recipient to repeat the credential.

Why “two separate messages” is not always enough

Sending the link and passkey as two consecutive messages in the same compromised account provides little separation. A real separate-channel approach uses communication paths with different access controls—for example, link by corporate email and passkey by a verified phone call.

The objective is not inconvenience. It is to prevent one stolen mailbox, chat session or forwarding rule from delivering every component needed to reveal the secret.

Choosing the right channel for the passkey

A verified voice call is appropriate for highly privileged credentials. Signal or another approved secure messenger can work when the recipient identity is already established. SMS may be acceptable for lower-risk transfers but has known account-takeover and SIM-swap risks.

Do not send the passkey in the subject line, the same ticket, an attachment next to the link or a calendar invitation visible to multiple participants.

How CyberRiskEvaluator protects the transferred value

The secret is encrypted with AES-256-GCM, which protects confidentiality and detects unauthorized modification. PBKDF2-HMAC-SHA-256 derives the encryption key from the passkey and a random salt. A unique initialization vector is used for encryption.

The recipient’s browser performs decryption after the correct passkey is entered. The server therefore does not need to process the readable password. The link token can also be represented in storage by its SHA-256 hash rather than the original token.

Different password types require different follow-up actions

• Initial user password: force change at first login.
• Temporary support password: expire or rotate immediately after the session.
• Service-account password: place it in an enterprise vault and restrict access.
• Privileged administrator password: use privileged access management and time-bound elevation.
• Shared Wi-Fi password: rotate periodically and avoid reusing it for sensitive systems.

A simple policy employees can remember

Organizations can reduce confusion with one clear rule: never place a password directly in email, chat or a ticket. Use the approved encrypted-sharing tool, send the passkey separately and rotate the credential whenever the access is temporary.

The policy should name the approved channels, define maximum expiration times and explain how recipients are verified. A short process that employees can follow is more effective than a complex rule that encourages workarounds.

Frequently Asked Questions

Related Secure Sharing Guides

• Secure Password Sharing: Protect Credentials with Encrypted Links
• One-Time Secret: Share Sensitive Information with Limited Access
• How to Share an API Key Securely with Developers and Partners
• Encrypted File Sharing for Confidential Documents and Sensitive Data
• Self-Destructing Link for Passwords, Files and Private Messages
• How to Share Credentials with a Client Securely and Professionally
• Secure Secret Sharing for Business, IT Teams and Service Providers

Content reviewed on 14 July 2026. Security requirements should be adapted to your organization’s risk, policy and regulatory obligations.