Skip to main content
Identity Authority
Category: FIDO & Passkeys

Test of User Presence

Also known as: TUP, user presence test, user presence check
Simply put

Test of User Presence is a simple check that confirms a real person is physically present and approving an action, typically by touching or tapping a security key or device. It answers the question of whether someone is there and interacting, but it does not attempt to confirm which specific person it is. It is commonly used with FIDO authenticators to make sure an operation is not performed silently without any human action.

Formal definition

In FIDO specifications, Test of User Presence (TUP) is a mechanism by which an authenticator confirms that a human is present and deliberately authorizing an operation, most often through a physical gesture such as touching a security key. Per the FIDO Authenticator Security Requirements, once the TUP succeeds and user presence is detected, the user is deemed 'present' for a defined scope. TUP should be distinguished from user verification (UV): TUP establishes only that some human interacted with the authenticator, whereas UV attempts to verify the identity of a specific user (for example via PIN or biometric). According to community and vendor guidance, the intent of TUP is to ensure that every relevant operation is accompanied by a deliberate user action rather than occurring silently, and it is characterized as more than a simple button press in that it must be tied to the operation being authorized. Exact prompt behavior and enforcement depend on the authenticator implementation and the invoking profile.

Why it matters

Test of User Presence addresses a specific and important risk in authentication flows: operations being triggered silently, without any deliberate human action. Without a presence check, malware, a remote attacker with access to an authenticator, or an automated process could potentially invoke sensitive operations against a connected security key without the user ever knowing. By requiring a physical gesture such as a touch or tap that is tied to the operation being authorized, TUP ensures that a human is present and consciously approving each relevant action.

It is critical for architects to understand what TUP does and does not establish. TUP confirms only that some human interacted with the authenticator; it does not confirm which specific person did so. That distinction separates TUP from user verification (UV), which attempts to verify the identity of a specific user via a PIN or biometric. Treating a presence check as if it proved identity would overstate the assurance provided and could lead to authorization decisions that assume more than the mechanism supports. In deployments where confirming the specific user matters, UV rather than TUP alone is the appropriate control.

In practice, TUP is a foundational building block in FIDO-based authentication rather than a complete authentication solution on its own. According to FIDO Alliance guidance, community discussion, and vendor documentation, its value lies in guaranteeing that each relevant operation is accompanied by a deliberate user action. Understanding its scope helps teams choose correctly between a lightweight presence check and stronger user verification based on the sensitivity of the operation being protected.

Who it's relevant to

Security architects
Architects designing FIDO-based authentication must decide, per operation, whether a presence check is sufficient or whether user verification is required. Understanding that TUP confirms a human is present but not which human helps them match the assurance level of a control to the sensitivity of the action being authorized, and avoids overstating what a touch or tap actually proves.
IAM engineers
Engineers integrating security keys and WebAuthn/FIDO authenticators need to configure and test presence prompts correctly, recognizing that prompt behavior and enforcement depend on the authenticator implementation and the invoking profile. They should ensure sensitive operations are not able to execute silently and that presence is tied to the specific operation being authorized rather than a generic acknowledgment.
Compliance and audit leads
Reviewers assessing authentication controls should distinguish a Test of User Presence from user verification when evaluating whether a control demonstrates deliberate human approval versus verified user identity. Documenting which mechanism protects a given operation supports accurate claims about the assurance provided and avoids conflating presence with identity confirmation.

Inside TUP

User Presence Signal
A boolean-style indication that a human is physically present and interacting with the authenticator at the moment of the operation, typically satisfied by a simple gesture such as a touch, tap, or button press.
UP Flag in Authenticator Data
In WebAuthn and FIDO2 (CTAP) flows, the result of a Test of User Presence is conveyed via the User Present (UP) flag within the authenticator data structure returned to the relying party during registration or authentication.
Distinction from User Verification
TUP only confirms that someone is present, not who they are. User Verification (UV), for example a PIN, fingerprint, or facial match, establishes identity of the user, whereas presence establishes only interaction. The two are represented by separate flags (UP versus UV).
Anti-Automation Purpose
The test is intended to defend against silent, remote, or automated invocation of an authenticator by requiring a deliberate human action, ensuring the operation is not performed without the user's awareness.
Gesture Mechanism
The presence gesture is typically deliberately simple and does not necessarily involve any inherence, knowledge, or possession factor being verified; it is a proof of interaction rather than a proof of factor.

Common questions

