Email is where credentials go to live forever. A password sent on Monday is still in the sender's outbox, the recipient's inbox, every phone and laptop that syncs either account, and the backups of two mail providers. Forward it once and the number of copies doubles.
Sharing credentials securely without email means choosing a channel that leaves no copies, or at least none you do not control. There are four good options. Which one fits depends on whether the recipient needs the credential once or for good, and whether they are inside your organisation.
Four ways to share credentials without email
| Method | Best for | What it does not do | | --- | --- | --- | | Password manager sharing | Teammates who need ongoing access | Help with a one-off recipient outside your vault | | One-time secret link | A single handoff to anyone, inside or out | Control what happens after the reveal | | Encrypted messenger with disappearing messages | Quick handoffs between people already on the app | Stop screenshots or prevent syncing to other devices | | Phone call or in person | Very high-value secrets, short strings | Scale, or leave any record of the handoff |
A password manager is the right place for a credential a team reuses. Shared vaults in 1Password, Bitwarden and the rest give named access, revocation and rotation. The gap is the person who is not in your vault: a contractor, a client, a new hire on day one, a vendor's support engineer. Inviting them for one password is heavy, and many managers' public share links are just time-limited plain pages.
A one-time secret link is built for that single handoff. The secret is encrypted before it is stored, the message you send carries only a link, and the stored copy is destroyed the first time the link is opened. Nothing is left in the chat or the ticket, and the link stops working at its expiry if nobody opens it. The secret links vs password managers guide goes into when each one wins.
Disappearing messages in Signal or WhatsApp protect the message in transit and remove it from the conversation after a set time. They do not stop a screenshot, and most people have their chats backed up or synced to a second device. Use them for low-stakes handoffs between people who are already on the app.
A phone call still works for a short string going to one person you can recognise by voice. It does not scale, and the recipient will write it down somewhere, so it is best for the passphrase that protects a link rather than the credential itself.
How to create a temporary link for sharing login details
The one-time link route takes about a minute. The steps below use LinkPilot's free secret link tool, which needs no account for text up to 10,000 characters. A signed-in account adds the expiry presets, view limits and file attachments.
- Check the recipient first. Confirm the person and the address or handle through a channel you already use with them. Most misdirected credentials are the result of autofill picking the wrong name.
- Paste only the password. The username, the URL to sign in at and any instructions go in a separate message. A link that leaks should give an attacker a dead link or useless context, never both halves.
- Set the expiry to the real window. One hour if they are waiting, 24 hours if they are in another time zone, seven days only with a reason. The link also burns the first time it is opened, so expiry is the fallback for a link nobody opens.
- Set the view limit to one unless two people genuinely need to open it. Multi-view links exist for that case, but the default for a login should be a single reveal.
- Add a passphrase on Pro for anything you would not want in a public channel, and send the passphrase by a different route, for example by text message or on a call.
- Send the link with one line of context: what it is for and when it expires. Then send the username and sign-in URL in a second message.
- Confirm the open. If the link says it has already been viewed and the recipient says they did not open it, change the password straight away. Pro accounts can check the audit timeline for the exact time of the reveal.
The encryption happens in your browser, before anything is sent to LinkPilot. The decryption key travels in the part of the URL that browsers keep to themselves, so the service never has the plain text and neither does anyone who sees the link in transit. The details are in client-side encryption for secret sharing.
Prepare the credential as well as the channel
A secure channel cannot fix a bad credential. Before you share anything:
- Give the recipient their own login when the system allows it. A separate account can be scoped and removed; a shared one cannot.
- Make the password unique. If the same string unlocks something else, you are sharing that too.
- Strip everything the recipient does not need. No recovery codes, no second account's details, no "while I'm at it" extras.
- Decide the end date now. If access should stop when the work does, put the date in your calendar before you send the link.
After the handoff
Once the recipient has signed in, the credential is on their side and out of your hands. Three things are still yours to do:
- Revoke the link if it was never opened and is no longer needed, rather than waiting for expiry.
- Rotate or remove the login when the work ends. Expiry on the link does nothing to the account.
- Watch the account's own sign-in history for a day or two. A login from an unexpected place is worth a question.
Credentials will keep needing to move between people. The point is to make the move leave nothing behind, so there is nothing to find in anybody's inbox later.