Start with the accounts that can reset the others
Your WordPress login has 2FA enabled. Good. But which inbox receives its password-reset emails, and who controls the hosting account?
A website depends on more than one login. Before choosing another security plugin, map the accounts that can change the site or recover access to it. For a small business, that usually means:
- Business email: the mailboxes and identity provider used for sign-in and recovery.
- Domain and DNS: the services that control where your website and email traffic go.
- Hosting and backups: access to website files, databases and recovery copies.
- WordPress: administrator accounts and any other accounts with sensitive permissions.
Start with the accounts that have the most control, then extend protection to the rest. CISA recommends prioritising administrative access when introducing multifactor authentication (MFA) across a business.
Choose a method your team can use reliably
Two-factor authentication (2FA) requires two different kinds of proof. A password plus a code from an authenticator app is a familiar example. A stolen password alone is then insufficient to complete that sign-in.
Where the service supports them, prefer phishing-resistant options such as FIDO security keys or passkeys. They bind authentication to the genuine service, making a fake login page much less useful to an attacker. A passkey may replace the password step entirely; follow the provider’s setup instructions.
An authenticator app that generates one-time codes is a practical alternative, but those codes can still be captured by a phishing site. SMS is a fallback when stronger options are unavailable. NIST explains these differences and why the choice of method matters.
For a self-hosted WordPress site, check how 2FA is provided and enforced by your authentication plugin or sign-in integration. Check every relevant login route, including any custom login page. The WordPress authentication guide is a useful starting point, but the exact setup depends on your site.
Plan for a lost phone before it happens
A useful test is simple: the person who normally signs in is away, and their phone is unavailable. Can an authorised colleague still manage the website without sharing that person’s login?
Where supported, register a backup authenticator and store recovery codes in an approved secure vault with restricted access. Make sure the recovery route is accessible if the primary sign-in method fails. Codes stored only inside the locked account cannot help you recover it.
Record who owns recovery and how to contact the provider. Keep the actual codes out of ordinary documents, email threads and support tickets. OWASP’s recovery guidance explains why account recovery needs protection too.
Check access before making 2FA compulsory
Use an authorised test account to check the full process before enforcing it across the team. A successful setup screen is only the beginning.
- Sign in again. Use a separate browser session to confirm the expected second factor is required. Keep a known working admin session available during the test.
- Check recovery. Follow the provider’s documented process. If you use a single-use recovery code, mark it as consumed and securely retain any replacement set.
- Check the team. Give each person their own account and only the permissions their work needs. Confirm another authorised owner has an appropriate way to act when the usual administrator is unavailable.
- Check connected tools. API tokens and application passwords may authenticate without an interactive 2FA prompt. Review their permissions, storage and revocation separately.
Revisit access when someone leaves or changes role. Remove access they no longer need, and review active sessions and credentials belonging to their work.
One useful next step
List the four account groups above. For each, record the responsible person, the sign-in method and the recovery owner. Leave passwords and recovery codes out of the list. Any blank entry gives you a concrete place to start.
2FA reduces account risk. It does not replace updates, sensible permissions or tested backups. Those belong in the same website care routine.
Protecting access is a separate job from checking incoming enquiries. For the latter, read our note on email verification and contact-form spam.