How to share credentials with clients (without leaking them)

If you run an agency, freelance, or consult, this conversation is your weekly routine: the client needs the WordPress admin password, you need their AWS keys, someone needs the staging database URL. And the channel, almost every time, is email or Slack.

Both fail the same way, for the same reason: retention.

The problem isn't interception — it's storage

TLS protects messages in transit; almost nobody is sniffing your packets. The real exposure is that email and chat are databases of everything ever sent. The password you emailed in 2023 is still there — in the recipient's inbox, your sent folder, both providers' servers, every backup, and every device either of you has logged into since. When any one of those is compromised — one successful phish, one stolen laptop, one reused password on the client's side — the attacker doesn't get one credential. They get the archive. "Search inbox for password" is a standard post-breach move precisely because it works.

Add the offboarding problem: the contractor you stopped working with two years ago still has every credential you ever Slacked them, and you have no way to know which ones, let alone revoke the copies.

What "good" looks like

A credential handoff is safe when it has these properties:

• Ephemeral — the message ceases to exist after delivery, automatically, without relying on anyone's discipline.
• End-to-end encrypted — no server in the middle can read it, so a breach of the middleman reveals nothing.
• Delivery-confirmed — you know it arrived, and to whom, because exactly one open is possible.
• Accountless for the other side — clients won't install a tool or create an account for a 30-second task. Any workflow that requires it will be bypassed back to email.

The workflow that survives contact with real clients

1. Send a one-time encrypted link. The credential is encrypted in your browser; the decryption key rides in the URL fragment, which never reaches any server. The first open destroys the secret — if the link leaks afterwards, it opens nothing.
2. Send the link over the channel you already share (email, Slack, WhatsApp). This is now safe: the channel only ever saw a link that no longer works. Its retention problem stops mattering.
3. If the link arrives already-dead, treat it as an incident. One-time delivery doubles as a tripwire: "already viewed" before your client opened it means someone else did. Rotate the credential — you just caught an interception that email would have hidden forever.
4. For the crown jewels, skip storage entirely. Live P2P transfer moves the secret directly between your browser and the client's, end-to-end encrypted with forward secrecy — it never exists on any server, even as ciphertext.
5. Receiving credentials? Send a request link instead. Clients will otherwise reply with the password in plaintext — it's what people do. A secret-request link inverts the flow: they paste, it encrypts in their browser, you get a one-time read.

The checklist

• Never send credentials as message text — only as one-time links.
• Set the shortest expiry the workflow tolerates (hours, not weeks).
• Rotate immediately if a link reports "already viewed".
• Use P2P mode for keys with long lifetimes (SSH, signing, cloud root).
• Request secrets via request links; never let clients improvise.
• Keep an audit trail of what was shared when — without storing the secrets themselves.

The uncomfortable truth about credential leaks is that they're rarely exotic. They're an old email, found later, by the wrong person. The fix costs thirty seconds: share a link that dies on arrival, instead of a message that lives forever.