Two-factor authentication on cPanel means a stolen password is not enough to get in. Given that cPanel opens every file, database and mailbox on the account, it is the highest-value ten minutes available on a hosting account.
Setting it up
In cPanel, open Two-Factor Authentication under Security. Scan the QR code with an authenticator app, enter the six-digit code it shows, and confirm.
Do this while you are logged in and everything is working. Setting up two-factor is not something to attempt while troubleshooting a login problem.
Save the recovery information now
This is the step people skip, and it is the one that decides whether losing a phone is an inconvenience or a support ticket.
When the QR code is displayed, there is also a text secret. Save that somewhere safe. A password manager entry alongside the cPanel password. It lets you set up the same code on a second device.
Better still, add it to two devices immediately. A phone and a tablet, or a phone and a desktop authenticator. Then a lost phone is a nuisance instead of a lockout.
Without either, losing the device means contacting support to have two-factor removed, which they will do only after establishing you are the account holder, and that takes time you will not want to spend.
Use an app, not SMS
Authenticator apps generate codes on the device with no network involved. SMS depends on your phone number, which can be moved to another SIM by someone who convinces a mobile operator to do it.
That attack is well established and targets exactly the kind of account worth protecting. Where you have the choice, choose the app.
The clock has to be right
The codes are derived from the current time, so the device and the server must agree within a small margin.
If codes are rejected and you are certain they are current, check the device's clock is set automatically. A phone a couple of minutes out produces codes that look correct and are refused, and there is nothing in the error to suggest the clock.
What it protects and what it does not
Protects: the cPanel login itself. Someone with your password cannot get in.
Does not protect: FTP, SSH keys, or email account logins. Those authenticate separately and are unaffected.
Nor does it protect the application inside your account. A compromised WordPress admin account is compromised regardless of what protects cPanel: that needs its own two-factor, and it is a separate setting inside WordPress. WordPress user roles covers which accounts need it.
Resellers: your WHM login first
If you resell hosting, the WHM account controls every client account you have. It is the single highest-value credential in the arrangement, and it is frequently protected by a password alone.
Enable it there before anywhere else. WHM also lets you require two-factor across accounts, which is worth considering if you host anything commercially significant, though be prepared for the support conversation that follows, since some clients will lose their devices.
Do not disable it to fix something else
A common pattern: something is not working, two-factor is turned off while debugging, and it is never turned back on.
If you must turn it off, put a reminder in your calendar for the same day. Six months later nobody remembers it was temporary, and the account is protected by a password again without anyone deciding that.
The rest of the login surface
Two-factor closes the password-guessing route into cPanel. Three other things matter alongside it.
A unique password, stored in a password manager, so a breach somewhere else cannot be replayed here.
An account contact address you actually read, and not one hosted on this account, password resets and warnings go there, and if the account has a problem the notification goes with it.
And shell access left off unless you specifically need it, since that is a separate route in with its own credentials.
This handles the login that succeeds with a stolen password; the volume of attempts is a separate mechanism. For that half, see cPHulk Brute Force Protection in WHM.
Requiring it rather than offering it
Left optional, two-factor authentication is enabled by the people who were already careful. Requiring it is a setting instead of a campaign.
The order matters, because switching it on for everyone at once produces a support queue. Enable it for your own accounts first, then announce a date, then enforce it, with the announcement stating what the customer needs before the date rather than after.
Two things to prepare beforehand. Anything logging in without a person present: a deployment script, a backup tool, a file transfer client, is unaffected by this and should be confirmed rather than assumed. And you need an answer ready for the customer who cannot complete the setup, because there will be several. There is more on where the setting sits alongside the others in WHM Security Center.
Clearing it for someone who is locked out
Somebody will lose the phone and the recovery information, and the account cannot be opened without intervention.
The removal is straightforward from the level above. A reseller can clear it for accounts they own, and it takes seconds. The difficulty is not technical.
Verify who is asking before doing it, using something the request itself did not supply: a callback to the number on file, confirmation from an address other than the one making the request, or a detail from the billing record. A password reset requested by email and a two-factor removal requested by email are the same request twice, and granting both undoes the protection entirely.
Record who asked, what confirmed them, and when. That record is what makes the difference if the removal turns out to have been the attack. Securing your hosting account deals with the surrounding controls.
Changing phones without losing access
The moment people lose access is not a theft. It is a new phone.
The shared secret is what the codes are generated from, and it can exist in more than one place. Enrolling a second device from the same secret at setup time, or storing it where a password manager keeps it, means a replaced phone is an inconvenience instead of a lockout.
Where the secret was not kept, the route is to disable and re-enrol from a session that is already authenticated, which is why doing it before the old phone is wiped is considerably easier than afterwards.
A migration feature offered by an authenticator application moves its own entries between devices and does not help if the application is being changed as well. Treat the secret as the thing to preserve, not the app.
Check who actually has it
An enforced policy and an enabled policy are not the same, and the difference is only visible if somebody looks.
ls /var/cpanel/authn/twofactor_user_configs/ 2>/dev/null | wc -l ls /var/cpanel/users | wc -l
Comparing the two counts shows the coverage. Accounts created before the requirement, or exempted during a support conversation and never re-enabled, are what the gap consists of.
Repeat it after any period of unusual support volume, since that is when exemptions are granted and forgotten. Coverage that was complete a year ago is not a statement about today, and an account with the protection quietly removed is more exposed than one that never had it, because everyone assumes it is protected.