Most MFA products can show a passkey demo, but the purchase succeeds or fails on enrolment, recovery, legacy systems and the help desk, which demos rarely cover. The market spans identity providers with built-in MFA, standalone MFA and passwordless platforms, hardware authenticator programmes and customer identity products, and their claims overlap. NIST SP 800-63B-4 now requires verifiers to offer at least one phishing-resistant option at AAL2 and bars syncable passkeys at AAL3, so "supports passkeys" is no longer a sufficient answer. This vendor-neutral buyer's guide is for identity architects, security leads and procurement teams writing requirements, running an RFP or replacing an MFA product for workforce or customer use. It covers what to define first, the criteria to score, questions that expose weak answers, red flags and a proof of concept plan.
Key takeaways
- Buy for phishing resistance, not factor count. NIST SP 800-63B-4 states that passwords, look-up secrets, out-of-band and OTP authentication are not phishing-resistant. Score each product on how well it delivers and enforces passkeys, security keys and certificate-based authentication.
- Synced and device-bound passkeys are different assurance levels. Synced passkeys can meet AAL2 but "SHALL NOT be used at AAL3", which requires a non-exportable private key. You need policy that can tell them apart.
- Attestation and AAGUID policy are where control lives. Without enforced attestation, a product cannot reliably know which authenticator a user registered, so allow lists become guidance rather than enforcement.
- Recovery is the weakest link. A strong authenticator with a weak reset path (SMS, knowledge questions, a phone call to the help desk) is only as strong as the reset.
- Coverage gaps cost the most. Legacy protocols, offline logon, shared devices and non-browser apps decide how many exceptions you will carry, so test them before you sign.
Define requirements
- Populations and assurance: list employees, administrators, contractors, frontline and shared-device workers, partners and customers, and the assurance level each needs. Federal agencies must already require phishing-resistant MFA for staff, contractors and partners under OMB M-22-09, and offer it as an option to the public.
- Target authenticators: decide which you will support: synced passkeys, device-bound passkeys on security keys, platform authenticators built into Windows, macOS, iOS and Android, PIV or CAC smart cards and certificate-based authentication, and which legacy factors (authenticator app OTP, push with number matching) remain as transitional. See the Passwordless and Passkeys Guide.
- Identity provider fit: decide whether MFA comes from your existing IdP, a separate MFA platform federated to it, or both. Two systems mean two policy engines, two sets of logs and two recovery paths. See the IAM and IdP Buyer's Guide.
- Systems to cover: SaaS and custom web apps, VPN and RADIUS, Windows and macOS logon (online and offline), Linux and SSH, virtual desktops, privileged access tools and line-of-business apps that only speak LDAP or Kerberos.
- Customer requirements: for customer identity, define sign-up conversion targets, account recovery without a help desk, support for third-party passkey providers, and fraud signals. See the CIAM Buyer's Guide.
- Non-human identities out of scope: service accounts and workloads cannot complete MFA. Plan workload identity and secrets controls separately rather than letting MFA exemptions pile up. See the Service Account Security Guide.
Size changes the answer. A smaller organisation on one cloud suite will usually get furthest by enforcing the passkey and security key features it already licenses. A large or regulated enterprise needs AAL3 for administrators, smart card or certificate support, multiple IdPs and a formal key issuance programme.
Capability areas
| Authenticator | Phishing-resistant | Highest NIST AAL | What to check in the product |
|---|---|---|---|
| Synced passkey | Yes | AAL2 (key is exportable) | Support for platform and third-party passkey providers; policy to allow or block synced passkeys per group |
| Device-bound passkey on a security key | Yes | AAL3 with a non-exportable key | Attestation enforcement, AAGUID allow lists, PIN policy, bulk issuance and lost key handling. See the Hardware Security Keys Guide |
| Platform authenticator (device-bound) | Yes | Depends on the device and its attestation | OS versions supported, shared device behaviour, offline logon |
| PIV, CAC or certificate-based authentication | Yes | AAL3 | Certificate authority integration, revocation checking, derived credentials on mobile |
| Authenticator app OTP or push with number matching | No | AAL2 | Number matching, location and app context in prompts, rate limits. See the Authenticator Apps and OTP Guide |
| SMS or voice code | No (PSTN is a restricted authenticator) | AAL2 with restrictions | Ability to disable per group, and an alternative for every user |
CISA's phishing-resistant MFA fact sheet ranks methods the same way: phishing-resistant MFA is "the gold standard", app-based OTP and number-matched push come next, push without number matching is weaker, and SMS or voice "should only be used as a last resort".
Evaluation criteria
Weight these to your requirements. An illustrative split for a workforce programme is 25% authenticator support and policy, 20% enrolment and recovery, 20% coverage of legacy and offline systems, 15% administration and reporting, 10% platform security, 10% cost; adjust rather than copy.
| Criterion | What good looks like | Weak signs |
|---|---|---|
| Phishing-resistant enforcement | Policy can require phishing-resistant methods per app, group and risk level, including for administrators, with report-only mode before enforcement | "Passwordless" that is push or OTP; enforcement only tenant-wide |
| FIDO certification | Server and authenticators listed in the FIDO Certified Products Directory; authenticator security levels stated (L1 is the minimum; L2 and above are evaluated by an accredited laboratory) | "FIDO compatible" with no certification listing |
| Attestation and AAGUID policy | Enforced attestation at registration, allow and block lists by AAGUID, FIDO Metadata Service (MDS3) checks, separate policy for synced and device-bound passkeys | AAGUID lists without attestation; no way to tell synced from device-bound |
| Enrolment | Identity proofing or a time-limited bootstrap credential (for example a one-time temporary access code), registration bound to a verified session, bulk pre-registration of security keys | First registration protected only by a password or SMS code |
| Recovery | At least two authenticators encouraged, self-service recovery with a phishing-resistant fallback, identity verification for full resets, waiting periods and notifications | Knowledge questions; SMS-only reset; help desk can reset admins without a second approver |
| Legacy and offline coverage | Documented options for RADIUS and VPN, Windows and macOS offline logon, SSH, virtual desktops and shared kiosks | "Use a password plus OTP" for every non-web system |
| Admin and help desk controls | Scoped roles for registering and resetting methods, approval for privileged resets, full audit trail, no help desk view of secrets | One admin role that can reset anyone, including other admins |
| Reporting | Registration status per user and method, phishing-resistant coverage over time, sign-ins by method, exportable logs and SIEM integration | Coverage only as a dashboard tile; short log retention |
| Customer use | Passkey sign-up and sign-in with conditional UI, cross-device sign-in, recovery without agents, fraud signals | Passkeys bolted onto an SMS-first flow |
| Pricing model | Clear unit (per user, per monthly active user or per authentication), hardware and support costs stated, no extra charge for phishing-resistant policy | Phishing-resistant enforcement or reporting only in a premium tier |
Questions to ask vendors
- Show us a policy that requires phishing-resistant MFA for administrators, in report-only mode first, then enforced. What happens to an admin who loses their only key?
- Can policy distinguish synced from device-bound passkeys, and does that rely on enforced attestation? What happens to existing registrations when we tighten the policy?
- Which of your server and authenticator products are in the FIDO Certified Products Directory, at which certification level, and do you consume the FIDO Metadata Service?
- Walk us through the first enrolment of a new starter who has no credential yet, and a full reset for a user who has lost every authenticator. Which steps can the help desk perform, and what verification is required?
- How do you cover VPN and RADIUS, offline Windows and macOS logon, SSH and shared devices? Which of these fall back to OTP or passwords?
- Which admin roles can register or reset methods, can resets for privileged users require a second approver, and is every change logged?
- What reports show phishing-resistant coverage by group and by app, and can we export raw registration and sign-in events?
- For customers, how do you support third-party passkey providers and recovery when a customer changes phone ecosystem?
- What does the price count, what does a security key programme add (keys, spares, shipping, replacement), and which features sit in higher tiers?
Red flags
- "Passwordless" that turns out to be push approval or a magic link, sold as phishing-resistant. Push without number matching is what attackers spam: in the Uber breach repeated prompts eventually won an approval.
- No way to enforce attestation, or AAGUID allow lists presented as a security control without it.
- Recovery or first enrolment that depends on SMS, knowledge questions or an unverified help desk call. The MGM Resorts breach began with a help desk call. See the Account Recovery and Help Desk Security Guide.
- Bootstrap codes with long lifetimes or unlimited use, or bootstrap methods that do not work with your RADIUS or federation components.
- Admin roles that cannot be scoped, or resets of other administrators by a single person.
- Claims of "AAL3 support" for synced passkeys, which NIST SP 800-63B-4 excludes.
- Coverage figures you cannot reproduce from exported data.
Proof of concept
- Scope and score first: agree weights, pass criteria and pilot groups (IT administrators and the help desk first, as CISA suggests, then a business unit and, for customer products, a test user population).
- Configure policy in report-only mode: require phishing-resistant MFA for administrators and one sensitive app, with break-glass accounts excluded and monitored. See the Break-Glass Account Guide.
- Test enrolment end to end: a new starter with no credential, a user adding a second authenticator, and bulk issuance of security keys. Record time per user and support calls.
- Test attestation and AAGUID policy: register an allowed security key, a blocked model and a synced passkey, and confirm each is accepted or rejected as the policy says, at registration and sign-in.
- Test recovery and the help desk: run a lost-device scenario and a social engineering script against the help desk with consent, and check that privileged resets need a second approver.
- Test coverage: VPN or RADIUS, offline laptop logon, SSH, a virtual desktop, a shared device and a non-browser app. List every fallback to OTP or password.
- Check reporting and logs: export registration and sign-in events to your SIEM and reproduce the vendor's coverage figure.
- Roll back: switch enforcement back to report-only, confirm users can still sign in with existing methods, and remove test registrations.
Carry a few measures into production: percentage of users and administrators with a phishing-resistant method registered, share of sign-ins using one, number of active exceptions and fallbacks, recovery requests per 1,000 users per month, and median time to complete a verified reset.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support across authentication, IAM, PAM and NHI. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Passwordless and Passkeys Guide · Hardware Security Keys Guide · Authenticator Apps and OTP Guide · Account Recovery and Help Desk Security Guide · MFA Guide