How To Share Passwords With Clients Safely

Sharing passwords with clients is common in freelance work, but it is rarely the best way to give access.

The safer goal is to avoid sharing passwords when a named account, invite, role, or temporary permission can do the job. When a password really must be shared, use a controlled method that can expire, be revoked, and be documented.

This guide is for freelancers who need to handle client logins without turning Slack messages, email threads, screenshots, and old project notes into a permanent password archive.

The short version

Do not send passwords in email, chat, screenshots, or project-management comments. Ask for named access first. If that is not possible, use a password manager’s secure sharing feature or a temporary encrypted link, limit who can open it, set an expiration time, and rotate the password after the handoff if needed.

Use this order:

Ask the client to invite you as a named user.
Use role-based access instead of a shared admin login.
If a password must be shared, use a secure password-manager sharing feature.
Send any link and passphrase through different channels when possible.
Document who shared it, why, and when access should be removed.
Rotate or remove access at project close.

This keeps password sharing as a controlled exception, not the normal operating model.

A shared password has three problems.

First, it hides accountability. If five people use the same admin login, it is hard to know who changed a setting, downloaded a file, installed a plugin, or deleted a record.

Second, it spreads into places that were never designed to store secrets. Email inboxes, Slack threads, screenshots, support tickets, and project-management comments can keep a password long after the project is finished.

Third, it is hard to remove cleanly. If the client changes agencies, ends the project, or hires another contractor, the password has to be rotated everywhere it was used. That is often skipped because nobody remembers where it was sent.

For a freelancer, this creates risk in both directions. You do not want to be responsible for a client’s leaked login, and you do not want old client credentials sitting in your systems forever.

Start by asking for named access

The safest password is the one you never receive.

Before accepting a shared credential, ask whether the client can invite you as a named user. Many tools support users, members, collaborators, guests, roles, seats, or temporary access.

Named access is better because:

Advantage	Why it matters
Accountability	Changes can be tied to your user account instead of a shared login.
Least privilege	The client can give only the role you need.
Offboarding	The client can remove your access without changing the password for everyone.
MFA support	You can protect your own login with your own MFA method.
Cleaner records	Your password manager stores your account, not the client’s shared secret.

If the client says there is no user-management feature, confirm that before accepting a shared admin password. Some smaller tools hide access settings behind “team”, “members”, “users”, “staff”, “collaborators”, or “roles” rather than calling it user management.

Use the lowest useful access level

If the client can invite you, ask for the lowest role that lets you do the work.

A designer editing a landing page may not need billing access. A developer debugging DNS may not need full domain-transfer permissions after the initial setup. A copywriter writing in a CMS usually does not need administrator-level plugin access.

For short tasks, ask whether the client can grant access for the duration of the task and then remove it. This is not about making the client do extra work. It protects both sides if a device is lost, a freelancer account is compromised, or the project relationship changes later.

Use admin access only when the work genuinely requires it.

When a shared password is unavoidable

Sometimes a client uses an old tool, a single-seat account, a shared hosting login, or a small SaaS product with no proper user management. In that case, treat password sharing as a temporary exception.

Before the password is sent, agree on:

which account the password unlocks
why shared access is necessary
who is allowed to receive it
how long it should remain valid
where it will be stored
when it should be rotated or removed

Then use a controlled sharing method. A password-manager share link, encrypted send feature, or client-approved secure portal is better than sending the password directly in a normal message.

If the sharing tool supports expiration, recipient restriction, access count, or a separate passphrase, use those controls. If you must send a link and a passphrase, send them through different channels when possible.

Do not use these methods

Avoid these common patterns:

Method	Why it is weak
Emailing the password directly	It can stay in multiple inboxes and backups indefinitely.
Posting in Slack or Teams	It can be searched, retained, forwarded, or seen by the wrong channel members.
Sending a screenshot	It creates an image copy that is easy to forget and hard to rotate.
Project-management comments	Old tickets and tasks become a password archive.
Plain text files	They are easy to sync, copy, leak, or forget.
Reusing a “client password” pattern	If one account leaks, the pattern can expose others.

The problem is not only interception. The bigger everyday risk is persistence: a password ends up stored in places nobody reviews.

Use a password manager for client credentials

If you receive client credentials, store them in a password manager, not in browser notes, documents, screenshots, or chat history.

