How to Send a Password Securely

Start by asking whether the password must be shared

The safest shared password is often no shared password at all. For a workplace service, prefer a separate user account, delegated access, a password-manager sharing feature, or a temporary recovery code. Those options preserve accountability and let you revoke one person without changing access for everyone.

Sometimes a direct handoff is unavoidable: you may be transferring a newly created account, helping a family member regain access, or giving a contractor a temporary credential. In that case, reduce how long the password remains useful and how many places contain a readable copy.

A practical five-step password handoff

First, verify the recipient using a contact method you already trust. A reply from an unfamiliar address or a new phone number is not proof of identity. If the request is unusual, confirm it through a known number or an in-person conversation.

Next, place only the password in an encrypted secret link. Avoid including the service name, username, email address, or customer record in the same message. Set a short expiration and use one-time viewing when the recipient is ready to open it.

If you add an access password to the link, deliver that password through a different channel. For example, send the encrypted link in email and read the access password over a phone call. After the recipient confirms access, delete the message if the service allows it and rotate the credential if it was intended only for the handoff.

Verify the recipient through a known contact method.
Share the password without the account name or other identifying context.
Choose one-time viewing or the shortest practical expiration.
Send the link and its separate access password through different channels.
Confirm receipt, then rotate or revoke the shared credential when possible.

Example: handing a vendor a temporary login

Suppose a vendor needs to inspect a staging site for one afternoon. Create a temporary account with only the permissions needed. Email the vendor the staging URL and username, but send the temporary password in a one-time SecretLink that expires that day. If the link is password-protected, provide that access password during a scheduled call.

When the work is complete, disable the account rather than relying on the secret link to protect the credential forever. The link controls delivery; the account system controls whether the credential still works.

What encrypted links protect—and what they do not

Browser-encrypted links can keep plaintext out of the delivery service's stored message record and can reduce long-lived copies in inboxes. One-time access and expiration also narrow the period in which the encrypted payload can be retrieved.

They cannot make a compromised device safe. Malware, a malicious browser extension, screenshots, clipboard history, screen recording, or a recipient who intentionally copies the password can expose it after decryption. Anyone who obtains the complete SecretLink URL may also possess its decryption key, so treat the full URL as sensitive.

One-time viewing does not prevent the first viewer from copying or photographing the password.
Expiration does not revoke a password that has already been revealed.
A separate access password helps only when it travels through a genuinely separate channel.
No delivery method fixes weak, reused, or over-privileged credentials.

After the password arrives

Ask the recipient to store the credential in a reputable password manager rather than a note, spreadsheet, or chat thread. Use a unique password and enable multi-factor authentication when the account supports it.

For recurring collaboration, replace shared credentials with individual accounts. Secure delivery is a useful bridge, not a substitute for access controls, audit logs, revocation, and good account design.

Related guidance

When an encrypted delivery link is appropriate, create a free SecretLink account.