Multi-Factor Authentication for Small Business: Methods, Settings and Rollout

A stolen password is the most common way into a small organisation's email, files and finance systems. A second sign-in factor stops most of those attempts, but not all factors are equal. This guide to multi-factor authentication for small business ranks the methods by how well they resist phishing. It then sets out what Microsoft 365 and Google Workspace let an administrator enforce, on which licence, and in what order to roll it out.

It is the anchor page for the identity and access topic. Password length, expiry and blocklists are covered separately in the NIST password rules that are now prohibited. Everything here is desk research from published sources, as described on the methodology page.

What multi-factor authentication for small business has to stop

CISA's fact sheet on implementing phishing-resistant MFA names four attacks that get past weaker second factors. Each one targets a different method.

• Phishing. A fake sign-in page collects the password and the six-digit code, then replays both to the real site.
• Push bombing. The attacker sends repeated approval prompts "until they press the 'Accept' button".
• SS7 exploitation. Weaknesses in the phone network let an attacker read codes sent by text or voice.
• SIM swap. The attacker persuades a mobile carrier to move the victim's number to a SIM card they control.

The same fact sheet is clear that "any form of MFA is better than no MFA". It also calls phishing-resistant MFA "the gold standard" and asks organisations to make the move a high priority. The rest of this guide follows that order: switch something on now, then move towards the strongest methods.

CISA's page for small and mid-size businesses sets the scope. It asks for MFA "across systems like email, file storage and remote access". It says to start with "admin accounts and employees who handle sensitive data".

Sign-in methods ranked by phishing resistance

Three public bodies have published a ranking, and they agree on the order. CISA's fact sheet has a table from strongest to weakest. The UK NCSC's recommended types of MFA asks organisations to adopt methods "in the order presented". NIST's SP 800-63B-4 defines the line between them.

NIST's test is simple. Phishing resistance is "the ability of the authentication protocol to prevent the disclosure of authentication secrets". Any method where the user types or reads out a code fails that test, because the code can be relayed by a fake page.

CISA says the only widely available phishing-resistant option is FIDO/WebAuthn. Certificate-based smart cards also qualify, but CISA notes they need "highly mature identity management practices". That rules them out for most organisations of 10 to 250 people.

For anyone not ready for keys or passkeys, CISA names a fallback. App or token codes, or push with number matching, "are the best options for small- and medium-size business that cannot immediately implement phishing-resistant MFA".

Text and voice codes sit at the bottom of every list. CISA says they "should only be used as a last resort". The NCSC says message-based methods "are only likely to be appropriate when no other strengthening method is possible". NIST goes further and classes the phone network as a "restricted" authenticator, so a service must also offer an alternative and warn users of the risk.

Push bombing and the limits of number matching

CISA's second fact sheet, on number matching, describes the attack in detail. An attacker who already has the password can "generate hundreds of prompts" on the user's phone. The user then approves one "by accident or out of annoyance".

Number matching breaks that pattern. The sign-in screen shows a number, and the user has to type it into the app. Someone who did not start the sign-in cannot see the number, so repeated prompts become pointless.

Microsoft has made it compulsory in its Authenticator app. Its number matching page states that "Number matching is enabled for all Authenticator push notifications", and users cannot opt out. NIST now says plain approve-or-deny prompts are "no longer considered acceptable" because of fatigue attacks. It also asks services to limit how many push prompts they send.

Number matching is still not phishing-resistant. The NCSC says it "only provides partial phishing resistance". A convincing fake page can show the user the real number and pass the approval through.

Passkeys, security keys and Windows Hello for Business

These three are all built on the FIDO2 and WebAuthn standards. The FIDO Alliance describes a passkey as a credential "tied to a user's account on a website or application". Because the credential only answers the real site, a look-alike domain gets nothing it can reuse.

The practical difference is where the private key lives:

