Why MFA belongs on every “can change the internet for us” login
If someone can change your DNS, renew your domain, log into hosting, or reset mailbox passwords, they can take your site offline, hijack email, or point customers to a fake page—without touching your office network. For a small business, those admin logins are often the highest-leverage accounts you own, and too often they still sit behind one shared password on a sticky note.
This is a practical operator checklist TwoQM recommends for turning on multi-factor authentication (MFA) across hosting, domain, and email admin accounts. It is not a vendor bake-off.
MFA adds a second factor after the password—usually an authenticator app code, a hardware key, or (less preferably) SMS. Even if a password leaks from reuse, phishing, or an old contractor laptop, the second factor blocks most drive-by takeovers.
The accounts that matter most are not personal social media. They are the ones that can:
Change DNS (A, MX, TXT, CNAME records)
Renew, transfer, or unlock a domain at the registrar
Deploy or wipe a site in hosting or the CMS admin
Create mailboxes, reset passwords, or change forwarding in email admin
Control billing profiles tied to those services
Treat those as production infrastructure, same as backups and SSL.
Step 1: Inventory every login that can change DNS, hosting, CMS, or email
Do not start from memory. Start from a shared sheet and name owners:
Domain registrar — Where the domain renews and transfers.
DNS host — Often the registrar; sometimes Cloudflare, Route 53, or your host’s DNS panel.
Web hosting / VPS / cloud console — cPanel, Plesk, host dashboard, or cloud org owners.
CMS admin — WordPress, Webflow, Shopify, Squarespace—anyone with Administrator / Owner.
Email admin — Microsoft 365, Google Workspace, or host webmail admin that can create users and set forwarding.
CDN / edge / SSL — Panels that can alter traffic before your origin.
Related billing and recovery — Accounts that receive verification emails, phone numbers on file, and cards tied to renewals.
Minimum columns: service, URL, primary owner, backup owner, MFA status, recovery codes stored?, last access review.
Step 2: Turn on MFA—prefer authenticator apps over SMS
For each row that can change production:
Sign in as the owner (avoid shared generic logins when you can).
Find Security / 2-Step Verification / MFA in account settings.
Prefer an authenticator app (TOTP) or hardware key over SMS. SMS still beats nothing, but SIM-swap risk is real on high-value accounts.
Enroll two devices or two people where the vendor allows backups—so one lost phone does not lock the company out.
Confirm a test login after enrollment before you close the tab.
If a vendor only offers SMS, enable it, document the gap, and revisit quarterly.
Step 3: Store recovery codes offline—and treat them like cash
Most platforms give one-time recovery codes when you enable MFA. Print them or store them in a sealed envelope / offline password manager vault that is not the same laptop that holds day-to-day passwords. Do not paste recovery codes into Slack, a shared Google Doc titled “passwords,” or a screenshot album on a phone that also receives SMS codes.
Rules that keep recovery honest:
One sealed copy for the primary owner; one for a named backup (owner or trusted officer).
Note the date codes were generated; regenerate after a staff change.
Never email recovery codes “just in case.”
Step 4: Kill shared passwords and orphan admin seats
Shared info@ / admin@ logins with one password everyone knows defeat MFA the moment someone leaves with the authenticator phone. Prefer:
Named user accounts with admin roles (Juan, Maria) instead of a single shared superuser.
Role cleanup — Remove former contractors, agencies, and “temporary” admins from hosting, CMS, Workspace/365, and registrar contacts.
Unique passwords in a business password manager; MFA on the password manager itself.
App passwords / API tokens inventoried and revoked when people leave.
If you must keep a break-glass shared account, put its MFA on a hardware key in a locked drawer and log every use.
Step 5: Quarterly access review (30 minutes on the calendar)
Put a recurring 30-minute review on the calendar four times a year:
Open the inventory sheet.
Confirm every high-risk service still has MFA on and recovery codes exist.
Remove people who no longer need Owner / Administrator.
Check registrar lock, correct abuse/tech contacts, and that renewal email goes to a monitored mailbox—not a departed employee.
Spot-check that CMS and email admin lists match today’s team.
Write the date and reviewer name on the sheet. Infrastructure that is never reviewed drifts.
A short MFA enablement checklist
Registrar, DNS, hosting, CMS, email admin, and CDN/edge logins are rows in one sheet
MFA enabled on each; authenticator app preferred over SMS
Recovery codes printed or stored offline for primary and backup owners
Shared passwords removed or break-glass controlled; former staff roles revoked
Next quarterly access review scheduled with a named owner
How TwoQM thinks about admin MFA
Domains, hosting, and email admin are the keys to your public presence. Passwords alone are not enough for those keys in 2026. Spend an afternoon on inventory, MFA, recovery codes, and role cleanup, and you sharply cut the odds that one phished login becomes a weekend outage and reputation mess.
If you want a second set of eyes on panels that still lack MFA—or help documenting owners without rebuilding your stack—TwoQM can walk the checklist with you and leave a living ops sheet, not a one-off lecture.