Hardening runbook · Beginner · 15 min
Two-Factor Authentication, Enrolled in Blast-Radius Order
A password that leaked in somebody else's breach should not be enough to reach your servers — TOTP is the cheapest control you will deploy this month.
The short answer
Enrol TOTP on the logins in order of what they control — client area first because it owns your services and domains, then cPanel because it owns your files, then the application, the registrar and finally the mailbox that can reset any of them.
TOTP works from a shared secret and the clock: your app and the server derive the same six digits from that secret and the current thirty-second window, so nothing transmittable ever crosses the network. Choose it over SMS, save the recovery codes into your password manager at setup, and the whole exercise takes about fifteen minutes.
By the HostingFast team · Reviewed 12 August 2026
Beginner
Assumed level
5
Steps to done
Free
Support cost
Proven
Verified on production
Fifteen minutes, one authenticator app, and one honest decision about where to keep the recovery codes. That last part is the bit people regret skipping.
Both logins that matter here support it: the client area and cPanel each carry their own two-factor setting, enrolled separately with separate secrets.
The mechanism, in one paragraph
At setup the server generates a random secret and shows it to you as a QR code. Your app stores that secret. From then on, both sides run the same function over the secret and the current thirty-second time step and truncate the result to six digits. Nothing is sent anywhere, no network call is made, and the code is worthless a moment later.
That design has exactly one operational failure mode: clock skew. If your phone's time is wrong by more than a step or two, every code you produce is rejected even though the secret is correct. Turn on automatic network time and the problem disappears permanently.
Why SMS is the weaker second factor
An SMS code travels over a network you do not control and is delivered to a number that can be moved. Port-out and SIM-swap attacks are the standard route, and they target exactly the accounts worth targeting. The code also passes through intermediaries, any of which is a place it can be observed.
An authenticator app removes all of that. The secret never leaves the device, there is no delivery path to intercept, and the code is generated offline — which also means it works when you have no signal, in a basement, abroad, on a plane.
Enrol in order of what each login controls
The client area comes first: it can change services, move domains and see billing. cPanel comes second: it can read wp-config.php, dump databases and write PHP files. Then the application's own admin, then your registrar if names live elsewhere, and finally the recovery mailbox, which can trigger resets on every one of the above.
That last one is the reason ordering matters at all. Two-factor on cPanel is worth much less if the mailbox that can reset it has nothing but a reused password in front of it. Work down the tree, not across it alphabetically.
Recovery codes are an operational artefact
The backup codes shown at setup are the only route back after a lost or wiped phone, and setup is the only moment they are ever displayed. They belong in your password manager, in the entry for that account — not in a screenshot on the same phone that holds the authenticator, which is a single point of failure wearing a disguise.
Then test one. Log out, log back in using a recovery code rather than the app, and confirm it works. An untested recovery path is a guess, and you will find out whether the guess was right on the worst possible day.
Where the second factor is offered here
Both of the logins that matter on our platform carry two-factor authentication: the client area that owns your services, and the cPanel account that owns your files. They enrol separately, each with its own secret.
Support is staffed by humans at every hour of every day, which is the part that matters if you ever lock yourself out mid-enrolment.
- The TOTP mechanism explained, not just the toggle
- Enrolment ordered by what each login controls
- Clock drift named as the one real failure mode
- Recovery codes treated as something to test
Why HostingFast
Standard on every plan
Mechanism before instruction
You get why a code works offline and expires in thirty seconds, which makes every later troubleshooting step obvious.
An enrolment order with a reason
Client area, panel, application, registrar, mailbox — sequenced by blast radius rather than by convenience.
The SMS comparison, stated plainly
Port-out and SIM swap named as the specific attacks, so the choice of app over text is an informed one.
Clock skew, pre-empted
The single most common cause of rejected codes gets its own explanation and its own one-setting fix.
Recovery treated as a test
Codes into the password manager, then one of them actually used, so the escape hatch is known to open.
Automation not left hanging
The guide covers how scripted deploys and CLI access carry on working once interactive logins need a code.
Quick Start
From order to online
- 1
Pick an authenticator you can move between devices
Aegis, 1Password or Google Authenticator all implement the same standard. What differs is whether the vault can be exported or synced — which is what decides how bad a lost phone is.
- 2
Fix the phone's clock before you enrol anything
Automatic network time on. Skip this and your first rejected code will send you looking for a fault in the enrolment rather than in the clock.
- 3
Enrol the client area first, then cPanel separately
Security settings, scan the QR, confirm with a live code. Two separate secrets for two separate scopes — the billing account governs services and domains, the panel governs every file you host.
- 4
Store the recovery codes, then spend one
Straight into the password manager entry for that login. Then log out and log back in with a code instead of the app, so you know the path works before you need it.
- 5
Extend down the chain, mailbox last but not least
Application admin, registrar, then the address that can reset the lot. Two-factor compounds: it is worth most when the account that could bypass it is covered too.
Built In
Loaded onto every plan
- Two-factor authentication on the cPanel account, enrolled with its own secret
- Two-factor authentication on the client area that owns services and domains
- Full SSH access with key authentication, so automation needs no interactive login
- Imunify protection watching every site on the platform
- Free SSL on every plan, renewed automatically before it can expire
- Daily backups with restores you trigger yourself from the panel
- DDoS filtering absorbed out at the network edge
- cPanel API tokens for scripted access, issued and revoked by you
- Money-back cover: 30 days on hosting plans, 7 on reseller
- Human support on duty every hour of every day
Frequently Asked
What people ask us most often
Why is my authenticator code being rejected as invalid?
Almost always clock drift. TOTP derives the code from the shared secret and the current thirty-second window, so if your phone's clock is off by more than a window or two the digits will not match even though the secret is correct. Switch the device to automatic network time and try again. If codes are still rejected after that, the secret itself was mis-scanned and the enrolment needs redoing with a fresh QR.
What happens to my logins if the phone with the codes is lost?
You use a recovery code, which is why they belong in your password manager rather than on the phone. If they are gone too, the route back is the account's own recovery process through your verified contact address — which is precisely why that mailbox needs its own protection. Support is staffed at every hour and can talk you through identity checks, but a stored recovery code turns a bad afternoon into a thirty-second detour.
Can I use a hardware security key instead of an app?
cPanel's built-in two-factor is a TOTP implementation, so it expects an authenticator app rather than a hardware key. That does not make the key useless: put it on the accounts that do support it — your password manager, your email provider, your version control host — because those sit above the panel in the reset chain anyway.
How do deploys and cron keep working once two-factor is on?
They are unaffected, because they do not use the interactive login. SSH key authentication, cPanel API tokens and cron jobs all authenticate by their own credential, not by a code you type. That separation is deliberate: enrol the human paths in two-factor and give automation its own revocable key, and nothing in your pipeline needs to know you did it.
Keep reading
How to Schedule Server Backups
Put the backup on a schedule with a retention rule you have actually tested.
How to Enable LiteSpeed Caching
Turn on the cache, then prove the hit from the response headers before tuning.
Two-Factor Authentication (2FA) (Glossary)
What the second factor is, and why a time-based code cannot be replayed.
Domain Names
Registration, renewal and delegation, with your first year free on annual plans.
Business Hosting
More cores, more RAM and priority support for a site doing real work.
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.
Put a second factor in front of everything.
Two-factor on cPanel and the client area, SSH keys for automation, Imunify protection on every site, and humans answering at any hour.
View Domain Names plans