The first sign that passwords have failed is usually not a breach notification. It is a quiet login from a city where nobody works, a mailbox rule that forwards invoices to an attacker, or a help desk ticket from an employee who swears they never approved the sign-in. For small businesses, the painful part is that the attack often looks boring: a convincing phishing page, a reused password, a push notification approved in a hurry, and suddenly the attacker is inside email, payroll, cloud storage, or the admin console.
Passkeys and FIDO2 security keys change the shape of that problem. Instead of asking users to type a secret into whatever page looks legitimate, FIDO authentication binds the login to the real domain using public key cryptography. If an employee is tricked into visiting a fake login page, the passkey will not authenticate to that fake origin. That is why CISA continues to describe FIDO/WebAuthn as the practical path toward phishing-resistant MFA for most organizations.
What Passkeys Actually Fix
A passkey is not just a stronger password. It replaces shared secrets with a key pair. The private key stays on the user’s device or hardware key. The service stores the public key. During sign-in, the service asks the authenticator to sign a challenge for that specific website or app. There is no password to reuse, no one-time code to paste into a phishing kit, and no push prompt for an attacker to spam until the user gives up.
That does not mean passkeys solve every identity problem. A stolen unlocked laptop, a compromised session cookie, overprivileged admin accounts, and weak recovery workflows can still hurt you. The goal is to remove the most common initial access path while tightening the parts around it.
Start With The Accounts That Matter Most
Do not begin with every employee and every app. Start with accounts that can cause business damage if compromised: email administrators, accounting, payroll, domain registrar access, cloud root accounts, source control owners, and password manager admins. These users should have phishing-resistant MFA before the rest of the company.
# Priority group for a first passkey rollout 1. Global admins and identity admins 2. Finance, payroll, and executive assistants 3. Domain registrar and DNS administrators 4. Cloud platform owners 5. Source control and CI/CD maintainers 6. Password manager administrators 7. Everyone else
For a ten-person company, that priority group may be three people. For a two-hundred-person company, it may be twenty. Keep the first wave small enough that support can watch every enrollment and fix problems the same day.
Choose The Right Authenticator Mix
Small teams usually need two authenticator types. Platform passkeys are built into phones and laptops, such as Windows Hello, Apple passkeys, Android passkeys, or browser-synced passkeys. Hardware security keys are external devices that work across many services and are excellent for admins, emergency access, and shared break-glass procedures.
A workable policy is simple: employees may use platform passkeys for daily work, but privileged users must register at least two authenticators, one platform passkey and one hardware key stored separately. Break-glass accounts should use hardware keys, long random passwords stored offline, and strict monitoring.
# Minimum enrollment policy - Standard users: 1 platform passkey + 1 backup method - Privileged users: 1 platform passkey + 2 hardware keys - Break-glass accounts: hardware key only, no daily use - Contractors: passkey required, account expires automatically - Shared accounts: eliminate where possible; otherwise isolate and monitor
Run A Pilot That Finds Operational Problems
A passkey pilot should test normal work, not just successful enrollment. Ask the pilot group to sign in from their usual device, a new device, a phone, a browser profile, a VPN workflow, and any SaaS app that uses single sign-on. Document every place where the login falls back to a weaker method. Attackers love fallback paths because security teams forget to harden them.
Track four things during the pilot: enrollment success rate, failed login reasons, recovery requests, and apps that do not support your desired MFA policy. The pilot is successful when users can work normally and the admin team knows exactly how recovery works.
Recovery Is The Real Security Control
The most dangerous passkey rollout mistake is leaving account recovery weaker than login. If an attacker can call support and convince someone to reset MFA, the cryptography does not matter. Recovery should require identity verification, manager approval for privileged users, a ticket trail, and a temporary access window.
Recovery checklist for lost device requests: [ ] Confirm the request through a known channel, not the email being recovered [ ] Verify the user's manager or owner approval [ ] Revoke old sessions before adding a new authenticator [ ] Add the new authenticator with a short-lived temporary access method [ ] Review sign-ins for the previous 24 hours [ ] Close the ticket with exact actions taken
A 30-Day Rollout Plan
Week one is inventory. List identity providers, SaaS apps, admin accounts, recovery methods, and users who cannot use a normal device. Week two is the pilot. Enroll the priority group, test recovery, and tune conditional access rules. Week three is privileged enforcement. Require phishing-resistant MFA for admins, finance, DNS, cloud, and source control. Week four is broader rollout. Move remaining users in batches, publish a short support guide, and report adoption weekly.
Do not wait for perfect coverage before enforcing protection on privileged accounts. It is better to have strong controls on the accounts that can destroy the company than weak controls everywhere.
What To Monitor After Rollout
After passkeys are live, monitor for fallback use, new authenticator registration, session token theft indicators, impossible travel, OAuth consent grants, and admin role changes. Passkeys reduce credential phishing, but attackers may shift to stealing sessions or abusing OAuth permissions.
Example detection ideas: - Alert when a privileged user registers a new authenticator - Alert when password-only login succeeds for any admin - Alert when a user grants a high-risk OAuth app - Alert on sign-ins from unmanaged devices to admin portals - Alert when break-glass accounts are used at all
Further Reading
Useful official references include CISA’s guidance on phishing-resistant MFA, CISA’s FIDO implementation success story, and FIDO Alliance documentation on WebAuthn and passkeys. Use them to align your internal rollout plan with widely accepted identity security practice.