THE SHORT ANSWER
Start with an individual invitation and the permissions the work requires. If a credential really must be shared, use a temporary handoff, confirm receipt, and agree when the access ends.
A client handoff is rarely just a password. It is a decision about who should have access, what they should be able to do, and when that access should end. A little structure makes the exchange easier to manage.
Use this checklist at the start of a project, when a contractor joins, or when you hand completed work back to a client.
Keep the checklist handy.
A simple text file you can adapt to your process. No email required.
Download the checklistChoose access before you choose a channel.
Check whether the service can give the recipient an individual account or role. This is usually easier to remove later than a shared password, and it avoids granting more access than the job requires.
- Identify the work the person will do.
- Choose the minimum permissions that support it.
- Use a named account or invitation when available.
- Agree who owns the account and when access should end.
Sharing a credential and granting access are not the same thing. A private note can help with delivery. It does not manage permissions inside the service.
Request the details. Keep the secrets out.
Your onboarding checklist can record which services are involved, who owns them, and whether access is ready. It should not become another place to store plaintext passwords.
| Keep in the checklist | Handle separately |
|---|---|
| Service and account owner | Passwords |
| Requested role or permission | API tokens and private keys |
| Approval and access end date | Recovery codes and security answers |
| Access status | Full one-time secret links |
Confirm the recipient using an established contact method, especially if the request came from a new address or an unexpected message.
Make the handoff easy to understand.
Send an individual account invitation where possible. If a password or temporary credential must be delivered, use a suitable protected sharing tool. Keep the contents limited to what the recipient needs.
- Check the recipient before sending.
- Choose an appropriate expiration window.
- Treat the full sharing link as sensitive.
- If you add a password, communicate it separately.
- Confirm receipt without asking them to paste the secret back.
Tell the recipient that a one-time link may stop working after opening. They should open it when ready and follow their organization’s rules for storing credentials.
The recipient can save or screenshot what they see. Use the tool to reduce lingering hosted copies, and choose the recipient carefully.
Close the loop when the work is done.
Delivery is only part of the process. At the agreed end date, remove access that is no longer needed. Revoke a temporary token or rotate a shared credential when appropriate.
Update the inventory with access status and owner. Record completion of the task, not the secret itself. This gives the next handoff a useful starting point.
For your next project, start with the same checklist. Adjust the permissions and timing to the actual work rather than adding every possible account to the request.
Download the checklist