Security
How to Collect Website Logins From Clients Securely
Collect a client's hosting, domain, and CMS logins through an end-to-end encrypted request they open without an account, not a Slack DM or a shared doc. Here's the workflow, and which access to delegate instead of collecting.
The safe way to collect a client's website logins is to delegate the access that supports it and collect only what can't be delegated, through an end-to-end encrypted request the client opens without an account. Hosting, registrar, database, and CMS admin logins are the ones with no "add a user" option, so those are what you collect, encrypted, instead of over a Slack DM or a shared doc.
First, delegate what you can
Not every kind of access should be collected as a password. Where a platform lets the client add you as a user, that's the safer route, because it's revocable and nothing secret changes hands:
- WordPress and most modern CMSs: ask for your own admin user, not the shared login.
- Google Analytics, Search Console, Tag Manager: the client adds your email.
- Most SaaS with team seats: request a seat rather than the account password.
Delegated access can be pulled the moment the engagement ends, without the client resetting anything.
Then collect what can't be delegated
Hosting panels, domain registrars, database credentials, and older or bespoke CMS logins usually have no per-user model, so the client has to hand over the actual login. This is the part that ends up in Slack and email if you don't give it a safe home. Collect these through an encrypted request instead.
Delegate, collect, or chat: how they compare
| Access | Best method | Why |
|---|---|---|
| Analytics, Search Console, most SaaS | Delegate (add a user) | Revocable, no password shared |
| WordPress / modern CMS | Delegate (your own admin user) | Revocable, per-person |
| Hosting / cPanel, registrar, database | Collect via encrypted request | No delegation option, must share the login |
| Anything pasted in Slack / email | Neither | Plaintext, no expiry, unrevocable |
How to collect the logins cleanly
- Split the ask. List what you'll delegate and what you'll collect, so the client isn't sending passwords for things you could have been added to.
- Send one encrypted request for the non-delegatable logins, not an email thread.
- Label every field. "Hosting control panel URL, username, password," not "send me your server details."
- Encrypt on the client's device, so the hosting and database passwords never sit in a message.
- Keep a record for the handoff, so you know exactly what to rotate or return when the build ends.
Where doconvoy fits
doconvoy gives you one encrypted request for the logins delegation can't cover. The client opens a page in your agency's name, fills in the hosting, registrar, and CMS fields, and each is encrypted in their browser before it's sent, so doconvoy never holds a readable login. See it applied to a full kickoff in client onboarding for web agencies.
Send clients one encrypted request for the hosting, registrar, and CMS logins delegation can't cover.
Collect website logins securelyRelated: How should clients share hosting and domain access with an agency? · What access does a web developer need from a client? · Client onboarding for web agencies · Secure Requests
Common questions
What's the safest way to get a client's website logins?
Delegate the access that supports it (add your email as a user), and for the logins that can't be delegated, hosting, registrar, database, CMS admin, collect them through an end-to-end encrypted request the client opens without an account. Avoid Slack DMs, email, and shared docs.
Should a client just email me their cPanel or WordPress password?
No. Emailed or DM'd credentials sit in plaintext in inboxes and message history with no expiry and no way to revoke them. Use an encrypted request, and rotate anything that was already sent in the clear.
Which website access can I get without collecting a password?
Anything with a user or delegated-access model: WordPress user accounts, Google Analytics and Search Console, most modern SaaS. Ask to be added as a user there. Hosting panels, registrars, and legacy CMS logins usually have no such option, so those are the ones worth collecting securely.