Choosing and Deploying Hardware Security Keys for Business

Is a hardware security key worth the trouble, or will an authenticator app do? For the accounts that can do the most damage, the key is worth it. It is one of only two kinds of multi-factor authentication (MFA) that CISA counts as phishing resistant. The other is the PIV or CAC smart card that federal staff carry. Codes sent by text, voice calls, emailed links and simple approve-or-deny push prompts all fall outside CISA's definition in its phishing-resistant MFA fact sheet.

This page is for the security lead who has already decided to move the company off phishable MFA and now has to carry that decision through: which people get a physical key, what that costs per person, how to turn on enforcement without locking out the company on the first morning, and what policy has to exist before the first key is lost.

Most teams get one thing wrong. They treat the key as the project. According to the federal agencies that have done this at scale, the weak points are elsewhere: the recovery path people fall back on when a key goes missing, the logistics of getting keys into hands, and the login session a key produces. A key stops an attacker from stealing the login. It does not stop an attacker from stealing the session afterward.

A six-digit code is only a secret, and it works wherever it is typed. When a fake login page asks for it, the user types it, and the attacker's server passes it straight to the real site within seconds. That handoff is how adversary-in-the-middle (AiTM) phishing works. The attacker's proxy sits between the user and the real login page and relays everything in both directions.

A hardware key uses the FIDO2 standard. Its browser-side half is called WebAuthn, the web authentication interface that browsers and websites use to talk to the key. Instead of a shared secret, the key holds a private cryptographic key for each site and proves possession by signing a challenge. CISA's fact sheet explains that the signature is bound to the origin domain of the relying party, meaning the real website. A look-alike domain is a different origin, so the key produces nothing the attacker can replay on the real site. Think of a house key cut for one front door. It will not open the house next door, however similar that door looks.

This is why CISA's senior technical advisor Bob Lord wrote that with security keys "phishing scams don't work, and even weak passwords have an extra layer of protection."

Where apps and passkeys fit

CISA's public Secure Our World guidance ranks MFA methods from strongest to weakest. Physical security keys come first. Authenticator apps that use number matching come second, followed by apps that show time-based codes, then biometrics, with text and email codes at the bottom. Number matching makes the user type a number shown on the login screen into the app. It beats a bare approve button, but it is still not on the fact sheet's list of phishing-resistant methods.

FIDO2 credentials come in two physical forms, according to CISA's Hybrid Identity Solutions Guidance. Roaming authenticators are external keys that connect over USB, NFC or Bluetooth. Platform authenticators are built into the device, such as Windows Hello or Face ID. The same guidance notes that a passkey, which is a FIDO2 credential, can be device-bound or synced through a cloud account. CISA states plainly that it "assesses that the WebAuthn protocol and FIDO2's roaming authenticators are 'phishing resistant'" under OMB Memorandum M-22-09, the federal zero trust mandate.

On assurance, CISA's guidance says FIDO2 meets NIST SP 800-63 Authenticator Assurance Level 2 (AAL2). Depending on how it is implemented, it may meet AAL3, the level that calls for a hardware-backed authenticator. That distinction matters mainly for the regulated cases covered further down.

Most companies do not choose just one. In the FIDO Alliance's 2026 workforce survey of 1,400 decision-makers at organizations with 500 or more employees, published May 7, 2026, 47% of deployments combined synced passkeys with device-bound ones. In practice that means hardware keys for the people whose accounts carry the most risk, and passkeys on laptops and phones for everyone else.

The federal playbook tells agencies to expect a pilot to take months to a year. Across the 16 agencies it drew on, production rollouts ranged from 5 users to 130,000. A mid-sized company sits near the low end of that range, but the order of work is the same. Have the following in hand before you start.

1. Find everyone still on phishable methods. Pull the authentication-method report from your identity platform and sort users by method. When this step has worked, you have a named list of everyone on SMS, voice or bare push. In Microsoft Entra ID, SMS and voice users matter first. Microsoft announced that since September 1, 2026, those users have been automatically enabled for passkeys and prompted to register one, and that native SMS and voice authentication ends on February 1, 2027. Cost: an afternoon.

2. Sort users into two tiers. Put administrators first. Bob Lord of CISA names system administrators as the top priority and calls on SaaS providers to require keys for any staff accessing customer data. Add executives and finance staff, whom the Mirage2FA reporting identifies as high-risk targets. Those people get hardware keys. Everyone else gets a platform authenticator or a synced passkey. When this has worked, every account has a tier, and the hardware tier is small enough to fund. Cost: a meeting with HR and department heads.

3. Close the recovery back door before anyone enrolls. The GSA playbook reports that registration and recovery often still rely on passwords or email codes even when sign-in itself is phishing resistant. An attacker who cannot phish the key can phish the recovery. Decide now that a lost key is replaced through the backup key or an identity check done in person or on video, never through an emailed code. When this has worked, you can describe how each recovery path begins, and none of them starts with something an attacker can phish. Cost: policy time, no spend.

