Authenticators: Independent vs Dependent

An authenticator is the thing that actually confirms who you are - a password, a security key, an app on your phone. It's the middle layer of the identity stack: credentials prove an identity, an authenticator holds those credentials, and one or more factor types describe how the authenticator proves it. There's a dedicated page on MFA factors for that bottom layer.

This page sorts authenticators into the buckets that matter in practice, starting with the one Auth0 draws on the MFA dashboard: independent vs dependent.

The two-way split (one glance)

On Auth0's Security > Multi-factor Auth screen, every factor is either independent or dependent. The rule: you cannot enable a dependent factor until at least one independent one is switched on.

INDEPENDENT Standalone proof - works alone, nothing else needs to be on first. These are the factors that can carry MFA on their own:
  • WebAuthn with FIDO Security Keys
  • One-time Password (OTP / authenticator app)
  • Push Notification (Auth0 Guardian)
  • Phone Message (SMS + Voice)
  • Cisco Duo Security
You must enable at least one of these to require MFA.
DEPENDENT Fallbacks and alternatives - only usable once an independent factor is already on. They extend or rescue an existing setup, they don't start one:
  • WebAuthn with FIDO Device Biometrics
  • Email (one-time code)
  • Recovery Code
Enabling one of these before an independent factor is effectively blocked by the dashboard.
The mental model, once: independent = primary proof, dependent = backup or alternative. Independent authenticators are the foundation you build MFA on; dependent ones are the recovery and convenience net on top. Don't confuse this with factor type - a FIDO security key and a FIDO device biometric both reduce to Possession, yet one is independent and the other dependent. Independence is about whether you can start with it, not what factor category it sits in.

Why the split exists

Independent authenticators are real, standalone proof of possession - a key you carry, a code from an app, a push you approve. That's enough to stand as the second factor on its own. Dependent ones need an independent anchor first because they are, by themselves, too weak or too easily forged to be the primary proof: an email code can be intercepted, a recovery code is single-use and only exists if you enrolled something first, and device biometrics assume a device you already proved you have. Once an independent factor is on, the dependent ones become useful fallbacks.

Beyond the two-way split: the other ways to cut it

"Independent vs dependent" is one axis. Two more are worth keeping straight because they answer different questions.

Other ways to categorise authenticators

> FACTOR TYPE - WHAT IT PROVES The classic three categories from the MFA cheat sheet:
  • Knowledge (something you know): Password, Email code, security-question answer.
  • Possession (something you have): OTP, Authenticator app (Guardian, Duo), Security key, Phone (SMS/Voice).
  • Inherence (something you are): Fingerprint, facial recognition (Touch ID / Face ID / Windows Hello), voice.
Key gotcha from the course: SMS OTP counts as Possession (you hold the phone), and Email counts as Knowledge (even though it's delivered, not typed from memory).
> MULTI-FACTOR REACH - HOW MANY IT CAN COVER Some authenticators are single-factor only; others can span two when configured with a device unlock:
  • Single-factor only: Password, Phone (SMS/Voice), Email - each proves one factor type and stays there.
  • Multi-factor capable: Auth0 Guardian (Possession, or + Knowledge/Inherence with a device passcode/biometric) and FIDO WebAuthn security keys or device biometrics (same pattern) - they can cover two categories at once.
  • Passkeys only ever appear already combined (Possession + Knowledge or + Inherence) - they are never listed as a bare possession-only factor, because a passkey is inherently backed by a device unlock.
> ASSURANCE / PHISHING RESISTANCE How high up the AAL ladder an authenticator can push you:
  • Not phishing resistant: Password, Email, Phone (SMS/Voice). Single-factor, capped at AAL1 on their own.
  • AAL2 reach: Auth0 Guardian push, synced passkey, WebAuthn device biometrics - two factors, approved crypto, no hardware-bound guarantee.
  • AAL3 (phishing resistant): FIDO security keys and device-bound passkeys - a "hard" key that resists impersonation.
See the AAL page for the full ladder.

Gotchas worth drilling

  • Independent/dependent is NOT the same as factor type. WebAuthn security keys (independent) and WebAuthn device biometrics (dependent) both sit in the Possession camp, but only one can be a tenant's first enabled factor. Dependency says "can this begin a setup?", factor type says "what does it prove?"
  • WebAuthn is not a single category. The security-key variant is independent; the device-biometrics variant is dependent. Don't lump them together when you read a dashboard or docs table.
  • Email and OTP are different. Email delivers a one-time code to users who are already enrolled in an independent factor (it's a dependent fallback). OTP is the standalone authenticator-app TOTP code - an independent factor in its own right.
  • At least one independent factor is the hard requirement. Auth0 won't let you run MFA off dependents alone - the tenant needs an independent anchor before Recovery Code or Email can serve as your backstop.

Q&A: Resetting MFA enrollment

A real one - the sort of thing that comes up in practice (it surfaced on a live engagement). Here's the knowledge-check asked about it, with the reset options broken down into the three that actually work.

What are three ways to reset MFA enrollment?

Options (from the quiz, verbatim):

  • An admin can go to Dashboard > Security > Multi-factor Auth to reset MFA for end user. No - that's where you configure tenant-wide factors and policies, not reset one person's enrollment.
  • An end user can use a biometric, such as Touch ID, to reset MFA. No - biometrics authenticate; they aren't a reset path.
  • An admin can go to Dashboard > Users Management > Users. Yes - pick the user and reset their Multi-factor there.
  • An end user can use a push notification to reset MFA. No - pushing a notification verifies; it doesn't reset.
  • An admin can use the Management API to delete an end user's MFA enrollment. Yes - DELETE /api/v2/users/{id}/authentication-methods.
  • An end user can use a recovery code to log in. Yes - a recovery code gets you back in without the factor.

The three reset paths: the admin Dashboard (Users > user > Reset Multi-factor), the Management API delete endpoint, and the end user's own recovery code. The three distractors all mistake a verification step (biometric, push, policy page) for a reset mechanism.

How do you actually reset a stuck factor in practice?

When the customer is locked out of their MFA factor, the routes are:

  • Recovery code (self-service, fastest): if they enrolled one, they use it to get back in, then re-enroll. No admin involved.
  • Admin dashboard: Users > the user > Reset Multi-factor. A routine helpdesk action under the Users section - not the MFA policy page.
  • Management API: DELETE /api/v2/users/{id}/authentication-methods clears the enrolled factors so the user re-enrolls on next login.

Watch-out: a password reset does not clear the MFA factor. If the user forgot their password and lost their factor, you reset the password and reset MFA separately.

Reading further: MFA & Authentication Factors for the factor-type layer, and Authenticator Assurance Levels for how all of this maps to a trust score.