The client should be the owner of the domain, hosting and code repository accounts, and the agency should work as a named user with only the access it needs. This keeps the site portable if the relationship ends and makes removing access a one step job.
The common failure runs the other way. The agency registers everything under its own account to move fast, and the client later discovers they cannot renew, transfer or even prove the domain is theirs.
Account by account
| Account | Owner | Agency role | Notes |
|---|---|---|---|
| Domain registrar | Client | Delegate or technical contact | Keep renewal email on a client controlled address |
| DNS host | Client | Delegate with edit rights | DNS changes redirect all traffic and email, so limit who can edit |
| Web host | Client | Named user or team member | Prefer per person logins over a shared one |
| Code repository | Client organisation | Collaborator | Protect the main branch |
| Package registry or licence portals | Client | Named user | Premium plugin licences should be in the client's name |
| Email and analytics | Client | Viewer or editor | Only what the work needs |
Why shared logins fail
One shared password means you cannot tell who did what, and you cannot remove one person without changing it for everyone. Per person accounts give you an audit trail and a clean exit. The WordPress handbook lists limiting access as the first of its security themes: making smart choices that reduce the possible entry points.
Where a service has no team feature, store the credential in a password manager shared vault owned by the client, and rotate it when someone leaves.
Turn on two-step login everywhere it exists
CISA describes MFA as requiring two or more authenticators before access is granted, so a stolen or guessed password is not enough on its own. Registrar and host accounts are high value, because whoever controls them controls the domain. Enable it for every person with access, including the agency staff.
When the agency must hold something temporarily
Sometimes a build starts before the client has accounts. That is fine if you write down what is held, why, and a date by which it moves. Put the transfer in the project plan, not in good intentions. Record it in the handover document so the next review catches anything left behind.
What to do on exit
If the client leaves, the sequence is: confirm ownership records, transfer or remove your user, rotate any shared credentials, remove deploy keys and tokens you created, and hand over the repository and a list of installed software. If you built a pipeline, list the secrets it uses so the client can rotate them.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how findings are tied to a project and owner; ownership is what makes a finding actionable.
Safeguard covers dependency scanning and policies for repositories; the free scan is an easy way to show a client what is in their project.
Quick check
Can an agency keep the domain to protect its invoice?
It is a commercial and legal decision, so ask a lawyer. From a security view, holding a client's domain hostage creates risk for them and reputational risk for you.
Is a shared password manager vault enough?
It is better than email, but prefer per person logins where the service supports them, because they give you an audit trail.
Sources
Last reviewed: 19 October 2026.
