Skip to main content
Identity Authority
Category: Authentication Factors

Something You Are

Also known as: Inherence Factor, Biometric Factor
Simply put

"Something you are" describes a category of authentication that verifies identity based on a person's physical or behavioral traits, such as a fingerprint, facial features, or voice. It is one of the classic factor types used to confirm that someone is who they claim to be, alongside "something you know" (like a password) and "something you have" (like a security key). Because these traits are inherent to the individual, they are meant to be difficult for someone else to replicate.

Formal definition

"Something you are" is the inherence category of authentication factors, one of the three canonical factor types distinguished in multi-factor authentication alongside knowledge factors ("something you know") and possession factors ("something you have"). It relies on measurable physiological or behavioral characteristics of a principal, for example fingerprint, face, iris, or voice patterns, captured and matched against an enrolled template during the authentication step. Note that inherence factors verify identity (authentication) and do not by themselves determine what a principal may access (authorization); behavioral traits sometimes described as "something you do" are treated by some practitioners as a distinct factor category rather than part of inherence, and this classification is not universally settled. The evidence packet does not provide detail on specific biometric standards, matching algorithms, or template protection methods, so those are out of scope for this entry.

Why it matters

Inherence factors matter because they address a fundamental weakness of the other two factor categories: knowledge factors like passwords can be shared, guessed, or phished, and possession factors like security keys can be lost, stolen, or handed off. A trait that is inherent to an individual is meant to be difficult for someone else to replicate, which is why "something you are" is frequently combined with a knowledge or possession factor to build multi-factor authentication. When correctly deployed as one factor among several, inherence can raise the assurance that the principal presenting credentials is the enrolled individual rather than someone who merely holds a shared secret or a device.

At the same time, the category carries limitations that IAM practitioners must weigh. Unlike a password, an inherent trait cannot be reset or reissued if the underlying template or the matching process is compromised, so the consequences of a failure differ in kind from those of knowledge or possession factors. Because inherence factors verify who a principal is (authentication) and do not by themselves determine what that principal may access (authorization), they should never be treated as a substitute for authorization controls. Practitioners should be careful not to assume that adding a biometric automatically produces multi-factor authentication; the classification and independence of the factors involved still have to hold.

There is also genuine ambiguity at the edges of the category. Behavioral traits sometimes described as "something you do" are treated by some practitioners as a distinct factor category rather than as part of inherence, and this classification is not universally settled. Teams designing authentication policies should agree on how they categorize such traits so that claims about factor count and factor independence remain consistent and auditable.

Who it's relevant to

Security Architects
Architects deciding how to combine factors into a multi-factor authentication design need to treat inherence as one distinct factor category alongside knowledge and possession factors, and to confirm that combined factors are genuinely independent. They should also account for the fact that an inherent trait cannot be reset like a password, which affects how failures are handled in the overall design.
IAM Engineers
Engineers implementing authentication flows should treat inherence checks strictly as part of the authentication step that verifies who a principal is, keeping them separate from authorization decisions about what the principal may access. Where behavioral traits are involved, engineers benefit from a clear, agreed classification of whether those count as inherence or as a separate "something you do" category, since this affects factor counting.
Compliance Officers and Auditors
Those reviewing authentication policies need consistent definitions of factor categories to assess whether a deployment truly meets multi-factor requirements. Because the classification of behavioral traits is not universally settled, auditors should confirm that an organization documents how it categorizes such traits so that claims about factor independence and count can be evaluated reliably.

Inside Something You Are

Inherence Factor
"Something You Are" is the inherence category of authentication factors, distinct from knowledge factors (something you know, such as a password) and possession factors (something you have, such as a security key). It relies on a biological or behavioral trait of the principal to support authentication, which is the step of verifying who a principal is, not authorization.
Physiological Biometrics
Traits based on physical characteristics, such as fingerprints, facial geometry, iris or retina patterns, and voiceprints. These are captured by a sensor and compared against a stored reference template during authentication.
Behavioral Biometrics
Traits based on patterns of behavior, such as typing rhythm, gait, or interaction patterns. Depending on the deployment, these may be used for continuous or risk-based signals rather than a single discrete authentication event.
Biometric Template
A stored mathematical representation derived from a captured biometric sample, used as the reference for matching. In most deployments the raw biometric is not stored directly; templates are generated for comparison and should be protected.
Matching and Thresholds
Inherence verification is probabilistic rather than exact. Matching relies on a similarity score compared against a configured threshold, producing trade-offs typically expressed as false acceptance rate (FAR) and false rejection rate (FRR) depending on how the threshold is tuned.
Local vs. Server-Side Verification
Biometric matching may occur on the user's device (for example, unlocking a local authenticator) or against a central store, depending on the architecture. In FIDO2/WebAuthn passkey flows, biometrics typically unlock a device-resident credential locally rather than transmitting the biometric to a relying party.

