Category: Authentication Factors

Possession Factor

Also known as: Something You Have, Ownership Factor

Simply put

A possession factor is a way of proving who you are during login by demonstrating control of a physical or digital item you have, such as a phone, a hardware key, or a smart card. It is one of the standard categories of authentication factors, alongside something you know (knowledge) and something you are (inherence). Requiring a possession factor helps ensure that simply knowing a password is not enough to gain access.

Formal definition

A possession factor is one of the three commonly recognized authentication factor types (possession, knowledge, and inherence) used to verify a claimant's identity by demonstrating control over something the user has, such as a mobile device, email account, hardware token, or smart card. In practice, possession-based authenticators are frequently combined with other factor types to satisfy multi-factor authentication requirements, since factor categories are distinguished by their nature (something you have versus something you know or are) rather than by strength alone. Implementation details, such as whether the possession is proven via a device-bound non-exportable credential, a hardware token, or an out-of-band channel like email, vary by authenticator and deployment configuration; some methods described as possession-based (for example, email-based verification) provide weaker assurance than device-bound cryptographic credentials. Vendor platforms may also allow ordering of factor prompts, for example requesting a possession factor before a password, depending on configuration. This entry addresses the possession factor as an authentication concept and does not cover authorization decisions.

Why it matters

The possession factor is one of the three foundational authentication factor categories, and it exists to close a gap that knowledge factors alone cannot. A password can be phished, guessed, reused across sites, or leaked in a breach without the legitimate user ever knowing. Requiring proof that the claimant also controls a specific item, a mobile device, hardware token, or smart card, means that a stolen or cracked password is typically insufficient on its own to gain access. This is why possession factors are central to most multi-factor authentication (MFA) deployments.

However, treating all possession factors as equivalent is a common and consequential mistake. The category is defined by the nature of the proof (something you have), not by its strength. An email-based one-time code and a device-bound, non-exportable cryptographic credential both qualify as possession factors, yet they offer very different levels of assurance. Out-of-band channels such as email can be compromised through account takeover or interception, whereas device-bound credentials are far harder to export or replay. Security architects should therefore evaluate the specific authenticator implementation rather than assuming that the possession category alone guarantees robust protection.

Deployment configuration also shapes how possession factors are used in practice. Some vendor platforms, such as Okta, allow administrators to order factor prompts, for example, requesting a possession factor before a password, which can change the login flow and user experience depending on how the environment is set up. Understanding these configuration options matters when designing flows that balance assurance with usability.

Who it's relevant to

IAM Engineers and Security Architects

Those designing authentication flows need to select possession-based authenticators that match their assurance requirements. Because the possession category spans everything from email-based codes to device-bound non-exportable credentials, engineers should evaluate the specific implementation rather than the category label, and understand configuration options such as prompt ordering that vendor platforms may expose.

System Administrators

Administrators configure and enforce MFA policies that incorporate possession factors, and they manage settings such as whether a possession factor is requested before or after a password. On platforms like Okta, these ordering options are configurable, so administrators must understand how their choices affect both the login flow and the resulting user experience.

Compliance Officers and Identity Governance Leads

Those responsible for meeting MFA and access assurance requirements should recognize that not all possession factors provide equivalent assurance. Documenting which authenticator types are in use, and distinguishing weaker out-of-band methods such as email from stronger device-bound cryptographic credentials, supports accurate risk assessment and defensible compliance positions.

Inside Possession Factor

Possession Factor Definition

An authentication factor category based on something the user has, as distinct from knowledge factors (something the user knows) and inherence factors (something the user is). It contributes to authentication by proving control over a physical or digital object.

Hardware Security Keys

Physical devices, such as FIDO2-capable authenticators, that the user physically possesses and uses during authentication. In most deployments these interact with WebAuthn ceremonies to demonstrate possession of the device holding a private key.

Registered Mobile Devices

Smartphones or tablets enrolled as authenticators, typically via an authenticator app generating one-time codes or via push-based approval. Possession is inferred from control of the enrolled device, depending on configuration.

OTP Generators

Hardware or software tokens that produce time-based or event-based one-time passwords. The possessed element is the seed or device that generates the code, not the code value itself, which is a transient artifact.

Smart Cards and Certificates

Physical cards or embedded credentials holding cryptographic key material. Possession is demonstrated by proving control of the private key associated with the card during an authentication exchange.

