Secret Links vs Password Managers

A password manager stores credentials a team uses repeatedly. A one-time secret link hands a credential to one person once, then destroys the copy it carried. Use the manager as the system of record and the link for the hand-off: most security-aware teams need both, and most of the friction comes from using one where the other belongs.

The jobs each one is built for

A manager is a system of record. A secret link is a delivery mechanism with strong forgetting semantics: after the hand-off, the link burns, expires, or gets revoked, and the URL left behind in chat or email points at nothing.

When the password manager wins

• The credential will be used repeatedly by a known team.
• You want a single canonical copy that updates everywhere.
• The recipient is already in your vault.
• You need autofill in browsers and CLI tools.
• You want breach-monitoring and weak-password reports across the whole credential inventory.

When the secret link wins

• The recipient is a contractor, customer, or vendor not in your vault — and never will be.
• You only need to deliver the credential once.
• You want a clear "this was read at 14:32" audit event for the hand-off, tied to that specific delivery.
• The credential is a short-lived token, OTP, or rotation secret that should not linger anywhere.
• You need the sensitive value out of the channel you're forced to use. Email and chat retain everything; a burned link retains nothing.

Pick by scenario

Three worked examples

Contractor hand-off

1. Pull the credential from the manager (or better, mint a scoped, time-boxed credential just for the contractor).
2. Create a one-time secret link: burn after one view, 24-hour expiry, passphrase set.
3. Email the link; send the passphrase by text or a Slack DM.
4. Watch for the view event. Once it's read, the link is dead and the email thread contains nothing sensitive.
5. When the engagement ends, revoke the credential at the source.

New-hire onboarding

The manager holds the canonical values. The hand-off problem is that the new hire isn't in the vault yet — their first credential is vault access. Deliver that bootstrap credential through a one-time link with a same-day expiry; everything after that flows through the manager like normal.

Customer API key delivery

Never email the key itself: email is stored indefinitely on multiple servers and is a primary target in account takeovers. Generate the key, send a one-time link, and let the burn event double as delivery confirmation. If the link expires unread, you know delivery failed before the customer complains — reissue with a fresh link.

The combined pattern most teams settle on

1. The team's long-lived credentials live in the password manager (1Password, Bitwarden, Vaultwarden).
2. When someone outside the vault needs a credential, an authorized team member pulls it from the manager and sends a one-time secret link with a short expiry.
3. The recipient stores the credential in their manager.
4. The link burns. The manager retains the canonical copy and the rotation history.

This way the audit story is split correctly: the manager owns "who has access to what" and the link owns "when did the hand-off happen, and was it read by exactly one party."

What about managers' built-in share links?

Several managers now ship their own expiring share features — 1Password item sharing, Bitwarden Send (as published July 2026; verify current docs before relying on specifics). If your whole world is inside one manager, these are legitimate and convenient.

A dedicated secret link still earns its place when you want a passphrase gate delivered out-of-band, a per-secret audit timeline you can point to later, unfurl-safe behavior in chat and email, or a tool that doesn't assume anything about which manager (if any) the other side uses.

What about rotation?

A secret link doesn't track rotation. If you share the same value twice through two different links, neither link knows the other exists. That's fine for the hand-off but useless for ongoing governance — keep that responsibility in the manager, and treat every rotation as a fresh hand-off with a fresh link.

Limits and honest caveats

• A secret link is not storage. If the recipient doesn't save the value into their own manager before the link burns, you're reissuing it. Say so explicitly when you send it.
• Neither tool survives the recipient. Once a human has read a credential, they can copy it anywhere. Both tools protect the transport and storage, not the far end.
• Know your provider's encryption model. Reputable password managers encrypt vaults end-to-end, and so does LinkPilot for Secret Link text payloads: the content is encrypted in your browser and the key stays in the URL fragment, so an operator cannot read an active secret. Passphrases are hashed client-side and burned payloads are irreversibly overwritten. Attached files are encrypted the same way. Update, 29 September 2026: this bullet previously said Secret Links were not end-to-end encrypted, which was accurate until that date. The details are on the security architecture page.
• The manager's master password is a single point of failure. That's the price of a system of record; protect it with a strong passphrase and hardware-backed 2FA.

Related reading

• How to share API keys securely
• Secure password sharing: 5 methods compared
• LinkPilot vs OneTimeSecret

References

• 1Password Support, Share items with anyone.
• Bitwarden Help Center, About Send.