• Security keys are small USB or NFC devices. The key never leaves the hardware, which is why the NCSC gives the example of issuing one to every IT administrator for admin consoles.
• Device-bound passkeys stay on one device, such as a phone app or a security key.
• Synced passkeys are copied between a person's devices through a cloud account, such as Apple's or Google's password managers.
• Windows Hello for Business keeps a key on the laptop's security chip and unlocks it with a PIN or biometric. Microsoft's overview calls it "phish-resistant two-factor authentication" and notes the PIN "never leaves the device".

Synced passkeys carry one caveat. NIST allows them only up to its middle assurance level, AAL2, and says syncable authenticators "SHALL NOT be used at AAL3". It also asks that the cloud account holding the keys be protected to AAL2 itself. Microsoft says synced passkeys "do not support attestation", so the organisation cannot confirm what device holds them.

For most staff, a synced passkey is still a large step up from a code. For administrators, Microsoft's passkey guidance suggests a stricter profile: device-bound passkeys only, with attestation enforced. Windows Hello for Business needs Windows Pro, Enterprise or Education, according to the same Microsoft overview. Device enrolment and hardware standards are covered in the endpoint security guide.

What a Microsoft 365 tenant can enforce, by licence

Microsoft gives every tenant one of two control systems. Which one you use depends on your licence.

Security defaults are free and switched on for new tenants. They require every user to register for MFA, with no 14-day grace period since July 2024. They make admins complete MFA every time and block legacy sign-in protocols that cannot do MFA at all. Microsoft decides when ordinary users are prompted, "based on factors such as location, device, role, and task".

The limit is that security defaults are on or off, with nothing to tune. Users register the Microsoft Authenticator app with notifications, or a third-party code app. You cannot require passkeys for a group, exempt an account, or demand a stronger method for the finance system.

Conditional Access provides that control. Microsoft says it "requires Microsoft Entra ID P1 licenses", and that "Microsoft 365 Business Premium licenses can also use Conditional Access features". Risk-based policies, which react to suspicious sign-ins, need P2. Security defaults must be turned off before Conditional Access policies replace them.

The key Conditional Access tool for this topic is the authentication strength. The built-in "Phishing-resistant MFA strength" accepts only Windows Hello for Business, FIDO2 security keys and certificate-based sign-in. Text codes and Authenticator push do not satisfy it.

As of 14 Nov 2026, Microsoft's Entra pricing page lists P1 at $7.00 per user per month and P2 at $10.00, both "paid yearly" on an annual subscription. The Microsoft 365 Business Premium product page did not load when read, so its price is not given here.

Microsoft also enforces MFA itself on admin portals, whatever the tenant's settings. Its mandatory MFA page covers the Azure portal, Entra and Intune admin centres from October 2024 and the Microsoft 365 admin centre from February 2025. It applies to break-glass accounts too, and "There's no way to opt out."

What Google Workspace admins can enforce

Google's controls are simpler, and its pricing page lists 2-Step Verification in every Workspace plan. The deployment guide offers three allowed-method settings:

• Any. Users choose their own method, including text codes.
• Any except verification codes via text, phone call. This removes the weakest methods.
• Only security key. Google says this "now supports both security keys and passkeys as a 2SV method".

Two settings need care. The new-user enrolment period can run from one day to six months, and during it "users can sign in with just their passwords". Under Only security key, users "cannot generate their own backup verification codes", so an admin has to issue them.

Google is also enforcing 2SV on admin accounts, rolled out gradually. Its admin enforcement page says enforcement applies "immediately when a user is made an admin" and that affected admins "cannot bypass it". The only remedy for an admin who cannot enrol is to remove their admin rights.

Passkeys can replace the password too. The skip passwords setting lets users sign in with a passkey alone. Google notes it "doesn't deactivate or remove the user's existing password", so the password still needs the protections in the NIST rules.

As of 14 Nov 2026, Google's pricing page lists Business Starter at $7.00, Business Standard at $14.00 and Business Plus at $22 per user per month on an annual plan, in US dollars. Business plans are capped at 300 users. Context-aware access, Google's nearest match to Conditional Access, is listed under Enterprise. Google's current help pages do not say which editions can use the Only security key setting, so that is not stated here.