Relationship to MFA and 2FA

A possession factor is one category that can be combined with knowledge or inherence factors to satisfy multi-factor or two-factor authentication requirements. A possession factor alone provides single-factor authentication.

Common questions

Answers to the questions practitioners most commonly ask about Possession Factor.

Is a possession factor the same as multi-factor authentication?

No. A possession factor is a single category of authentication factor (something you have), alongside knowledge factors (something you know) and inherence factors (something you are). Multi-factor authentication requires factors from two or more distinct categories. Using a possession factor by itself is single-factor authentication; combining it with, for example, a knowledge factor is what produces MFA. A possession factor is a building block, not MFA in itself.

Does presenting a possession factor mean the user has been authorized?

No. A possession factor contributes to authentication, which verifies that a principal is who they claim to be. Authorization is a separate step that determines what an authenticated principal may do, typically evaluated after authentication completes. Successfully proving possession of a factor establishes identity assurance for that authentication event; it does not by itself grant access to any resource. Access decisions depend on the authorization policies applied afterward.

How do hardware security keys serve as a possession factor in practice?

In most deployments, a hardware security key demonstrates possession by holding a private key that never leaves the device and by producing a signed challenge response during authentication. The relying party verifies the signature against a registered public key. Because the possession proof is cryptographic rather than a transmitted secret, this approach is generally more resistant to phishing and replay than possession signals derived from transmitted one-time codes, depending on the protocol and configuration in use.

Are one-time passcodes sent by SMS considered a reliable possession factor?

SMS-delivered one-time passcodes are commonly used as a possession signal on the assumption that the user controls the associated phone number. However, this binding can be weakened by SIM-swapping, number porting, and interception, so many security teams treat SMS as a lower-assurance possession factor. Whether it is acceptable typically depends on the risk profile of the protected resource and any applicable assurance requirements in your environment.

How should possession factors be handled when a device is lost or replaced?

Possession-factor lifecycle handling typically requires the ability to deregister the lost factor and enroll a replacement, along with a vetted recovery path that does not silently downgrade assurance. In most deployments, this means maintaining backup authenticators or recovery mechanisms so that loss of a single device does not permanently lock a user out, while ensuring the recovery process itself is not a weaker point than the possession factor it restores. The exact enrollment and revocation workflow depends on vendor and configuration.

Can step-up authentication rely on a possession factor?

Yes. Step-up authentication requests additional or stronger verification for higher-risk actions, and a possession factor is frequently used for that additional challenge. For example, a session established with a knowledge factor might require a possession-based proof before a sensitive operation proceeds. The suitability of a given possession factor for step-up depends on the assurance level required for the specific action and on how the step-up policy is configured in the deployment.

Common misconceptions

A one-time password code is itself the possession factor.

The possession factor is the device or seed that generates or receives the code, not the code value. The code is a transient proof that the user controls the possessed object; treating the code as the factor conflates the artifact with the object being possessed.

Using a possession factor automatically means the authentication is multi-factor.

A possession factor used on its own is single-factor authentication. MFA requires combining factors from distinct categories, such as possession plus knowledge or possession plus inherence. Two possession-based methods together do not typically satisfy true multi-factor requirements.

All possession factors provide equivalent assurance.

Assurance varies by mechanism and configuration. For example, cryptographic hardware authenticators used in WebAuthn ceremonies generally resist phishing better than transmitted one-time codes, which can be intercepted or relayed. The level of protection depends on the specific method and deployment.

Best practices

Prefer phishing-resistant possession factors, such as FIDO2 hardware authenticators used through WebAuthn, over transmitted one-time codes where the threat model and deployment support it.

Combine the possession factor with a factor from a different category (knowledge or inherence) when multi-factor authentication is required, rather than pairing two possession-based methods.

Maintain a secure enrollment and re-enrollment process so that binding a device or key to an identity is verified, since possession assurance depends on the integrity of registration.

Provide and govern backup or recovery authenticators so that loss of a possessed device does not create lockout, while ensuring recovery paths do not weaken the overall assurance level.

Define clear deprovisioning and revocation procedures for lost, stolen, or retired devices and keys, coordinating with identity lifecycle processes so stale possession factors cannot be used.

Evaluate the assurance level of each possession mechanism against the sensitivity of the protected resource, and apply step-up authentication where higher-assurance possession factors are warranted.