How to send a password to a client or supplier
With an outside party you can't impose tooling: they don't share your password manager and won't install anything to receive one login. What you can control is whether the credential ends up archived at two companies at once. An encrypted link that expires solves precisely that, and the client only needs a browser.
Always keep the file apart from its key
If you send an encrypted ZIP or PDF and type the password into the same message, the encryption adds nothing: whoever reads the email holds both pieces. The file can travel by email; the key goes through a different channel. That is the one requirement that genuinely matters.
How to run the handover
- 01Create a credential dedicated to that client or supplier, with least privilege and no reuse of internal passwords.
- 02Email the context: what the access is for, where it is used, who the technical contact is, and the encrypted file if there is one.
- 03Generate an encrypted link for the password, with self-destruct on open and an expiry that matches the use case.
- 04Send the link through a different channel: a text to the contact's phone, a call, or the project chat if it is private.
- 05Record in your internal log what was handed over, to whom, and when — without writing down the password.
- 06When the project ends, revoke the access. A temporary credential nobody disables stops being temporary.
Which expiry to choose
The shortest window that still works for the other person. Same time zone and both at your desks: minutes. Time difference, or a contact who is travelling: hours or a day.
| SITUATION | EXPIRY |
|---|---|
| You are on the phone right now | 10 minutes |
| Same time zone, working hours | 30 minutes - 1 hour |
| Different country, or contact travelling | 24 hours |
| Handover before a weekend or holiday | 7 days |
| Documented long-lived credential | Longer window, and ask them to rotate on first sign-in |
Common mistakes in B2B handovers
- Sending the credential to a distribution list or shared alias: you don't know who read it.
- Reusing the same password across clients: one leak affects all of them.
- Leaving access open when the project ends because it is on nobody's checklist.
- Attaching a document with every project credential instead of just the one needed.
- Sharing an employee's personal login instead of creating an account for the outside party.
What to tell the client
One line is enough: "I'm sending the password as an encrypted link that deletes itself when opened; open it when you can save it, and if it expires I'll generate another in seconds". They don't need an account or an install, and if they want the technical detail you can point them at the security guide.
