Authentication factors: the five categories

One password, two outcomes

On a Sunday morning David gets two emails within a minute of each other. The first comes from his streaming service: “Your password was changed.” The second comes from his bank: “We blocked a sign-in attempt from a new device.” Someone had found the password he’d used on an old forum years ago, the one that leaked in a breach, and tried it everywhere. The streaming service only asked for the password, so the attacker got in and changed it. The bank asked for the passkey on David’s phone, which the attacker didn’t have, so the attempt went nowhere.

Same password, same attacker, same morning. The difference was the factors, what each service asked David to present to prove he was himself. Factors range from a memorized password to a cryptographic key sealed inside secure hardware, and each has strengths, weaknesses, costs, and cases where it fits. If all you know is “password plus SMS code,” you’re missing most of what changed between 2010 and 2026: passkeys, biometrics with liveness detection, contextual and behavioral signals.

In the previous article we placed authentication between identification and authorization. Here we open it up: the five categories of factors, their common forms with their trade-offs, the SFA, 2FA, and MFA terms that many people use loosely, step-up authentication, and risk-based adaptive authentication. By the end you should be able to look at any sign-in design and say whether it’s solid or security theater, and you’ll probably want to move a couple of your own accounts to passkeys.

The five categories

The industry traditionally talks about three classic categories, something you know, something you have, and something you are, plus two that gained weight over the last decade, something you do and context. We’ll treat them as five to reflect how things work today.

Knowledge factors are the most common and the weakest. Possession factors are solid when implemented well. Biometric factors are strong with liveness detection, but they can’t be revoked if they leak. Behavioral factors work silently and serve as support rather than as a factor on their own. And context doesn’t prove anything by itself; it raises or lowers how much proof the system asks for. Strong authentication combines factors from different categories, which is why a password plus a PIN isn’t real MFA.

Something you know

Passwords

The password is still the most used factor in the world, and the weakest. People reuse passwords, write them down, choose predictable ones, and forget them, as David’s old forum password shows. Decades of research show that almost every desirable property of a password fights with usability. Complex enough to be secure means hard to remember; easy to remember means easy to attack.

Current good practice, based on NIST SP 800-63B, favors length over complexity: twelve characters or more does more than rules like “one capital, one number, one symbol.” Check new passwords against lists of leaked ones and reject the known ones; Have I Been Pwned offers a free API for this. Don’t force periodic changes without a reason, because a change every 90 days just produces Passport01!, Passport02!, and so on. And always store passwords with a strong, salted hashing algorithm such as bcrypt, Argon2, or scrypt, never plain MD5 or SHA-256. An unsalted hash is indefensible.

PINs

PINs are a special kind of password, usually short and numeric, four to six digits. With only ten thousand to a million combinations they look weak, but they’re acceptable when they’re combined with another factor rather than used alone, when attempts are strictly limited before a lockout, and when they’re tied to one device. Your phone’s PIN only works on that phone, which changes the picture entirely.

Security questions

“What was your first pet’s name?” “What street did you grow up on?” These questions were popular in the 2000s and are now one of the most criticized practices in security. The answers are often public on social media, easy for an attacker to look up, and known to family and friends. If you still see security questions in a system in 2026, you’re looking at an IAM program two decades behind.

Passwords won’t disappear tomorrow, but the direction is clear: passwordless. Apple, Google, and Microsoft are pushing passkeys as a mass replacement. A new system designed in 2026 shouldn’t start with the password as its main factor. It should start with a passkey and keep the password as a fallback, not the other way round.

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, and Authy. During setup you scan a QR code, and the server and your device end up sharing a secret seed. From then on, both derive a six-digit code from that seed and the current time (TOTP) or a counter (HOTP). You type the code, and the server works it out on its side and compares. It works offline, needs no SMS, costs nothing, and is standardized. On the other hand, you have to copy six digits within thirty seconds, and a real-time phishing page can ask you for the code and use it immediately.

SMS codes

A code sent by text message is convenient and widely adopted, and technically weak. In a SIM swap, an attacker persuades the carrier to move your number to their SIM, which takes minutes. Weaknesses in the SS7 protocol allow messages to be intercepted. And real-time phishing captures the code and replays it within seconds. NIST SP 800-63B has discouraged SMS codes for AAL2 since 2017. If you still use them, assume they’re the weakest link in your chain.

Codes sent by email work the same way, and they’re only as secure as the email account. If that account is protected by a password alone, “email code” is really a single factor in disguise.

Push notifications

