FTP accounts get created when somebody needs to upload something and are then never thought about again. They are access decisions, and treating them as conveniences is how accounts accumulate that nobody can account for.
Connecting, client settings and connection problems are a separate matter. See connecting to your hosting account via FTP. This is about who should hold what.
The account you already have cannot be restricted
Every hosting account comes with FTP access using the cPanel username and password. It works immediately and it has two properties worth stating plainly.
It reaches every file in the account, including everything above the web root. And it is the same credential as the control panel login, so anyone holding it can also log into cPanel.
Which means handing it to a designer for one upload hands over the whole account. The databases, the mail configuration, the backups, and the ability to change the password.
Use it yourself. Do not give it out.
Create an account for the job
In cPanel, FTP Accounts. The field that matters is the directory.
Set it to the narrowest path that lets the person do the work. One site's directory rather than the account root, and a subdirectory instead of the whole site if that is enough.
The account is then confined there. It has its own password, and removing it later affects nothing else.
What directory scoping does not do is protect against everything: the person can still overwrite anything inside that path, and a site's own configuration files usually live in it. It limits blast radius rather than eliminating it.
One account per person
The temptation is one "developer" account that everyone uses. It is always the wrong choice, for two reasons that only appear later.
A shared credential cannot be revoked for one person. When one of three contractors finishes, changing the password locks out the other two, so nobody changes it and the departed contractor keeps access.
And the logs record the account, not the human. When a file changes and nobody admits to it, a shared account guarantees you cannot find out.
An account each costs nothing and takes a minute.
Remove them when the work ends
This is the step that is almost universally skipped, and it is the one that matters.
An unused FTP account does not expire. It keeps working indefinitely, and its password is now stored in a client on a machine you do not control, possibly synced to a service, possibly on a laptop that gets sold.
Deleting the account removes only the access. cPanel asks whether to remove the files too, and the answer is almost always no, because those files are the work you paid for.
Review the list twice a year
cPanel → FTP Accounts
Read the list and ask, for each one, who holds it and whether they still need it.
Typical findings on an account that has existed a few years: a developer from two agencies ago, an account created for a one-off migration, and one nobody can identify at all. All three are working keys.
Put it in the yearly maintenance round so it actually happens. The yearly website maintenance checklist walks through where it fits.
Prefer SFTP where you can
If the person needs shell access anyway, SFTP over SSH keys is better in every respect: encrypted, no password to share, and revoked by removing one key.
It requires SSH access, which is a larger grant than FTP, so it is right for a developer and wrong for someone who only uploads images. Managing SSH keys in cPanel deals with it.
When no account is needed at all
For a one-off file, or for someone who needs to change one thing occasionally, File Manager avoids creating a credential at all, and a credential that does not exist cannot be forgotten.
Using File Manager goes over it, and it is the right answer more often than the habit of creating an account suggests.
Check what an account can actually reach
An account restricted to a directory is only restricted if the setting took effect, and confirming it takes one session.
grep -E '^[^:]+:' ~/etc/ftpquota 2>/dev/null | head
awk -F: '{print $1, $6}' /etc/passwd | grep -i "$(whoami)" | head
Connect with the account and try to move above its directory. It should refuse. An account that can reach the account root can read configuration files containing database credentials, which is a full compromise from a login created for one folder.
Test this when the account is created rather than assuming the panel applied it. A path typed with a leading slash frequently means something different from one without, and the difference is the entire restriction.
The protocol matters more than the account
Plain file transfer sends the password and every file in the clear, so anyone positioned between the two ends reads both.
grep -iE 'TLSRequired|RequireValidShell' /etc/proftpd.conf 2>/dev/null | head ss -tlnp | grep -E ':21|:22|:990' curl -sI ftp://example.com/ 2>&1 | head -2
The encrypted variants exist on almost every server and cost nothing to use, and the usual obstacle is a client configured years ago that nobody has changed.
Where a customer insists on the plain protocol, the account should at least be restricted to one directory with no access to anything that matters. The credentials will eventually be captured somewhere, and the question is only what they unlock.
Watch what the accounts are doing
Transfer accounts are created for a task and outlive it, and the log is the only record of whether they are still in use.
grep -ciE 'USER|LOGIN' /var/log/xferlog 2>/dev/null
awk '{print $14}' /var/log/xferlog 2>/dev/null | sort | uniq -c | sort -rn | head
awk '{print $NF}' /var/log/xferlog 2>/dev/null | sort | uniq -c | head
An account with no activity for months is a credential in somebody's client with no current purpose. Removing it is the cheapest security action available.
Unexpected activity is the other finding. Uploads to an account created for downloads, or transfers at hours nobody works, are worth understanding rather than dismissing. Securing your hosting account covers the wider review.
