Most hosting accounts are compromised through the account itself rather than through the website. A password reused elsewhere, a contact address nobody reads, credentials shared with someone who left, none of that is stopped by anything you install on the site.
The measures below take about twenty minutes in total.
Two-factor authentication, first
The single highest-value thing here, because it makes a stolen password insufficient on its own.
Enable it on your billing account and on cPanel. They are separate logins and both need it: someone with billing access can usually reach the hosting, and someone with cPanel access can reach everything the sites hold. For setting it up there, see two-factor authentication in cPanel.
Save the recovery codes somewhere that is not the phone running the authenticator. Losing both at once is a support conversation involving identity checks and days.
The contact address decides everything else
Password resets, security alerts, quota warnings and expiry notices all go to the address on the account.
Two rules. It must be an address you actually read, and it must not be on a domain hosted in this account.
The second one matters more than it sounds: if the account is suspended or full, mail to that address stops, so the warning about the problem fails to arrive because of the problem. And an attacker who reaches the account can read the reset emails for it.
Use an address at a separate provider, and check it is current. An address belonging to someone who left the company is a live route into your account.
Stop sharing the main password
The usual arrangement (one cPanel password given to whoever needs to work on the site) means you cannot revoke one person's access without changing it for everyone, and you cannot tell who did what.
The alternatives take minutes:
An FTP account limited to one directory, for someone who only uploads files.
A WordPress user with the right role, for someone working on content or the site itself. There is more on choosing one in WordPress user roles.
An API token for a script, scoped to what it needs and revocable on its own. Using cPanel API tokens goes into it.
Each of those is removable individually, which is the property you want when a contractor's work finishes.
Do not reuse the password anywhere
Credential-stuffing attacks take passwords leaked from unrelated sites and try them everywhere. A hosting password that is also your forum password is only as safe as that forum.
Use a password manager and let it generate something long. You never type it, so its length costs nothing.
And change it when someone with access leaves, even amicably. That is not distrust; it is the same reason you collect keys back.
Review who has access, twice a year
Accounts accumulate. FTP users created for a one-off job, WordPress administrators from a previous developer, API tokens for scripts that no longer run.
Open each list and remove anything you cannot account for. If you are unsure whether something is in use, disable it and see what breaks. Anything still needed announces itself within a day.
The FTP list is usually the worst offender, because those accounts are created quickly and nobody thinks about them again.
Watch what the account is doing
Two signals that show a compromise before anyone reports it.
Outbound mail volume. A sudden rise from an account that sends little is a compromised script sending spam, and it is visible hours before a blocklist entry.
Disk and bandwidth. Heavy outbound traffic with no matching visitors usually means your account is serving files for someone else. Monitoring your hosting resources sets out where to look.
Neither takes more than a monthly glance, and both are earlier warnings than an abuse report.
Keep the domain out of the blast radius
The domain registration is separate from the hosting, and losing it is worse than losing the hosting.
Enable the registrar lock, turn on two-factor authentication there too, keep auto-renewal on with a valid card, and make sure the registrant contact address is one you read. Domain locking walks through why the lock matters.
A hosting account can be rebuilt from a backup. A domain transferred away is a legal process.
Backups are the part that assumes the rest failed
Every measure above reduces the chance of a problem. Backups are what makes one survivable.
Keep copies off the server, keep enough history to reach back past a compromise you did not notice for a fortnight, and restore one deliberately at least once so you know it works. Backing up and restoring walks through doing that.
An untested backup is a hope. A restored one is a plan.
A twenty-minute pass
Two-factor on billing and cPanel. Contact address external and current. Recovery codes stored separately. Shared passwords replaced with individual access. Access lists reviewed. Domain locked with its own two-factor.
That covers the routes actually used against hosting accounts, and none of it requires buying anything.
It is also worth being clear about what your provider can reach regardless of what you do. What Your Hosting Provider Can and Cannot See walks through the extent of it.
Check whether your details are already exposed
Most account compromises begin with a password from somewhere else, and it costs nothing to find out whether yours is in circulation.
Breach notification services let you check an address against known disclosures. If the address you use for hosting appears in one, treat every password you have ever used with it as known, not just the one for that site.
The practical response is narrow. Change the hosting password, change anything reusing it, and confirm two factor authentication is active on the mailbox that receives your resets. That mailbox is the account that protects everything else, and it is frequently the one with the oldest password.
Look at what has been logged in recently
The record exists and almost nobody reads it, which is why an unauthorised session can last months.
last -20 lastb 2>/dev/null | head -10 grep -iE 'accepted|failed' ~/logs/*login* 2>/dev/null | tail -20
What you are looking for is a successful entry from somewhere you have never been, or at a time you were not working. Failed attempts are constant and unremarkable; a failed run followed by a success is the pattern that matters.
Check the panel's own login history as well as the shell record, since they are separate. And check whether any session is currently active that is not yours, because changing the password does not always end an existing session.
Know what you would do in the first hour
Security advice is mostly prevention. The part people skip is deciding, in advance, what happens if it fails.
Write down four things and keep them somewhere not on the account. Where the backups are and how to reach them without this login. Who at the host you contact and how you prove who you are. Where the domain is registered and how you reach that account. And which addresses would need to be told.
Working this out during an incident is what turns a bad day into a bad week, because the answers all live in the account that is currently the problem. Backing up and restoring in cPanel deals with the first, and the point of writing it down is that you can reach it when the account cannot.