Every web project involves passing credentials around. The client sends you their registrar login so you can point the domain. You send them the WordPress admin account when the site goes live. Someone needs the Google Analytics property, the SMTP password, the Stripe test keys.
Most of that traffic goes by email or chat because it is quick and it works. The problem is not that someone is watching the message as it travels. The problem is that it never goes away.
Why emailed passwords linger for years
When you send a password by email, you do not create one copy. You create a handful, and you control almost none of them:
- Sent and received folders. Your sent folder keeps it, their inbox keeps it, and most people never delete either. Both are searchable for words like "password" and "login".
- Provider storage and backups. Gmail, Microsoft 365 and hosting mailboxes store messages in a form the provider can read, and deleted items often survive in trash, retention policies or backups for weeks or longer.
- Synced devices. The same message lands on a laptop, a phone, a tablet and maybe an old work PC that still has the account signed in. Lock screen notifications can show it to anyone nearby.
- Forwarding. Your client forwards "the website stuff" to their new marketing person, who forwards it to a contractor. Now the password lives in mailboxes you have never heard of.
- Future breaches. If any of those accounts is phished next year, the attacker searches the mailbox and finds a working login for the hosting account that has not changed since launch.
Slack, Teams and SMS have the same shape. Chat messages are kept according to workspace retention settings, are searchable by anyone in the channel, and can be exported by admins on some plans. Texts sit on the phone, in its cloud backup and in Messages in iCloud or Google's equivalent.
The threat model in plain English
You do not need to defend against a nation state. For a typical small business site, the realistic threats are:
- A compromised mailbox later on. The most likely one. Phishing and reused passwords give attackers access to email accounts all the time, and old credentials are the first thing they search for.
- The wrong person reading it. A mistyped address, an assistant with delegated inbox access, a shared family iPad.
- Someone reading the inbox right now. Less common, but it happens when an account is already compromised and nobody has noticed.
A good handoff method should leave nothing useful behind for threat one, make mistakes in threat two recoverable, and require a second channel to beat threat three. That is the bar the options below are measured against.
Your options compared
| Method | Strengths | Weaknesses | Best for |
|---|---|---|---|
| Plain email or chat | Instant, no setup, the client already knows how to use it | Persists in many places for years, searchable, easy to forward, readable by anyone who gets into either account | Nothing sensitive |
| Phone call | Leaves no written copy, the voice confirms who you are talking to | Long random passwords are painful to read aloud and easy to mishear, and people write them on sticky notes | Short passphrases, or the second half of a split handoff |
| Password manager sharing (1Password shared vaults or item links, Bitwarden organizations or Send) | End-to-end encrypted, access can be revoked, updates sync automatically, audit trails on business plans | Both sides usually need an account, and clients who do not use a manager will not set one up for a single login | Ongoing access between teams, agencies with many clients |
| One-time secret link with a separate passphrase | Nothing readable left in the inbox, works for anyone with a browser, no account needed, view and expiry limits | One-off: the client has to save the password somewhere themselves, and the link only works once | Handing a login to a client or a new contractor |
For most client handoffs the answer is a one-time link plus a passphrase sent another way. For long-running relationships between people who both use a password manager, share through the manager. The two work well together: the secret link gets a password to someone, and their password manager becomes where it lives.
A client handoff process for web projects
This is the routine we use at the end of a build. It takes about five minutes and leaves nothing useful in anyone's inbox.
1. Generate a strong, unique password
Never reuse the password you used during development, and never hand over something guessable like ClientName2026!. Use 20 or more random characters, or a six-word passphrase if the client will type it by hand. Generate it with a cryptographic random generator, not by mashing the keyboard.
2. Create a one-time link with a short expiry
Paste the username, password and login URL into the secret link tool. Set it to 1 view and an expiry of 24 hours or 3 days, depending on how quickly the client reads email. Add a passphrase. If you are also handing over a recovery codes PDF or an SSH key, attach it to the same secret so it is encrypted too.
3. Send the passphrase by a second channel
Email the link. Text or call with the passphrase. Someone with access to the inbox alone gets a link that asks for a passphrase they do not have, and someone who sees the text has nothing to type it into.
4. Confirm receipt
Ask the client to reply once they have logged in. That reply tells you the link was opened by the right person, and it gives you a timestamp to compare against if anything looks odd later.
5. The client changes the password and enables 2FA
Ask them to change the password on first login and save the new one in their own password manager, or at least their browser's built-in one. Then turn on two-factor authentication: WordPress via a plugin such as Wordfence or Two Factor, and the hosting panel and registrar from their security settings. Two-factor protects them from the password leaking anywhere else, not only from your handoff.
6. Revoke or rotate when the project ends
Remove your own user accounts, or downgrade them if you are on a maintenance plan. Rotate any shared secrets you had access to: SMTP passwords, API keys, FTP or SFTP accounts. Write down what you changed so the client has a record.
Tip: keep views at 1 for passwords. Use 2 or 3 only when several named people genuinely need to open the same secret, and in that case consider a password manager instead.
If the link shows as already viewed
Your client clicks the link and sees that the secret is gone. Treat that as a possible interception until you can explain it:
- Ask whether anyone else could have opened it: a colleague, an assistant, a second device where they clicked first.
- Rule out the email scanner. Website Blueprints Secret Share requires a click on Reveal before it decrypts, so automated link checkers do not use up the view. Other services may not work that way.
- If there is no innocent explanation, change the password immediately and log out all sessions. In WordPress, Users, Profile has a "Log Out Everywhere Else" button.
- Check the account's recent activity or login history if the platform shows it, then send a fresh link with a new password.
That is the real value of a one-time link: you find out. An emailed password can be read a hundred times without anyone noticing.
Recurring access for agencies
Handoffs are one-off. Ongoing work needs a different approach, because the best password to share is one you never share at all.
One account per person
Every person who needs access gets their own login. That means a separate WordPress user for each developer, a separate hosting user, a separate registrar user. When someone leaves, you remove their account and nothing else changes. Shared logins make that impossible: the only way to remove one person is to change the password on everyone.
Never share the owner login
The client should own the hosting account, the domain registration and the primary admin on every platform, with their own password and 2FA. Agencies get added as users. If the relationship ends badly, or the agency closes, the client still controls their business, and nobody is locked out because the only person who knew the owner password left.
Use role-based access
- WordPress: Administrator for developers who install plugins, Editor for content teams, Author or Contributor for guest writers. Do not make everyone an Administrator because it is easier.
- Hosting: hPanel, cPanel resellers, Cloudflare and most managed WordPress hosts let the owner invite collaborators with limited permissions, and remove them later without touching the owner password.
- Registrars: many registrars offer delegated or shared access so a developer can manage DNS without the ability to transfer the domain away. Use it, and keep transfer lock on.
- Google Analytics, Search Console, Tag Manager: add people by their own Google account with the lowest role that does the job.
Review the user list on every platform at least once a year, and every time someone leaves the agency.
Sample email wording
Clients are more likely to follow the process if you explain it briefly. This template works for most handoffs:
Subject: Your website login Hi Dana, Your new site is live. Here are the WordPress admin details: https://websiteblueprints.tech/s/#... The link opens once and expires in 3 days. It is protected with a passphrase, which I will text you in a moment. Once you are logged in: 1. Change the password and save it in your password manager. 2. Turn on two-factor login (I have installed the plugin). 3. Reply to let me know you are in. If the link says it has already been viewed, do not worry, just tell me and I will reset the password and send a new one. Thanks, Sam
Frequently asked questions
Is it really that bad to email a password?
The risk is not the moment of sending, it is the years afterwards. The password sits in both mailboxes, their backups and every synced device, and anyone who later gets into either account can search for the word password and find it. If the client changes it straight away, the damage is limited, but most never do.
Why send the passphrase by text if the link is already one-time?
A one-time link protects against someone finding the email later. It does not protect against someone who is reading the inbox right now, because they could open the link first. A passphrase sent by a different channel means an attacker needs both the email account and the phone to read the secret.
Can the secret share service read my passwords?
Not with a properly built tool. Website Blueprints Secret Share encrypts the secret in your browser with AES-256-GCM and puts the key after the # in the link. Browsers never send that part of a URL to the server, so the server only stores ciphertext it cannot decrypt, and deletes it after the last view or when it expires.
What if my client's email scanner opens the link first?
Corporate filters in Outlook, Gmail and security gateways often visit links to check them for malware. Secret Share does not decrypt or count a view until a person clicks Reveal, so a scanner loading the page does not use up the view. If a link still shows as already viewed, treat the password as exposed and change it.
Should I give my client the hosting owner login or my own account?
The client should own the hosting, domain and site accounts, with their own login and two-factor authentication. You should be added as a separate user with the access you need. That way nobody shares the owner password, and removing you at the end of the project is one click rather than a password reset that locks everyone out.