Use a dedicated client vault, folder, collection, or label. The exact feature depends on the tool, but the purpose is the same: client access should be easy to identify, review, and remove later.

Good record names help:

Weak name	Better name
WordPress	Client: Acme - WordPress admin
Hosting	Client: Northwind - hosting panel
DNS	Client: Example Co - Cloudflare admin
Mailchimp	Client: Acme - newsletter account

Add notes for ownership and handoff:

who owns the account
who sent the credential
whether the client has other users
whether MFA is enabled
when access should be reviewed
whether the password should be rotated at project close

Do not mix client credentials casually with your personal logins. You want client-owned secrets to be visible as client-owned secrets.

Many password managers include sharing features. The exact controls vary, but look for:

expiration dates
recipient email restrictions
access limits
separate passphrase support
shared vaults or collections
audit or activity history
easy revocation

Use the most restrictive option that still works for the client. A link that expires in one hour is better for a handoff than a public link with no expiration. A shared vault is better for ongoing work than repeatedly sending one-off links.

If the client already uses a password manager, ask them to share from their system instead of sending you a standalone password. That keeps ownership on their side and makes offboarding easier.

Client-owned vs freelancer-owned accounts

Not every account in a project should be owned by the same party.

Client-owned accounts should usually include domains, hosting, analytics, payment processors, ad accounts, email platforms, source repositories for client code, and long-term business tools.

Freelancer-owned accounts may make sense for your own development tools, templates, project management, test environments, staging utilities, and internal workflow tools.

Problems start when these are blurred. A domain registered in the freelancer’s personal account, a payment processor controlled through an agency login, or a shared admin account with no ownership notes can create serious handoff problems later.

When in doubt, ask: who should still control this account six months after the project ends?

How to receive a password from a client

If a client asks where to send a password, give them a simple answer.

For example:

Please do not send the password in email or chat. If possible, invite me as a named user. If the tool only supports a shared login, use your password manager’s sharing feature or a temporary encrypted link. Please set an expiration time and send any passphrase separately.

This makes you look more professional and gives the client a clear path. It also avoids sounding like you are refusing to help.

If the client cannot use a secure sharing tool, ask whether they can create a temporary password, send it through the least-bad channel available, and rotate it immediately after you finish the work.

How to hand credentials back to a client

At the end of a project, do not leave credential ownership vague.

Create a handoff list that includes:

accounts created during the project
who owns each account
which credentials were shared
which passwords should be rotated
which users should remain active
which freelancer or contractor accounts should be removed
where recovery codes or backup codes are stored
which MFA methods are active

If the client owns the account, they should have the final recovery path. If you created the account during the project, transfer ownership before the project closes rather than keeping it in your personal email or password manager.

For domains, DNS, hosting, payment, and analytics accounts, this handoff matters more than most clients realize.

Offboarding checklist

When a project ends, review client access before you archive the project.

Use this checklist:

Remove your named user account where the client no longer needs you.
Rotate any shared passwords you used.
Delete one-time share links.
Remove old shared vault access.
Archive client records that must be retained.
Delete credentials that should not be retained.
Confirm the client has owner access and recovery options.
Confirm domain, hosting, email, and billing accounts are in the right owner’s control.
Update your password manager notes so the project status is clear.

This is also a good time to remove local SSH keys, API tokens, .env files, staging credentials, and old project secrets from your development machine if they are no longer needed.

What to do if a password was shared badly

If a client sent a password through email, chat, or a screenshot, do not panic. Fix the path.

Move the credential into the password manager, confirm what account it controls, and ask the client to rotate the password after you no longer need it. If the account is important, turn on MFA and replace shared access with named access if the tool supports it.

If the password was posted in a group channel, ticket, or shared document, assume more people saw it than intended. Rotate it sooner.

Common mistakes

The most common mistake is accepting the first access method offered. Clients often send passwords because it is familiar, not because it is required. A named invite is usually cleaner if the platform supports it.

Another mistake is failing to remove access at the end. Freelancers often keep client credentials “just in case.” That may feel helpful, but it creates long-term risk and confusion. Keep only what you have a reason to keep.

The third mistake is using one password manager vault for everything. Client access should be separated enough that you can review it without digging through personal banking, streaming services, and old test accounts.

Good next step

Pick one active client and review how you currently access their tools. For each account, decide whether you should have a named user account, a shared vault item, or no access at all.

Then read: