Multifactor authentication enhancements

Identity Engine enhances the way that you work with multifactor authentication (MFA).

In Classic Engine, factors represent the authenticator that a user uses to prove their identity when sign-on policies require more verification. All factors are equal to each other, though some are stronger than others.

Identity Engine realigns MFA and assurance terminology with industry standards:

  • Factors are now called authenticators

  • Authenticators refer to the type of verification used, such as Password, Security Question, WebAuthn, or others

  • Factor refers to a way of categorizing authenticators and methods

  • Methods describe the technological means by which the authenticator helps provide proof of identity, such as a phone call or a one-time password

This table shows the relationship between authenticators, factors types, and methods in Identity Engine.

Factor type: Knowledge

Factor type: Possession

Factor type: Biometrics/Inherence
 

Something you know

Something you have

Something you are

Authenticator
  • Password

  • Security Question

  • Phone

  • Google Authenticator

  • Email

  • WebAuthn

n/a

Methods

n/a

  • SMS

  • Voice

  • Google Authenticator

  • Okta Verify (TOTP & Push)

  • Email Magic Link

  • Security Key (touch-enabled YubiKey)

  • Okta Verify (with biometrics)

  • WebAuthn with Touch ID

  • Security Key (YubiKey with biometrics)

Methods also have characteristics. For example, some authenticators are bound to a specific device, while others demonstrate the physical presence of the user (instead of a bot, for example). This table describes the characteristics of methods.

Method characteristic Description Examples
Device-Bound The device key or secret is stored on the device and can’t be transferred to another device without re-enrolling All possession authenticators except for Email and Phone
Hardware-Protected An authenticator that provides hardware protection of secrets or private keys Okta Verify proof-of-possession key
Phishing-Resistant An authenticator that cryptographically verifies the login server WebAuthn
User Presence The user proves they have control of the authenticator by actively authenticating (interacting with the authenticator, such as touching a YubiKey or entering a one-time password) Every method except an Okta Verify verification signed by a proof-of-possession key

Each method enrollment satisfies a different set of factor types and method characteristics.

This table lists some common authenticators, their factor types, and method characteristics.

Authenticator Factor type Method characteristic Description
Okta Verify
  • Possession

  • Possession + Biometric*

  • Hardware-protected

  • Device-bound

Okta Verify is an authenticator app used to confirm a user's identity when they sign in to Okta or protected resources.
Security Key, Biometric (WebAuthn)
  • Possession

  • Possession + Knowledge*

  • Possession + Biometric*

  • Phishing-resistant

  • Device-bound

The Security Key/Biometric that follows the FIDO2 WebAuthn standard. The user inserts a security key, enter a PIN, or touches a fingerprint reader to verify them.
Phone Possession   The SMS and Voice Call authenticators require the use of a phone. They send a code in a text message or voice call that the user enters when prompted by Okta.
Email

Possession

The Email authenticator allows users to authenticate successfully with a security token (code) or magic link that is sent to their primary email address.

Password

Knowledge

The Password authenticator consists of a string of characters that users or an admin set.

Security Question

Knowledge

The Security Question authenticator consists of a question that requires an answer that was defined by the end user.

* Verification with these authenticators always satisfies at least one possession factor type. Based on the device used to enroll and the method used to verify the authenticator, two factor types could be satisfied.

The goal of an MFA strategy is to provide a certain level of assurance. This is the degree of confidence that the user attempting to sign in is who they say they are.

To achieve high levels of assurance, select authenticators that cover different types of factors and methods. The more factor types and methods you cover, the higher the level of assurance. For example, you could select a combination like this:

  • Select Password or Security Question to ask the user for something they know

  • Select Google Authenticator to prove that a user possesses the device they’re authenticating with, and that it really is that user’s device

  • Select Okta Verify with biometrics enabled to verify the physical person attempting to authenticate

This new assurance model recognizes that not all authenticators provide the same protection. For example, security questions are less effective than biometric authenticators. You can decide which authenticators to deploy while providing users the freedom to set up those authenticators they prefer to use.

Authenticator deactivation

Deactivate an authenticator from all policies before you deactivate it at a global level.

Related topics

MFA options: end-user enhancements

Upgrade from Factor Sequencing to Assurance Models