Protect website admin accounts with MFA and a recovery plan that survives device loss

Map the accounts that can control the website

List the CMS administrator, hosting panel, domain registrar, DNS provider, deployment account and the mailbox used for recovery. Depending on the setup, a password manager or identity provider may control several of those accounts. An attacker need not use the CMS login if another account can replace the site or its recovery email.

For each service, record the official sign-in address, owner, role, supported authentication methods, recovery procedure and access-removal process. Do not put passwords, authenticator seeds, recovery codes or session-bearing links in this inventory.

Start with accounts that can change ownership, reset other accounts or alter DNS and production content. This is an access map, not a security certification. Protecting one WordPress user does not automatically enable MFA on the hosting or registrar accounts.

Understand passkey storage before relying on it

The FIDO Alliance’s passkey explanation distinguishes synced credentials from device-bound passkeys. A synced passkey may become available through the same passkey-provider account on another compatible device. A device-bound credential stays with its device or security key.

Neither label proves that your replacement-device plan is ready. Check the actual service, operating system, passkey provider and supported sign-in path. A biometric gesture may unlock a credential locally; it is not a transferable copy of the account’s recovery material.

For a fictional site owner with one laptop and phone, losing the phone should not also remove the only way to sign in to the password manager and retrieve all recovery instructions. Consider a supported additional enrolled method or separately protected recovery material. Two credentials synchronized through the same inaccessible account can share a failure dependency.

Check the implementation and account scope

Find the provider’s documented MFA settings and supported recovery process for the specific service. WordPress.org community accounts, WordPress.com accounts and users of an independently hosted WordPress website are distinct accounts; enabling protection on one does not configure the others.

The Two Factor plugin’s official directory entry is one example of an implementation that requires each site user to configure their own methods. It is not a requirement to install that plugin or proof that it fits an existing login integration.

On an existing website, identify any security plugin, single sign-on service, custom login or host policy already in use. Confirm method compatibility, roles covered and the official lockout procedure before changing enforcement. Test a protected copy or a limited authorized account first when that can establish compatibility without risking all administrators.

Plan recovery that survives a realistic loss

Write a short scenario: “My phone is unavailable, the laptop has restarted, and I need to access the registrar.” Work through which verified recovery method remains available. Then consider losing the laptop instead. The purpose is to uncover circular dependencies before an emergency.

OWASP’s MFA guidance treats recovery as a security-sensitive process and discusses additional enrolled methods, recovery codes and verified support routes. The appropriate arrangement depends on the service and risk; a weak fallback can undermine a strong primary method.

Use documented recovery options, keep the recovery mailbox controlled and current, and identify who can legitimately request help. Do not rely on a colleague knowing a shared administrator password or assume support will waive MFA because you can describe the website.

If storing recovery material in an encrypted password manager, verify access to that manager under the same loss scenario. A secured offline copy or separately held supported credential may reduce a shared failure, but its physical protection and authorized ownership still require care.

Handle recovery codes as secrets

Generate codes only through the service’s official settings when the account owner is ready to store them securely. Never paste them into chat, email, a support ticket, source control or a public screenshot. Document where authorized recovery material is kept without recording the material itself in the inventory.

Google’s backup-code documentation provides a concrete example: a used code becomes inactive, and generating a new set invalidates the old set. Exact formats, counts and availability vary across services; those details should not be generalized to every website.

GitHub’s recovery guidance similarly recommends securely stored recovery codes and additional authentication methods. Replace obsolete stored copies after regeneration. If a code is intentionally consumed during an authorized recovery rehearsal, record that it was used and follow the provider’s replenishment process.

Replace devices and factors deliberately

Before wiping or trading a phone, follow the authenticator or passkey provider’s supported transfer/recovery process and verify access on the replacement. Installing an authenticator app again does not by itself prove the original accounts or secrets were restored.

Factor changes deserve the same care as enrollment. Confirm the official service, reauthenticate as required and inspect change notifications. Keep the old authorized method until the new one is verified, then revoke the retired device or credential through the supported settings.

If a device was stolen or a factor changed unexpectedly, treat that as a possible incident. Use a known official recovery route, review active sessions and recent account changes, and revoke affected access. Do not approve an unsolicited push or disclose a current code to someone claiming to be support.

Keep administrator roles, sessions and integrations separate

WordPress roles and capabilities control what a user can do; MFA strengthens authentication but does not reduce an unnecessarily broad administrator role. Give collaborators individual accounts and the access their tasks actually require.

OWASP’s session guidance distinguishes authenticated sessions from the sign-in event. Enabling MFA is not a substitute for revoking stolen or obsolete sessions, and closing a browser alone is not proof of server-side logout.

Automation can have separate credentials. WordPress application passwords are individually revocable credentials for programmatic access, not interactive browser-login passwords. Inventory permitted integrations and revoke retired ones deliberately; do not assume a browser MFA prompt automatically protects every API authentication path.

Make offboarding and emergency access accountable

Before a contractor leaves, transfer legitimate ownership, confirm the remaining owner’s recovery access and preserve required content. Remove the departing person’s roles, sessions, enrolled credentials and integration access through the appropriate services. Changing one shared password is not a complete handover.

Use our temporary access guide for WordPress collaboration and the email administration recovery guide for the mailbox dependency. If a formal emergency account is required, define who controls it, when it may be used and how use is reviewed; do not leave a hidden permanent MFA exception.

Revisit the inventory after device, phone-number, personnel or provider changes. A useful plan records who can recover access and how that was checked. It reduces avoidable lockouts while retaining accountability; it does not guarantee immunity from compromised devices, sessions or application vulnerabilities.