The question nobody asks before hitting send
Most people pick a channel for sharing a secret the same way they pick a lunch spot — whatever is convenient and already open on their screen. Slack is up, so the database password goes into Slack. Email is faster than scheduling a call, so the recovery code goes into email. The decision is made by proximity, not by risk.
That habit is how credentials end up preserved forever in chat history, searchable by anyone who inherits the account or responds to a legal hold. If you have never thought about what makes a sharing channel actually trustworthy, this post is for you.
The four properties a trustworthy channel needs
Before picking a tool, it helps to name what you are actually trying to protect against. A channel is trustworthy for sharing secrets when it satisfies four conditions:
- The secret does not persist after delivery. Once the recipient has read it, a copy should not remain on a server, in a log, or in a thread. Persistence is the enemy of secrets.
- The channel is not a shared surface. A Slack channel where a dozen people have read access is not a private channel, even if it feels like one. Email forwarding, CC fields, and shared inboxes create the same problem.
- Encryption is end-to-end, not just in transit. TLS protects data moving between your browser and a server. It does not protect data sitting in the server's database, readable by the service provider or anyone who compromises their infrastructure.
- Delivery confirmation is possible without re-exposing the secret. You want to know the right person got it — without needing to send it twice.
Most everyday tools fail at least two of these. Email fails all four.
Mapping common tools to those four properties
It is worth being concrete here, because people often assume that using an encrypted messaging app solves the problem. It does not fully solve it.
Slack and Microsoft Teams: Persistent by default. Searchable. Often backed up by eDiscovery tools your employer or a regulator can access. If you are worried about what an IT audit will find in your chat logs, secrets in Slack are the first thing that surfaces.
Email: Persistent at both ends, usually unencrypted at rest, easily forwarded, and frequently scanned by spam and security filters along the route. TLS between mail servers is opportunistic — servers can and do negotiate unencrypted connections.
Signal or iMessage: Better. End-to-end encrypted in transit. But messages persist in the conversation history on both devices. If the recipient's phone is compromised, unlocked, or subject to a legal request, the secret is still there to be read.
Password vaults with sharing features (1Password, Bitwarden): Strong for long-term credential storage and team access. Weaker for one-time delivery to someone outside your organisation, because you are creating a persistent shared item that requires ongoing management. One-time links and password vaults serve different purposes — knowing which situation you are in matters.
One-time encrypted notes: Designed specifically for this problem. The secret is encrypted before it leaves your browser, the key lives only in the URL fragment and never touches the server, and the note is deleted after the first read. Nothing persists. The channel is not shared. The encryption is end-to-end by construction.
A practical decision framework
Here is how to think through the choice quickly:
- Is this going to someone inside your organisation who already has a vault? Share it through the vault. That is what vaults are for.
- Is this a one-time transfer to a contractor, new hire, or external party? Use a one-time encrypted note. You want delivery, not ongoing access.
- Does the recipient need to act on it once and never again? A self-destructing note handles this cleanly. A shared vault item creates a dangling permission you will need to revoke later.
- Is the secret high enough value that you want a second factor on delivery? Add a passcode sent via a separate channel — a phone call works well here. The link delivers the ciphertext; the passcode delivers the decryption key. Two channels means a single compromise does not expose both.
That last point is underused. Sending a note link over email and a short passcode via SMS is significantly more robust than sending either the password itself over either channel. The attacker now needs to compromise both.
The threat model most people skip
Here is the insight that changes how most people think about this: the biggest risk in secret-sharing is usually not interception. It is persistence.
Your Slack messages are not being intercepted mid-flight in most threat models. They are sitting in a log, being indexed by a third-party eDiscovery tool, getting forwarded to a new channel when the project gets reorganised, or just sitting there waiting for the day someone's account gets compromised and an attacker has full search access to years of history.
Designing for persistence means designing for the worst day, not the average day. A secret that disappears after one read cannot be exfiltrated six months later in a breach. That is the fundamental advantage of self-destructing messages — not the theatrics of watching something disappear, but the practical reality that there is nothing left to steal.
This also changes how you think about confirmation. With a one-time note, if you send the link and the recipient says they never received it, you have a signal: either the link was intercepted and already read, or there was a delivery failure. Either way, you now know to generate a new secret rather than continuing to trust the old one. Persistent channels give you no such signal.
One workflow worth adopting immediately
If your team regularly onboards contractors or shares credentials during vendor setup, build a one-sentence default into your runbooks: Never share a secret directly in a message. Always generate a one-time note and send the link.
The overhead is about thirty seconds. The payoff is that your chat history, your email archive, and your eDiscovery exposure are all clean. When you rotate credentials after a contractor offboards, you are not hunting through six months of Slack threads to figure out what they had access to. The note was read, the note is gone, and your log shows a clean handoff.
Try it before you next paste a password into Slack
The framework here is not complicated: match the tool to what the secret actually needs. One-time delivery to an external party almost always calls for a one-time encrypted note. Compose a self-destructing note on SecureNotes — it takes less time than typing the password directly into your chat window, and it leaves nothing behind.
