Resellers frequently work the hard way: ask the customer for their cPanel password, log in as them, fix the thing, and leave the password sitting in a support thread forever.
There is no need. WHM opens any account you own directly.
Where the jump lives
In WHM, open Account Information → List Accounts. Each row expands, and each has a cPanel icon that opens that account's control panel in a new tab.
You are now inside the customer's cPanel with everything they would see. No password was involved, and theirs has not changed.
The same route exists from the account's row after a search, which matters when the server has hundreds of accounts and scrolling is not a plan. Search by domain rather than by username, customers report the domain, and the username is frequently something truncated they have never seen.
Why this is the correct habit, not just the convenient one
A password you asked for cannot be taken back. It exists in your inbox, in their sent folder, and quite often in the same form on their bank and their email. Not asking for it removes an entire category of risk you would otherwise be carrying on the customer's behalf.
It also works when the customer has forgotten the password, which is a large share of the tickets where you needed access in the first place.
And it separates the two things cleanly: your reseller session is what authenticated, and the customer's own credentials are untouched. If they change their password an hour later, your access still works.
What this access actually includes
Everything. File Manager, databases, and (the part worth pausing on) the webmail interface and the contents of every mailbox on the account.
That is a level of access most customers do not consciously realise their host has. Treat it accordingly: open the account for the task in front of you, do the task, close the tab. Do not read mail to diagnose a mail problem when the delivery logs will tell you the same thing without opening anyone's correspondence.
The email deliverability tool and mail delivery tracking answer most mail questions from outside the mailbox, which is where you want to be answering them from.
Say what you changed
Because this access leaves no trace the customer will see, the record is whatever you write in the ticket.
"Enabled the PHP extension and restarted" is thirty seconds of typing that prevents the conversation three weeks later where a setting changed and nobody knows who changed it. It also protects you: an unexplained change on an account you had access to is a bad position to argue from.
Working in one dashboard
Once this is a habit, most reseller support happens without leaving WHM. You find the account by domain, read its disk and bandwidth from the list, jump into cPanel for the fix, and come back.
The screens worth knowing beside the jump are the account list itself, the server health view, and the account functions for suspensions and package changes: the WHM dashboard overview goes over where each of them sits, and the reseller support workflow explains stitching them into a routine.
What you cannot do this way
You are entering as the account, so you are subject to the account's feature list. If you removed a tool from the package, it is missing for you too.
That is occasionally confusing during support: the interface a customer is describing genuinely is not there, because you took it away. Feature Manager is where to check before assuming the panel is broken.
Two sessions in one browser
Opening a customer's cPanel while logged into your own account works, and browsers keep the two sessions separate only up to a point.
The practical problem is confusion instead of a technical one: several tabs open on several accounts, all looking identical, and a change applied to the wrong one. That is a genuinely common way to modify a customer who did not report a problem.
Two habits prevent it. Close each account's tab when finished rather than accumulating them, and read the domain in the interface before making any change: cPanel displays it, and glancing at it takes a second.
For work on several accounts in a session, a separate browser profile or a private window per account removes the ambiguity entirely.
Reaching a specific screen directly
The jump lands on the customer's home screen, and for repetitive work that is several clicks away from where you need to be.
The panel's own interface addresses can be appended once the session exists, so a bookmark or a note of the paths you use most, file manager, email accounts, the error log, turns a five-click routine into one.
What matters is that the session is established by the jump rather than by any address you construct. A link that appears to work while you are already authenticated will not work for anyone else, which is worth knowing before sharing it with a colleague.
When the customer is watching
Support conversations frequently involve the customer having their own cPanel open at the same time.
That produces a specific confusion: they change something while you are looking at a screen that no longer reflects reality, and the resulting disagreement about what the setting says wastes real time.
Say plainly at the start whether you want them in the panel or out of it. "I will look now, please close the panel and I will tell you when I am done" is a sentence that saves the whole class of problem.
Access when the customer has left
An account whose owner is unreachable still needs administering. A certificate renewal, a compromised mailbox, a support obligation to a third party.
The jump works regardless, which is convenient and is exactly the situation where a written record matters most. Nobody is going to confirm what you did, and the ticket or the account note is the only account of it.
Where the work is on behalf of somebody other than the account holder, get that request in writing before acting, not afterwards. Handling a chargeback or billing dispute deals with why the documentary record is what settles disputes.