Authentication factors: the five categories

Why dedicate a whole article to factors

Factors are what the subject presents to prove they are themselves. They can be as trivial as a memorized password or as sophisticated as a cryptographic key signed by secure hardware. Each one has strengths, weaknesses, costs, and ideal use cases. If you only know “password + SMS OTP,” you’re halfway into the 21st century — between 2010 and 2026 a whole universe of new factors emerged (passkeys, biometrics with liveness, contextual, behavioral) that change the rules of the game.

In this article we go through the five categories of factors, their most common implementations with pros and cons, the SFA/2FA/MFA nomenclature that many people use incorrectly, the concept of step-up authentication, and risk-based adaptive authentication. By the end you’ll have judgment to say, in any design you see: “this is robust” or “this is security theater.”

The five factor categories

Traditionally the industry talks about three classic categories (“something you know / have / are”) and two modern categories that gained weight in the last decade (“something you do” and context). We’ll treat them as five to reflect current reality:

flowchart TB
  accTitle: The five authentication factor categories
  accDescr: Top-down flowchart with authentication branching into five categories: something you know (password, PIN), something you have (phone, hardware key), something you are (fingerprint, face, iris, voice), something you do (typing, gestures), and context (location, time, device).
  AUTH([Authentication])
  AUTH --> KNOW[1. Something you know]
  AUTH --> HAVE[2. Something you have]
  AUTH --> ARE[3. Something you are]
  AUTH --> DO[4. Something you do]
  AUTH --> CTX[5. Context]
  KNOW --> K1[Password, PIN]
  HAVE --> H1[Phone, hardware key]
  ARE --> A1[Fingerprint, face, iris, voice]
  DO --> D1[Typing, gestures]
  CTX --> C1[Location, time, device]

Quick read: authentication has five possible pillars. Strong authentication combines factors from different categories. That’s why asking for password + PIN is not real MFA — they’re both things you know. Let’s go through them one by one.

Summary table of the five categories

#	Category	Examples	Relative strength
1	Something you know	Password, PIN, passphrase, security questions	Low to medium
2	Something you have	Smartphone, hardware key (YubiKey), smart card, certificate	Medium to high
3	Something you are	Fingerprint, face, iris, voice	High (with liveness)
4	Something you do	Typing pattern, gestures, movements	Auxiliary (not single factor)
5	Context	Geo, time, known device, behavior	Auxiliary (risk modulator)

Category 1: Something you know

Passwords

The password is still the most-used factor in the world. It’s also the weakest. The average human reuses passwords, writes them down, picks predictable ones, and forgets them. Decades of research show that almost every desirable password property fights with usability: if it’s complex enough to be secure, it’s hard to remember; if it’s easy to remember, it’s vulnerable.

Modern best practices (based on NIST SP 800-63B):

• Length over complexity: 12+ characters is more useful than rules like “1 uppercase + 1 number + 1 symbol.”
• Verify against leaked password lists: reject known passwords (Have I Been Pwned offers a free API).
• Don’t force periodic rotations without reason: forcing a change every 90 days makes things worse because people end up with Passport01!, Passport02!, etc.
• Always store with strong hashing: bcrypt, Argon2, scrypt — never plain MD5 or SHA-256.
• Hash without salt is indefensible; with salt + proper algorithm, much better.

PINs

PINs are a special case of password, typically numeric and short (4-6 digits). Although they look weak due to small space (10,000 to 1 million combinations), they’re acceptable when:

• They’re combined with another factor (not the only factor).
• There’s strict rate limiting (max N attempts before lockout).
• They’re tied to a specific device (the iPhone PIN only works on that iPhone).

Security questions: the classic anti-pattern

“What was your first pet’s name?” “On what street did you grow up?” These questions were popular in the 2000s and are today one of the most questioned practices in security. The answers are usually:

• Public: if you have Facebook, anyone can probably know your pet’s name.
• Forgeable: the attacker looks up your Instagram and has the information.
• Shared with family and friends: they aren’t secret.

If you still see security questions in a system in 2026, it’s a sign of an IAM program two decades behind.

Category 2: Something you have

TOTP and HOTP

TOTP (Time-based One-Time Password, RFC 6238) and HOTP (HMAC-based, RFC 4226) are the algorithms behind apps like Google Authenticator, Microsoft Authenticator, Authy. They work like this:

• The server and the user’s device share a secret seed (when you do the initial setup, you scan a QR code).
• Both derive a 6-digit code every 30 seconds from that seed + current time (TOTP) or a counter (HOTP).
• The user types that code; the server recalculates and compares.

