How to Ask Clients for Logins and Passwords Securely

Sending logins by email or WhatsApp leaves a permanent password in a chat log. Here are safer options, ranked worst to best, plus what to do after.

What access you'll actually need

Not every project needs all of these, but most website work touches at least three or four:

• Hosting control panel — cPanel, Plesk, or the provider's own dashboard (Wedos, Active24, Forpsi, and similar are common in the Czech market).
• Domain registrar / DNS — to add records for email sending, verify a custom domain, or point the domain at a new host.
• CMS admin — WordPress, Shopify, Webflow, or whatever the site already runs on, if you're rebuilding rather than starting fresh.
• Google Analytics and Search Console — usually granted as a user on the existing property rather than handed over as a password.
• Social media business accounts — Facebook Business Manager, Instagram, or a Google Business Profile, needed if the project touches ads or reviews.
• Payment gateway — Stripe, GoPay, Comgate — only if you're wiring up checkout, and usually the most sensitive item on the list.

The common thread: these are almost never things a client hands over once and forgets. Most of them support inviting a second person with a specific role, which matters for what follows. If you're assembling the full list of what a website project needs beyond credentials, see the website project intake checklist.

Why not email or WhatsApp

A password sent by email doesn't disappear when the project ends. It sits in the client's Sent folder, your Inbox, both of your phones if mail is synced, and any backup either of you has ever taken — indefinitely, in plaintext, searchable by anyone who later gets into either account. WhatsApp is marginally better in transit (it's end-to-end encrypted) but identical in the outcome that matters: the message never expires, and a phone left unlocked on a table shows the password to whoever picks it up.

Neither channel was built to hold credentials. Both were built to hold conversation, and a password typed into a conversation behaves exactly like the rest of the conversation — it gets backed up, forwarded, searched, and quoted back into replies without anyone intending harm.

The options, worst to best

1. Plain email or chat message

The password is typed directly into the body of an email or a WhatsApp message. It works, in the sense that you now have the password. Everything else about it is a liability: no expiry, no record of who else has seen it, no way to know if it leaked until something goes wrong.

Use this only when nothing else is available and the account is genuinely low-stakes — a free newsletter tool, say, not hosting or payments.

2. A shared entry in a password manager

The client adds you as a collaborator on one entry in 1Password, Bitwarden, or similar, rather than typing the password anywhere. This is a real improvement: the value never appears in an inbox, and revoking access is one click instead of a password reset. The catch is that it assumes the client already uses a password manager and is willing to set up sharing correctly, which a lot of small-business clients simply haven't done. It also still lands the client's actual, permanent password in your vault rather than something scoped to the project.

3. A temporary account with least privilege

Instead of the client's own login, they create a second account for you — a collaborator invite on WordPress, a "Users" entry on the hosting panel, a team member on Google Analytics — scoped to only what the task needs, and only for as long as the project runs. Most platforms in the list above support this natively: WordPress has roles below Administrator, Google Analytics has per-property access levels, most hosts support a secondary cPanel or FTP user.

This is the option to reach for by default. It answers the two questions that matter most — what can this account do, and when does it stop existing — without asking the client to adopt a new tool.

4. A one-time, auto-expiring credential

For the cases where a temporary account isn't possible — a hosting provider with no multi-user support, a single admin login with no roles — the better shape than "send me the password" is a channel built specifically to hand off one secret exactly once: the client types it into a field that encrypts it immediately, you retrieve it a single time, and after that retrieval nobody — including the client, re-opening the same page — can see it again. It never sits in an inbox because it's never in an email to begin with.

BriefGate's secret item type works this way: the value is encrypted in the browser before it's stored, released to your agent or your dashboard exactly once, and gone from both after that, whether or not you remembered to write it down. If you're already using BriefGate to collect a logo and some copy for the same project, adding one secret item for "current site login" replaces the separate WhatsApp message you'd otherwise have sent for it.

How to ask, without it sounding like a security lecture

Most clients haven't thought about any of this, and a wall of security caveats reads as friction, not care. Frame the request around what they need to do, not why email is unsafe:

"Could you add me as an Administrator on your WordPress site (Users → Add New) rather than sending the login? Takes about a minute and means I never see your actual password."

That gets the least-privilege account without ever using the word "security." If the platform genuinely has no multi-user option, fall back to asking for the value through whatever vault or one-time link you're using, with a one-line reason: "so it's not sitting in an email afterward."

After the handoff: the checklist

Getting access is the easy half. What happens when the project ends is where most of the actual risk sits, because a stale collaborator account is a working login nobody is watching.

• Rotate, not just for accounts you created — for anything the client's original password may have touched if it was ever typed into an email or a chat, even temporarily.
• Remove your temporary account or collaborator invite the moment your work is done, not "at some point." An open ticket to delete access later is an access grant that never actually ends.
• Confirm the client still holds primary ownership — the original admin account, the domain registrar login, the Stripe account owner — so nothing about their business depends on your account staying active.
• Document what was granted and when, even briefly: which accounts, what role, what date it was revoked. Six months later, when the client asks "who has access to our site," you want an answer that isn't "I think just us."
• Tell the client what to do with anything sent insecurely before you got involved. If a password arrived by email before you had a chance to suggest an alternative, say so and recommend they change it — a five-second, no-blame heads-up costs nothing and closes the gap.

Where BriefGate fits

Everything above works with plain accounts and a password manager — no tool required. Where it gets tedious is running it project after project: remembering to ask for a role rather than a password, chasing the client when they forget, and keeping the eventual credential out of your own inbox. BriefGate folds a credentials request into the same checklist as the logo and the copy — the client fills in a masked field, you retrieve it once through your agent or the dashboard, and it's gone from BriefGate's side the moment you do. See what BriefGate does, or read the companion piece on requesting the rest of the project's materials if credentials are only one item on a longer list.