How to send a password securely, and what to do after

You need to get a password to someone else: the contractor who needs the staging database, the colleague covering your on-call shift, a client’s new office manager. Here is how to send a password securely. If you both use the same password manager, share it there. If you don’t, send it as a one-time link that expires, put anything that says what the password is for in a different channel, and change the password once the handover is done if more than one person now knows it.

The rest of this page is about choosing between those, doing it properly, and the follow-up. The aim is the same every time: the password should exist in as few places as possible, for as little time as possible, and you should be able to tell if anyone other than the intended person saw it.

Choose the method by what the recipient does next

Plain email, Slack, Teams, SMS and support tickets are missing from that table on purpose. A password sent that way can be read by far more people than the one you meant: mail and chat admins at both ends, anyone on CC or a distribution list, anyone it’s forwarded to, every synced phone and laptop, years of backups and archives, and whoever breaks into any of those accounts later. Why you shouldn’t send passwords over email or Slack goes through each one. A one-time link turns “everyone who can ever read this mailbox” into “one person, once, before it expires”.

Use the password manager when access is ongoing

If the person will keep using the credential, a password manager beats any link. In 1Password, move the item into a shared vault the person belongs to. In Bitwarden, put it in a collection in your organisation and give their group access. Rotation then reaches everyone automatically, and you have one place to answer “who can get at this?”

Both also do one-off sharing. 1Password can share a copy of an item as a link with an expiry and, if you choose, a single view. Bitwarden Send shares text or a file with a deletion date, an optional maximum access count and an optional password. If your team already pays for one of these, those features are a perfectly good way to send a one-time link.

A password manager is only the wrong answer when the recipient isn’t in it and isn’t going to be.

Send a one-time link, step by step

This is the method for most handovers to people outside your vault. The steps apply to any one-time link tool; where ShareShield does something specific, it’s noted.

1. Check the request is real. If someone emailed asking for a password, confirm it with them through a channel you already trust before you send anything. A request for credentials out of the blue is exactly what a phishing attempt looks like.
2. Paste only the password. Leave the username, URL and system name out of the secret. A link that reveals a string is far less useful to an interceptor than one that reveals the hostname, the admin username and the password together.
3. Set the views to 1. One view means that if the recipient clicks and finds the link already used, someone else read it, and you know to change the password.
4. Set the shortest expiry they can realistically meet. An hour if they’re waiting for it, a day if they’re in another time zone. Choosing a link expiry has a table by scenario.
5. Add a passcode for anything that matters, and send it separately. Read it out on a call or send it by text, never in the same message as the link. In ShareShield, five wrong passcodes destroy the secret.
6. Send the link directly to the person. A direct message or an email to them alone, not a team channel or a shared mailbox. ShareShield can email the link from the app and lock it so only that address can open it, with a code sent to the recipient’s inbox.
7. Tell them what it’s for through the other channel. “The staging database password is in your email; the username is deploy” over Slack keeps the context away from the secret.

One thing to check about any tool you use: chat apps and email security gateways open links to build previews and scan for malware. If the tool counts that automated visit as a view, the link burns before your recipient sees it. ShareShield only counts a view when someone presses Reveal secret, so previews and scanners don’t use it up.

To be plain about what you’re trusting: ShareShield encrypts each secret on its servers with AES-256-GCM under its own key, and deletes it after the last view or at expiry. That is server-side encryption: our servers encrypt and decrypt it, so you are trusting us to run them properly. The security page explains the model, including what it doesn’t protect against.

Split channels only when a link won’t work

Splitting means sending the username by email and the password by text, or half of something one way and half another. It protects you if exactly one channel is compromised. It does nothing about retention: both halves are still stored, searchable and backed up wherever they landed.

If you have to do it, put the password in the channel least likely to be kept and searched (a phone call beats a text, a text beats an email) and the context in the other. Don’t split the password itself into two halves; each half is weaker on its own, and both are stored anyway.

Hand it over in person for the keys to everything

For credentials that control other access, such as the domain registrar, the cloud root account, the identity provider’s global admin or a set of recovery codes, a link is often not enough ceremony. Hand it over in person, or write it down, seal it, and keep it in a safe with a record of who opens the envelope. The NCSC’s password guidance for system owners accepts that a securely stored written record is sometimes the right answer.

Reading a password aloud over the phone is fine for a short passcode. For a long random password, it invites mistakes, repeated attempts and someone writing it on a pad.

After it’s sent: confirm, then rotate

Sending the password is half the job.

• Confirm they received it. Ask the recipient to tell you once they have it. The guidance for control 5.17 in ISO/IEC 27002:2022 (authentication information) suggests users acknowledge receipt of credentials they’re given, and it’s a cheap habit.
• Check the link’s state. If they say the link was already used, or it expired unopened, treat the password as exposed. Change it and send the new one. In ShareShield, the dashboard shows whether a secret has been opened, and you can ask to be emailed when it is.
• Rotate on events, not on a calendar. NIST SP 800-63B says not to force periodic password changes, and to force a change when there’s evidence of compromise. For a handover, the events are: a temporary password being used for the first time (the user sets their own), a temporary person finishing their work, and any sign the secret went somewhere it shouldn’t.
• Make sure it lands somewhere sensible. Ask them to save it in their password manager, not a notes app or a text file on the desktop.

Mistakes that undo the rest

• The passcode in the same email as the link. Anyone with the email has both.
• A link posted in a team channel “for whoever picks this up”. You lose the one-view signal and have no idea who read it.
• Ten views, just in case. If several people need it, send each person their own link, so each has their own one-view check.
• Screenshots. Photos sync to cloud libraries, and Apple’s and Google’s photo apps can search the text in images.
• Pasting it into a ticket. Jira, Zendesk and ServiceNow keep comment history, email it out as notifications and show it to everyone with access to the queue.
• The same temporary password for every new starter. Once one person knows the pattern, they know everyone’s.
• Sending it back to whoever asked by email, without checking the request was genuine.

If you’re on the other side and need a client or colleague to send a password to you, asking a client for a password covers secret requests and what to say.