One-time links vs password managers: which to use when

If a credential will be used again by people on your team, it belongs in a password manager. If you need to hand one credential to someone who isn’t in your vault (a client, a contractor, a new starter whose accounts don’t exist yet), a one-time link is the better tool. Most teams need both, and they work best together: the vault is where a credential lives, and the link is how it crosses to someone who can’t see the vault.

Trouble starts when one tool is used for the other’s job. A shared vault entry for a contractor you’ll never work with again is an account someone has to remember to clean up. A one-time link for a password the team uses every day means sending it again each time someone needs it, with nobody clearly responsible for changing it.

Storage and handover are different jobs

A password manager such as 1Password, Bitwarden or Keeper is storage with access control. Credentials live there for months or years. People are given access to a vault or collection, use autofill to sign in, and lose access when they leave. Team plans record who opened or changed an item.

A one-time link is a handover. You paste a secret, choose how many times it can be opened and when it expires, and send the link. When the recipient opens it, the secret is shown and then deleted from the service. Nothing stays behind except what the recipient decides to save. Compare that with an email, which can be read by everyone in CC, anyone it’s forwarded to, the mail admins at both ends and whoever compromises either mailbox later. A link narrows that to one person, once.

Side by side

When the password manager is the answer

• The credential is shared and used repeatedly. The company’s social media login, the domain registrar, the staging database, the Wi-Fi in the office. Put it in a shared vault with a named owner.
• People need to sign in with it, not just read it once. Autofill is the point of a password manager, and it also protects against typing a password into a convincing fake sign-in page.
• You need to know who has access right now. A vault’s membership list answers that. A pile of opened links doesn’t.

One caution applies to both tools. Removing someone from a vault stops them seeing future changes, but they may already have copied the current value. When a person who knew a shared credential leaves, change the credential.

When a one-time link is the answer

• The recipient isn’t in your password manager and shouldn’t be. A client receiving the admin login for the site you built, a freelancer who needs an SFTP password for a fortnight, a vendor’s support engineer who needs a test account.
• Bootstrapping. A new starter’s first-day password for their laptop or identity provider account, before they have anywhere safe to keep it. Send it as a one-view link with a short expiry and force a change at first sign-in.
• One-off values. Recovery codes, a licence key, a token for a CI system, or the authenticator seed when you hand over an account that uses 2FA.
• Collecting a credential from someone else. If you need a client’s DNS login, asking them to email it puts it in two mailboxes. A secret request sends them a one-time form instead, and what they enter arrives in your account.

When a one-time link is the wrong tool

• Anything the team will need again next week. Re-sending is a sign the credential needs a home in the vault.
• As storage. A link kept in a ticket “for later” opens once, and then the next person finds an empty page.
• When the recipient already shares your password manager. If your contractor has a guest seat in 1Password or is in your Bitwarden organisation, share the item directly.
• When you need the provider to be unable to read the secret. ShareShield encrypts secrets on its own servers, not in your browser. If that doesn’t fit your threat model, read server-side vs end-to-end encryption for secret links, which also names the end-to-end tools we’d point you to.

It’s also worth knowing that 1Password’s item sharing and Bitwarden Send both create expiring links from inside the password manager. If you already pay for one of them and only hand things over now and then, they may be all you need. A dedicated tool earns its place when handover is frequent, when you want to request secrets as well as send them, or when you need organisation-wide rules about expiry, passcodes and who links can be sent to.

Using them together

This is the routine we’d suggest to most teams:

1. The vault is the credential’s home. Each shared item has an owner, who is responsible for changing it.
2. Handover happens by link. When someone outside the vault needs the credential, the owner sends a one-time link: one view, an expiry measured in hours rather than days, and for anything with admin rights, a passcode sent by a different channel (a phone call or text, not the same email thread).
3. The recipient stores it properly or not at all. If they will keep using it, they copy it into their own password manager from the reveal page. If not, they use it and close the tab.
4. Credentials come in the same way. When someone needs to give you a password, send them a request and move what arrives into the vault.
5. Endings trigger a change. When the engagement ends or someone leaves, change the credential in the vault. The link has already gone, so there is nothing to clean up on that side.

If you run this across a team, organisation policies let you set the maximum expiry and view count for everyone, require passcodes, and limit which email domains links can be sent to, so the routine doesn’t depend on everyone remembering it.