Phishing-resistant MFA is authentication designed so a claimant cannot be tricked into giving an attacker an authenticator output that works at a fraudulent verifier. Procurement language must preserve that technical property. A product that sends a code, asks for an approval, or adds number matching may improve security yet still expose a transferable response to an adversary-in-the-middle. Buyers need requirements that exclude look-alikes across sign-in, enrollment, recovery, administration, and every exception path.
NIST states that passwords, out-of-band methods, and OTP authentication are not phishing-resistant in its authenticator requirements. WebAuthn uses public-key credentials scoped to a relying party, with signed challenges verified by that party. The W3C WebAuthn specification is therefore more useful in an RFP than broad promises such as passwordless or advanced MFA. The procurement task is to convert protocol behavior into evidence a vendor can demonstrate in the buyer's environment.
Define the journeys that require phishing-resistant MFA
List user populations, applications, transactions, devices, and operating conditions before evaluating products. Distinguish employee SSO, privileged administration, customer authentication, contractors, shared endpoints, remote desktops, mobile-only use, offline access, and emergency accounts. State where step-up is required and which legacy protocols bypass modern authentication. A product may support WebAuthn for its own console while an important downstream application still accepts a relayable factor, so coverage must be assessed journey by journey.
Set assurance outcomes and constraints: acceptable credential portability, user verification, hardware protection, accessibility, residence requirements, regulated cryptography, managed-device policy, and maximum recovery time. The MFA rollout guide can help estimate operational load, while the OIDC checklist helps identify federation boundaries. The RFP should state that usability and continuity matter, but neither can be achieved by silently restoring a weaker unrestricted factor.
Write protocol requirements that prove resistance
Require a standardized cryptographic challenge-response protocol with verifier or origin binding. For WebAuthn, the relying party must validate the challenge, origin, RP ID relationship, credential identifier, signature, user-presence or user-verification flags as policy requires, and replay protections. Ask which FIDO and WebAuthn versions are implemented, which browser and platform combinations are supported, and how the vendor handles algorithm changes. The FIDO specifications directory lets evaluators trace claims to the relevant standards rather than a proprietary feature name.
Require the vendor to identify every offered method that is not phishing-resistant and show how policy prevents its use for protected journeys. That includes passwords, SMS, email codes, TOTP, voice, and approval-only push. Number matching can reduce accidental approvals but does not turn a shared or transferable secret into verifier-bound cryptography. Ask whether the product supports discoverable credentials, roaming security keys, platform authenticators, user verification, backup-state signals, and attestation. Each feature needs an administrative policy and test, not merely a check mark.
| Requirement | Acceptable evidence | Weak answer | Acceptance test |
|---|---|---|---|
| Verifier binding | Documented WebAuthn or equivalent origin-bound protocol | Proprietary anti-phishing algorithm | Credential cannot authenticate to a look-alike domain |
| No relayable fallback | Policy export showing protected apps reject OTP and push | Fallback is configurable | Attempt downgrade through every sign-in route |
| User verification | Configurable UV requirement and authenticator result logs | Device biometrics supported | Reject assertion without required UV flag |
| Credential controls | Inventory, metadata, revocation, limits, and timestamps | Users manage their own devices | Revoke one credential and verify immediate effect |
| Standards interoperability | Conformance evidence and supported matrix | Works with modern browsers | Execute buyer-defined browser, OS, IdP, and key matrix |
| Cryptographic lifecycle | Algorithms, key protection, rotation, and update process | Military-grade encryption | Review configuration and observe upgrade behavior |
Evaluate authenticators and deployment fit
A sound platform can still fail a deployment if credential options do not fit the workforce. Compare synced passkeys, device-bound platform credentials, roaming security keys, smart cards, and certificate-based authenticators against target devices and transactions. Ask who controls the credential provider, whether keys can leave hardware, how backup eligibility is surfaced, and how shared workstations operate without shared credentials. For high-impact administration, require evidence for non-exportability and inventory; for broad customer use, credential portability and ecosystem coverage may carry more weight.
Test accessibility with users and assistive technology, not a vendor statement. Verify cross-device flows, biometric alternatives, PIN behavior, browser focus, readable prompts, and recovery when a biometric cannot be used. Establish whether resident-key storage limits or key inventory affect large account sets. Include virtual desktop, remote browser isolation, device replacement, and restricted networks. A procurement score should distinguish a missing capability from one that requires an operational workaround, because workarounds often become permanent security exceptions.
Inspect enrollment and administration controls
Require high-confidence authorization for initial enrollment and post-enrollment binding. The system should record the initiator, subject, authentication context, credential identifier, authenticator properties, device context, policy, and outcome. Administrative APIs need least privilege, scoped service identities, approval for bulk changes, and complete audit events. Ask whether an administrator can disable phishing-resistant policy tenant-wide, create an exempt group, or impersonate a user without a second control. Test those capabilities as attack surfaces.
Lifecycle requirements should cover lost, stolen, damaged, duplicated, expired, replaced, and compromised authenticators. NIST's authenticator-event section provides a useful control baseline. Buyers should require selective revocation, session response, customer or employee notification, bulk incident handling, and exportable event evidence. Integration with joiner-mover-leaver processes matters: removing an employee or privileged entitlement must stop access regardless of whether the physical authenticator remains functional.
Attack recovery and fallback during evaluation
Treat recovery as part of the product's effective authentication protocol. Document self-service recovery, help-desk-assisted rebinding, recovery codes, trusted devices, verified channels, identity proofing, and break-glass access. Require independent evidence proportionate to the protected account and controls on high-risk changes after recovery. A vendor cannot claim a phishing-resistant tenant if a support agent can restore a password or SMS factor that immediately grants the same privilege. Exceptions need scope, owner, expiry, notification, and review.
In the proof of concept, simulate a compromised mailbox, recently ported number, stolen active session, executive impersonation call, lost hardware key, and inaccessible sync provider. Attempt to enroll a new credential from each state and inspect alerts and logs. Test rate limits and concurrent requests. Verify that emergency administration uses dedicated, monitored identities instead of a universal bypass. These scenarios reveal product architecture and support authority far more effectively than a polished happy-path demonstration.
Score evidence, operations, and contract duties
| Domain | Required proof | Contract commitment | Decision consequence |
|---|---|---|---|
| Protocol | Standards mapping and adversarial test result | Maintain conformance and disclose material change | Fail if protected journey remains relayable |
| Coverage | Buyer application and device matrix | Named support and deprecation notice | Limit award or fund remediation plan |
| Recovery | Demonstrated pathways and override logs | No unilateral assurance downgrade | Fail for unrestricted weak recovery |
| Administration | Role model, configuration export, immutable events | Incident notice and evidence access | Require compensating approval or reject |
| Resilience | Outage, replacement, and break-glass exercise | Recovery objectives and support escalation | Accept only with tested continuity |
| Privacy and accessibility | Data inventory, retention, user testing | Correction and regulatory cooperation | Require remediation before enforcement |
Weight mandatory security properties as gates, not points that attractive usability features can offset. Then score deployment fit, operational burden, support, cost, and roadmap among products that pass. Contract for configuration portability, event access, vulnerability notification, protocol deprecation notice, and assistance during credential migration. Define acceptance artifacts and a remediation clock. The wider SSO and MFA planning guide can help turn selection into phased adoption.
Plan implementation acceptance before contract signature
Name the production acceptance owner and define when payment, rollout expansion, or legacy-factor retirement can occur. Require the vendor to support a representative pilot, export final policy, correct failed negative tests, document unsupported combinations, and train administrators without retaining unnecessary tenant access. Include migration assistance if authenticators, relying-party identifiers, or account bindings must move at contract end. Set service objectives for authentication and recovery, escalation for widespread lockout, and evidence delivery during an incident. Procurement should also reserve the buyer's right to retest after material protocol, browser, authenticator, or recovery changes. These terms turn the proof of concept into an enforceable production baseline instead of allowing the deployed configuration to drift away from the product that passed evaluation. Record who may approve a temporary acceptance waiver, which controls compensate for it, and the date on which deployment must stop if remediation is incomplete.
Phishing-resistant MFA procurement takeaways
- Define protected journeys and assurance constraints before comparing products.
- Require verifier-bound cryptographic protocols and test them against a look-alike service.
- Identify and block every relayable fallback for protected applications.
- Evaluate credential types against real devices, privilege, accessibility, and continuity needs.
- Test enrollment, administration, recovery, and break-glass as attack surfaces.
- Use mandatory gates for resistance, then score operations, coverage, cost, and contract quality.
Phishing-resistant MFA procurement FAQ
Is number-matching push phishing-resistant? It can mitigate blind approval and fatigue, but it does not inherently provide the verifier binding that defines phishing resistance. Buyers should classify it accurately and avoid using it as the unrestricted fallback for journeys that require phishing-resistant authentication.
Is every passkey suitable for privileged access? No. Passkeys share a WebAuthn foundation, but credential backup, key exportability, authenticator hardware, user verification, device governance, and recovery differ. Privileged policy may require device-bound, hardware-protected credentials and stronger inventory controls.
What should a proof of concept produce? It should produce a completed journey matrix, configuration export, credential and lifecycle evidence, recovery attack results, interoperability results, event samples, documented gaps, owners, remediation dates, and a clear pass or fail against mandatory requirements.
Conclusion
Buying phishing-resistant MFA means buying a verifiable security property across an operating lifecycle, not a label. Anchor requirements in protocol behavior, run the buyer's real applications and devices, attack every downgrade route, and demand evidence that administrators and support cannot quietly undo the control. Products that pass those gates can then compete on adoption, resilience, manageability, and total cost with the central claim already proven.