You have chosen a team in another country to look after your WordPress site, and now comes the awkward part. They need to get in. Somebody on your side says “just send them the admin password”, and somebody else says that sounds like a terrible idea. Both are partly right.
Safe website access for an overseas team is mostly the same as safe access for anyone: separate accounts, the lowest level of permission that does the job, a proper way of passing secrets over, and a clear day when access ends. The distance adds a few practical wrinkles, which is what this post is about. None of it requires technical skill on your part, only a bit of discipline in the first week.
Safe website access for an overseas team starts with a list
Before you create a single account, write a short list of the places your website lives. Most small business sites involve more than one:
- The WordPress dashboard, where pages, plugins and users are managed.
- The hosting account, where the files, database and server settings sit.
- The domain registrar, where the name is registered and renewed.
- DNS, which may be with the registrar, the host or a separate service, and which decides where web traffic and email go.
- Extras: Google Analytics and Search Console, your email provider, a payment provider, a booking or form service, premium plugin licences.
Now ask which of these the maintenance work really requires. Updates, backups, security checks and small fixes mostly happen in the WordPress dashboard and sometimes in the hosting account. The registrar almost never needs to be shared. That single observation removes the most dangerous item from the list before anyone has typed a password.
Three levels of access, from lowest to highest
It helps to think in levels rather than in “access or no access”.
| Level | What it allows | Typical use |
|---|---|---|
| Dashboard only | A named WordPress user with a suitable role | Updates, content changes, plugin checks |
| Dashboard plus hosting | The above, and a way into the hosting panel or file transfer | Backups outside WordPress, restoring files, server-level fixes |
| Everything, including domain and DNS | Control over where the site and email point | Hosting moves or DNS corrections, and only for the duration of that job |
Begin at the first level. Add the second when a specific task needs it. Treat the third as a short loan, not a permanent arrangement. If you run into trouble later, being able to say “they only ever had level one” is a comfortable position to be in.
Match the access to the monthly work
A simple way to avoid over-sharing is to start from the job. The page describing what our India-based team does each month lists the regular tasks, from updates and backups through to uptime monitoring and the monthly report. Hold that list up against the levels above. Updates and content changes work happily at the dashboard level. Backups and restores may need hosting access. Nothing on that list needs your domain registrar.
Give them their own WordPress accounts
Do not hand over your own login. Create a separate user for each person on their side who will work on the site, in that person’s name and work email address, and let them set their own password.
This matters for three reasons. If one person leaves their team, you can close that one account without anybody else being locked out. If something odd happens on the site, an activity log can tell you which account did it. And you stay in control: removing a user takes seconds, whereas changing a shared password affects everyone who relied on it.
Choose the role with care. The Administrator role can install plugins, change settings and create other users. Maintenance work often does need it, but content editing does not, and an Editor role is plenty for someone who only updates pages. What each WordPress user role can and cannot do is worth five minutes of reading before you decide.
Ask them how many people will need access and why. A small team with two named people is easy to reason about. A vague answer such as “our staff” deserves a follow-up question.
Two-factor sign-in when the team is asleep on your night
With two-factor authentication switched on, knowing the password gets a thief nowhere. It is one of the most useful protections you can switch on, and it is also where distance causes friction. If the login codes go to your phone, and your team is working at a time when you are asleep, they cannot sign in until you wake up and read out a number. That is slow and, worse, it teaches everyone to look for workarounds.
The fix is to set it up per person rather than per site. Each member of their team gets their own account with their own authenticator app, so nobody needs yours. Your own administrator account has its own second factor, on your phone. If you want the setup steps, the guide to WordPress two-factor authentication walks through the options.
Ask the team whether their accounts will be protected this way, and ask them to tell you if that ever changes. A team that already works like this will not blink at the question.
How to pass logins across without using email
Passwords sent in an email thread stay in two mailboxes for years. The same goes for messaging apps, where messages can be forwarded, backed up and seen on a phone left on a desk.
Better routes, in rough order of preference:
- Do not send a password at all. Add the user in WordPress with their email address and let them set their own password through the link WordPress sends.
- Use an invitation feature if your host or registrar offers one. Many let the account owner invite another person with limited rights, so you never share your main login.
- Use a password manager’s sharing function for anything that cannot be invited. This keeps the secret out of chat and email, and you can withdraw it later.
- If you must use a one-time message, send the username by one route and the password by another, then change the password afterwards.
Do this once for every account and the rest of the arrangement gets much easier. A bit of effort in week one saves a very awkward conversation in year two.
Hosting and server access
If the team needs to get at your files, ask how they intend to connect. Plain FTP sends the password without encryption, so the better options are SFTP or SSH, which most hosts support. Where the host allows a separate login for each person, use it rather than sharing the main account.
Keep the hosting account in your own name, with your email and your payment method, even if the team does the day-to-day work inside it. That one decision is what stops a disagreement turning into a lockout. If the host will let you invite them as a second user, do that. If not, share the login through a password manager and plan to change it when the work ends.
Keep the domain with you
Whoever controls your domain controls your website address and your email routing. Unless the job is moving the site to a new host, a maintenance team has no reason to log in to your registrar. If a one-off change to DNS is needed, there are two safer approaches: you make the change yourself while they tell you exactly what to type, or you give temporary access and remove it the same day. Do not store the registrar login in a shared document that several people can open.
As a basic hygiene step, make sure your own registrar account has a recovery email you can still read and an extra sign-in step switched on. Teams change, and your account should not depend on anyone else’s inbox.
What to ask the team about their side
Your security also depends on what happens on their computers. You are entitled to ask, politely, and a good team will answer plainly. If you would like a longer list for judging a provider overall, vetting an Indian maintenance company before you hire covers the wider picture. For access specifically, ask:
- Who on your team will have my logins, and how are they named in my records?
- Where are credentials stored, and who else can see that place?
- Do your staff sign in with two-factor authentication?
- What happens to my access when somebody on your team leaves?
- If I need to cut off access right now, how quickly can you confirm it is done?
You are not looking for impressive vocabulary. You are looking for specific answers given without hesitation. Vagueness here is useful information.
Customer data is a separate question
Giving someone dashboard access can also mean giving them a view of customer records, form entries and, on a shop, order details. That is not a reason to refuse access. It is a reason to ask what the team will see and to limit it. The question of what personal information sits on your site and how an overseas team should treat it has its own treatment in what an overseas team can see of your customer data. Rules on personal data vary by country; this is general information, not legal advice, so check with a professional if your business handles sensitive records.
Write down the register, then review it
A short access register, kept by you, is the cheapest security tool in this post. A simple table with these columns is enough:
- The account (WordPress, hosting, registrar, analytics and so on)
- Who has access, by name
- What level they have
- The date it was given
- The date it should end, or the date you will next review it
Review it every few months, and whenever either side changes staff. Look for people who no longer work on the project, accounts nobody can explain and levels higher than the job needs.
When the arrangement ends
Every working relationship ends eventually, even good ones. Ending access should be a normal, unemotional step rather than an argument. Agree in advance that when the work stops, you will remove the WordPress users, they will confirm in writing that they hold no copies of your logins, and you will change any shared passwords. If you want a worked example of the same routine for staff, the checklist on removing access when an employee leaves follows exactly this pattern, and it applies just as well to a team abroad.
Also ask for a final copy of the backups and a list of every plugin and account they set up for you, so that nothing important exists only in somebody else’s records.
A short honest summary
Safe website access for an overseas team comes down to a handful of habits, and distance changes the logistics rather than the principles. Separate accounts, the lowest sufficient role, two-factor sign-in per person, no passwords in chat, your own name on hosting and domain, and an access register you actually read. Do those six things and giving an overseas team access to your website, even one you may never meet in person, becomes a manageable risk rather than a leap of faith. And if you want to know what is currently on your site before you decide who should see it, our no-obligation site check is a calm place to start.
Next in this series: Website Maintenance Calendar for a Seasonal Business
