Category: FIDO & Passkeys
User Verification
Also known as: UV, User Presence and Verification, Identity Verification (context-dependent)
Simply put
User verification is a check that confirms a person is who they claim to be before they are allowed to take an action or access a system. It commonly involves proving knowledge of a secret such as a PIN, or demonstrating another factor tied to the individual. The specific mechanism and strength of the check vary widely depending on the system and how it is configured.
Formal definition
User verification is the process of confirming a claimed identity so that only authorized individuals are granted access to a given system, application, or action. In practice it can involve a knowledge factor (such as a PIN or password), and in help-desk and enterprise contexts it is often performed against a directory such as Active Directory or Entra ID, sometimes reinforced with multi-factor methods. Note that the term is used loosely across the evidence: it may refer to an authentication-time check that a user knows or possesses a credential, or to a periodic affiliation check confirming a person remains associated with an organization. This entry addresses user verification as a confirmation step in an access flow and does not, on its own, define the subsequent authorization decision (what the verified principal is permitted to do), which is a separate concern. The precise assurance level, factors used, and whether the check constitutes full authentication depend on the deployment and configuration.
Why it matters
User verification sits at the boundary between an unknown request and a trusted action. When it is weak or inconsistently applied, an attacker who has learned or intercepted a single secret can impersonate a legitimate person, which is why the strength and configuration of the check matter as much as its presence. As the evidence notes, verification is one of the best ways to protect platform integrity, yet it can also be one of the most frustrating steps for a new user, so teams must balance assurance against friction rather than treating a stronger check as universally better.
Who it's relevant to
IAM Engineers and Security Architects
They decide where verification checks are placed in an access flow, which factors are required, and what assurance level is appropriate. Because the term is used loosely, they must specify whether a given check is an authentication-time confirmation or a recurring affiliation check, and design the subsequent authorization decision as a separate control.
Help Desk and IT Operations Teams
Verifying callers before password resets and account unlocks is a routine but high-risk task. Automating identity checks against Active Directory or Entra ID with multi-factor methods reduces exposure to social engineering compared with manual question-and-answer checks.
Identity Governance Leads
Where verification is framed as a periodic check that an individual remains affiliated with the organization, it overlaps with lifecycle and access review concerns. Governance owners should distinguish this ongoing affiliation check from runtime authentication and ensure both are covered rather than assuming one substitutes for the other.
Product and Platform Teams
For consumer-facing systems, verification protects platform integrity but can introduce friction, particularly for new users. These teams weigh assurance against usability and tune the mechanism to their risk profile rather than defaulting to the strongest available check.
Inside UV
User Verification (UV)
In the FIDO2/WebAuthn context, User Verification is the process by which an authenticator confirms that the specific person interacting with it is the legitimate enrolled user, typically through a knowledge factor (such as a PIN) or an inherence factor (such as a fingerprint or face). It is distinct from User Presence, which only confirms that some human is present.
User Presence (UP)
A test that confirms a human is physically interacting with the authenticator (for example, a touch or tap) without establishing which human. User Presence does not authenticate identity by itself and should not be treated as equivalent to User Verification.
Knowledge and inherence factors
User Verification is commonly satisfied by a knowledge factor (a device PIN) or an inherence factor (a biometric such as fingerprint or face recognition). The factor used depends on the authenticator's capabilities and configuration.
UV flag in authenticator data
WebAuthn authenticator data includes flags indicating whether User Verification (UV) and User Presence (UP) were performed during a ceremony. A relying party evaluates these flags when validating an assertion, depending on its policy requirements.
Relying party UV policy
During registration and authentication, a relying party can express a User Verification requirement (for example, required, preferred, or discouraged in WebAuthn terms). The enforced behavior depends on the authenticator's support and the deployment configuration.
Local verification scope
User Verification is typically performed locally on the authenticator or device; biometric data used for inherence-based verification generally remains on the device rather than being transmitted to the relying party. Exact handling depends on the platform and authenticator implementation.
Common questions
Answers to the questions practitioners most commonly ask about UV.
Is user verification the same as user authentication?
No. In the FIDO2/WebAuthn context, user verification (UV) is a specific check performed by the authenticator to confirm that the person present is the legitimate owner of the authenticator, typically via a PIN, biometric (inherence), or similar local gesture. Authentication is the broader process of a relying party verifying who a principal is, which relies on the authenticator's assertion. UV is one component that raises an authenticator's assurance from single-factor (possession only, when UV is not performed) toward multi-factor, but it is not itself the complete authentication event.
Does user verification mean a biometric was used?
Not necessarily. User verification confirms the presence and consent of the authorized user, but the mechanism depends on the authenticator and its configuration. It may be a knowledge factor such as a PIN, an inherence factor such as a fingerprint or face scan, or another local gesture. The WebAuthn UV flag typically signals only that some verification method succeeded, not which method was used. A relying party generally cannot infer the specific modality from the UV flag alone.
How do we require user verification during a WebAuthn ceremony?
In most WebAuthn deployments, the relying party sets the userVerification parameter in the authentication or registration options to 'required', 'preferred', or 'discouraged'. Setting it to 'required' instructs the authenticator to perform UV and, per the standard, the relying party should reject an assertion whose UV flag is not set. Behavior can vary by authenticator capability and browser, so relying parties should validate the returned UV flag server-side rather than relying solely on the requested policy.
How should the relying party confirm that user verification actually occurred?
The relying party should inspect the UV bit in the authenticator data flags returned in the assertion, rather than assuming the requested policy was honored. This check happens during server-side validation of the WebAuthn response, alongside signature verification and other flag checks such as user presence. Depending on your assurance requirements, treat an assertion lacking the UV flag as single-factor and handle it according to your policy.
What is the difference between user presence and user verification in these flows?
User presence (UP) typically confirms that a human interacted with the authenticator, such as a touch, without confirming identity. User verification (UV) additionally confirms that the interacting person is the authorized user through a PIN, biometric, or similar check. Both are represented by distinct flags in the authenticator data, and a relying party can require either or both depending on the assurance level it needs.
When would we choose 'preferred' over 'required' for user verification?
The choice generally depends on balancing assurance against compatibility and user experience. 'Required' enforces UV and, per the standard, should cause rejection when UV is absent, supporting multi-factor assurance but potentially excluding authenticators that cannot perform UV. 'Preferred' requests UV where the authenticator supports it but does not fail the ceremony when it is absent, which broadens compatibility at the cost of guaranteed UV. The appropriate setting depends on your risk tolerance and deployment context; some flows may pair 'preferred' with step-up authentication for higher-risk actions.
Common misconceptions
User Verification and User Presence are the same thing.
They are distinct. User Presence confirms only that a human is interacting with the authenticator, while User Verification confirms that the interacting human is the legitimate enrolled user via a knowledge or inherence factor. The WebAuthn authenticator data carries separate UP and UV flags for this reason.
User Verification always means biometrics.
User Verification can be satisfied by a knowledge factor such as a device PIN or by an inherence factor such as a fingerprint or face. Which method is used depends on the authenticator's capabilities and configuration, not on biometrics exclusively.
If a relying party requests User Verification, it is guaranteed to occur.
Whether User Verification is actually performed depends on the authenticator's support and the deployment configuration. Relying parties should confirm this by evaluating the UV flag in the returned authenticator data rather than assuming a request was honored.
Best practices
Set the relying party's User Verification requirement (for example required, preferred, or discouraged) deliberately based on the sensitivity of the resource, rather than defaulting without considering the risk context.
Do not rely on the request alone; validate the UV flag in the returned WebAuthn authenticator data to confirm that User Verification actually occurred before granting access.
Keep User Presence and User Verification distinct in policy and logic, and avoid treating a simple presence test as proof of the user's identity.
Account for varying authenticator capabilities, since not all authenticators support User Verification or the same verification methods; design fallback and policy behavior accordingly.
Prefer keeping biometric-based verification local to the device where the platform supports it, so that inherence data is not transmitted to the relying party.
Document and test how your deployment behaves when a requested User Verification level cannot be met, so enforcement decisions remain predictable across different devices and configurations.