With push, the user gets a notification in an app such as Microsoft Authenticator, Duo, or Okta Verify and approves with a tap. It’s more convenient than TOTP, and it brought a new risk with it: MFA bombing, or push fatigue. An attacker who already has the password fires off notification after notification until the victim, annoyed or half asleep, approves one. That’s how Uber was breached in 2022. Modern platforms counter it with number matching: instead of a plain approve or reject, the notification shows a number the user has to type into the screen where they’re signing in, which rules out approving on reflex.

Hardware keys

A hardware key such as a YubiKey or a Google Titan implements FIDO2 and WebAuthn. It generates a key pair whose private key never leaves the device, and the public key is registered with the service. To authenticate, the server sends a challenge, the key signs it, and the server checks the signature with the public key. The signature includes the site’s origin, so if someone tricks you onto a fake site the signature won’t be valid there. There’s no shared secret, so a breach at the server doesn’t expose your credential, and an attacker sitting in the middle gets nothing useful. The downsides are cost, around $25 to $50 per key, the need for another factor to recover if you lose it, and a bit more friction than a push notification.

Smart cards and X.509 certificates work on the same principle in a different form: a card with a chip holding a private key. They’re common in government, such as national electronic ID cards or the CAC used by the U.S. military, and in companies with heavy compliance requirements.

Passkeys

A passkey is the synced version of WebAuthn. The private key lives in the operating system’s keychain, such as iCloud Keychain, Google Password Manager, or Windows Hello, and syncs across the same person’s devices. It combines the best of several worlds: it resists phishing like a hardware key, removes the password entirely, unlocks with a face or fingerprint instead of a typed string, and works on the phone and the laptop alike. Apple, Google, and Microsoft pushed passkeys hard between 2022 and 2024, and they’re now by far the best possession factor for ordinary users. It’s what saved David’s bank account.

Something you are

Fingerprints are the most mature and cheapest biometric: Touch ID on iPhones, sensors on corporate laptops. The fingerprint is stored as a mathematical template, not as an image, and on modern devices it lives inside the chip’s secure enclave, out of reach even of the operating system. Wet or dirty hands cause failures, some people’s fingerprints read poorly because of manual work or age, and a fingerprint lifted into a silicone mold can fool cheap sensors.

Facial recognition, as in Face ID or Windows Hello, measures the three-dimensional shape of the face. Two very different things get lumped together here. Simple 2D recognition, the kind a cheap webcam does, can be fooled by printed photos and videos. 3D recognition with liveness detection measures depth with infrared and watches tiny movements, and it’s far harder to fool.

Other biometrics have their niches. Iris scanning is very precise and used at airports, but needs special hardware. Voice (“say your passphrase”) has become vulnerable to deepfakes and recordings; since 2024 there have been documented bank frauds using AI-cloned voices. Palm-vein recognition is used in Japan and is very accurate, with expensive hardware. Dynamic signature recognition is rare outside some Asian banks.

A few measurements matter when comparing biometric systems.

Biometrics has one property that sets it apart: it can’t be revoked. If your password leaks, you change it. If your fingerprint leaks, it’s still your fingerprint for the rest of your life. That’s why a good implementation never stores images of fingerprints or faces, only derived templates that ideally can’t be turned back into the original. And it doesn’t keep them in a central database that could be breached; it keeps them in secure hardware on the user’s own device. A breach of central biometric templates is practically impossible to fix and affects the people involved forever, which is why payment systems like Apple Pay and Google Pay keep everything in the device’s secure enclave. Regulation reflects this: Illinois’s BIPA requires notice and explicit consent, GDPR Article 9 treats biometric data as a special, highly protected category, and Mexico’s LFPDPPP includes it among sensitive data.

Something you do

This is the newest category, and it’s still treated as a supporting factor rather than one that stands alone. It measures patterns in how you behave: your rhythm, pauses, and usual typos when typing; how you move the mouse and where you click; the pressure, speed, and angle of your swipes on a touch screen; which screens you visit in an app, in what order, and at what time. It works silently, without asking the user for anything, and it learns a personal profile over weeks or months. That makes it useful against account takeover, because it notices when someone who types differently is inside the account. Vendors like BioCatch, NuData (Mastercard), and TypingDNA sell it widely to banks, which like it precisely because it adds no friction.

Context

Strictly speaking, context isn’t something the user presents as proof. It’s what the system observes about the circumstances of the request, and it plays the same role: raising or lowering trust. A sign-in from a country you’ve never signed in from is riskier. So is one at 3 a.m. if you never work at that hour. The device fingerprint, a combination of model, operating system, fonts, plugins, and screen size, shows whether this is a device you’ve used before. An IP address from a VPN or Tor network raises the risk. And “impossible travel,” a sign-in from Madrid at 14:00 and another from Tokyo at 14:05, is a strong signal on its own.