Pros: works offline, doesn’t need SMS, free, standardized. Cons: the user has to copy 6 digits in 30 seconds, susceptible to real-time phishing (man-in-the-middle).

SMS OTP

Receiving a code by text message. Convenient and widely adopted, but technically weak:

• SIM swapping: an attacker convinces the carrier to port your number to their SIM. Takes minutes.
• SS7 protocol vulnerabilities that allow intercepting messages.
• Real-time phishing: the attacker captures the OTP and replays it in seconds.

NIST SP 800-63B has discouraged SMS OTP for AAL2 (medium-level authentication) since 2017. If you still use it, assume it’s the weakest link in your chain.

Email OTP

Similar to SMS but via email. It’s only as secure as the email itself, which in practice means: it depends on how well-protected the email account is. If that account is protected only with a password, “email OTP” is essentially a single factor in disguise.

Push notifications

The user receives a notification in their app (Microsoft Authenticator, Duo, Okta Verify) and approves with a tap. More convenient than TOTP. But it introduced a new risk: MFA bombing or push fatigue.

The attacker, with the password already stolen, repeatedly fires push notifications at the victim. The victim, fed up or half-asleep, eventually approves one. Famous real case: the Uber breach in 2022.

Modern platforms mitigate this with number matching: instead of just approve/reject, the push shows a number the user must type into the originating app. That eliminates automatic approval.

Hardware keys (FIDO2 / WebAuthn)

A hardware key (YubiKey, Google Titan) generates a cryptographic key pair: the private key never leaves the device; the public one is registered on the server. To authenticate, the server sends a challenge, the key signs it with the private key, the server verifies with the public one.

Decisive pros:

• Phishing-resistant by design: the signature includes the origin (site URL); if you’re tricked to a fake site, the signature isn’t valid.
• No shared secret: a server leak doesn’t expose your credential.
• Resistant to man-in-the-middle.

Cons:

• Cost (the key costs $25-$50).
• If lost, recovery requires another factor.
• More friction-heavy UX than push notifications.

Smart cards and X.509 certificates

Cards containing a chip with a private key. Common in governments (digital ID, DNIe in Spain, CAC in the US military) and companies with high compliance requirements. They work like FIDO2 keys but in a different form factor.

Passkeys: the modern successor

Passkey is the synced version of WebAuthn. The private key lives in the OS keychain (iCloud Keychain, Google Password Manager, Windows Hello) and syncs between the same user’s devices.

Combines the best of several worlds:

• Phishing-resistant (like FIDO2).
• No passwords (real passwordless).
• Simple UX: “unlock with your face or fingerprint” instead of “type this string.”
• Works across devices: if you have iPhone + Mac, the passkey works on both.

Apple, Google, and Microsoft pushed passkeys massively between 2022 and 2024. By far the best “have” factor option for end users in 2026.

Category 3: Something you are (biometrics)

Fingerprint

The most mature and cheapest. Touch ID on iPhone, sensors on corporate laptops. The fingerprint is stored as a mathematical template (not the actual image) and, on modern devices, inside the chip’s Secure Enclave — inaccessible even to the operating system.

Limitations:

• If your hand is wet or dirty, it fails.
• Some people don’t generate good fingerprints (manual jobs, age).
• A fingerprint lifted with a silicone mold can fool cheap sensors.

Facial recognition

Face ID on iPhone, Windows Hello, modern access controls. Measures the 3D geometry of the face, not just a photo.

Important: there are two very different categories that get confused:

• Simple 2D facial (what a cheap webcam uses): vulnerable to printed photos and videos.
• 3D facial with liveness (Face ID, Windows Hello): measures depth, infrared, micro-movements. Much more robust.

Iris, voice, vein, handwriting

• Iris: very precise, used in airports. Requires specialized hardware.
• Voice: “say your phrase.” Vulnerable to deepfakes and recordings — by 2024 there are already documented cases of banking fraud via AI-cloned voice.
• Palm vein: used in Japan, high precision. Expensive hardware.
• Dynamic handwriting/signature: rare outside Asian banks.

Metrics that matter in biometrics

Metric	What it measures
FAR (False Accept Rate)	% of incorrect users the system accepts. The lower, the better.
FRR (False Reject Rate)	% of correct users the system rejects. The lower, the better.
EER (Equal Error Rate)	The point where FAR = FRR. Single metric to compare systems.
Liveness detection	Detects whether what’s presented is alive (not a photo, video, mask).
Anti-spoofing	Set of techniques to detect deception attempts.

