What a safe process must prohibit
Passwords, API keys, private keys and database dumps must never be requested through ordinary email, a web form, or chat. Those channels are stored, forwarded, backed up and indexed in places neither of us controls.
Therefore if anyone asks you to paste a password into a support thread, that is a reason to stop, regardless of who they claim to be. The same applies to us.
How WordPress site access should be granted
- Create an individual account where the platform allows it, rather than sharing an existing login.
- Use the lowest privilege that will do the job. Not every task needs administrator.
- Make it temporary. Access should have an expected end, agreed at the start.
- Use a channel built for secrets, with expiry, rather than a channel built for conversation.
Additionally, an individual account produces something a shared login cannot: an audit trail. When several people have touched a site, that trail is often the fastest route to the cause.
While work is active
Changes need a record. Furthermore, credentials must stay out of analytics, order records, support notes and application logs, because those are exactly the places that get exported and shared later.
Where work has to happen on a live site rather than a copy, the specific actions and the way back are agreed in writing before anything is touched.
When work closes
Access is removed, and you are told plainly what to revoke or rotate on your side. In particular, that includes anything shared during the work that cannot simply be deleted, such as a hosting password you disclosed under pressure during an incident.
Rotation matters most after a compromise. If credentials were exposed, changing them in the wrong order can lock you out or reopen the hole, which is covered under hacked site recovery.
Why shared logins cause disputes later
When several people use one administrator account, nothing that happens on the site can be attributed to anyone. As a result, an ordinary disagreement about who broke what becomes unanswerable.
Individual accounts fix this cheaply. Furthermore, they let you remove one person without changing the password for everyone else, which is the practical reason shared logins survive far longer than they should.
What you should ask any provider
How will you ask me for access? If the answer involves emailing a password, stop there.
What level do you actually need, and why? A specific answer signals someone who has thought about it.
What happens to it when we finish? Removal should be part of the plan, not an afterthought you have to chase.
Reducing what access can reach
Access hygiene is not only about contractors. Most sites accumulate accounts that nobody has audited for years, and each one is a way in. Consequently the cheapest security work is usually removing accounts and code that stopped being used.
That standing work is covered under security services, and keeping it current is part of ongoing maintenance plans. The WordPress hardening documentation sets out the baseline measures. For what DuePress does and declines, see the service scope.