One hosting account per client is the safer default. If one site is compromised, the attacker is contained to that account instead of reaching every other client on the same login, database and file space. A shared account is cheaper, but it ties every client's fate together.
The WordPress hardening guide names containment as a core security theme: configure the system to minimise damage if it is compromised.
What changes between the two setups
| Factor | Shared account for many sites | One account per client |
|---|---|---|
| Compromise spread | A hit on one site can reach others in the same file space | Contained to one site in most setups |
| Access removal | Removing a person affects everything | Remove per client |
| Ownership | Often under the agency | Client can own it |
| Backups and restores | Often all or nothing | Per site |
| Cost and admin effort | Lower | Higher |
The database detail
The handbook says that if you run multiple sites on the same server, it is wise to keep them in separate databases, each managed by a different database user. The reasoning is containment: if one installation is cracked, it is harder to alter the others. The same guide explains that day to day WordPress operations need only read and write privileges on the database, with a caution that some plugin, theme and major upgrades change the schema and need temporary extra privileges. So do not strip those rights without a tested backup plan.
File permissions matter too
The handbook suggests that files be owned by your user account and writable only by it, with write access given to the web server only for directories like uploads. Plugin directories should be writable only by your user account. On a shared account, one mistake in permissions can expose all sites at once.
When sharing is acceptable
A shared account is reasonable when sites are small, similar, owned by the same organisation, and have the same people maintaining them. Examples are a church and its youth site, or a company's brochure and campaign microsites. It is less suitable when clients are unrelated, because their risk profiles and people differ.
A middle path
If cost is the concern, ask whether your host supports isolated sites within one plan, with separate system users and databases per site. Verify the claim rather than assuming it, and ask how backups and restores work per site.
How to decide
- List which sites share an owner and a team.
- Group only those together.
- Give every unrelated client their own account and database user.
- Record the choice in the handover document.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are grouped per project, which mirrors how separate accounts keep clients apart.
Safeguard offers dependency scanning and policy gates for project repositories, and the free scan works on one project at a time.
Quick check
Does a separate database per site help if files are shared?
It helps with database containment, but shared file space can still expose every site. Treat both as separate controls.
Is a separate account always required?
No. It is a safer default for unrelated clients, but related sites with one owner and team can reasonably share.
Sources
Last reviewed: 19 October 2026.
