A reseller privilege list reads like a feature menu. It is really a list of things one customer can do that other customers will experience.
In WHM, Resellers → Edit Reseller Nameservers and Privileges.
The principle
A reseller should be able to do anything to their own accounts and nothing to the server.
That single sentence resolves most of the list. If a privilege's effect would be visible to another reseller's customers, it belongs to the administrator.
What they need
Creating, modifying, suspending and terminating the accounts they own. Managing their own packages. Viewing their own accounts' resource usage. Resetting their customers' passwords.
Withholding any of these means the reseller cannot run their business without contacting you, which converts your reseller product into a support obligation.
The reseller support workflow deals with what that day-to-day work looks like.
What they should not have
Restarting services. A restart affects every account on the machine. A reseller restarting the web server to fix their own customer's problem takes everyone offline for a moment, and will do it again.
Editing server configuration. Anything server-wide is by definition outside their scope.
Managing all accounts. This is the one that gets granted by accident, usually as part of a bundle. It lets a reseller see and modify accounts belonging to other resellers and to you.
Shell access. On a shared machine this is effectively administrative control, whatever the panel says. It belongs on a VPS, where the customer having root is the arrangement in place of a mistake. Moving from shared hosting to a VPS deals with that conversation.
The account limit
Separate from the privileges: how many accounts the reseller may create, and how much total disk and bandwidth they may allocate.
This is what stops a reseller overselling into your server. Set it against what they bought, and treat a request to raise it as a commercial conversation rather than a support ticket.
Managing disk quotas and bandwidth deals with the enforcement.
The failure that surprises people
If reseller accounts are provisioned automatically from billing software, the product configuration carries its own idea of which privileges to grant.
When that field is left empty, a provisioning action can apply no privileges, silently removing whatever was granted by hand. The reseller then reports that they have lost access to functions they were using yesterday, and nothing in the panel explains why.
The fix is to set the privilege list in the product configuration to match what you actually intend, so every automated action reapplies the same thing rather than blanking it.
Check this after any upgrade, downgrade or package change on a reseller account. Those are the operations that trigger it.
Nameservers
The same screen sets the nameservers the reseller's accounts are created with, which is how a reseller offers hosting under their own brand.
Those hostnames must actually exist and resolve before they are used, or every account the reseller creates is configured to use nameservers that answer nothing. There is more in setting up private nameservers.
Review what you granted
Privileges accumulate. A reseller needed something once, it was granted, and it was never removed.
Read the list for each reseller once a year and remove anything that is not currently justified, particularly anything server-wide that was granted to resolve a specific incident years ago.
The WHM security centre covers what a reseller can see and change beyond this screen.
Read what a reseller currently holds
Privileges are granted individually and accumulate, so the effective set is rarely what anybody remembers approving.
cat /var/cpanel/resellers 2>/dev/null grep -c . /var/cpanel/resellers 2>/dev/null ls /var/cpanel/resellers-* 2>/dev/null
Read the list for each reseller rather than trusting the summary. A privilege granted for one task, years ago, is still granted, and several of them together permit considerably more than any one alone.
The ones worth checking specifically are anything allowing access to other accounts, anything that can change limits, and anything touching the server rather than the accounts. Those are the three categories where an over grant matters.
Confirm the change did not reset something
Editing a reseller's configuration through some routes clears privileges rather than adding to them, which is discovered when the reseller reports losing access.
cat /var/cpanel/resellers | grep '^username:' | tr ',' '\n' | head -20
Read the list back immediately after any change. An entry that is now much shorter than it was is the signature of a reset rather than an edit.
The same applies to account limits, which are stored separately from the privilege list. A modification through the wrong screen can leave a reseller with privileges intact and an account limit of zero, which prevents them creating anything while everything appears correct. Creating and managing hosting packages covers the limits.
Test the limits by using them
A privilege set that reads correctly can still refuse the thing it was granted for, and the fastest check is to try it.
whmapi1 --user=reseller listaccts 2>/dev/null | head -5 whmapi1 --user=reseller myprivs 2>/dev/null | head -20
Query as the reseller rather than as root. What comes back is what they actually see, which occasionally differs from what the configuration screen suggests they should.
Create a test account under their ownership and remove it. That exercises the account limit, the package assignment and the ownership in one operation, and it fails immediately if any of the three is wrong.
Ownership is what decides everything
Privileges describe what a reseller may do. Ownership decides which accounts they may do it to, and the two are configured separately.
grep -l '^OWNER=reseller' /var/cpanel/users/* 2>/dev/null | wc -l grep '^OWNER=' /var/cpanel/users/username
An account whose ownership was not set correctly at creation belongs to root, and the reseller cannot manage it however complete their privileges are.
That is the usual explanation when a reseller reports being able to manage most of their accounts and not one particular one. Reading the ownership field answers it immediately, and correcting it is a single change rather than a privilege review.