In this article, Okta will cover different use cases for Factor Sequencing after upgrading to Okta Identity Engine (OIE).

• Okta Identity Engine (OIE)
• Multi-Factor Authentication (MFA)

Show the Okta username as the identifier on the first sign-in screen.

After the upgrade, one can see the identifier-first experience directly. There is no longer a need to create an IDP routing rule with a placeholder domain.

Enable users to authenticate using any factor other than a password

After upgrading to Identity Engine, perform the following steps on the applications that require single-factor passwordless authentication.

1. Switch to an identifier-first flow in the global session policy. Before switching, carefully consider the implications of an identifier-first flow compared to a password-first flow.
2. Create an authentication policy that allows users to authenticate with possession factors.
   1. In the Identity Engine Admin Console, go to Security > Authentication Policies.
   2. Create an authentication policy called Passwordless Authentication.
   3. Create a rule called Single Factor Passwordless Authentication.
   4. From the User Must Authenticate dropdown, select Possession Factor. This results in the same behavior because the users in this group can now authenticate with any possession factors except the password.

After creating the authentication policy, associate it with the applications. See Authentication policies.

NOTE: If User Enumeration Prevention is enabled for authentication, the user will be prompted for a password first, regardless of whether the factor sequencing is configured or not. 

Users undergo authentication using both a password and an additional factor

After upgrading to Identity Engine, perform the following steps for applications that require a password and another authentication factor.

1. Switch to an identifier-first flow in the global session policy. Before switching, carefully consider all the implications of a password-first flow to an identifier-first flow.
2. In the Admin Console, go to Security > Authentication Policies.
3. Create an authentication policy called Password + Another Factor.
4. Assign this rule to a group.
5. Select Password/IDP + Another factor.
    

Limit the factors available for user authentication

This can be done in a limited way in Identity Engine by applying constraints on possession factors.

1. Switch to an identifier-first flow in the global session policy. Before switching, carefully consider all implications of an identifier-first flow from a password-first flow.
2. Create an authentication policy with possession factor constraints.

3. 1. Phishing-resistant: Requires users to provide possession factors that cryptographically verify the sign-in server (the origin). FIDO 2 (WebAuthn) and the Okta FastPass option in Okta Verify satisfy this requirement. Because phishing resistance implies device-bound, that constraint is selected automatically when Phishing-resistant is selected.

   2. Hardware protection: Requires that keys used to authenticate are stored in secure hardware (TPM, Secure Enclave) on the device. Currently, only Okta Verify meets this constraint. Because hardware protection implies device-bound, that constraint is selected automatically when Hardware protection is selected.

   3. Exclude phone and email authenticators: Requires that the factor's keys be stored securely on the device and are not transferable to another device without re-enrolling the factor. Email and SMS are the only possession factors that are not device-bound. This constraint is selected automatically if either of the other constraints is selected.

By utilizing the shareable authentication policies APIs, the authenticators can be limited to certain factors. See the Constraints default example.