Phishing-resistant MFA for a small business: a practical rollout guide

NIST distinguishes resistance to phishing from resistance to replay. A code that expires or works only once can still be entered into an impostor page and relayed immediately. This distinction matters when comparing an authenticator app that generates codes with an app that stores passkeys: the application label alone does not identify the protocol. See the technical definition in [NIST’s authenticator guidance](https://pages.nist.gov/800-63-4/sp800-63b.html).

A hardware key is likewise not automatically a complete MFA deployment. Decide whether the service requires a local PIN or biometric verification, or combines the key with another factor. Touching a key establishes user presence; do not assume that a touch alone establishes a second factor. Ask your administrator or provider to explain the enforced authentication flow in plain language.

Write a one-sentence target before buying equipment: named employees must use an approved phishing-resistant method to access the listed business accounts, with documented exceptions and recovery. For a small company, an explicit list of protected accounts is more useful than an undefined promise to make everything passwordless. Give one person responsibility for maintaining that list.

FIDO Alliance distinguishes credentials that synchronize through a provider from credentials bound to a particular device. Its enterprise guidance discusses hardware keys for shared-device scenarios and the need for backup when a key is lost. These are deployment choices, not a universal ranking that makes one format best for every employee. Review the [enterprise passkey paper](https://fidoalliance.org/white-paper-replacing-password-only-authentication-with-passkeys-in-the-enterprise/) before choosing your default.

Our suggested procurement exercise is deliberately small: borrow or obtain enough authenticators for a representative pilot, then test the exact laptops, phones, browsers and connectors employees use. Include a remote worker and anyone with accessibility requirements. Do not order for the entire business on the strength of a successful demonstration on the owner's computer.

For administrators, consider issuing a primary and separately stored spare hardware key under a documented custody process. For routine staff, assess whether an approved managed passkey provider fits existing device management. Ask who can recover the provider account, whether work credentials can enter personal accounts, and what happens when a contractor leaves. Count setup time, support time and replacement handling in the budget.

OWASP treats changing MFA factors as a sensitive operation and warns against weak recovery processes. Apply that principle to initial enrollment: do not accept an unsolicited message asking the help desk to attach a new key. Use a scheduled, verified onboarding process and document who approved the binding. Consult [OWASP’s MFA guidance](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) for the underlying lifecycle considerations.

Our suggested pilot group includes the business owner, the administrator and one employee with a different work pattern. Schedule a support window and explain the expected prompts beforehand. Ask each person to sign out and start a new session, rather than relying on an already authenticated browser. Register and test the approved backup before declaring the person ready.

Keep a short acceptance record for every application: the intended method succeeded, the backup succeeded, an unauthorized method failed after enforcement, and the recovery contact knew the procedure. If an application fails, record the precise limitation and a decision owner. A blocked pilot is useful evidence for a replacement or integration decision; it should not silently become a permanent exemption.

NIST’s assurance framework evaluates the authentication transaction, while FIDO’s higher-assurance guidance discusses organizational control over credential lifecycles. Neither buying a key nor selecting an assurance label establishes the security of an entire business environment. Use the [FIDO higher-assurance paper](https://fidoalliance.org/white-paper-high-assurance-enterprise-fido-authentication/) to structure questions about control, without claiming that your deployment has been independently assessed.

Our recommended application worksheet asks whether the app uses the central identity provider, whether a separate local password still works, whether administrators have a different login page, and whether an older mail client bypasses the intended flow. Ask the provider to identify the relevant controls and subscription requirements. Verify the answer in your own tenant; menus and available policies vary.

For unsupported services, keep the strongest available MFA while assigning an owner and review date to the limitation. Consider federation, restricted access or replacement according to business impact and verified capabilities. Do not disable a working protection while waiting for a future improvement. For an exception, state which users can use it, why it exists and what would allow its removal.

FIDO guidance notes that device-bound credentials need a recovery strategy and that synced credentials introduce dependence on the synchronization environment. OWASP recommends protecting factor replacement and recovery against account takeover. Read the [moderate-assurance deployment discussion](https://fidoalliance.org/white-paper-fido-authentication-for-moderate-assurance-use-cases/) alongside your provider’s recovery documentation, especially when choosing who can authorize a reset.

Our suggested lost-key procedure is: report through the established company channel; verify the employee using a prearranged process; use the separately registered backup if available; remove the missing credential from affected services; register and test its replacement; review recent account changes. A spare in the same laptop bag is a poor continuity choice for a bag-loss scenario. Store it somewhere separately accessible to its authorized custodian.

If takeover is suspected, ask the administrator to revoke active sessions where supported, examine sign-in records and newly registered factors, and investigate affected devices. Review mailbox forwarding, delegated access and relevant application permissions. If money or supplier details were involved, independently verify pending transactions using a known contact route. These are incident-response tasks, beyond simply issuing another key.

For ongoing operations, we recommend a recovery drill after rollout and after material changes to devices, administrators or the identity provider. Make offboarding a checklist item: disable access, revoke applicable credentials and sessions, recover company equipment, and confirm who retains custody of spare authenticators. Keep the runbook available outside the account it is intended to recover.