Every new client starts the same way: someone on your side creates their account, and someone has to tell them the password. For an agency, a managed service provider or a SaaS team with a hands-on onboarding process, that moment repeats dozens of times a year, and the welcome email with the credentials in it is one of the most reliable leaks in the business.
One-time credential sharing for client onboarding replaces that email with a link that is destroyed the first time it is opened. The routine below takes a minute per client, works for the first login and for confidential onboarding instructions alike, and leaves a record you can point to later.
What the welcome email should and should not carry
Onboarding mixes two kinds of information. Sort them before you write anything.
| Goes in the normal email | Goes in a one-time link | | --- | --- | | Welcome note, kickoff schedule, who to contact | Initial password or access code | | Public help articles and the login URL | API keys, webhook secrets, integration tokens | | What the client will receive and when | Internal procedures, admin URLs, anything you would not want forwarded | | Their username (on its own) | Any passphrase or recovery code |
The rule of thumb: if a forwarded copy of the email would let someone act as the client, that line belongs in the link.
The routine, step by step
- Create the client's account with its own login and the role it needs. If your platform supports it, make the first password temporary so the client must change it on first sign-in.
- Verify the contact. Use the name and address from the signed agreement or the kickoff call. If credentials were requested from a new address, confirm by phone with the person you already know.
- Create the one-time link. Paste the password into the secret link tool and nothing else. The text is encrypted in your browser before it is stored, the stored copy is destroyed on first open, and the link expires at the time you set if nobody opens it.
- Set the expiry to the real window. One hour if you are on a call with them, 24 hours if they will pick it up later. Set the view limit to one.
- Add a passphrase on a Pro account for admin-level access, and send it by text message or read it out on the call.
- Send the link in the welcome email with the username, the login URL and one line saying the link opens once and expires at a stated time. The email now contains nothing an attacker can use.
- Confirm access, not the value. Ask the client to sign in and change the password. If the link reports it was opened before they got to it, reset the credential and send a fresh link.
- Record the handoff: client, account, who received it, when, and when the temporary password was replaced. Never the password.
One MSP pattern we see often: the temporary admin password goes out as a burn-after-read link with a one-hour expiry and a passphrase sent by SMS, and the audit timeline on the Pro plan later shows the exact minute the client opened it. That timeline is the evidence when a client asks who had access and when.
How to share confidential onboarding instructions with a one-time link
Credentials are the obvious case, but onboarding also includes material that is not a password and still should not be forwarded: the admin console URL and its initial access code, the steps to connect their payment provider with a live key, a runbook for the integration you are building for them, or a client-specific procedure with internal details in it.
Share confidential onboarding instructions with a one-time link in the same way, with three adjustments:
- Write the instructions in the order the client will do them, naming the official portal or application at each step, so they do not need to ask follow-up questions in email that quote the content back.
- Keep the permanent parts out. A link that burns on first open is wrong for a reference the client will return to. Put the durable guide in your client portal or help centre, and use the one-time link only for the confidential part: the code, the key, the internal URL.
- Attach a file when the content is a document. From a signed-in LinkPilot account you can attach up to three files of 9 MB each, encrypted in your browser before upload and deleted after one download. A PDF of the client-specific setup steps fits easily.
Tell the client in the kickoff call who will send the link and roughly when, so an unfamiliar link from your domain does not look like phishing, and so they do not open it on a shared machine before they are ready.
Scaling it across clients
An agency with many clients needs the routine to survive handoffs between account managers.
- One account per client, one credential per person. Shared "agency@" logins cannot be audited or removed cleanly. LinkPilot's Agency plans give each client an isolated workspace with its own members and domain, so access is per client by design.
- Set the expiry by default, not by judgement. Most teams settle on 24 hours for onboarding links and one hour for live calls.
- Keep the record in the CRM, not in the email thread: date, recipient, which credential, when it was replaced.
- Rotate on contact change. When the client's main contact leaves, their access ends and any credential they received is reset, even if the client relationship continues.
When the link is the wrong tool
A one-time link delivers a value once. It is not a place to store anything, and it is not a substitute for proper access control. If the client's team needs ongoing access to a credential, that belongs in a password manager the client owns. If your platform supports inviting the client by email to set their own password, use that and skip the credential handoff entirely. The link is for the gap in between, and for every onboarding where that gap exists today.