Skip to content
Agency Resources

How Agencies Can Share Client Logins Safely

Agencies hold more client credentials than almost anyone. Here is how to receive, store, share and revoke them without putting client sites at risk.

A team planning with sticky notes on a wall
8 sections · 7 min read
In this article · 8 sections

A new client emails over their WordPress login. Username “admin”, a password that is clearly their dog’s name and a year, and in the same message, for convenience, their hosting password and the login for their domain registrar. They are trying to be helpful. They have also just put the keys to their entire online business into an email thread that will sit in two inboxes for years.

Agencies handle more credentials than almost any other kind of business: dozens or hundreds of client sites, each with a WordPress dashboard, a host, a registrar, DNS, email and a stack of third-party services. How you handle that access is a security question, but it is also a trust question. Clients rarely ask how you store their logins. They will ask, very pointedly, if something goes wrong.

The principles, before the tools

Every practice below comes from four ideas:

  1. One person, one account. Nobody shares a login. Each person who needs access gets their own, in their own name.
  2. Least access. Each account gets only what that person needs for their work, and nothing more.
  3. Secure transfer. Passwords never travel in plain email, chat messages or documents.
  4. Revoke on time. Access ends when the work ends. Not eventually; on a set day.

If your current process breaks one of these, that is where to start.

WordPress access: separate users with the right role

Never work on a client site using the client’s own administrator login. Ask them to create a user for you, or create one yourself if you already have admin access, in your name or your agency’s name. If several people at your agency work on the site, each one gets a separate user.

Separate accounts matter for three reasons. First, you can remove one person without changing everyone’s password. Second, activity logs, if the site has one, show who did what. Third, if an account is compromised, you know exactly which one and can close it without locking out the client.

Then choose the role carefully. Not everyone needs to be an Administrator. A copywriter adding blog posts can be an Author or Editor. Someone managing a shop can often work as a Shop Manager on a WooCommerce site. Only the people who install plugins, change settings or manage users need full admin. Our post on what each WordPress role can and cannot do covers the details, and it is worth sending to clients who have more administrators than they realise.

Turn on two-factor authentication for every administrator account, including yours and the client’s. It means a stolen password alone is not enough to log in. If you have not set it up before, our step-by-step on adding two-factor to WordPress walks through the options.

Hosting, registrar and DNS access

This is the access that can do the most damage, and the one most often handled carelessly. Someone with the registrar login can transfer the domain away. Someone with the hosting login can delete the site and its backups in one step.

Where you can, avoid using the client’s main login at all. Many hosting providers and registrars let the account owner invite another user or grant limited access, sometimes called a team member, collaborator or delegate. Features vary a lot between providers, so check what the client’s host offers. If it exists, use it: the client keeps the main account, and you get access that can be removed without a password change.

Where it does not exist, and you must use the main login, agree with the client how it will be stored, who on your side will see it, and that they should change it when your work finishes.

For server-level access:

  • Prefer SFTP or SSH over plain FTP. Plain FTP sends credentials without encryption.
  • Where the host allows it, create a separate SFTP or SSH user for your agency rather than using the main account.
  • For SSH, use key-based login where the host supports it, with a separate key for each person.
  • Database access usually goes through the hosting panel. Avoid creating extra database users unless the job needs one.

Storing credentials: a password manager, not a spreadsheet

If your agency keeps client logins in a spreadsheet, a shared document or a notes app, that file is the most valuable thing a thief could take from you. One leaked file means every client site at once.

A team password manager solves most of this. The general approach that works well:

  • A separate shared folder or vault per client, so access can be given per client rather than all or nothing.
  • Staff see only the clients they work on.
  • Each entry notes what the login is for, who created it, and when it should be reviewed.
  • The password manager’s own account is protected with a strong master password and two-factor authentication.
  • When someone leaves your agency, their access to the vault ends the same day.

Pick a password manager that suits your team and check its sharing and permission options against these points. Products differ, and the right one is the one your team will actually use every time.

Getting credentials from clients safely

Most clients will send passwords by email unless you give them another route. Make the safe way the easy way.

Here is wording you can use at the start of a project:

“To get started, we’ll need access to your website and hosting. Please don’t send passwords by email. Instead, could you create a user for us from the Users menu in your WordPress dashboard, with the email [address] and the Administrator role? We’ll set our own password. For your hosting, if your provider lets you invite another user, please invite [address]. If not, let us know and we’ll send you a secure link to share the login.”

That last part refers to a secure sharing link from your password manager or a similar one-time sharing method. Have this ready before you ask.

If a client does email a password anyway:

  • Thank them, and do not make them feel bad.
  • Move the credential into your password manager.
  • Delete the email from your inbox and ask them to delete it from their sent folder.
  • Once your own account exists, suggest they change the password they sent.

Sharing access with a development partner

When you bring in a freelancer or a partner, the same rules apply, with one addition: you stay in control of the access. The partner should not have to go to your client for logins, and your client should not need to know a second party exists unless you choose to tell them.

  • Create the partner a separate WordPress user, with a role matched to the job.
  • Share other credentials through your password manager, scoped to that client only.
  • Agree in writing that the partner will not keep copies outside the shared vault.
  • Note in your records which partner has access to which sites, and remove it when the job is done.

Ask any partner how they store credentials on their side, and expect a clear answer. If they cannot give one, that tells you something.

Revoking access: the step everyone skips

Creating access is easy because someone is waiting for it. Removing it is easy to forget because nobody is. The result is client sites with administrator accounts for developers who left years ago. Those old accounts are one of the common ways into a WordPress site, and if you find one you cannot explain, our piece on an unexpected admin user in WordPress explains what to check.

Build revocation into your process:

  • When a project ends: remove or downgrade your agency’s accounts unless you are staying on for maintenance.
  • When a staff member or freelancer leaves: remove their WordPress users from every client site, revoke their vault access, and rotate any shared credentials they could see.
  • When a client leaves you: hand over their credentials, remove your users, and confirm in writing that you have done so.
  • Every quarter: review the user list on each site you look after. Anyone who should not be there gets removed.

When removing a WordPress user, WordPress asks what to do with their content. Choose to attribute it to another user rather than delete it, unless you are sure the content should go.

A quick audit for your agency

Answer these honestly:

  • Are any client logins stored in a spreadsheet, document or email folder?
  • Does anyone at your agency use a client’s own admin login?
  • Do all administrators on the sites you manage have two-factor authentication?
  • Could you list everyone who has access to a given client’s hosting, today?
  • When did you last remove an account from a client site?

Any “no” or “not sure” is a place to tighten up. Most of these take an afternoon to fix across a whole client list.

Access is one of several practical questions that come up once you start sharing work with others; the guide to outsourcing WordPress work for agencies covers the rest. If you want a second pair of eyes on user accounts, logins and hardening across the sites you look after, that is part of what our security monitoring for agency client sites includes, run quietly under your name.

Next in this series: Onboarding a Client’s Existing WordPress Site

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.