Hardening runbook · Beginner · 30 min
How to secure your hosting account — The Hosting Account Is the Whole Blast Radius
Every site you host, every mailbox, every database and every cron job sits behind one login — which makes your credential list infrastructure, not admin.
The short answer
Start by drawing the blast radius: one cPanel login reaches every vhost, every database, every mailbox and every scheduled task on the account, so that single credential is worth more than any individual site password you have ever rotated.
Then reduce the number of things that can open it. Distinct generated passwords on the client area and cPanel, TOTP on both, SSH and deploys moved onto ed25519 keys, and every FTP account, panel user and API token you cannot name the owner of deleted. The recovery mailbox comes last because it outranks all of them.
By the HostingFast team · Reviewed 24 August 2026
Beginner
Assumed level
30 minutes
Wall-clock time
5
Steps to done
24/7
Engineers on call
Half an hour, once, and then a five-minute review every quarter. Nothing here needs a plugin or a paid tool; it is all in cPanel, the client area and your password manager.
The key-based part assumes a terminal. SSH access with Git and Composer is included on every shared tier here, so the ssh-keygen route is available whatever plan you are on.
Draw the blast radius before you defend it
Write down what one leaked cPanel password reaches on your account. Every document root, so every site you host. Every MySQL database, including the one behind your store. Every mailbox on your domains, which means every password-reset email those addresses can receive. Cron jobs, which means arbitrary scheduled code. That is the actual scope, and it is considerably wider than most people picture when they choose that password.
The client area sits above it and is wider still: it can change services, transfer domains and see invoices. Two credentials, two very different kinds of damage, and a single reused password collapses both into one.
Keys beat passwords wherever the platform allows it
SSH is on every shared tier, and a key is strictly better than a password for it: nothing guessable travels over the wire, and revoking access is deleting one line rather than changing a secret that three people know. Generate one with ssh-keygen -t ed25519 -C 'laptop-2026', keep the private half on the machine that made it, and upload the public half in cPanel's SSH Access screen. Then stop using the password for that route entirely.
The same logic applies to deploys. A repository deploy key or a dedicated FTP account scoped to one directory is revocable in isolation. Handing a contractor the cPanel password is not: undoing it means rotating a credential that also affects everything else you run.
The credential inventory nobody keeps
Open four screens and list what you find: FTP Accounts, additional cPanel users, API tokens, and your application's own credentials — WordPress application passwords, plugin API keys, SMTP logins. Each entry is a door with its own lock, and doors created for a departed contractor or an abandoned experiment are the ones nobody is watching.
The rule that keeps this tidy is simple: if you cannot say who or what uses a credential, delete it. Something breaking loudly today is much cheaper than something being used quietly for a year.
Detection: what to read, and how often
cPanel records last login details, and your access log records the attempts that failed. A quick grep for POSTs to your login path — grep 'POST /wp-login.php' access.log | wc -l — turns a vague sense of being probed into a number you can watch month to month. On the plans carrying Imunify360, its reporting adds the blocked attempts you never see at all.
Then there is the credential that outranks the rest: your contact address. Account recovery flows through it, so its mailbox silently caps the security of everything above. Give it its own strong password, its own second factor, and a review at the same cadence as the rest.
What ships switched on, and what is yours to set
cPanel's SSH Access, FTP Accounts, API tokens and two-factor screens are all present on the accounts we sell, and Imunify protection runs in front of every site on the platform.
Free SSL on every plan renews itself before it can lapse, so one credential you will never have to rotate is the certificate.
- Blast radius written out, not implied
- ssh-keygen command given in full
- Four cPanel screens named, in the order to open them
- Support reachable at any hour if a credential goes wrong
Why HostingFast
Standard on every plan
Scope stated first
The guide starts by listing exactly what one account credential reaches, because that is what decides how much care it deserves.
Keys, with the command
ed25519 generation, where the public half goes in cPanel, and why revoking a key beats rotating a password.
An inventory you can finish
Four named screens, each producing a list, with one rule for deciding what stays.
Detection made concrete
A grep against the access log turns being probed into a monthly number you can actually track.
The recovery mailbox ranked properly
It can reset everything else, so the guide treats it as the top of the tree rather than an afterthought.
Humans at every hour
Locked out mid-rotation at an inconvenient time? Support is staffed round the clock and used to it.
Quick Start
From order to online
- 1
Rotate the two credentials that matter, separately
Client area and cPanel, both generated by your password manager, both distinct. Reusing one for the other means a single leak reaches billing and files at once.
- 2
Add TOTP to both logins before you go further
The client area governs services and domains; cPanel governs files. Each has its own two-factor setting and each needs enrolling on its own.
- 3
Move SSH and deploys onto keys
ssh-keygen -t ed25519, upload the public key in SSH Access, confirm you can log in with it, then stop using the password for that path. Give every machine and every contractor its own key so revocation is surgical.
- 4
Delete every credential you cannot attribute
FTP Accounts, extra cPanel users, API tokens, application passwords. Unknown owner means delete. Anything that genuinely breaks can be recreated in a minute with a named owner attached.
- 5
Harden the recovery mailbox last, because it sits above the rest
It can reset your client area, which can reach everything else. Its own password, its own second factor, and no forwarding rule you did not create yourself.
Built In
Loaded onto every plan
- Full SSH access with key authentication on every shared plan
- Two-factor authentication available on both cPanel and the client area
- Imunify protection sweeping every site on the platform
- Free SSL on every plan, renewed automatically before it can expire
- cPanel API tokens and FTP accounts you can scope and revoke individually
- Daily backups with self-service restores from the panel
- DDoS filtering absorbed out at the network edge
- Human support on duty every hour of every day
- Money-back cover: 30 days on hosting plans, 7 on reseller
- Renewal billed at the rate you signed up at, with no setup fee
Frequently Asked
What people ask us most often
Does hardening WordPress also cover the hosting account?
No, and conflating the two is a common gap. A WordPress security plugin defends one application: its login form, its files, its users. The hosting account sits underneath and reaches every application on it, plus mail, databases and cron. Someone with cPanel access does not need your WordPress password at all — they can read wp-config.php. The two need hardening separately.
How do I give a contractor deploy access without the cPanel password?
Three options, in ascending order of neatness. Create an FTP account scoped to a single directory. Create an additional cPanel user with limited features. Or best, add their public SSH key so you can revoke exactly their access later without touching anything else. All three are removable in isolation, which the shared password never is.
Are SSH keys available on shared hosting here?
Yes — full SSH access with Git and Composer is included on every shared tier, and cPanel has an SSH Access screen where you import or generate keys. That means the key-based workflow is not something you have to move to a VPS for; it is available on the entry plan.
What does the panel's login history actually tell me?
It records recent successful logins with their source, which is enough to notice a session you did not create. It will not show you the attempts that failed — for that, read the raw access log for POSTs against your login paths, and on the plans carrying Imunify360, its own reporting shows what was blocked before it reached you.
Keep reading
How to Test Your Website Speed
Field data, lab data and TTFB, and which of the three answers which question.
How to Install WooCommerce
A store on WordPress, with a test order pushed all the way through checkout.
SSH (Secure Shell) (Glossary)
The protocol, the key exchange, and why a key beats a password on it.
PHP Hosting
Per-site PHP switching, OPcache and the extensions a real application needs.
CMS Hosting
Any CMS on NVMe behind a LiteSpeed cache, with shell access included.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Hosting that gives you real keys.
SSH with key authentication on every plan, two-factor on cPanel and the client area, Imunify protection in front of every site, and support at any hour.
View PHP Hosting plans