A password in a Slack message
A freelance developer is booked to add a feature to a client site. The project manager sends the SFTP details and the WordPress admin login in a direct message. It is the same admin login the studio uses, created at launch. The freelancer does the job and moves on to other clients.
A year later, the studio realises that several freelancers still have working access to a number of client servers and admin accounts. Nobody knows exactly who. Changing the shared passwords means updating every tool and person that uses them, so it keeps being put off.
Why freelancer access sprawls
- Shared logins are quicker than creating named accounts for each person.
- Credentials are sent in chat or email, where they stay forever.
- Nobody records which freelancer was given access to which client.
- Jobs end quietly, with no step for removing access.
- Changing a shared password breaks things for everyone else using it.
Access is granted in a hurry and removed never, because granting has a deadline and removing does not.
Why it matters
A former freelancer with working access is a security risk, even if they would never misuse it, because their own devices and accounts could be compromised. If a client site is hacked, the studio cannot say who had access. Clients increasingly ask agencies how they control access to their systems, and "we share a password" is not an answer that reassures anyone.
The per-job access we build
- Each client site's access points are recorded: hosting panel, SFTP or SSH, database, WordPress admin, DNS and any third-party services.
- When a freelancer is booked on a job, named access is created for them: their own WordPress user with an appropriate role, their own SSH key or SFTP user where the host supports it.
- Any credentials that must be shared are shared through a team password manager, such as 1Password or Bitwarden, in a vault for that job, never in chat.
- An access record lists every freelancer, what they hold on which client site, and the job it was for.
- When the job is marked complete, a removal checklist is generated, and where platforms allow it, accounts are disabled automatically through APIs or scripts.
- Shared legacy logins are replaced over time with named accounts, starting with the sites that have had the most freelancer access.
| Access point | Old way | New way |
|---|---|---|
| WordPress admin | Shared admin login | Named user per freelancer, removed after the job |
| SFTP or SSH | Shared password | Personal key or user, revoked after |
| Hosting panel | Studio owner's login | Only when essential, via password manager |
| Database | Shared credentials | Temporary user where the host allows |
| DNS | Rarely needed | Studio staff only |
What access your contracts with clients and freelancers allow is for you and your adviser. The system makes sure that whatever is allowed is recorded and taken back.
The next freelancer booking
A freelancer is booked for a feature on a client site. The system creates their WordPress user and SSH access, and shares the database details through a job vault. When the project manager marks the job complete, the accounts are disabled and the vault is closed. The access record shows exactly who had access, to what, and when it ended.
Is freelancer access under control at your studio?
- Freelancers are given shared logins to client sites.
- Credentials are sent in Slack, WhatsApp or email.
- Nobody can list which freelancers have access to which sites.
- Access is rarely removed when jobs end.
- Changing shared passwords has been put off because it breaks things.