Category: Authentication Factors

Something You Have

Also known as: Possession Factor, Possession-Based Authentication Factor

Simply put

"Something you have" is one of the categories of authentication factors, referring to a physical or digital item a person possesses to prove their identity, such as a smart card or a security token. It is used to confirm who someone is during login, often alongside a password or biometric. Because the item must be in the user's possession, it removes the problem of having to remember information, though the object itself must be kept with the user.

Formal definition

The possession factor is one of the classical authentication factor categories, distinct from knowledge factors (something you know, e.g., a PIN or password) and inherence factors (something you are, e.g., a biometric). It authenticates a principal based on demonstrated possession of an item, which may be a cryptographic identification device, a hardware token, a smart card, or a private key secured within a hardware security processor. In multi-factor authentication, a possession factor is combined with a factor from a different category to strengthen assurance; note that this factor addresses only the authentication step (verifying identity) and does not by itself determine authorization. The strength of a possession factor depends on implementation: hardware-backed cryptographic keys typically provide stronger assurance than shared-secret tokens, but specific security properties vary by device, protocol, and deployment configuration.

Why it matters

The possession factor is a foundational building block of multi-factor authentication, and its value lies in binding identity verification to something a user physically or digitally holds rather than something they merely know. Because a possession factor removes the problem of forgetting a memorized secret, it addresses a distinct failure mode from knowledge factors: a password can be phished, guessed, or reused across sites, whereas an attacker generally must obtain the actual item to satisfy a possession check. When combined with a factor from a different category, such as a knowledge or inherence factor, the possession factor materially raises the assurance of the authentication step.

The strength a possession factor delivers depends heavily on implementation. A private key secured within a hardware security processor can serve as a robust possession factor, enabling strong authentication because the key material typically cannot be extracted from the device. By contrast, a shared-secret token relies on a value that may be intercepted or replayed depending on the protocol, so the same broad category can span a wide range of real-world security properties. Architects should not treat all possession factors as equivalent; the device, protocol, and deployment configuration determine the actual guarantees.

It is important to keep scope clear: a possession factor addresses only authentication, the step of verifying who a principal is. It does not by itself determine authorization, which governs what that principal may do once authenticated. Because the physical or digital object must remain with the user, deployments must also account for the operational realities of possession, such as the item being kept with the user and the consequences if it is not.

Who it's relevant to

Security Architects

Architects selecting authentication factors need to distinguish among possession-factor implementations, since hardware-backed cryptographic keys typically provide stronger assurance than shared-secret tokens. Understanding that the possession factor addresses only the authentication step, and not authorization, helps keep access-flow designs precise.

IAM Engineers

Engineers implementing multi-factor authentication must ensure a possession factor is paired with a factor from a different category to genuinely strengthen assurance, rather than combining two items of the same type. They also handle the operational concerns of provisioning and maintaining devices that must stay in the user's possession.

Compliance Officers

Compliance leads evaluating authentication controls should recognize possession as one of the classical factor categories distinct from knowledge and inherence factors, and should note that the strength of a possession factor varies by implementation rather than assuming a uniform level of assurance across deployments.

System Administrators

Administrators managing login flows deal with the practical trade-off that a possession factor removes the burden of remembering a secret but requires the physical or digital object to remain with the user, along with the consequences when that item is lost or unavailable.

Inside Something You Have

Possession Factor

"Something you have" is one of the three canonical authentication factor categories, alongside knowledge factors (something you know) and inherence factors (something you are). It establishes authentication assurance by requiring the user to demonstrate control of a physical or logical object during the authentication step.

Hardware Security Keys

Dedicated physical devices, such as FIDO2/WebAuthn authenticators, that hold cryptographic key material and perform challenge-response operations. In most deployments the private key never leaves the device, which reduces exposure to phishing and credential replay relative to shared-secret possession factors.

OTP Tokens (Hardware and Software)

Devices or applications that generate one-time passcodes, typically time-based or counter-based. Hardware OTP fobs and software authenticator apps both serve as possession factors, though their security properties differ depending on how the underlying seed is provisioned and stored.

Mobile Devices and Push Authenticators

Smartphones acting as possession factors via authenticator apps, push-approval prompts, or device-bound keys. The strength of this factor depends on configuration, including whether the credential is bound to hardware-backed key storage and whether push prompts include phishing-resistant context.

Smart Cards and PKI Tokens

Cards or tokens containing certificates and private keys used in certificate-based authentication. They demonstrate possession by performing cryptographic operations that prove control of the private key without disclosing it.

