Start with the accounts that can change your website
Multifactor authentication, or MFA, asks for another form of verification in addition to a password. It makes a stolen password less useful, although it cannot prevent every type of account takeover. For a small organization, the first task is to identify the accounts that could change the website, interrupt service or expose visitor information.
Make a short inventory of your domain registrar, web host, content management system, email provider, analytics tools and any service used to manage backups or site forms. Include accounts held by staff and outside contractors. A community group, for example, might have a volunteer who edits pages, a web agency with hosting access and a director who owns the domain registration. All three roles matter, but they may not need the same permissions.
Choose an MFA method you can support
Check the security settings of each service to see which methods it offers. Where available, a passkey or physical security key can provide strong protection against fake sign-in pages. An authenticator app that generates one-time codes is another common option. Text-message codes are generally better than using a password alone, but phone numbers can be lost or transferred, and messages may not arrive when needed. Choose the strongest practical method that the people responsible for the account can use reliably.
Avoid treating a shared phone as the default solution for a shared account. If a service supports individual user accounts, give each person their own login and enable MFA separately. This makes it easier to remove access when a volunteer leaves without disrupting everyone else. If several people must administer an important service, confirm that more than one authorized person can sign in through their own account.
Enable MFA one account at a time
Begin with the account used to manage your domain, then work through hosting, website administration and connected services. Sign in by opening the service directly rather than following an unexpected email link. Find its account security settings, select the MFA method and follow the on-screen enrollment steps. An authenticator app usually requires you to scan a setup code and enter a generated code to confirm it works. A security key or passkey may instead prompt you to approve a registration on your device.
Before moving on, sign out and test a fresh sign-in. Check that the password and second step both work on the device you expect to use. If the service has separate administrator accounts, repeat the process for each one; enabling MFA on an owner account may not automatically protect other users. Record completion in your account inventory, but never record one-time codes or private setup secrets there.
Prepare for lost devices and staff changes
MFA protects access only if authorized people can still recover it when a phone is replaced or a key goes missing. Save any recovery codes provided during setup in a secure location separate from the device used for sign-in, such as an organization-managed password manager. Treat those codes like passwords: limit who can see them, and replace them if you suspect they have been exposed. Add a second security key or other supported backup method where appropriate, and confirm that recovery email addresses belong to the organization rather than a departing staff member.
Write down a simple recovery workflow: who owns each service, where recovery material is kept and who can approve its use. For example, a small charity might give two named administrators separate hosting accounts while storing recovery codes in a restricted password-manager vault. When someone changes roles, remove their access, review recovery options and check whether any shared credentials need to be changed.
Keep the protection working
Review the account inventory whenever you add a website tool or change providers. Periodically check which users still have access and whether MFA remains enabled for administrative accounts. Some services allow exceptions for older connections or application-specific passwords; review these carefully because they may not use the same sign-in protections. Keep devices and browsers updated, and use unique passwords stored in a password manager.
Finally, remind your team that MFA prompts deserve attention. If someone receives an approval request they did not initiate, they should deny it and investigate the account rather than approving it to make the notification disappear. MFA works best as part of a routine: clear ownership, limited access, tested recovery and a habit of questioning unexpected sign-in requests.