Common questions

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

Is 'something you are' more secure than a password simply because biometrics can't be forgotten or guessed?
Not inherently. While inherence factors avoid some weaknesses of knowledge factors (they can't be forgotten and aren't easily guessed), they carry distinct risks. Biometric traits are not secret, faces, fingerprints, and voices are often observable or capturable, and unlike a password, a compromised biometric generally cannot be reissued. In most deployments the security benefit comes from combining an inherence factor with other factors in an MFA design and from the strength of the capture, matching, and liveness-detection implementation, not from the factor category alone.
Does using a fingerprint or face scan mean the system is storing and comparing my actual biometric image?
Typically no. Most implementations derive a mathematical template or feature representation from the biometric sample rather than retaining the raw image, and matching is performed against that template. Depending on the architecture, the template and matching may reside on a local device (for example, in a secure element on a phone) rather than on a central server. The exact storage location, template format, and whether raw samples are ever retained vary by vendor and deployment, so this should be verified against the specific product and its documentation.
How does a biometric factor fit into a broader authentication flow alongside other factors?
An inherence factor is one of the three factor categories, knowledge (something you know), possession (something you have), and inherence (something you are). To qualify as MFA, an authentication event must combine factors from different categories, so a biometric is typically paired with a possession or knowledge factor rather than used alone. It is also commonly used as part of step-up authentication, where a higher-assurance check is requested before sensitive operations, depending on policy configuration.
What is the difference between a device-local biometric check and a server-side biometric authentication?
In a device-local model, the biometric match happens on the user's device and the device then asserts a successful check to the relying party, for example, in passkey or WebAuthn flows, a local inherence check can unlock a possession-based authenticator, but the biometric itself is generally not transmitted. In a server-side model, biometric data or templates are sent to and matched by a central service. The two models have very different privacy, storage, and attack-surface characteristics, so the choice should be aligned with your assurance and data-protection requirements.
Why is liveness detection considered important when deploying an inherence factor?
Because a biometric trait is observable rather than secret, an attacker may attempt to present a copy, such as a photo, recording, or replica, instead of the live subject. Liveness detection aims to distinguish a genuine, present subject from such presentation attacks. Its effectiveness varies by modality and implementation, so in most deployments it should be treated as a configurable, testable control whose assurance level is validated rather than assumed.
What should be planned for when a biometric factor is compromised or unavailable?
Because a compromised biometric generally cannot be reissued the way a password or key can, deployments should plan recovery and fallback paths that do not depend solely on the inherence factor. This typically includes alternative authentication methods, enrollment and re-enrollment procedures, and handling for cases where a biometric cannot be captured (for example, injury or sensor failure). Governance concerns such as who can re-enroll a user and how that is reviewed fall under identity administration processes and should be defined separately from the runtime matching mechanism.

Common misconceptions

Biometrics are a form of password and can be reset like one.
Unlike knowledge factors, inherence traits are generally not revocable or replaceable if compromised, since they are tied to the individual. This is a key limitation practitioners must account for, and it argues against treating biometrics as the sole factor.
In FIDO2/WebAuthn, the biometric itself is sent to the server to authenticate the user.
In most passkey and WebAuthn deployments, the biometric is used locally to unlock a device-bound credential, and it is the resulting cryptographic assertion, not the biometric, that reaches the relying party. WebAuthn, FIDO2, and passkeys are related but not interchangeable terms, and the biometric is one possible user-verification method within them.
A biometric factor alone constitutes multi-factor authentication.
A single inherence factor is one factor. MFA requires factors from two or more distinct categories (knowledge, possession, inherence). A biometric contributes to MFA only when combined with a factor from another category; used alone it is single-factor authentication.

Best practices

Treat inherence as one factor within a broader MFA design, combining it with a possession or knowledge factor rather than relying on biometrics alone.
Prefer architectures that perform biometric matching locally on the device and release only a cryptographic assertion, as is typical in FIDO2/WebAuthn passkey flows, to avoid transmitting or centrally storing raw biometrics.
Protect biometric templates at rest and in transit, and account for the fact that a compromised inherence trait generally cannot be reset or reissued.
Tune matching thresholds deliberately, balancing false acceptance and false rejection rates against the risk profile of the resource being protected.
Provide accessible fallback or step-up authentication paths for cases where a biometric cannot be captured or matched, so users are not locked out due to sensor or trait limitations.
Scope biometrics to authentication only, and keep authorization decisions in the appropriate access control model (for example RBAC, ABAC, or PBAC) rather than deriving permissions from the inherence factor itself.
Promotional banner for the Penetration Report Template Kit