Context is rarely used as a factor by itself. Its value is in adjusting the decision: getting in from home on your usual laptop should be easy, and getting in from a new country on a new device should require more.

SFA, 2FA, MFA

These terms get used loosely, so it’s worth pinning them down. Single-factor authentication (SFA) uses one factor, usually a password. It’s the weakest model and has no place in a serious modern application, though it still appears in legacy internal apps and low-sensitivity systems. Two-factor authentication (2FA) uses exactly two factors from different categories: a password and a code from an app, a password and a fingerprint, a hardware key and a PIN. A password plus a PIN, two fingerprints, or a password plus security questions aren’t 2FA, because each pair comes from the same category. Multi-factor authentication (MFA) uses two or more factors from different categories, so 2FA is a subset of MFA. In practice the difference is wording: 2FA is exactly two, MFA is two or more.

Step-up authentication

Step-up means asking for an extra factor in the middle of a session, when the user is about to do something more sensitive than their original sign-in justified. You sign in to check your balance with a password and a push notification; to send a transfer over $1,000, the app asks for your PIN as well; to change the email address on the account, it asks for a biometric check. It’s the practical form of “the higher the risk, the stronger the authentication.” Asking for every factor all the time ruins the experience, but asking at the moment it matters makes sense.

When you design an app, ask which actions are irreversible or high value. Those deserve step-up. An ordinary sign-in gets a smooth experience; a critical action gets one more factor. It’s the 80/20 rule applied to security friction.

Risk-based adaptive authentication

Risk-based authentication (RBA) is the natural next step after step-up. Instead of fixed rules like “transfers over $1,000 need a PIN,” the system calculates a risk score in real time and decides on its own how much friction to add.

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[Sign-in 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]

The score draws on many signals. Some concern the identity: is the account new, how old is it, is its history clean? Some are contextual: IP address, location, device, time, network provider. Some are behavioral: typing, movement, navigation, rhythm. Some are anomalies: is this the first time from this country, is the travel since the last sign-in impossible? Some come from outside intelligence: is the IP on a blocklist, has the device been reported as compromised? And some come from what’s happening elsewhere: is there a wave of credential stuffing against other accounts right now, like the one that hit David?

Here’s how it plays out for Sara. She opens her bank’s app on a Friday at 8 p.m. on her usual phone, in her usual neighborhood, with her usual typing pattern. The score is low, the app asks only for her fingerprint, and she’s in within two seconds. The next Saturday she tries to sign in from a computer the system has never seen, in a café in another city, typing a little differently because she’s on a keyboard instead of her phone. The score is medium to high, so the app asks for her password, a push notification on her phone, and a question about her last transaction. If she then tries an immediate transfer, the score climbs again, and the system asks for her transaction PIN or holds the transfer until she confirms through another channel. Sara, the real user, gets through every check with a few extra seconds. An attacker with her password but without her phone, her patterns, and her context fails at one of them.

To follow the RBA market, Gartner Peer Insights for Access Management is useful, since RBA is a feature of modern access management platforms, as is the KuppingerCole Leadership Compass on adaptive authentication.

How this maps to NIST AAL

All of this connects to a formal standard. NIST SP 800-63B defines Authenticator Assurance Levels (AAL), which tie factors to levels of assurance, and the NIST SP 800-63 article covers them in depth.

If you’re asked to set the authentication level for a system, this table is the reference: ordinary banking usually requires AAL2, and government or high-value banking can require AAL3.

Recap

The five categories are the working vocabulary of any serious conversation about authentication. Something you know, passwords and PINs, is the most common and the weakest. Something you have, TOTP, push, FIDO2 keys, and passkeys, is solid when implemented well. Something you are, biometrics, is strong with liveness detection and can’t be revoked if it leaks. Something you do, behavioral signals, is a silent supporting factor. And context adjusts the risk rather than proving anything itself.

SFA, 2FA, and MFA come down to one rule: to count as real MFA, the factors have to come from different categories. Step-up and RBA are the modern ways out of the old trade-off between friction and security: ask only for what’s needed, when it’s needed, based on the actual risk of the moment.

Three questions to test yourself

1. An app offers “double authentication” by asking for a password and a four-digit PIN. Is it real 2FA? Explain why.
2. Design the step-up logic for an investment app: define at least four different actions and the level of authentication you’d ask for each.
3. Your CFO says, “Let’s implement RBA with a score from 0 to 100 and block any sign-in above 60.” What three warnings would you give about such a simple implementation?