WHM's Security Center groups a set of tools that mostly do one thing each. Some are genuinely useful on a reseller account, several require root and will refuse, and one is worth understanding properly because misusing it locks you out.
What a reseller can actually reach
Most of the Security Center is root-level: firewall configuration, kernel settings, service hardening. On a reseller account those screens are either absent or refuse the operation.
That refusal is correct rather than a limitation to work around. If a task genuinely requires server-wide security changes, a reseller plan is not the tier for it.
What you do control is per-account: password strength requirements, shell access, and the tools that inspect what your accounts are doing.
Password strength
Set a minimum strength for account passwords. This applies when you create accounts and when clients change their own.
Worth setting deliberately, because a weak client password is not just their problem. A compromised cPanel account becomes a spam relay, which gets the server's IP address blocklisted, and that affects every other account on it, including yours.
Shell access
Leave SSH access off by default for client accounts, and grant it only to a client with a specific need whom you trust.
Once granted it stays granted until somebody removes it. Review the list occasionally; access given for a one-off task two years ago is still open.
The security advisor
WHM has an advisor that scans the configuration and reports issues by severity. On a reseller account most of what it reports is server-level and not yours to fix.
Read it once to know what it says, then ignore the root-level items rather than raising each one as a ticket. What is worth acting on is anything about your own accounts, weak passwords, accounts with shell access you did not intend, unusual settings.
What actually protects your accounts
The Security Center is a smaller part of this than its name suggests. Three things matter more, and none of them are in it.
Two-factor on your own WHM login. That account controls every client you have. It is the single highest-value credential in the arrangement and it is frequently protected by a password alone.
Clients running current software. Almost every compromise on a shared server arrives through an outdated application, not through the server. You cannot patch their WordPress for them, but you can notice, and a client whose site is compromised is your problem, because the account is yours.
Watching for the symptoms. A sudden bandwidth increase on one account, or a mail queue growing, is usually a compromised site being used for something. Both are visible before anyone reports them.
When an account is compromised
Suspend it immediately, before investigating. It stops the damage and preserves what you need to understand how it happened, terminating destroys the evidence along with the problem.
Then change the account password, look at what changed recently in the files, and check whether the same client has other accounts with you.
Restore from a backup taken before the compromise rather than cleaning injected files by hand. Hand cleaning misses backdoors routinely, and a single leftover file returns the attacker a week later.
Update everything before putting it back online, or the same automated scan finds the same unpatched plugin within days. Suspending accounts explains the mechanics.
What you cannot do, and who to ask
Server-wide firewall rules, blocking an address at the server level, and kernel or service hardening are all root operations.
If you have a genuine need; an address attacking your accounts persistently, a service behaving oddly: that is a support ticket rather than something to configure around. Include what you observed and where you saw it, and it will be handled faster than a general report that something seems wrong.
When something does go wrong on an account, suspension is the fast reversible response and termination is not. How to Suspend, Unsuspend and Terminate Accounts in WHM goes into the difference and the checks worth doing first.
The part of this section you will actually use most is the login protection, usually to release someone it locked out. For tuning it first, see cPHulk Brute Force Protection in WHM.
What a reseller can reach in the first place is decided by their privilege list, and a few entries on it are effectively administrative. There is more in Reseller Privileges and ACLs in WHM.
Audit what you have already granted
Most of a reseller's exposure is not a setting that was configured wrongly; it is an exception granted a year ago and never withdrawn.
grep -l 'HASSHELL=1' /var/cpanel/users/* 2>/dev/null grep -L 'SHELL=/usr/local/cpanel/bin/jailshell' /var/cpanel/users/* 2>/dev/null | head
The first lists accounts with shell access. Read it and ask, for each, whether the reason still applies: a developer who needed it for a migration finished two years ago is still holding it.
The same review belongs on anything granted per account: an elevated limit, a feature enabled on request, a suspension lifted temporarily. Write the reason and a date next to each when you grant it, because without that the review has no basis to decide on and everything looks necessary.
Brute-force protection from a reseller's seat
Login attempts against your accounts are constant, and the protection that answers them is server-wide rather than yours.
What that means practically: you cannot change the thresholds, and you can be affected by them. A support session where you and a customer both mistype a password can put your own address on the blocked list, at which point everything you manage appears to be down.
So the useful preparation is knowing a second route in before you need it: a different network, or an address the server already trusts. Ask for your office address to be permitted in advance rather than during the incident, since the request has to travel through the channel you have just lost. There is more on what it is doing on your behalf in cPHulk brute force protection.
What is reachable that should not be
The commonest genuine exposure on a shared account has nothing to do with any security setting: it is a file left where the web server will serve it.
find ~/public_html -maxdepth 2 \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '.env' \) 2>/dev/null ls -d ~/public_html/.git 2>/dev/null curl -sI https://example.com/.env | head -1
A database dump downloaded by anybody who guesses the filename, a .env holding credentials, a .git directory exposing the whole source history. Each is a complete compromise and none is visible from any panel.
This is entirely within a reseller's control, which makes it worth checking across every account you manage instead of waiting for a report. Run it as a sweep, not once: the files arrive during maintenance and are forgotten afterwards.
Make the escalation actionable
The requests that need root are resolved at the speed of the information attached to them.
Before asking, collect four things: what you observed and at what time, which account and which domain, what you have already ruled out, and the specific outcome you are asking for. A request naming a symptom asks the other side to start the investigation from nothing.
date; grep -iE 'error|denied|fail' ~/logs/example.com.error.log | tail -20 > /tmp/evidence.txt
Attach the lines rather than describing them, and state which are yours. A ticket containing an exact timestamp, an account name and twenty log lines is acted on; one asking whether anything is wrong with the server is answered with a question. There is more on establishing which side the fault is on first in WHM service status and server health.