Why phishing-resistant MFA matters
Multifactor authentication is an essential control for business accounts, but not every MFA method provides the same protection. SMS codes, email codes and one-time passwords can often be entered into a convincing phishing site. Push approvals can also be abused through social engineering or repeated approval prompts.
Phishing-resistant MFA uses cryptographic authentication that is bound to the legitimate website or application. The authenticator does not simply provide a reusable code. Instead, it proves possession of a private key in response to a challenge from the correct service. As a result, a passkey or FIDO2 security key should not authenticate to an attacker’s look-alike domain. NIST describes WebAuthn and FIDO2 as examples of authentication with verifier-name binding. See the NIST Digital Identity Guidelines for the technical definition.
For a small business, the goal is not to eliminate every other authentication method immediately. The practical goal is to protect the accounts that would cause the most damage if compromised, establish a reliable recovery process, and then expand the stronger method across the organization.
Passkeys, security keys and platform authenticators
Passkeys
A passkey is a FIDO credential based on public-key cryptography. During registration, the device or authenticator creates a key pair. The service stores the public key, while the private key remains protected by the authenticator. At sign-in, the authenticator signs a service-specific challenge after the user unlocks it with a device PIN, fingerprint, face recognition or another local gesture.
Passkeys can be device-bound or synced. A device-bound passkey remains on a particular computer, phone or physical security key. A synced passkey is protected by a passkey manager and made available on multiple devices belonging to the same user. Synced passkeys can simplify replacement and cross-device access, while device-bound credentials provide tighter control over where the credential exists.
Microsoft explains the distinction and lists synced passkeys, Microsoft Authenticator passkeys, Windows Hello and FIDO2 security keys among its phishing-resistant authentication options in its passkey documentation. NIST also publishes guidance on incorporating syncable authenticators into enterprise authentication.
FIDO2 security keys
A FIDO2 security key is a physical authenticator that stores a device-bound passkey. Depending on the model, it may connect through USB-A, USB-C, NFC or Bluetooth. The employee usually inserts, taps or pairs the key and then touches it or enters a key PIN.
Security keys are particularly useful for administrators, finance staff, executives, help-desk personnel and employees who access sensitive systems from unmanaged or shared computers. They also provide a clear ownership model: the company can issue two registered keys, record their serial numbers, and recover an account by disabling a lost key and registering its replacement.
A security key is not automatically the right choice for every employee. It adds procurement, distribution and replacement work. Users may also forget the key, lose it or encounter compatibility issues with older devices. Microsoft’s guidance notes that physical FIDO2 keys are well suited to highly regulated environments and elevated-privilege users, while other users may use platform or synced passkeys.
Platform authenticators
A platform authenticator is built into a device or operating system. Examples include Windows Hello, Touch ID, Face ID and Android device authentication when supported by the identity provider. The device’s PIN or biometric unlocks the credential locally; the biometric itself is generally not sent to the service.
Platform authenticators are convenient because employees already have the required hardware. Their main operational limitation is device dependency. If a user loses a laptop or replaces a phone, the business needs a second registered authenticator or a documented account-recovery process.
Decision matrix for a small business
| Option | Best fit | Advantages | Trade-offs |
|---|---|---|---|
| Synced passkey | Most employees using managed or trusted personal devices | Convenient, supports multiple devices, reduces password use | Requires clear device and account ownership policies |
| Device-bound platform passkey | Employees with company-managed laptops or phones | Fast sign-in and no separate token to carry | Recovery depends on another registered device or admin process |
| FIDO2 security key | Administrators, executives, finance and high-risk users | Strong phishing resistance, portable and easy to revoke | Procurement, distribution, loss and replacement management |
| Authenticator app with number matching | Temporary transition for users not ready for passkeys | Better than SMS or simple push approval | Still exposed to some social-engineering and relay attacks |
| SMS, email or OTP | Fallback only when stronger options are unavailable | Broad compatibility | More vulnerable to phishing, interception, replay or account-recovery abuse |
CISA recommends that businesses use phishing-resistant MFA where possible and identifies physical security keys as one of the strongest practical options. Its small-business MFA guidance is available at CISA.gov.
Recommended policy for a small business
A balanced policy usually has three levels:
- Privileged accounts: Require two phishing-resistant authenticators, preferably two FIDO2 security keys or one security key plus a platform passkey. Do not allow SMS as the normal recovery method.
- Sensitive roles: Require a passkey or security key for owners, finance staff, payroll users, customer-data administrators, IT staff and anyone able to approve payments or change security settings.
- General users: Require a passkey where the identity provider and devices support it. Permit an authenticator app as a transitional method, but set a target date for moving away from phishable methods.
Maintain at least two registered authentication methods for each important account. For a security-key deployment, issue two keys per high-risk user: one for daily use and one stored securely as a spare. Do not leave the spare plugged into a computer or stored in the same laptop bag as the primary key.
Step-by-step deployment plan
1. Inventory accounts and applications
List your identity provider, email platform, file storage, accounting software, password manager, remote-access tools, code repositories and customer-facing administrative consoles. Identify which services support WebAuthn, passkeys, FIDO2 security keys or security policies that require phishing-resistant authentication.
Classify accounts by impact rather than by department. A regular employee account may be important, but a global administrator, mailbox administrator or payroll account can expose the whole business. Include shared accounts in the review; where possible, replace them with named users and delegated access.
2. Choose the identity-provider policy
Centralize authentication where practical. For Microsoft 365, review Microsoft Entra ID authentication methods and Conditional Access capabilities before purchasing keys. Microsoft states that a Microsoft Entra ID P1 license is recommended for the full set of passwordless deployment capabilities, including Conditional Access enforcement and authentication-method reporting. Verify current licensing in your tenant before finalizing the design.
For Microsoft Entra ID, begin with Microsoft’s phishing-resistant passwordless deployment planning guide and passkey enablement documentation. Configuration names and licensing may change, so use the current admin-center documentation during implementation.
3. Select compatible authenticators
Document the ports, browsers, operating systems and mobile devices employees actually use. A USB-C-only key may not work for staff with older laptops. NFC may be useful for phones, but it should be tested rather than assumed. If you need attestation or an approved-device list, confirm that your identity provider supports the required authenticator metadata and that the selected key models are eligible.
Buy from an authorized source and maintain an asset record containing the model, serial number, assigned user, registration date and disposal status. Do not record private keys, recovery codes or security-key PINs in the inventory.
4. Prepare enrollment and recovery
Enrollment should require an existing trusted sign-in or an in-person identity check. For Microsoft Entra ID, users may need to complete MFA before registering a new passkey. The enrollment instructions should tell users how to name the credential, where to store the spare key and whom to contact if the key is lost.
Write the recovery procedure before the first rollout. It should answer five questions:
- How does the employee report a lost or stolen authenticator?
- Who verifies the employee’s identity?
- Who disables the old credential?
- How is a replacement credential registered?
- How are emergency administrator accounts protected and audited?
Do not make account recovery weaker than normal sign-in. An attacker who controls an employee’s email or phone may try to use the recovery process to bypass strong MFA. CISA specifically warns that recovery paths can undermine MFA when they are not handled securely.
5. Pilot with high-value users
Start with the business owner, one administrator, one finance user and a small group of technically confident employees. Test sign-in from the supported browsers, mobile devices, remote locations and common SaaS applications. Test lost-key replacement, new-device enrollment, password reset and emergency administrator access.
Record issues in a short runbook. Common problems include registering a passkey in the wrong account, using a browser profile with a different identity, losing access to a device-bound credential, or discovering that a legacy application does not support the selected authentication method.
6. Roll out in groups
Enroll the remaining staff in small groups. Give each employee a concise procedure with screenshots, a support contact and a clear deadline. Explain that a passkey or security key is not a code to read to someone over the phone. Support staff should never ask users to disclose a security-key PIN or recovery secret.
During the transition, keep a monitored fallback method only where necessary. Set an expiration date for exceptions and review every exception individually. A permanent exception usually becomes the weakest account in the environment.
7. Enforce and monitor
After enrollment reaches an acceptable level, enforce phishing-resistant authentication for administrators first, then for sensitive groups and eventually for the wider organization. Monitor authentication logs, registration reports, failed sign-ins, new authenticator registrations and changes to security policies.
Microsoft’s identity protection guidance recommends protecting privileged accounts with phishing-resistant methods and applying policy controls that require them. Keep at least two emergency access accounts for a cloud identity environment where appropriate, protect them with separate procedures, and test access without routinely using those accounts.
Recovery and offboarding procedures
Lost or stolen key
Disable the credential as soon as the loss is reported. If the key may have been exposed along with its PIN, treat it as compromised. Issue the spare or replacement key, verify the employee’s identity through an independent channel, and record the incident.
Employee departure
Disable the user account, revoke active sessions where supported, remove registered passkeys and security keys, transfer business data according to policy, and recover company-owned hardware. Remove the user from administrative roles and application groups. A physical key should be returned, destroyed or securely reassigned only after its credentials have been removed.
Device replacement
Require employees to register the new device before wiping the old one when possible. For device-bound passkeys, confirm that another authenticator is available first. Never rely on a single laptop or phone as the only route into an administrator account.
Rollout checklist
- Inventory identity systems, SaaS applications and privileged accounts.
- Classify users by business impact and recovery risk.
- Confirm passkey and FIDO2 support for the applications employees use.
- Choose synced passkeys, platform authenticators, security keys or a combination.
- Issue two authenticators to administrators and other high-risk users.
- Document enrollment, lost-device, lost-key and employee-offboarding procedures.
- Pilot with administrators and a small representative user group.
- Train employees not to approve unexpected prompts or disclose PINs and recovery secrets.
- Enforce phishing-resistant MFA for privileged accounts first.
- Track exceptions with an owner and expiration date.
- Review authentication logs and registration activity regularly.
- Test account recovery and emergency access at least periodically.
Bottom line
For most small businesses, the best design is not passkeys versus security keys. It is a tiered approach: platform or synced passkeys for everyday users, physical FIDO2 security keys for administrators and high-risk roles, and a tightly controlled fallback during migration. The technology provides the phishing resistance, but the deployment process determines whether the protection survives lost devices, employee turnover and account recovery.