Two tools, two threat models
Password vaults and one-time secret links get lumped together because they both involve secrets. In practice they solve almost opposite problems, and confusing them is how sensitive data ends up in the wrong place.
A password vault — 1Password, Bitwarden, LastPass, take your pick — is designed for persistence. You store a secret because you need it again tomorrow, next month, and when a colleague is on leave. The vault encrypts at rest, syncs across devices, and gives you audit trails if you're on a business plan.
A one-time link is designed for transmission. You have a secret right now that someone else needs exactly once, and after that it should stop existing. The goal isn't storage; it's controlled, traceable delivery with a guaranteed end state.
Where vaults fall short
Vaults are excellent for credentials you own long-term. They're a poor fit for the moment you actually hand a secret to someone who doesn't share your vault.
Say you're onboarding a contractor for a three-week engagement. You need to give them the staging database password. Your options inside a vault: add them as a vault member (now you have an offboarding task and a lingering access entry), share a vault item directly (most tools require them to have an account in your system), or copy the password out of the vault and send it some other way. That third path is where things go wrong — the secret lands in Slack, an email thread, or a shared doc, and it never leaves.
The same problem applies when you're giving a new hire their initial login credentials, sending a two-factor recovery code to a colleague who locked themselves out, or passing an API key to an agency. These are one-way handoffs. Nobody needs a persistent shared record of them.
What a one-time link actually does
When you create a note on SecureNotes, the content is encrypted in your browser with AES-256-GCM before it leaves your device. The decryption key lives in the URL fragment — the part after the #. Because the fragment is never sent to the server in an HTTP request, the server never sees the key, only an opaque ciphertext. The zero-knowledge architecture means even a full server compromise doesn't expose your note contents.
When the recipient opens the link, their browser decrypts the note locally, and the note is deleted from the server. The link is now dead. If an attacker intercepts the link after it's been read, they get nothing.
That one-read guarantee is the part most people undervalue. It turns a secret into something with a known expiration, which is far easier to reason about than "I sent it over Signal so it's probably fine."
The handoff gap in most workflows
Here's the threat most teams don't model explicitly: the moment between generating a secret and getting it into the right vault on the other end.
You rotate a database password. You put the new one in your vault. Now you need to tell the three other engineers. You could add them to a shared vault folder — if they're all in your organization's vault. Or you could send it via a one-time link, they copy it into their own vault, the link dies, and the transmission channel is clean. No copy of that password ever sits in chat history.
This is the pattern worth internalizing: vault for long-term storage, one-time link for the transmission event. They're not competing; they're complementary. The complete guide to secure password sharing covers the broader workflow, but this vault-plus-link combination is the piece most guides skip.
When to add a passcode
A one-time link is only as safe as the channel you use to send it. If someone compromises the recipient's email inbox before they open the link, they read the note and it's gone — the recipient never sees it, and you have no idea.
For high-stakes secrets, add a passcode to the note and send the passcode via a different channel. The link goes by email; the passcode goes by SMS or a phone call. An attacker who intercepts the email now has a useless ciphertext. This is out-of-band verification, and it raises the bar considerably.
The SecureNotes FAQ explains the passcode option in detail. For anything beyond a routine credential hand-off — a bank recovery code, credentials for a production system, a legal document — it's worth the extra step.
Vaults win on these dimensions
- Shared team access. Multiple people needing the same credential long-term is a vault problem, not a one-time-link problem.
- Audit trails. If you need to know who accessed a secret and when, a business vault gives you that. A one-time link tells you only that someone opened it.
- Credential rotation reminders. Some vaults flag aged passwords. One-time links have no opinion about your password hygiene.
- Offline access. Vaults sync and cache. A one-time link that's already been read is gone.
One-time links win on these dimensions
- Sharing with people outside your organization. No account required, no vault membership to manage.
- Secrets that should stop existing after delivery. Recovery codes, temporary passwords, initial credentials for a new account.
- Keeping transmission channels clean. Email threads, Slack history, and shared docs are permanent. One-time links are not.
- Contractor and vendor handoffs. As covered in the post on sharing login credentials with team members, external parties create unique risks that a shared vault isn't designed to handle gracefully.
The honest answer
If you're only using a vault, you're probably pasting secrets into Slack to fill the transmission gap. If you're only using one-time links, you have no durable storage and you're re-generating secrets constantly. Most teams need both, with a clear rule: vault for what you keep, one-time link for what you hand off.
Try it before you next paste a password into Slack
The next time you need to send a secret to someone outside your vault — a contractor, a new hire, a colleague on a different team — compose a one-time note on SecureNotes instead. It takes about thirty seconds, leaves no copy in your chat history, and gives you the certainty that the link dies after it's read.