A phishing-resistant MFA rollout built on hardware security keys

The problem

Moving a password manager from one-time codes to hardware security keys is easy to describe and easy to get wrong. Most of the failures are operational:

• a key enrolled while an older, phishable method stays enabled beside it;
• an organization-wide policy switched on before everyone has a key, locking people out;
• a lost key with no tested replacement;
• a key whose firmware is below a safe minimum.

There is also a recurring debate about whether a key plugged in by cable is safer than one tapped over NFC. For FIDO2 the protection comes from the protocol, not the connection.

What was built

A versioned runbook for enrolling a FIDO2 hardware key as the second factor on a business password manager. Version 2.0 adds a second transport and a security baseline to the first. It covers:

• Two desktop operating systems and two phone platforms, using a single key model that supports both a wired and a contactless connection, so every in-scope device is covered without adapters.
• A one-time enrollment procedure per person, run on a desktop, that registers a primary and a backup key in one sitting and sets a FIDO2 PIN.
• Day-to-day sign-in steps per platform and transport.
• An enforcement sequence, recovery procedures, a per-person pilot checklist, a troubleshooting table and a quick-reference card.

Design decisions

The baseline comes first, transport second

A FIDO2 assertion is signed and bound to the site’s origin, so it cannot be replayed or phished over either a cable or a tap. The runbook therefore treats transport as a connectivity choice and ranks the controls that move the risk:

• Firmware gate. Some older security-key firmware carries published flaws that cannot be fixed in the field. Each key’s firmware is checked on receipt against a minimum version, and any key below it is quarantined, not enrolled.
• PIN on every key. A FIDO2 PIN means a lost or stolen key alone cannot authenticate, with a minimum length and a forced change on first use where firmware supports them.
• No weaker fallback. SMS and one-time codes are removed; leaving one enabled reopens a phishable path. The fallback factor is a second hardware key.
• Managed endpoints. A compromised endpoint can proxy an authenticated session over either transport, so phones are enrolled in device management with screen lock, biometrics, disk encryption and current patches.
• Cross-device sign-in discouraged. The QR-code cross-device flow, not the NFC tap, is the documented relay vector; users are trained never to approve a QR-initiated sign-in they did not start.
• Asset control. Each key is recorded by owner, role, serial number and firmware version.

Enforcement is the last step, not the first

Requiring keys organization-wide locks out anyone not yet enrolled. The runbook names this the most common self-inflicted lockout and gates enforcement on evidence: every member has at least two registered keys and a PIN and has passed the pilot checklist, and no SMS or code method remains permitted, before the policy is switched on.

Recovery is layered and rehearsed in the pilot

The key is a sign-in factor, not an encryption key, so losing one blocks new-device sign-in but destroys no data. Recovery is layered, starting with the backup key, and every recovery ends in re-registration and a register update. On loss or departure the key’s registration is removed. The pilot rehearses a lost primary: the backup key must sign in on a new device.

Evidence and limits

The pilot checklist runs per person, and every row should pass before enforcement:

#	Check	Pass condition
1	Firmware, both keys	At or above the minimum version
2	PIN set, both keys	PIN required on use; minimum length enforced
3	Both keys registered	Both listed in the account’s two-factor settings
4	No SMS or code fallback	Only the security-key method present
5-7	Wired on desktop, wired on phone, contactless on phone	Sign-in completes with the PIN
8	Lost-primary simulation	Backup key signs in on a new device
9	Recovery path confirmed	Stored securely

Limits, stated plainly:

• This is a written procedure; no pass rates or rollout figures are claimed.
• Platform steps reflect operating system versions current in June 2026 and need re-verification as those versions change.
• The documented fix for a forgotten PIN is resetting the key’s FIDO2 application, which wipes its credentials and forces re-registration.
• FIPS 140-3 key variants, passkey storage and other uses of the key, such as SSH, are out of scope.
• No hardware key solves endpoint compromise; the runbook relies on endpoint controls for that.

Where it applies

Healthcare payers and CMS contractors. Phishing-resistant MFA sits in the NIST 800-53 identification and authentication family that CMS ARS builds on. A key register, removed fallback methods and a pass/fail pilot record per user, once run, give an authorization package something concrete behind IA-2 and IA-5, rather than a policy statement.

Semiconductor and advanced-manufacturing suppliers. NIST 800-171 calls for multifactor and replay-resistant authentication. When a customer security questionnaire asks which second factors are permitted and how a lost authenticator is handled, the answers are specific: hardware keys only, no SMS fallback, a backup key per person, de-registration on loss or departure, firmware verified before issue.

Security leadership. The order of operations is itself a control: procure and verify, enroll in pairs, pilot each person, then enforce.

Independent work by Wade Blackwell. Each write-up is written from scratch for this site, without client, employer or personal data. Names, hostnames, addresses and configuration detail are left out on purpose.