4. Buy the keys, two per person. The playbook recommends devices validated to FIPS 140 Level 1 or 2 (FIPS 140 is the federal standard for cryptographic modules). USDA's rollout, described in a CISA case study, used FIPS 140 validated keys. Match connectors to your fleet: USB-C, USB-A, or NFC for phones. When this has worked, every keyed user has a primary and a backup assigned before shipping. Cost: see the budget section below.

5. Choose who registers the keys. Thales describes three models: users register their own keys, an administrator registers keys on a user's behalf, or keys are registered before they ship. In its September 22, 2026 post, it reports that an administrator spends under a minute per key, against about ten minutes when a user does it, and that batch pre-registration cut total processing time by roughly 30%. Thales sells keys, so weigh the exact figures accordingly, but the direction is consistent with its other finding: keys that arrive blank generate help-desk tickets and setup errors. When this has worked, keys arrive already tied to the right account. Cost: administrator hours, far fewer than user hours.

6. Plan how keys physically reach people. For a single office, hand them out at a desk. For a dispersed or international workforce, Thales reports that shipping from one headquarters caused customs delays, tariff complications and cost overruns, and that sorting keys by hand at a central office drained IT staff. It recommends regional fulfillment points and bundling instructions with each key. When this has worked, nobody's key is sitting in a customs warehouse on enforcement day. Cost: varies with geography; the sources give no figure.

7. Run a pilot with written success measures. Start with the IT team, who can tolerate friction and will find it first. The playbook's six-part pilot framework asks for clear objectives, executive sponsorship, a realistic timeline, a cross-functional team, documented risks and measurable success metrics. Write internal instructions for each operating system. The playbook found that Apple's named "Face ID" prompt and Android's generic biometric prompt confused users enough to need separate documentation. When this has worked, pilot users sign in daily with no help-desk contact. Cost: weeks of calendar time.

8. Enroll both keys and set a PIN. Register the primary and the backup on the same account at the same session. The playbook calls for a PIN of at least six digits. The user then stores the backup somewhere other than the laptop bag. When this has worked, the account shows two registered authenticators, and the user can sign in with either one. Cost: minutes per user if keys were pre-registered.

9. Enforce by tier, not all at once. Require phishing-resistant sign-in for the administrator tier first. Leave other methods available for everyone else until they have registered something stronger, then remove the weaker methods group by group. This is the step that prevents the day-one lockout: nobody is forced onto a method before they hold one. The sources here document the Entra ID timeline. They do not document enforcement settings in Okta, Ping or Duo, beyond BIO-key's statement that its FIDO2 product integrates with those platforms. Check your platform's own documentation for the exact policy names. When this has worked, sign-in logs for each enforced group show only phishing-resistant methods. Cost: one change window per group.

10. Shorten and bind the session. This is the step most rollouts skip. A key protects the login, but the login produces a session cookie, and a stolen cookie works without the key. The Mirage2FA reporting recommends shorter session lifetimes, token binding and Continuous Access Evaluation in Entra ID. Continuous Access Evaluation is Microsoft's feature for cutting off live sessions when risk changes. The Hacker News analysis adds device-bound session credentials, such as Google's DBSC, which tie a session cryptographically to the device that created it. It also recommends just-in-time privilege elevation, which grants admin rights only for the task at hand. When this has worked, a cookie copied off one machine does not work on another. Cost: configuration time and some re-authentication friction for users.

11. Write the lifecycle policy and publish it. It covers backups, lost keys and offboarding. The rules are set out in the section below. When this has worked, the help desk has a runbook for a lost key and does not improvise. Cost: a day of writing.

The lifecycle policy every deployment needs

Backup keys. Every keyed account has two registered authenticators from the start, per the GSA playbook. A user with only one key who loses it becomes a help-desk emergency, and help-desk emergencies are how weak recovery methods creep back in.

Lost or broken keys. The playbook's wording is precise. You do not "revoke" a piece of hardware. You remove its association with the account. The user signs in with the backup, the lost key's registration is deleted, and a new backup is issued and enrolled. If a user has lost every key and cannot be recovered through a verified identity check, the playbook says to suspend the account rather than fall back to a weaker factor. After any suspected compromise, the Hacker News analysis advises revoking active sessions and refresh tokens as well, because resetting the password leaves an existing stolen session running.

Inactive keys. The playbook sets no forced expiration date for authenticators. It does say users should authenticate at least monthly or every two months to stay active, which gives you a simple rule for flagging keys nobody uses.

Offboarding. Remove the departing user's key associations, revoke their sessions and tokens, and disable the account in the same change. Collect the keys if company policy calls for it. The sources do not address whether keys should be reissued to new staff, so treat that as an internal decision.

Recovery runs through a weaker factor. You will recognize this when your "lost key" process ends with an email code, a text or a password reset. The GSA playbook identifies it as a recurring, overlooked attack vector. The fix is step 3: recovery through the backup key or a verified identity check, with suspension as the last resort.

Keys arrive blank. You will see it as a surge in help-desk tickets the week keys land, most of them about registration. Thales reports that self-registration drives both ticket volume and setup errors. Pre-register the keys, or have administrators register them on each user's behalf.

