WebAuthn User Verification Skip: UV Flags and Server Trust Gaps
Product copy says "biometric required." The WebAuthn options say userVerification: "preferred". Those are not the same. Preferred means the authenticator might skip PIN or biometric and still return a happy assertion.
Your job is to see whether the server inspects the UV bit.
Read the options and the flags
On login start, inspect publicKey.userVerification. discouraged / preferred / required matter. On the assertion, decode authenticatorData and check the flags byte—UV and UP bits are documented in the WebAuthn spec.
If UV is unset but the account settings page claims "always verify user," try completing login with a security key configured without PIN. Some platforms allow that path while the UI implies otherwise.
Also check registration. An account enrolled with userVerification: "discouraged" may later be treated as high assurance MFA for sensitive actions. That downgrade is reportable when the policy promises phishing-resistant MFA with verification.
Enterprise IdPs sometimes advertise "passkey MFA" in marketing while the conditional UI request still uses preferred. Capture both the IdP options and the app's step-up options—mismatches are common after hasty rollouts.
When you cannot force a non-UV authenticator, still decode flags from a normal successful login. If production assertions arrive with UV=0 while the security whitepaper says UV is mandatory, that mismatch alone may be enough to open a conversation—then push for a sensitive-action proof.
Where skip becomes impact
- Step-up for password change or payouts accepts a non-UV assertion
- Recovery flows that trust "has a passkey" without UV
- Enterprise SSO apps that map WebAuthn success to a high LOA claim blindly
- Device transfer flows that re-bind a credential without a fresh UV ceremony
I test with two authenticators when I can: one with PIN enforced, one without. Same username. Compare whether both unlock the sensitive action. If only the non-UV key works on a kiosk-style platform authenticator, say so—hardware context matters for severity.
Ask whether re-authentication for "remember this device" bypasses UV on later visits. Sticky trust after a single weak ceremony is a quiet policy bug.
Do not confuse presence with verification
User Present (UP) only means a touch. User Verified (UV) means PIN/biometric. Reports that mix them get marked informative. Quote the flag bits and the server decision.
Backup eligibility and UV are separate flags too. Do not pad the report with every bit you decoded—stick to the ones that change the security claim.
Fix language for triage
Ask for userVerification: "required" on high-risk ceremonies, server-side rejection when UV is not set, and consistent enrollment policy so old low-assurance credentials cannot satisfy new step-up rules.
If the program only wanted "something WebAuthn-shaped," say so honestly and downgrade severity. If they advertise biometric MFA and skip UV checks, that is the story—show one sensitive action that succeeded without verification.
Also capture whether conditional mediation (passkey autofill) uses different UV options than the explicit button flow. I have seen the button path require UV while the autofill path quietly stayed on preferred—same RP, two policies.