Most hosting breaches we help clean up did not start with a zero-day exploit. They started with a password that worked on cPanel, WHM, the domain registrar, or Cloudflare. One login and an attacker owns DNS, email, and the website until someone notices.
Multi-factor authentication (MFA) is not a nice-to-have for agencies and small businesses anymore. It is the difference between "someone guessed a password" and "someone got in anyway."
What to protect first
Turn on MFA everywhere an attacker could redirect traffic or lock you out:
- Domain registrar (where your nameservers live)
- DNS host if separate from registrar (Cloudflare, Route 53, etc.)
- Hosting control panel (cPanel, Plesk, WHM, custom portal)
- Server root / SSH (keys plus MFA where supported)
- Email admin (Google Workspace, Microsoft 365, cPanel mail admin)
- Payment and billing tied to hosting renewals
Website WordPress admin MFA matters too, but registrar and DNS access beat site admin for total takeover speed.
Why DNS is the crown jewel
Change an A record and your "secure" server does not matter. Visitors go to the attacker's box. Change MX and they intercept mail. Add a TXT record and they can pass domain verification for phishing infrastructure.
Canadian data residency on your VPS is irrelevant if someone else controls the zone file at the registrar.
TOTP vs SMS (use an app)
Authenticator apps (Google Authenticator, Authy, 1Password, Bitwarden) generate time-based codes that work offline. Prefer these over SMS when the provider offers both.
SIM swap attacks target SMS codes. SMS is still better than nothing for accounts that only offer it, but app-based TOTP or hardware keys (FIDO2/WebAuthn) are stronger.
Hardware keys for high-value accounts
Agencies managing dozens of client domains should consider YubiKey or similar on registrar and cloud accounts. Phishing-resistant where supported. Store a backup key in a safe place, not in the same drawer as the primary.
Shared logins are MFA killers
"We all use the same cPanel login" means MFA codes go to one person's phone, or nobody enables MFA because it is inconvenient. Use named accounts, role-based access, and a password manager for the team.
When someone leaves, disable their access the same day. MFA on a shared password they still know does not help.
Recovery codes: save them once, store them safely
Every MFA setup offers backup codes. Download them, put them in your password manager or a physical safe, and label which account they belong to. You will need them when someone drops a phone in a lake.
Do not store recovery codes only in email on the same account they protect.
What we see go wrong
- MFA enabled on hosting but not on the registrar (attacker moves nameservers)
- Old employee still on Cloudflare with full access
- Registrar account uses info@domain.com that nobody monitors for takeover alerts
- MFA disabled "temporarily" during a migration and never turned back on
Run a quarterly access audit: who can change DNS, who has WHM, who gets billing emails.
Canadian hosting clients specifically
Law 25 and contract language push Quebec and federal clients to document security controls. MFA on infrastructure accounts is an easy checkbox that actually works. Document which systems use TOTP or hardware keys for compliance questionnaires.
Swift Host encourages MFA on client portal and control panel access. We cannot force your registrar choices, but we will nag you politely if DNS lives on an account with a password from 2019.
Bottom line
MFA on hosting and DNS is non-negotiable for any business that depends on its website and email. Start with registrar and DNS, use an authenticator app, kill shared passwords, and save recovery codes before you need them at 9 p.m. on a Friday.
Want help hardening access on Canadian-hosted infrastructure? Talk with Swift Host. We can walk through which accounts matter most for your setup.