Where single sign-on and password managers fit

Single sign-on lets staff sign in once to the identity provider and reach other apps without a separate password. Microsoft's SSO overview puts the benefit plainly: "Admins control access from one identity provider." Apps connect through SAML or OpenID Connect.

For MFA, the point is reach. CISA notes that MFA "can often be added through integration with enterprise identity and single sign-on (SSO) systems". Every app behind SSO inherits the sign-in rules set in Entra ID or Google Workspace. Removing a leaver from the identity provider also cuts their access to those apps.

Some apps will never join SSO. For those, a password manager is the practical answer. The NCSC's buyers guide says password managers help staff use "unique passwords that are harder for an attacker to guess".

The same guide is realistic about the risk. Password managers "are a natural target", and "Multi-factor support should be used on all cloud-sync password managers." It does "not recommend sharing passwords between individuals", and warns that the vendor's recovery method "may be exploited". NIST also requires services to allow password managers, and recommends allowing pasting.

Recovery, lost phones and break-glass accounts

Most MFA problems in a small organisation are lost or replaced phones. NIST says services "SHOULD encourage subscribers to maintain at least two separate means of authentication". In practice, that means each person registers a second method, such as a passkey on a laptop plus the phone app.

NIST lists four acceptable recovery routes: saved recovery codes, issued recovery codes, recovery contacts and repeated identity checks. It also says any recovery "SHALL cause a notification to be sent". A help desk that resets MFA on a phone call alone is the weak point attackers look for.

The NCSC's anti-patterns page warns against accounts left outside MFA. It says "All user accounts with access to sensitive data should have MFA enforced". The one accepted exception is a closely monitored emergency, or break-glass, account.

Microsoft's guidance on emergency access accounts gives a concrete checklist:

1. Keep at least two, cloud-only, on the .onmicrosoft.com domain.
2. Protect them with a FIDO2 passkey or certificate, different from your normal admin method.
3. Exclude them from Conditional Access policies that block or restrict sign-in.
4. Store the keys in "secure, fireproof safes" in separate locations.
5. Alert on every sign-in, and check the accounts work at least every 90 days.

Losing all admin access is an incident in its own right. Write the break-glass steps into your incident response plan, and keep identity settings in mind when planning backup and recovery.

A rollout order for 10 to 250 people

CISA suggests phasing the move to phishing-resistant MFA. Start with services that already support FIDO, noting that "most hosted mail and SSO systems support FIDO". The first group should be help desk staff and IT administrators. The order below follows that advice.

1. Turn on a baseline today. On Microsoft 365 without P1, confirm security defaults are on. On Google Workspace, enforce 2SV with a short enrolment period.
2. Block legacy sign-in. Old mail protocols bypass MFA entirely. Security defaults do this, and Conditional Access has a policy for it.
3. Create the break-glass accounts. Do this before any strict policy, so a mistake cannot lock everyone out.
4. Move admins to keys or passkeys. In Entra, register device-bound keys with attestation, then require them with the phishing-resistant strength if you hold P1. In Google, apply Only security key to admin groups.
5. Extend to finance, HR and executives. CISA names HR staff and those with e-discovery rights as high-value targets.
6. Remove text and voice codes. In Google, choose "Any except verification codes via text, phone call". In Microsoft, disable those methods once everyone has an alternative.
7. Connect apps to SSO and issue a password manager. Bring each business app under the same sign-in rules.
8. Write the recovery process. Two methods per person, identity checks before any reset, and a notification on every recovery.

Mail protection sits alongside this work. A fake sign-in page usually arrives by email, which the business email security guide covers. To map these steps against a recognised standard, see the guide to security frameworks for small business.

What the sources leave open

The guidance agrees on the direction but leaves some decisions to each organisation. NIST is written for US federal systems, and the NCSC and CISA documents are guidance, not law. None sets a deadline for a small private firm.

Prices and features also move. The Microsoft and Google figures above were read on 14 Nov 2026 from the vendors' own pages. Check them again before buying, and check your own tenant's settings rather than relying on defaults described here.