Passkeys

Discoverable FIDO credentials that can be device-bound or synced across a user's devices. Passkeys function as a possession factor (and, when unlocked with a local PIN or biometric, contribute an additional factor), but passkeys, FIDO2, and WebAuthn are related components rather than interchangeable synonyms.

Common questions

Answers to the questions practitioners most commonly ask about Something You Have.

Is a password a 'something you have' factor because you store it in a password manager?

No. A password is a knowledge factor (something you know), regardless of where it is stored. Placing it in a password manager changes how it is stored and retrieved but does not change its factor category. A possession factor requires demonstrating control of a distinct physical or cryptographic object, such as a hardware security key or a device holding a private key, rather than reciting a secret.

Does using a possession factor by itself count as multi-factor authentication?

No. MFA requires two or more factors drawn from different categories (knowledge, possession, inherence). A possession factor used alone is single-factor authentication. It becomes part of MFA only when combined with a factor of a different type, such as a PIN (knowledge) or a biometric (inherence). Note that in many FIDO2/WebAuthn deployments the authenticator itself may verify a local PIN or biometric, which can satisfy multiple factors depending on configuration.

How do I distinguish a genuine possession factor from a knowledge factor delivered to a device?

The distinction depends on what is actually proven. A hardware security key or a device holding a non-exportable private key demonstrates possession of the object itself. By contrast, a one-time code sent to a device that the user then reads and types back typically proves receipt but is often treated as a weaker possession signal, because the code can be phished or intercepted depending on the channel. Cryptographic possession factors that never transmit a reusable secret are generally considered stronger.

What options exist for provisioning and recovering possession factors across an enrolled user base?

In most deployments this involves an enrollment step that binds the factor to the identity, plus a recovery path for lost or replaced devices. Considerations typically include supporting more than one registered authenticator per user, defining fallback methods, and setting policies for re-enrollment. The strength of the recovery process matters, because a weak recovery flow can undermine an otherwise strong possession factor. Specific capabilities vary by vendor and standard profile.

How does a possession factor relate to phishing-resistant authentication?

Not all possession factors are equally phishing-resistant. Factors based on public-key cryptography that bind the authentication to the origin, such as FIDO2/WebAuthn credentials, are typically considered phishing-resistant because the private key never leaves the authenticator and the assertion is scoped to the relying party. Possession factors that rely on transcribing a code, such as some OTP methods, generally offer weaker phishing resistance because the code can be relayed to an attacker.

Where does a possession factor fit in a step-up authentication flow?

In many deployments a possession factor is invoked as an additional challenge when a session or transaction requires higher assurance, rather than at every authentication. This is an authentication assurance decision and is separate from authorization, which determines what the authenticated principal may do. The policy that triggers step-up is typically evaluated at runtime based on risk signals, resource sensitivity, or context, depending on configuration.

Common misconceptions

Using a possession factor means you are doing MFA.

A single possession factor by itself is single-factor authentication. MFA requires factors from at least two distinct categories (for example, possession plus knowledge or inherence). Two possession factors alone do not constitute MFA in the strict sense.

All possession factors offer equivalent security.

Security varies significantly by mechanism and configuration. Phishing-resistant, hardware-bound cryptographic authenticators typically provide stronger assurance than shared-secret OTPs, which can be phished, replayed within their validity window, or compromised if the seed is exposed.

Possession factors authorize what a user can do.

"Something you have" contributes only to authentication, verifying that the presenter controls the expected object. Authorization, the determination of what the authenticated principal may access, is a separate step handled by access control models and enforcement points.

Best practices

Combine a possession factor with a factor from a different category (knowledge or inherence) when MFA is the goal, rather than treating any single possession factor as multi-factor.

Prefer phishing-resistant, hardware-bound cryptographic authenticators (such as FIDO2/WebAuthn security keys or device-bound passkeys) over shared-secret OTP methods where the deployment and user base support them.

Protect OTP seed provisioning and storage, since the assurance of OTP-based possession factors depends on keeping the underlying seed confidential.

Define and enforce lifecycle procedures for issuing, rotating, and revoking possession factors, including immediate revocation when a device is lost, stolen, or decommissioned.

Provide vetted backup or recovery authenticators so that loss of a single possession factor does not lock users out or drive them toward weaker fallback methods.

Verify that push-based possession factors include phishing-resistant context and rate limiting to reduce the risk of prompt-fatigue and unauthorized approval.