Privacy and biometrics

Biometrics has a property that makes it different: it can’t be revoked. If your password leaks, you change it. If your fingerprint leaks, the fingerprint is the fingerprint — you don’t get a different one in the next life.

That’s why a good implementation never stores images of fingerprints or faces. It stores derived mathematical templates that (ideally) don’t allow reconstruction of the original image. And it never stores them in a central database that could be compromised — it stores them in the user’s device’s secure hardware.

Specific regulations:

• BIPA (Illinois Biometric Information Privacy Act): requires notice and explicit consent.
• GDPR Art. 9: treats biometrics as a special sensitive data category; high protection required.
• LFPDPPP (Mexico): includes biometrics in its sensitive data category.

Category 4: Something you do (behavioral biometrics)

This is the newest category and is still treated as an auxiliary factor, not a single factor. It measures unique patterns in how you behave:

• Keystroke dynamics: your rhythm, pauses, and typical typos when typing.
• Mouse movement: how you move it, where you click, what route you follow.
• Touch screen gestures: pressure, swipe speed, finger angle.
• App usage pattern: which screens you visit, in what order, at what time.

Characteristics:

• Works silently, without explicitly asking the user for anything.
• Gets learned over weeks or months to create a personal profile.
• Useful against ATO (account takeover): detects when “someone who types differently” enters the account.

Vendors: BioCatch, NuData (Mastercard), TypingDNA. Heavily used in banking due to its zero friction.

Category 5: Context

Strictly it’s not something the user “presents” as proof — it’s information the system observes about the request’s environment. But it plays the same role: raise or lower trust.

Contextual signal	What it tells about risk
IP geolocation	Login from a new country = high risk
Time of day	Login at 3 AM if you never do that = suspicious
Device fingerprint	Unique combination of device data (model, OS, fonts, plugins, resolution)
ASN / ISP	If the IP comes from a VPN or Tor, risk goes up
Impossible velocity	Login from Madrid at 14:00 and from Tokyo at 14:05 = impossible
Known device	If you’d never used this device before, higher risk

Context is rarely used as a single factor. Its value is in modulating the decision: passing your check from home with your usual laptop should be easy; passing your check from a new country on a new device should require additional factors.

SFA, 2FA, MFA: the nomenclature

Many people use these terms imprecisely. Let’s nail them down:

Single-Factor Authentication (SFA)

Only one factor is presented. Typically just the password. It’s the weakest model and should be out of any serious modern app. Cases where it still appears: legacy internal apps, low-sensitivity systems.

Two-Factor Authentication (2FA)

Exactly two factors from different categories. Valid examples:

• Password (know) + OTP in app (have).
• Password (know) + fingerprint (are).
• Hardware key (have) + PIN (know).

Invalid examples (not real 2FA):

• Password + PIN (both “know”).
• Two different fingerprints (both “are”).
• Password + security questions (both “know”).

Multi-Factor Authentication (MFA)

Two or more factors from different categories. It’s a superset of 2FA. The difference between 2FA and MFA in practice is semantic: 2FA is exactly two, MFA is two or more.

flowchart LR
  accTitle: SFA, 2FA, and MFA mapped to relative strength
  accDescr: Left-to-right flowchart with three branches: single-factor authentication mapping to weak, two-factor authentication with two different factors mapping to medium, and multi-factor authentication with two or more different factors mapping to strong.
  SFA[SFA - 1 factor] --> WEAK[Weak]
  TWOFA[2FA - 2 different factors] --> MED[Medium]
  MFA[MFA - 2 or more different factors] --> STRONG[Strong]

Step-up authentication

Step-up is requesting an additional factor mid-session, when the user is about to do something more sensitive than what their original login justified.

Examples:

• Logged in to view your balance: password + push.
• For a transfer over $1,000: ask for an additional PIN.
• To change the email associated with the account: ask for biometric.

Step-up is the practical implementation of “the higher the risk, the higher the authentication.” It doesn’t make sense to ask for all factors all the time — that destroys UX. But it does make sense to ask for them right when it matters.

Risk-based adaptive authentication (RBA)

RBA is the natural evolution of step-up: instead of fixed rules (“transfers > $1,000 require PIN”), the system calculates a real-time risk score and automatically decides how much friction to add.

How it works