One key per person. The first lost key turns into a lockout, then a request for an exception, then a permanent exception. Two keys per account is the playbook's baseline for exactly this reason.

Treating the key as the end of account takeover. This is the costliest mistake, and the recent evidence on it is specific. Cyber Security News reported that the Mirage2FA phishing-as-a-service kit, which surged through August 2026, targeted Microsoft 365 users at 3,518 organizations in 94 countries. The kit does not try to beat keys or passkeys. It relays the real Microsoft login, lets the user complete it, and takes the session cookie that results. Of 9,332 recorded compromise events, 4,561 involved stolen session cookies. The report gives that share as 51%, while the Hacker News analysis of the same figures gives 48.8%. Either way, it is roughly half. As that analysis puts it, "the initial authentication succeeds normally... so the sign-in event may look ordinary." You will recognize this pattern as a successful, unremarkable sign-in followed by activity the user did not perform. The fix is step 10.

Legacy systems keep passwords alive. You will spot it when a user with a key still gets a password prompt for a file server, a mainframe app or an older single sign-on product. The playbook names Active Directory, mainframes and Siteminder. Keys still protect the front door in this case. Being fully passwordless has to wait for those systems to be modernized, so record them as known exceptions rather than letting them stall the rollout.

Mobile users get skipped. About a third of successful logins in the Mirage2FA data came from mobile devices, where the browser's shortened address bar makes a fake page harder to spot. If your keyed users read email on phones, issue keys with NFC or register a device-bound passkey on the phone as well.

You run Microsoft Entra ID and some users still use SMS or voice. You have a date. Microsoft says native SMS and voice authentication ends February 1, 2027. Organizations that must keep those methods for regulatory or access-management reasons have to move to third-party telecom providers offered through the Microsoft Security Store, and the carrier charges the customer. Microsoft said provider names and pricing would be announced September 18, 2026, and that administrator configuration would open October 30, 2026. Those provider details are not in the sources for this page, so check the Security Store directly. For most companies, it is cheaper to move those users to passkeys or keys before February than to keep paying for SMS.

You are a federal agency or hold federal systems. OMB M-22-09, issued January 26, 2022, requires agencies to use phishing-resistant methods and rules out SMS codes, time-based codes, email codes and push notifications. FIPS 140 validated devices and AAL3 matter here. That points to device-bound keys rather than synced passkeys, since FIDO2 reaches AAL3 only in some implementations.

You are a SaaS provider or hold customer data. CISA's Bob Lord specifically urges SaaS providers to set company-wide policies requiring keys whenever staff access customer data. That puts support and engineering staff with production access in the hardware tier, not just administrators.

You are a managed service provider (MSP), or you rely on one. The Mirage2FA reporting found MSPs heavily targeted, because one MSP account often holds administrative access to many client tenants. If you are the MSP, every technician belongs in the hardware tier. If you use one, ask what they use to sign in to your tenant.

Some staff cannot use phones or standard devices. USDA built its FIDO rollout partly for employees who could not get standard PIV cards, such as seasonal workers. For staff at biocontainment facilities, it used keys designed to survive decontamination. Shared workstations, cleanroom or plant-floor staff, and people without company phones are the cases where a roaming key beats a platform authenticator.

You are subject to NIS2 or CMMC. Both appear in the brief for this page. The sources behind it, however, do not state what either one requires for authentication, so this page makes no claim about what they require or by when. Read the regulator's text, or your contracting officer's guidance, before you assume a key program satisfies either one.

The only per-unit price in these sources comes from a company that sells a biometric alternative to keys. BIO-key's September 23, 2026 release put traditional tokens at $25 to $70 each. It also claimed that about 25% of issued tokens are lost or replaced every year. That figure has no independent source here and comes from a party with a reason to make keys look expensive, so treat it as a ceiling to plan against rather than a measured rate.

With those caveats, the arithmetic looks like this. Two keys per person puts the upfront cost at $50 to $140 per keyed user, at the September 2026 price range. Suppose a 400-person company keys only its 40 administrators, executives and finance staff. That is 80 keys, or $2,000 to $5,600. If the 25% replacement claim held, that company would replace about 20 keys a year, for $500 to $1,400. The other 360 people would use platform authenticators or synced passkeys, which need no hardware purchase.

Labor is the larger hidden cost. At Thales's figures, registering those 80 keys takes an administrator under 80 minutes. Leaving it to users costs roughly 800 minutes of scattered staff time, spread across a week of help-desk calls.

The case for spending the money rests on two points. First, the threat has grown. Microsoft's July 2026 announcement cited a 54% click-through rate for AI-generated phishing, against about 12% for traditional phishing. Second, most organizations have not finished the job. In the FIDO Alliance's 2026 survey, 87% of organizations were deploying or piloting FIDO2 passkeys in some form, up from 53% two years earlier. Yet 57% still relied on phishable methods for primary employee sign-in, and only 28% had reached their passwordless goal. Among adopters, 45% reported faster logins, 35% fewer password-reset tickets and 32% fewer phishing incidents. Those are self-reported survey answers, not measured outcomes. The FIDO Alliance's workforce margin of error is plus or minus 2.6 points.