Multifactor authentication with two devices.

Protect accounts with multifactor authentication

Cybersecurity Starter Kit: Section 3

In this section, you’ll learn to:

Understand how multifactor authentication (MFA) protects your accounts.
Explore different MFA methods and choose the right ones for your organization.
Set up secure account recovery and recognize suspicious sign-in requests.

Your nonprofit’s accounts connect people to email, files, finances and essential services.

Protecting those accounts helps protect everything accessible through them.
A strong, unique password is an important safeguard. Multifactor authentication, or MFA, adds another check to confirm that the person signing in is authorized. It can make a stolen password much less useful to someone trying to access your account.

What is MFA?

MFA requires two or more different types of proof when you sign in:

Something you know

A password or PIN

Something you are

A fingerprint or facial recognition used to unlock an authenticator

Something you have

A registered phone, authenticator app or security key

For example, you might enter your password and then enter a code generated by an authenticator app on your phone. You may also see the term two-factor authentication, or 2FA. This is MFA using two types of proof. A password followed by a security question does not provide the same protection: both rely on something you know.

What does it look like in practice?

A staff member signs in to the organization’s email account. After entering their password, they are asked to confirm the sign-in through an authenticator app.
Someone who obtains that password would usually need the additional authentication step to gain access.
MFA strengthens account protection, but some methods can still be defeated by phishing or by tricking someone into approving a request. Keep verifying unusual requests even when MFA is enabled.

Understand your options

The choices available depend on the service and your account settings.

Text message or phone call

A code is sent to a registered phone number.

Provides added protection over a password alone, but is vulnerable to interception and phone-number takeover.

Authenticator app codes

An app generates short-lived codes that you enter when signing in.

Does not depend on receiving a text message. Codes can still be captured through a fake sign-in page.

Authenticator approval prompts

An app asks you to approve a sign-in, sometimes by matching a number.

Number matching is preferable to a simple approve/deny prompt. Approve only sign-ins you initiated.

FIDO security keys or passkeys

A registered security key or a passkey on a device verifies the sign-in with the service.

Designed to resist phishing during sign-in. Account security still depends on device protection, recovery arrangements and any other sign-in methods that remain enabled.

What does “phishing-resistant” mean?

Passkeys are tied to the service they were created for, which helps prevent a fake website from capturing credentials that can be reused on the real site. This is a specific protection for the sign-in process.
It does not prevent someone from being persuaded to send money, disclose information or grant access after signing in. A compromised device, stolen signed-in session or weaker account recovery method can also undermine account security.
Where available and practical, phishing-resistant methods can strengthen sign-in protection. If they are not currently practical, use an available MFA method while planning improvements.
A note about passkeys: A passkey can replace a password. A device PIN, fingerprint or facial recognition may authorize its use; those checks are not themselves the passkey. Before adopting passkeys, confirm where they are stored, whether they sync across devices and how your organization would recover access if a device were lost or a staff member left.

Start with your most important accounts

Use the inventory from Section 1 to decide where to begin. Prioritize:

Email, because it often receives password-reset messages for other accounts.
Administrator accounts, which can change settings and grant access.
Banking, payroll and payment services.
Cloud storage and systems holding sensitive information.
Website, social media and fundraising accounts that could be used to impersonate your organization.
Check each person’s account. MFA enabled for one administrator does not mean it is enabled for everyone.
Where a service allows it, require MFA through organization-wide settings rather than relying only on individual users to turn it on.

Set it up with recovery in mind

Before enabling MFA, agree who will coordinate the change and help people who encounter difficulties.

Open the service directly.

Use its official website or app and find the account security settings.

Choose an appropriate method.

Consider the account’s importance, available options and the person’s access needs.

Register the method and test it.

Confirm that the person can complete a sign-in successfully.

Establish a recovery route.

Depending on the service, this could involve recovery codes, a second registered authenticator or an authorized administrator who can reset MFA. Protect these recovery routes because they can also provide access to the account.

Record the arrangement.

Note which methods are enabled, who manages recovery and where recovery information is securely stored. Keep the actual codes out of general worksheets.

Make it workable for staff and volunteers

Discuss practical needs before choosing a method.

Does someone lack a smartphone? Are personal phones used for work? Will people need access while travelling or without cellular service? Are there accessibility barriers?

Consider supported alternatives, such as a security key, and confirm any costs before adopting them. Many services include MFA, but some methods or organization-wide management features may depend on the plan.

For team access, use individual accounts with appropriate permissions wherever possible. Avoid arrangements in which several people depend on one person to forward codes or approve their sign-ins.

If using passkeys, agree whether they may be stored in personal accounts or must be managed through an organization-approved service. Ensure the arrangement supports access removal and continuity when someone leaves.

Know what to do with an unexpected request

Only approve authentication requests for a sign-in you initiated. If you did not start it, do not approve it—even if requests keep arriving or someone claiming to be support asks you to accept.

If you receive an unexpected prompt or code:

Deny the request where possible.

Report it promptly to your designated contact.

Open the service directly to review account activity, with help if needed.

Follow your organization’s response process to secure the account.

An unexpected request does not automatically mean someone has accessed the account, but it deserves attention.
Never give a sign-in code or recovery code to someone who calls, emails or messages you. Enter a code only in the legitimate sign-in process you initiated.

Plan for new phones and departing staff

When someone changes phones, confirm that the new authentication method works before removing the old one.
When someone leaves, transfer necessary organizational information and responsibilities, remove their access and update authentication or recovery arrangements they controlled. For shared organizational accounts, confirm that the departing person can no longer authenticate or recover access. This includes removing their registered passkeys or security keys where applicable.
Keep a backup route for critical administrator access so the organization can recover without relying on one person.

A suggested policy rule

MFA must be enabled for organizational accounts wherever supported, prioritizing email, administrator access, financial services and sensitive information. Approved authentication methods and recovery arrangements must be documented and protected. Users must not share sign-in codes or approve requests they did not initiate. Exceptions require approval, protective measures and a review date.

Before adopting this rule, identify who approves methods, assists users and manages recovery.

Activity

Check your priority accounts

Record arrangements, not passwords or recovery codes. Include alternative sign-in and recovery methods so you can assess the account’s overall protection.

If MFA is unavailable, document the limitation and decide what additional safeguards or alternative service should be considered.

Download worksheet here

Your takeaway

By the end of this section, you should have:

Checked MFA coverage for your priority accounts.
Chosen appropriate methods and identified practical barriers.
Established protected recovery arrangements and backup responsibility.
Explained how to handle unexpected authentication requests.
Understood that stronger sign-in protection works alongside other security practices.

Next, you will look at password managers and how to manage unique passwords and organizational access.

Section 4: Make passwords manageable

Nonprofits need strong, unique passwords and effective account access management to keep information secure and ensure continuity when staff are away or leave.