Sharing passwords with contractors, vendors and clients

You need to share a password with an external contractor, a vendor’s support engineer, your auditor or a client, and none of them is in your password manager. The short answer: give them their own account wherever the system allows it. If it doesn’t, decide by how long they need the credential. For a job of weeks or months, give them guest access to one vault in your password manager. For a single handover, send a one-time link. Either way, write down the end date on the day you grant access, and change the password when that date arrives.

Sharing inside a company is mostly a tooling problem. Sharing across companies is a trust and timing problem: you don’t control their devices, their mailboxes or their staff turnover, and nobody on their side will remind you when the job is over.

Why your password manager often can’t reach them

The obvious move is to share the item from 1Password or Bitwarden. Across a company boundary, that often doesn’t happen, for ordinary reasons:

• Seats cost money. In Bitwarden an external person usually needs a paid seat in your organisation. 1Password Business has guest accounts, limited to the vaults you share with them, but they still need a 1Password account, and someone has to create and remove it.
• They already use a different manager. A contractor’s own company may require them to keep credentials in its Keeper or Bitwarden and nowhere else.
• Their laptop is locked down. An auditor from a large firm often can’t install your choice of software, or sign in to a personal account on a managed machine.
• It’s a one-off. Creating an account for a vendor’s engineer who needs one password for one afternoon is more work, and more to clean up, than the job deserves.

None of this makes email acceptable. It means you need a second method that works without the other person joining anything.

Choose by what they need and for how long

Named accounts win on every count when they’re available: their own MFA, their actions in your logs under their name, and nothing to rotate when they leave. In Entra ID that’s a B2B guest invitation. In AWS it’s an IAM role they assume from their own account, with an external ID. In GitHub it’s an outside collaborator on the repositories they need. Only fall back to a shared password when the system has one login, such as an old hosting panel, a supplier portal or a router.

Each kind of outsider is a little different

Contractors and freelancers are the closest to staff. Treat them as joiners with a known leaving date: a named account where possible, a guest vault for the shared logins they really need, and an entry in the same leavers’ process as everyone else.

A vendor’s support engineer usually needs access for hours, not weeks. Ask what they actually need to do before you send anything. Often a screen share where you type the password, or a temporary account you delete afterwards, beats handing over the admin login. Confirm any request for credentials through the support case or a number you already have. A support engineer asking for a password out of the blue is what a phishing call sounds like.

Auditors rarely need a password at all. They need evidence: exports, screenshots, a read-only account you watch them use. If they do need direct access, give them a named read-only account with a date when it will be disabled, and tell them that date.

Clients are the reverse case: you’re handing over something you built, and the password is becoming theirs. Send it once as a one-time link, ask them to change it and to set up MFA on their side, and then delete your own copy. If you’re the one collecting a password from a client, asking a client for a password covers secret requests and the scripts to use. Agencies that do both on every project will find the kick-off-to-launch routine in password sharing for agencies.

Sending it across the boundary

The steps in how to send a password securely apply unchanged. Across companies, three of them matter more than usual:

1. Send it to the person doing the work. Not their account manager, not a shared support@ mailbox. A shared mailbox at another company has an audience you can’t see and a retention policy you didn’t choose.
2. Use an address you already have. Take it from the contract or the purchase order, not from a new email thread asking for access.
3. Lock the link to that address if your tool can. In ShareShield, email recipients can be set to recipients-only, so anyone else who opens the link is asked for a code sent to the recipient’s inbox. If your organisation restricts which email domains secrets may be sent to, add the vendor’s domain for the length of the job and remove it afterwards.

Send the password alone. The hostname, username and what it’s for go in your normal email or ticket, where they’re harmless without the password.

Time-box it on the day you grant it

The most common failure with outside access isn’t the handover. It’s that nobody ends it. Contracts finish early or quietly, the person who arranged access moves on, and the vendor’s engineer still has a working login a year later.

So decide the end date before you send anything, and put it somewhere that will remind someone:

• On the account itself, where the system supports it. Entra ID entitlement management (an Entra ID P2 or ID Governance feature) can grant a guest an access package with an end date and remove the access when it passes. AWS roles hand out temporary credentials, so once you remove the role’s trust in their account, nothing they hold outlasts its session.
• On the vault membership. Neither 1Password nor Bitwarden expires a guest on a date by default, so the end date lives in your ticket or calendar.
• In the contract. A clause requiring them to return or destroy credentials at the end of the engagement gives you something to point at. ISO/IEC 27001:2022 Annex A covers this ground in controls 5.19 to 5.22 on supplier relationships.
• In your register of shared accounts, against each external person who knows the password, so the next leaver review finds them.

Getting it back

You can’t make someone forget a password. “Getting it back” means making their copy worthless.

1. Remove their access: disable their named account, or remove them from the vault.
2. Change every shared password they knew. Start with anything that controls other access. The offboarding rotation checklist gives the order, and it applies to outsiders exactly as it does to staff.
3. Re-enrol MFA on shared accounts if an authenticator on their phone holds the second factor.
4. Revoke anything they created: API keys, SSH keys, OAuth grants, forwarding rules, extra admin accounts.
5. Ask them to delete their copies, and to confirm in writing. Then assume they haven’t, which is why step 2 comes first.

If the relationship ends badly, do all five the same day, and look at the sign-in logs for the accounts they could reach before you change anything, so you have a record of what happened up to that point.