Credentials cross team boundaries all the time. Platform hands a deploy key to a product team, support gets the admin login for a vendor portal, finance passes the bank API token to engineering for an integration. Each handoff is routine, and each one is where a credential most often ends up in a Slack thread forever.
A secure way to hand off credentials between teams is less about a clever tool than a clear rule for which of two tools to use, plus a few habits around it. This guide sets out that rule and the habits: scope the credential, deliver it without putting it in a message, name an owner, and remove it on time.
The one decision that matters: vault or one-time link
Everything else follows from how the receiving team will use the credential.
| The receiving team will | Use | Why | | --- | --- | --- | | Keep using it, several people, indefinitely | A shared vault in your password or secrets manager | Named access, revocation and rotation in one place | | Use it once, or one person needs it briefly | A one-time secret link | The message carries only a link, the copy is destroyed on first open | | Run it from code or CI | A secrets manager with machine identities | No human ever sees the value |
The vault is the system of record. If the credential has a life beyond the handoff, it belongs in a shared vault that the receiving team owns, with members added by name. Most business password managers and tools such as Vault or AWS Secrets Manager do this well.
The one-time link is for the moment of transfer when a vault is the wrong fit: the recipient is not in your vault, the credential is temporary, or you need to pass a value to one person right now. The secret is encrypted in your browser, the stored copy is destroyed the first time the link is opened, and the link itself dies at its expiry if nobody opens it. Secret links vs password managers goes through the edge cases.
Never email, chat, shared documents or tickets. They all keep copies, they all sync to devices you do not control, and they are all searchable by the next person who gets into the account.
Scope the credential before it moves
A good channel cannot repair an over-powered credential.
- Create a separate account for the receiving team or person rather than lending one tied to an individual. Shared identities cannot be audited and cannot be removed cleanly.
- Grant the permissions the task needs. A team that reads reports does not need write access. A team that deploys does not need billing.
- Rotate first if the value has travelled. If the existing key has been pasted around, issue a fresh one for the handoff rather than spreading the old one further.
- Search the surrounding material. Tickets, runbooks, example configs and scripts attached to the work often contain the very credential you are about to hand over. Remove it before the handoff, or the handoff is the least of your exposure.
The handoff itself
- Verify the recipient by a channel your organisation already trusts: the ticket, a known manager, a video call. Lookalike addresses and autofilled names are the usual way a secret goes astray.
- Deliver through the chosen tool. Vault: add the person to the shared collection. Link: paste the value into the one-time secret link tool, set the expiry to the real window (an hour if they are waiting, a day across time zones), set the view limit to one, add a passphrase on a Pro account for anything sensitive, and send the link.
- Send context separately. The username, host and what the credential unlocks go in a normal message, never alongside the link. A single leaked message should never contain both halves.
- Record the handoff in your system of record without the secret: recipient, purpose, system, owner, end date.
- Ask for confirmation of access, not of the value. "Can you log in?" is the right question. "Send me the key back to check" is not.
For a team doing this often, the LinkPilot Slack app turns a pasted password into a one-time link from inside the channel, so the habit does not depend on everyone remembering to open another tool.
Name an owner, then review on a schedule
Credentials without an owner never get rotated or removed. The receiving team should name one person who is accountable for the value: who holds it, who else needs it, and when it goes away.
- Least privilege by role, with roles or groups where they make administration simpler, so one departure does not mean one reset per system.
- Multi-factor authentication on the vault, because the vault is now the thing worth attacking.
- A review cadence that matches sensitivity: quarterly for most shared credentials, at every team change for production access.
- Audit the handoffs. A vault shows who accessed what. A Pro LinkPilot account shows an audit timeline for each secret link, so you can see when a one-time reveal happened and match it to the recipient's confirmation.
Expiry, rotation and exposure
Decide the end of the credential's life before it begins.
- Temporary access ends on the agreed date. Remove the account or the vault membership and revoke any one-time link that was never opened.
- Rotation follows risk, not the calendar alone: after a departure, after a vendor change, after any suspected exposure, and on a schedule for anything long-lived.
- A suspected leak is a leak until proven otherwise. Rotate at the system that accepts the credential, tell the owner, and update the jobs and services that depended on the old value. The API key guide has a rotation checklist that applies to most credential types.
Two tools, one rule for choosing between them, and an owner for every value. That is the whole system, and it holds up across far more handoffs than any policy document people stop reading.