How to securely share credentials with contractors
A contractor needs the Stripe login on Monday and is gone in three weeks. Here is how to give them access without emailing a password, without adding them to a vault forever, and without having to remember to clean up.
Do not send the contractor a copy of the secret. Grant them access to it, with an approval step and an expiry.
A copy cannot be revoked. Access can, and if it expires by itself, nobody has to remember to clean up.
The three ways this normally goes wrong
Every team solves this problem in roughly the same three ways, and all three have the same flaw: the contractor ends up holding a copy of the secret that you can never take back.
- Slack or email. Fast, and permanently searchable. On paid Slack plans messages are retained indefinitely, so the credential is now sitting in an archive that future employees can search. There is also no record of who read it.
- A shared password-manager vault. Better, but it is an on/off switch. The contractor can open every item in that vault, as many times as they like, with nobody approving it, until someone remembers to remove them. Nobody remembers.
- A one-off encrypted link. Genuinely fine for a single hand-off. But it does not scale to a working relationship, it gives you no ongoing record, and the moment the link is opened the contractor has a copy you cannot revoke.
The distinction that fixes it: a copy versus access
If you send someone the value of a credential, you have given them a copy. Copies cannot be revoked. The only way to undo it is to rotate the secret, which means touching every system that uses it, which means you will not bother.
If instead you grant someone access to a credential held in a vault, you keep control. Access can be approved, timed, revoked, and, crucially, audited. The contractor still gets their job done. You just keep the ability to take it back.
What the workflow looks like
- Add the vendor once. Stripe, the ad platform, whatever it is. Give it an owner and a criticality.
- Store the credential. It is encrypted with AES-256-GCM and a per-credential IV. The list view never even loads the encrypted columns, so plaintext does not leave the server unless somebody with approved access explicitly clicks reveal.
- Invite the contractor as a viewer. A viewer can see that a credential exists. They cannot see its value.
- They request access to that one credential, with a justification and a duration.
- An admin approves or denies. Nothing is revealed until somebody says yes.
- The grant expires on its own. No cleanup task, no calendar reminder, no forgotten contractor with standing access six months later.
Every reveal is written to an append-only audit log with the actor, timestamp, IP address, and user agent. So the question "who actually looked at the production database password, and who let them?" has an answer.
The two failure modes this kills
The secret living forever in a searchable archive. Nothing you send in Slack or email can be taken back. Access to a vaulted credential can.
The access nobody remembered to revoke. Grants expire on a timer, so the cleanup happens whether anyone remembers or not, and offboarding the vendor closes the rest in one action.
Those two are what actually bite real teams, and both of them stop being your problem. See how this compares to a shared 1Password vault.
Common questions
- What is the safest way to share a password with a contractor?
- Do not send the value anywhere it will persist. That rules out Slack, email, and text, all of which keep a searchable copy forever. Use a system where the contractor is granted access to the credential rather than sent a copy of it, where somebody has to approve that access, where it expires on its own, and where you can see afterwards exactly who revealed what. If the contractor ends up with a copy of the secret in their inbox, you have not shared it, you have leaked it.
- Why is sharing credentials in Slack so bad?
- Because Slack is a searchable archive. On paid plans messages are retained indefinitely, so anyone who later joins the workspace with the right permissions can search for 'password' or 'api key' and read years of secrets. The credential also cannot be revoked: once someone has seen the message, the value is out, and rotating it is the only fix. And there is no record of who actually read it.
- Can I just add the contractor to our shared password manager vault?
- You can, and lots of teams do, but it grants standing access: from that moment they can open every item in that vault, as often as they like, with no approval and no expiry, until a human remembers to remove them. That last part is where it usually goes wrong. Nobody remembers.
- What happens when the contract ends?
- In our model, usually nothing, because the access already expired on its own. If you want to be certain, offboarding the vendor denies every pending access request against its credentials in the same transaction, and the audit log still shows everything that was revealed while they had access.
Keep reading
- Sharing an API key specifically?If it is an API key rather than a dashboard login, the developer guide walks the whole decision.
- Temporary accessWhy access that expires by itself beats access you must remember to revoke.
- Offboarding a vendorCut off everything a vendor could reach, in one action.
- vs a shared 1Password vaultWhy the shared-vault approach breaks down for contractors.
Give a contractor access that cleans itself up
Free while we build. No credit card, no sales call.