Colleague Access; Where Site Security Meets Team Velocity
The developer you've hired says, "Give me the cPanel username and password so I can start the work." The previous site manager has also left, and all you have is a welcome email from the hosting provider containing the root password or full control panel access. You're left with a decision: hand over the master key or not?
The short answer is: No. Never. But that doesn't mean the team's work has to stop. Almost anything a developer or colleague might want to do can be accomplished with restricted, revocable access. You just need to know which access is for which task and what the cost of each choice is.
This article is for the manager who is sitting at their screen right now and needs to grant access within the hour. Not for someone who wants to read "security fundamentals."
First, Understand Exactly What the Other Party Needs to Do
Granting access without defining the task is like giving someone the key to a safe when they only need to retrieve a letter from inside it. Before taking any action, ask: What exactly is this person going to change? There are three common scenarios:
- Changing site content — writing articles, uploading images, editing pages. This requires content management access, not server access.
- Changing code or templates — editing PHP, CSS, or JavaScript files. This requires file access (FTP or File Manager).
- Changing server settings — installing system plugins, changing the PHP version, restarting services. This requires control panel or SSH access.
Most requests that come under the guise of "full access" are actually of the first or second type. If the other party can't specify exactly which file or which setting they want to change, that in itself is a warning sign.
A rule of thumb: The higher the access level, the greater the vulnerability to accidental mistakes. A mistaken rm -rf by someone with SSH access will wipe your site without any warning. The same action isn't as easily done via FTP.
FTP or File Manager Access; The Most Common Scenario You Actually Need
If the developer needs to edit the WordPress template or move site files around, FTP access is sufficient. In cPanel or DirectAdmin, create a separate FTP account that only has access to the public_html folder. In cPanel, this is done via the FTP Accounts section.
Important note: Create a separate username for the new FTP account. Avoid using the main cPanel username as the FTP user. Restrict the new FTP account to the site's main folder and do not grant it access to folders like etc or logs.
Also limit the upload quota. If only a template change is planned, set a cap of 50 megabytes. This prevents the upload of a 2-gigabyte file that could fill up your disk.
When FTP Isn't Enough
FTP is great for editing individual files, but it's useless for working with databases or changing PHP settings. If the developer says, "I need to change php.ini" or "I need to install a system plugin," FTP won't help. In this case, you either need to grant restricted access through the control panel or use SSH with a public key.
This is where people make mistakes: Many hand over the main cPanel password to the developer for convenience so they can "do everything themselves." A few weeks later, when the collaboration ends, the password is changed, but the former developer still has access to the site via FTP because a separate FTP account was never created, and they were logging in with the main username. Result: an open access point that no one knows exists.
SSH Access; Only with a Public Key, Only for a Specific Task
If the developer needs to run Composer, deploy code with Git, or execute long-running scripts, FTP isn't sufficient. SSH access is necessary. But the right way to do this is not by handing over the root password.
Create a separate system user with restricted access. On a cPanel-based Linux hosting, register a public key for the new user via SSH Access in the security section. Then, add restrictive options to the /home/username/.ssh/authorized_keys file:
command="/usr/local/bin/deploy-script.sh",no-port-forwarding,no-X11-forwarding ssh-rsa AAAAB3NzaC1yc2E...With this, that key can only execute one specific command. Not rm, not cat /etc/passwd, nothing else. If the developer needs to do something else, they must submit a request, and you develop the script further.
This may seem strict, and it is. But the cost of this strictness is negligible compared to a database leak. If your team is small and you have complete trust, you can remove this restriction and settle for a system user with access to the site's folder. But never grant root access.
Database Access; The Riskiest Access After Root
The database is where customer information, orders, and site content reside. Direct access to phpMyAdmin means anyone who logs in can empty tables or change all users' passwords.
If the developer only needs to view the database structure or write a query, create a separate MySQL user with read-only access. In cPanel, go to MySQL Databases, create a new user with SELECT privilege, and connect it to the desired database. This user cannot INSERT or DELETE; they can only read.
If write access is genuinely needed, create a separate database for the testing environment and don't allow work on the main database. Have the developer work on a copy, and after approval, you apply the changes to the main database yourself.
Revoking Access; The Part Everyone Forgets
Granting access is only half the job. The other half is revoking it at the right time. When collaboration with a developer ends, run this checklist:
- Change the main cPanel or control panel password.
- Delete all FTP accounts created for that person.
- Remove their SSH keys from
authorized_keys. - Delete the MySQL users created for them.
- If you gave them access to the email service, change the email password as well.
This takes 15 minutes. But if it's not done, an open access point remains that no one knows about. The worst-case scenario is that a year later, when the site gets hacked, you see in the logs a login from an IP belonging to the former developer.
That's why I recommend keeping a table of the access you've granted from day one: to whom, what access, when, and for what purpose. Store this table in a secure file outside the server. When someone leaves the team, check this table first.
Control Panel Access; Only as Needed, Only for a Limited Time
Some tasks, like changing the PHP version or installing a system plugin, can only be done through the control panel. In this case, instead of granting main access, create a subaccount that only has access to that specific section. cPanel offers this via Sub Accounts.
If your hosting doesn't support this feature and there's no choice but to grant temporary access, change the password after the work is done. Don't postpone this to "later." Change it the moment the task is finished.
The choice between different hosting services can also affect this issue. If you're torn between Linux hosting and a virtual server, check the comparison of Linux hosting, cloud server, and dedicated server services. On shared hosting, access management tools are pre-built; on a virtual server, you need to create users and set restrictions yourself.
Colleague Access in Practice; My Recommended Scenario
For a team of two to five people working on a WordPress site, here's what I would do:
- A separate FTP account for each person, restricted to public_html, with an upload quota.
- A read-only MySQL user for anyone who needs to view the database.
- SSH access for only one person (the team lead) and only with a public key.
- Control panel access only for the site manager, not for anyone else.
If the team is larger or the project is more sensitive, move toward code management tools like Git with automated deployment. In this model, the developer has no direct server access; they only push code, and a script on the server deploys it. This is the cleanest approach, but it takes time to set up initially.
If the team is small and everyone works in the same office, having individual FTP accounts might be overkill. A single shared FTP account for the team is sufficient, and only the manager knows the password. The cost of this is that you can't tell who changed which file. If that matters to you, create separate accounts.
For choosing between shared hosting and a virtual server in terms of flexibility in access management, read the guide to choosing between shared hosting, a virtual server, or a dedicated server. If you've recently purchased a service and haven't fully read the welcome email yet, the guide to reading your hosting welcome email will tell you which settings you should change right away.
Frequently Asked Questions
What access should I give a developer to keep things secure?
A separate FTP account restricted to the public_html folder, and a read-only MySQL user if they need database access. SSH access only with a public key and only if genuinely needed. Never give root access or the main control panel password to anyone.
How do I create FTP access for a colleague?
In cPanel, go to the FTP Accounts section, create a new username, and restrict its directory to public_html. Choose a strong password and limit the upload quota. This account has no access to server settings.
What should I do after a developer's work is finished?
Change the main control panel password, delete their FTP account, remove their SSH key from authorized_keys, and delete the MySQL users created for them. Do this on the same day the collaboration ends, not a week later.
Is SSH access better than FTP?
For working with files and uploading content, FTP is simpler and safer. For running Composer, deploying with Git, or executing long scripts, SSH is necessary. If you don't know what SSH is needed for, you probably don't need it.