Expected Behavior of Remember Last Used Factor With Okta FastPass and Push

The Remember Last Used Factor (RLUF) feature in Okta Identity Engine (OIE) relies on a local, browser-specific cookie that interacts with Okta FastPass and Okta Verify Push. Okta routes users to specific factors based on manual selection, auto-challenge precedence, and cookie validity. Control the default authentication factor by configuring Authentication Policy rules or instructing users to manually select a preferred factor.

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

What design rules dictate the Remember Last Used Factor behavior?

The Remember Last Used Factor (RLUF) feature relies entirely on a local, browser-specific cookie (luf_ + <hashed user ID>) with a fixed 30-day expiration. Okta adheres to three strict design rules to route users to specific factors.

Manual Selection Updates the Cookie

The luf cookie updates only when a user manually interacts with and selects an authenticator from the Sign-In Widget factor selection list.

• Manual interaction (for example, clicking Verify with Okta Verify Push or manually selecting Okta FastPass after clicking Verify with something else) updates the cookie.
• Automated events (such as a FastPass silent probe or auto-challenge) do not write to or update the luf cookie.

The FastPass Auto-challenge Takes Precedence Over the Cookie

Okta evaluates authentication factors by following a strict hierarchical order.

1. Password: Okta prompts for a password first if the global session or authentication policy requires it as a primary factor.
2. FastPass Auto-Challenge: If FastPass is enrolled and allowed by the policy, Okta automatically triggers a device probe before checking LUF.
3. Remember Last Used Factor: Okta evaluates LUF only if FastPass does not automatically challenge the device.
4. Factor Selection List: Okta displays this list as a fallback if no valid LUF cookie exists or if the stored factor no longer satisfies the policy assurance constraints.

When does Okta bypass the cookie?

Okta bypasses the luf cookie and prompts the user to select a factor under specific conditions.

• The user is in an Incognito or Private browsing session.
• The cookie expires after 30 days.
• The user logs in from a new browser or device.
• The policy requirements change, and the stored factor no longer satisfies the current rule assurance constraints.

Okta Provides Options to Control the Default Authentication Factor

Control the default authentication factor by configuring Authentication Policy rules or resetting the pre-selected factor.

• Enforce FastPass as the Primary Option: Configure Authentication Policy rules to require Phishing-Resistant possession factors. This forces Okta to automatically trigger the FastPass auto-challenge pipeline and bypass the LUF cookie.
• Reset a Pre-selected Factor: Instruct the end-user to click Verify with something else on the Sign-In Widget and manually select a preferred factor. This manual action overwrites the luf cookie with the new preference for the next 30 days.