flowchart TB
  accTitle: Risk-based adaptive authentication decision flow
  accDescr: Top-down flowchart starting from a login request, collecting context, behavior, and initial factor signals, feeding a risk engine that computes a 0 to 100 score, and branching to four outcomes based on score: low allows frictionless access, medium asks for a second factor, high asks for MFA plus step-up and alerts the SOC, and critical blocks and requires a manual reset.
  REQ[Login request] --> COLLECT[Collects signals]
  COLLECT --> SCORE[Risk engine computes 0-100 score]
  SCORE --> DEC{Score level}
  DEC -->|Low| OK[Frictionless access]
  DEC -->|Medium| MFA[Asks for second factor]
  DEC -->|High| STEP[MFA + step-up, alerts SOC]
  DEC -->|Critical| BLOCK[Blocks, requires manual reset]

Reading: every login request triggers an evaluation. The engine collects signals (where it’s coming from, what device it is, at what time, what typing pattern it presents, what credentials it showed) and computes a score. Based on the score, it scales progressively: lets it through smoothly, asks for MFA, asks for step-up, or blocks outright.

Typical signals that feed the score

• Identity-related: is the account new? how long ago was it created? does it have a clean history?
• Contextual: IP, geolocation, device, time, ISP/ASN.
• Behavioral: typing, movement, navigation, rhythm.
• Anomalies: is this the first time coming from this country? impossible velocity vs previous login?
• External intelligence: is the IP on blacklists? is the device reported as compromised?
• Ongoing counterattacks: is there massive credential stuffing in other accounts right now?

Concrete example: María at the bank

María enters her bank app on a Friday at 8 PM from her usual iPhone, in her usual neighborhood, with her known typing pattern. Score: low. The app only asks for her fingerprint. She’s in within 2 seconds.

The following Saturday, she tries to enter from a computer the system had never seen, in a café in another city, with a slightly different typing pattern (because she’s using a keyboard instead of her iPhone). Score: medium-high. The app asks for password + push notification to her iPhone + answering a challenge about her last transaction.

If she still tried an immediate transfer right after that login: the score goes up further, and the system asks for additional step-up (transactional PIN) or blocks the transfer until confirmation through an alternate channel.

María as a legitimate user passes all checks in extra seconds. An attacker with her password but without her iPhone, without her pattern, without her context — fails on one of the checks.

Typical RBA vendors

Vendor	Product	Notes
Microsoft	Entra ID Conditional Access	Integrated to the Microsoft stack
Okta	Adaptive MFA	Part of Workforce Identity Cloud
BioCatch	Behavioral analytics	Specialized in patterns
Transmit Security	Detection and Response	Focus on passwordless + RBA
RSA	RSA Risk-Based Authentication	Veteran of the segment

Sources for tracking the RBA market: Gartner Peer Insights — Access Management (RBA is a feature inside modern AM platforms), KuppingerCole Leadership Compass: Adaptive Authentication.

NIST AAL: assurance levels

To close, it’s worth connecting all of this with a formal standard. NIST SP 800-63B defines Authenticator Assurance Levels (AAL) that map factors with security levels:

AAL	Requirements	Valid examples
AAL1	Minimum: SFA acceptable	Password only
AAL2	MFA required (two different categories)	Password + push, password + TOTP, passkey
AAL3	MFA with phishing-resistant cryptographic factor + hardware	FIDO2 with hardware key + PIN

If you’re tasked with designing the authentication level of a system, this table is the reference: regular banking usually requires AAL2; government and high-value banking can require AAL3.

Recap

The five factor categories are the operational vocabulary of any serious conversation about authentication:

1. Something you know (passwords, PINs) — most common and weakest.
2. Something you have (TOTP, push, FIDO2, passkeys) — robust if well-implemented.
3. Something you are (biometrics) — strong with liveness, irrevocable if leaked.
4. Something you do (behavioral) — auxiliary, valuable for being silent.
5. Context — risk modulator, not a factor in itself.

The SFA / 2FA / MFA nomenclature comes down to the central rule: for it to count as real MFA, the factors must be from different categories. And the concepts of step-up and RBA are the modern techniques to avoid the classic “friction vs security” dilemma — only ask for what’s necessary, when it’s necessary, based on the real risk of the moment.

Three questions to test yourself

1. An app allows “double authentication” by asking for password + a 4-digit PIN. Is it real 2FA? Justify.
2. Design the step-up logic for an investment app: define at least four different actions and what level of authentication you’d ask for each.
3. Your CFO tells you “let’s implement RBA with a score from 0 to 100 and block any login above 60.” What three warnings would you give about that simplistic implementation?