Answers to the questions practitioners most commonly ask about TUP.

Does test of user presence (TUP) verify who the user is?
No. TUP only confirms that a human is physically present and interacting with the authenticator at the moment of the operation, for example by touching a sensor or activating a button. It does not identify the user or verify their identity. TUP is distinct from user verification (UV), which establishes that a specific enrolled user is present through a PIN, biometric, or similar inherence or knowledge factor. Treat TUP as evidence of presence, not as an authentication factor that tells you which principal is acting.
Is passing a test of user presence the same as completing multi-factor authentication?
No. TUP by itself is not a factor in the MFA sense and does not on its own constitute two or more distinct factors. A simple presence gesture demonstrates that someone is there, but it does not, on its own, prove possession plus knowledge or inherence. Whether a ceremony rises to MFA depends on how presence combines with other checks such as user verification and possession of the authenticator, and this varies by authenticator and configuration. Do not assume a presence test alone satisfies MFA requirements.
How do we distinguish a test of user presence from user verification when configuring an authenticator?
In most deployments the distinction is expressed through relying party or authenticator policy settings that indicate whether user verification is required, preferred, or discouraged, separately from the presence check. Presence is typically the baseline gesture confirming a human is interacting, while user verification adds a specific check tied to the enrolled user. Review your relying party configuration and the authenticator's reported results to confirm which was actually performed; the exact flags and behavior depend on the authenticator and the profile in use.
How can a relying party confirm that a test of user presence actually occurred?
Typically the relying party inspects the signed attestation or assertion data returned by the authenticator, where presence and verification outcomes are reported as part of the ceremony result. Because that data is signed by the authenticator, the relying party can validate the signature to establish integrity of the reported result. Note that a signature confirms integrity and origin of the data, not confidentiality. The specific fields and their semantics depend on the authenticator and the standard profile in use, so validate against the relevant specification for your deployment.
When should we require user verification in addition to a test of user presence?
This depends on the risk profile of the operation and your policy. For lower-risk actions, a presence check may be sufficient in some deployments, while higher-risk operations often warrant requiring user verification so the ceremony ties the action to a specific enrolled user. This is a policy decision configured at the relying party and should align with your authentication assurance and step-up authentication strategy. There is no single correct setting; it varies by context, regulatory requirements, and the sensitivity of the resource being accessed.
What are the limitations of relying on a test of user presence for sensitive operations?
TUP confirms only that a human is interacting at that moment; it does not establish which user is present, and on its own it does not provide the identity assurance that user verification does. For sensitive operations, presence alone is generally insufficient because it cannot distinguish an authorized enrolled user from any person with physical access to the authenticator. In most deployments, combine presence with user verification and appropriate possession checks, and align the requirement with your authorization and step-up policies. The precise protections offered depend on the authenticator and configuration.

Common misconceptions

Test of User Presence authenticates the user.
TUP does not authenticate anyone. It only confirms a human is interacting with the authenticator. Authentication, establishing who the principal is, depends on User Verification and the underlying credential, which are separate concerns from presence.
User Presence and User Verification are the same thing.
They are distinct and are signaled by separate flags (UP versus UV) in authenticator data. Presence proves interaction; verification proves the identity of the interacting user, typically via a PIN or biometric. A ceremony can satisfy presence without satisfying verification, depending on configuration.
Requiring a presence gesture provides multi-factor assurance.
A presence gesture such as a touch is not, by itself, a possession, knowledge, or inherence factor being verified. It defends against silent automated use but does not add an authentication factor; factor assurance comes from the credential and any User Verification step.

Best practices

Decide explicitly whether an operation requires only User Presence (UP) or also User Verification (UV), and configure the relying party policy accordingly rather than treating presence as sufficient for identity assurance.
Validate the UP flag in the returned authenticator data on the server side during both registration and authentication ceremonies, and do not rely solely on client-side behavior.
Document in your access design that TUP addresses anti-automation and awareness, and pair it with appropriate User Verification when the flow demands proof of who the user is.
Where higher assurance is needed, require the UV flag in addition to UP and confirm the authenticator actually performed verification, since presence alone typically does not establish an authentication factor.
Test authenticator behavior across the vendors and platforms in your deployment, as the exact gesture and how presence is enforced can vary by authenticator and configuration.
Keep governance and lifecycle decisions (which authenticators are registered and permitted) separate from the runtime presence check, and audit both independently.
Application Security Isn’t Optional Anymore.