Devices known issues

Before you contact Okta Support, use the known issues information to identify the cause of the issue you experienced. The issues are grouped by platform:

All platforms

Okta Verify enrollments are desynchronized

Issue

When a user registers a device in Okta Verify, Okta creates two related enrollments for the user:

  • A local enrollment that resides on the user's device
  • A server-side enrollment in Okta

These two enrollments must remain synchronized for Okta Verify to function correctly, but some admin or end-user actions can desynchronize the enrollments.

Solution

Complete the appropriate solution based on the admin server-side or end-user cause:

  • Admin server-side causes

    • A user's device was reactivated after being deactivated.

      When you deactivate a device in the Okta Admin Console, it also deactivates the associated user's server-side Okta Verify enrollments. The local and server-side enrollments remain out-of-sync even if you reactivate the device. End users should be able to remove their account(s) from Okta Verify regardless of the device status, but they cannot add an account if the lifecycle status of the device is not Active (see Device lifecycle).

      Solution: Instruct the user to delete the invalid Okta Verify account from that device and then re-enroll (add the account).

    • A user's device was unsuspended after being suspended and the user deleted their Okta Verify account before the device was unsuspended.

      Solution: In the Okta Admin Console, navigate to the user’s page, and then click More Actions > Reset Authenticators to reset the user's Okta Verify enrollment.

    • A user's device was unsuspended after being suspended and the user didn't delete their Okta Verify account, no action is required. The user’s Okta Verify account will now work again.

  • End-user causes

    • A user resets their Okta Verify enrollment on the Settings page of the Okta End-User Dashboard.

      Solution: Instruct the end user to open Okta Verify, click the affected account, click Remove Account or Delete Account to remove the local enrollment, and then add the account back.

    • A user disables biometrics in their device settings (not in the Okta Verify settings) when it was previously enabled, and then re-enables it.

    • Solution: Instruct the end user to open Okta Verify, click the affected account, disable user verification (for example, Disable Windows Hello, or Disable Touch ID), and then enable user verification.

    • A user updates biometrics by adding a new fingerprint or face ID in the device settings (not in the Okta Verify settings), which causes a partial desynchronization. Using This device as an authenticator should continue to work if the policy does not have User verification (biometrics) configured as Required.

    • Solution: Instruct the end user to open Okta Verify, click the affected account, disable user verification (for example, Disable Windows Hello, or Disable Touch ID), and then enable user verification.

    • A user deletes an account from Okta Verify when there is no internet connectivity.

    • Solution: Instruct the end user to open Okta Verify, click the affected account, click Remove Account or Delete Account to remove the local enrollment, and then add the account back.

    • A user is not enrolled in any other Okta authentication factor and manually deletes the Okta Verify app from their device without first removing Okta Verify accounts from the app or removing Okta Verify enrollment from the Okta End-User Dashboard.

    • Solution: In the OktaAdmin Console, navigate to the user’s page, and then click More Actions > Reset Authenticators; or instruct the end user to go to theirOkta End-User Dashboard, click Settings > Security Methods (or Extra Verification), and then reset the factor.

    • A user backs up data from one device and restores it to a different device.

    • Solution: In the OktaAdmin Console, navigate to the user’s page, and then click More Actions > Reset Authenticators; or instruct the end user to go to their Okta End-User Dashboard, click Settings > Security Methods (or Extra Verification), and then reset the factor.

End users should remove accounts from Okta Verify before deleting Okta Verify

Before deleting Okta Verify from a device, the user should remove all accounts from the app.

Deactivated and then reactivated end users get an error when they try to delete an account in Okta Verify

If a deactivated and then reactivated user tries to delete an account in Okta Verify, the attempt fails and they get a "Resource not found" error message. To remedy, the user must contact their IT administrator.

Suspended and then reactivated end users are unable to enroll in Okta Verify on a different device

If you suspend and then reactivate a user, they can’t enroll in Okta Verify on a different device. To remedy, users must contact their IT administrator.

End users are unable to access apps without enabling biometrics in some circumstances

In some circumstances, end users who haven’t enabled user verification (biometrics, Windows Hello) for their Okta Verify account can’t access Okta-protected apps.

Issue

If a user does all of the following:

  1. Installs Okta Verify on their device.
  2. Adds an account to Okta Verify but does not enable user verification (biometrics, Windows Hello) for the account at that time or later.
  3. Tries to access an Okta-protected app from one of the following:
    • The Okta End-User Dashboard and they didn’t use Okta Verify to sign in to the dashboard (IdP-init).
    • The same browser, and in the same browser session, from which they added an account to Okta Verify (SP-init).
  4. And the app is gated by an authentication policy in which all the rules require that:
    • The user provide a possession factor
    • The re-authentication frequency is set to either Every sign-in attempt or Re authenticate after N minutes/hours/days
  5. Enters their email address instead of clicking Sign in with Okta FastPass on this screen:
  6. Sign-In Widget image showing the Sign in with Okta FastPass button.

One of the following known issues occurs:

  • Instead of accessing the app as expected, the user is denied access and they get an "Unable to fully authenticate into appinsstance Id <>" error message.
  • If the user is shown a list of authenticators, the Use Okta Verify on this device isn’t included because the user hasn’t enabled biometrics for their account. In this case, without the Use Okta Verify on this device option, the user can’t access the app.
  • The user sees this:

    Verify it's you with an authenticator screen that appears.

    Instead of this:

    Verify it's you with an authenticator screen that should appear.

Solution

An admin can set the re-authentication frequency to Once per device for all rules in the authentication policy.

- or -

An end user can do any of the following:

  • Click Sign in using Okta Verify when accessing the app from the Okta End-User Dashboard.
  • Enable extra verification for your Okta Verify account (go to Okta Verify, and then see Manage accounts > Configure account details for the relevant platform).
  • Access the app directly (not from the Okta End-User Dashboard). Make sure you use a different browser, or a different browser session than you used when you added an account to Okta Verify.

The remediation message for unmanaged devices might present the wrong device management solution to end users

To help users on unmanaged devices enroll in their organization's chosen device management solution, Okta displays an "Additional setup required" remediation message that includes the name of the solution and a link to their enrollment site.

For this org configuration:

  1. An org has more than one Device Management configuration for the same platform.
  2. Each configuration integrates with a different device management solution (for example, one of your Windows Device Management configurations integrates with Intune and another integrates with Workspace ONE).
  3. A user on an unmanaged device tries to access an app associated with one of the configurations and the authentication policy requires devices to be managed.

When multiple configurations exist for the same platform, the remediation message pulls information from the earliest Device Management configuration you created for that platform. Therefore, some remediation messages might reference the wrong device management solution and include a link that points to the wrong enrollment website.

AD-sourced end users who are deactivated in AD are able to enroll in Okta Verify

Issue

When an Active Directory (AD)-sourced user, active in both AD and Okta, prepares to set up Okta Verify through the Settings page of their Okta End-User Dashboard, the QR code for Okta Verify enrollment is displayed. If the user is deactivated in AD before they scan the QR code, they can successfully scan the QR code and enroll in Okta Verify after satisfying a user verification prompt. This is unexpected because the user should not be able to enroll into Okta Verify since their account has been deactivated in AD. QR codes generated before a user is deactivated in AD remain valid until they time out.

Solution

This is a corner case that would occur only if the account is deactivated between the time the QR code is generated and scanned by the user. Typically, this is a very short period of time for most users.

Even if a user who's been deactivated in AD is able to enroll into Okta Verify successfully, such users won't be able to sign in to any Okta-protected applications. Admins can delete any unwanted Okta Verify enrollments through the Admin Console if necessary.

Configure Device Management before creating authentication policies that require devices to be managed

When accessing an app protected by a policy that requires devices to be managed, users get an internal server error If Device Management is not already configured in Security > Device Integrations. Before you create an authentication policy that requires devices to be managed, make sure to configure Device Management.

An unexpected error message was received

If a user tries to access an Okta-protected app from a deleted or suspended mobile device or if the user is suspended or deactivated, the generic "Unexpected error while communicating with Okta. Please try again" error message appears.

An error occurs if a user enters the wrong email when setting Okta Verify through email link

When setting up Okta Verify, if a user chooses the Set up Okta Verify via email link option instead of scanning a QR code, they must enter either the primary or secondary email address that's specified in their Okta profile. Entering any other email address generates an error.

An MDM remediation message is not shown in some circumstances

If you configured an authentication policy that requires devices to be managed, but did not configure Device Management (Security > Device Integrations), users on unmanaged devices get a "You do not have permissions to perform requested action" message instead of a message guiding them to enroll in your chosen MDM software.

SP-initiated access fails for reactivated device

If an admin deactivates and later reactivates a registered device and the user then tries an SP-initiated authentication to an Okta-protected app from the device, access to the app fails but no error message appears.

Solution

If you deactivate and then reactivate a registered device, notify the user and advise them to remove and then re-add their account to Okta Verify.

Removing Okta Verify from a device must be done in the correct order

Uninstalling Okta Verify from a device in the wrong order breaks the connection between the user’s local Okta Verify registration and the corresponding registration maintained on the Okta Server. If the connection is broken, the Okta server is unaware of the change and continues to consider the registration intact, which prevents the user from resetting their enrollment or creating a new enrollment on the original device or another device without assistance from their IT admin.

To uninstall Okta Verify from a device, users should perform these steps in the following order:

  1. On the device, go to Okta Verify and delete any accounts from the app.
  2. In a browser, go to the Okta End-User Dashboard > Settings. Scroll down to Extra Verification, and then tap or click Remove Okta Verify. This removes the registration from the Okta server.
  3. On a mobile device, locate Okta Verify, long press the icon, and then tap Uninstall. On a desktop, double-click the Okta Verify icon, and then click Uninstall.

Okta Verify enrollments are still active after admin uses Revoke access option

Users can still use Okta Verify to access protected resources even after their admin removes the relationship between the user and the device by revoking access through the Okta Admin Console. If you intend to remove a user's Okta Verify authenticator enrollment on a device, go to the user's profile page, click More Actions, click Reset Authenticators, select Okta Verify, and then click Reset Selected Authenticators.

Changing biometrics on the user device invalidates the user verification enrollment in Okta Verify

If a user who is enrolled in Okta Verify with user verification (biometrics) changes their device biometrics, their existing user verification enrollment breaks. The user is prompted to Sync Face ID or Sync Touch ID to resolve the problem. If user verification is required and the user isn't enrolled in any other authentication method, they need to contact their IT admin for assistance.

Upgrading to Identity Engine if a user already has multiple Okta Verify accounts in the org

Identity Engine orgs don't support adding more than one Okta Verify account per org. But in an upgrade scenario from Classic Engine to Identity Engine in which users created more than one Okta Verify account while in the Classic Engine org, the following expected behavior is enforced:

Given a user in an Okta Classic Engine org with two Okta Verify accounts for that org and then the org is upgraded to Identity Engine:

  • Both accounts continue to work as before.
  • In both accounts, a Set up button appears in the This device authentication method in the app's Account Details. The button allows the user to enable one of the Okta Verify accounts created in Classic Engine to use their device as an authenticator (a Way to sign in). If, after updating one such account, the user clicks Set up to enable the method in their other account, an error appears and the method is not enabled in that account. This is expected behavior.

Authentication of device via certificate - failure: NO_CERTIFICATE system log events

After you migrate from Device Trust (Classic Engine) to Device Trust (Identity Engine) and have an authentication policy rule that requires Registered devices, you will see Authentication of device via certificate - failure: NO_CERTIFICATE system log events. This is expected behavior and will be resolved when you migrate to Okta FastPass. It occurs because the server is attempting a Device Trust challenge with a device that does not have a client certificate. The user can still log in, but the device is considered to be "not trusted".

Unable to deactivate and delete a device after the user(s) associated with the device are deleted

This error appears when the deletion job for user accounts is not complete. In the Admin Console, after you delete all user accounts that are associated with a device, wait approximately 5 minutes before you deactivate and delete that device. This allows time for the deletion job to complete.

Users whom are activated after being deactivated are able to access the Okta End-User Dashboard without first resetting their password

End-user authentication requirements are based on the Global Session Policy and authentication policy. This includes when you deactivate an end user and then reactivate them. For example, if your policies are configured for:

  • Password authentication: you generate a temporary password for the user, the user uses the temporary password to sign in, they change their password, and then accesses Okta-protected resources.

  • Passwordless authentication: the user is not prompted to enter the temporary password that is generated by you. Instead, they select a passwordless authenticator to use (for example, Okta FastPass), provide user verification, and then access Okta-protected resources. The next time the user signs in to Okta with a password, they are prompted to change their password.

The Okta FastPass Set Up button displays for suspended and deactivated users after upgrade

The Okta FastPass Set Up button displays for suspended and deactivated users in orgs that upgraded from Classic Engine to Identity Engine; however, users are not able to complete the setup if they are suspended or deactivated.

Users are unable to enroll in Okta Verify until they refresh the browser page

When multiple accounts exist in Okta Verify, the user should refresh the browser page before attempting to sign in; otherwise, the browser may think that the user is different than the user signing in.

Users must be active in Okta before they can enable biometrics

This is expected behavior. If a user was deactivated in Okta, but is still active in Active Directory, the user must sign in to an app (for example, the Okta End-User Dashboard) before they can enable biometrics.

Silent inline enrollment fails for users when multiple orgs exist

If you're using Okta FastPass to sign in to a multi-org environment and Okta FastPass is not set up for all orgs, inline enrollment may not work in some circumstances. To avoid this issue, make sure Okta FastPass is set up for all orgs before you sign in.

Users are not able to remove their account from Okta Verify if they are deleted from Active Directory

If a user is deleted from Active Directory, they are not able to remove their account from Okta Verify. To resolve this issue, you must manually delete the user enrollment from Okta.

FIPS mode does not apply to Okta Mobility Management (OMM) or desktop versions of Okta Verify

Users are able to sign in to apps from deactivated devices

This is expected behavior. If all rules in the authentication policy protecting a resource require devices to be registered, a user on a Deactivated device is denied access to that resource (regardless of the factors they have enrolled). If the policy includes rules that allow access from unregistered devices, a user on a Deactivated device might be able to access the resource but not by using Okta FastPass.

A suspended or deactivated user is unable to re-enroll their account with Okta Verify after they remove their account

When you suspend or deactivate a user in Okta, the user is still active in Active Directory. In this situation, if the user removes their account from Okta Verify or uninstalls Okta Verify, Active Directory synchronization does not occur. The user remains active in Active Directory, and suspended or deactivated in Okta. If the user isn’t enrolled in any other Okta authentication factor, they won’t be able to re-enroll. To resolve this issue, in the Admin Console, navigate to the user’s page, and then click More Actions > Reset Authenticators.

Users enrolled with Okta Verify are denied access when attempting to access an app

If you’re using a service account and your authentication policy rules are:

  • Rule 1: A non-service account, signing in with a device that is either registered and not managed or registered and managed with any one authentication factor.

  • Rule 2: Any service account, signing in from any device can access the app with any two factors.

  • Rule 3: Catch all deny.

Okta is not able to probe for device context, so users are denied access when they authenticate with a username and password. As a workaround:

  1. Enable Okta FastPass. Complete the Enable Okta FastPass procedure, but in step 5, select the Show the “Sign in with Okta FastPass” button checkbox.

  2. Ask users to click Sign in with Okta FastPass when they sign in to apps.

Okta Verify enrollment isn’t automatically triggered when an admin portal URL is used

If a user doesn't have any enrolled accounts in Okta Verify for their organization, enrollment is automatically triggered when they enter their org URL (for example, http://example.org.com ) in a browser. However, if they enter their admin portal URL (for example, http://example-admin.org.com ) in a browser, they are redirected to their org URL, but enrollment isn’t automatically triggered. As a workaround, the user should enter their org URL instead of the admin portal URL.

Users get a "This organization is not supported on Okta Mobile, but you can access your dashboard from your browser" message

When an Okta Mobile (OM) user is migrated to OktaIdentity Engine, they will get a "This organization is not supported on Okta Mobile, but you can access your dashboard from your browser" message. When they tap OPEN DASHBOARD, the Okta End-User Dashboard appears in a mobile browser, and the user is prompted to authenticate (for example, with Okta FastPass) before they can obtain access.

See Okta Mobile end user experience.

macOS

Users have problems accessing Google Drive File Stream native appOkta

Okta Verify single sign-on (SSO) fails when trying to access a Google Drive File Stream native app protected by a policy that allows passwordless access. As a workaround, click the Sign in with your browser instead link in the lower portion of the page to access the app.

Admins have problems auto-updating Okta Verify on devices when using Jamf Pro

Depending on your version of Jamf Pro, complete one of the following procedures to auto-update Okta Verify:

The Setup Touch ID screen appears when a Magic Keyboard with Touch ID is used for authentication

This occurs if the Magic Keyboard with Touch ID disconnects from the desktop device during enrollment or authentication. Okta Verify assumes that Touch ID is not set up on the device, so it prompts the user to enable Touch ID. To avoid this issue, make sure the Magic Keyboard is correctly connected to the desktop device, the Touch ID sensor is accessible, and that the hardware works as expected.

Silent authentication fails on Safari when Touch ID isn’t set up

If a user doesn't have Touch ID set up on their device and the authentication policy requires user presence, silent authentication on Safari won’t work. Instead, the user is prompted to select an authentication factor (for example, Okta FastPass), and then the user uses that factor to sign in with a non-silent authentication experience.

macOS occasionally fails to prompt users for Touch ID when accessing a restricted resource through Okta Verify

This a known issue for macOS Big Sur and earlier, but Apple has fixed the issue for macOS Monterey. To resolve this issue, the user must restart Okta Verify.

The issue is caused by the macOS coreauthd process, which fails to render the Touch ID prompt. There is an open support ticket with Apple to resolve this issue. Please reach out to Apple and reference feedback ticket number 9787063 if you would like more information.

Device lifecycle messages do not appear for users

Device lifecycle user messages are not currently available for macOS devices that use an SSO extension profile. This only affects Safari users with macOS Big Sur and earlier.

Elevated CPU levels experienced during certain authentication scenarios

During certain authentication scenarios, Okta Verify version 3.0.4 elevates CPU levels when running on a macOS 10.15 (Catalina) devices. As a workaround, upgrade Okta Verify to the latest version.

Windows

No hash appears for the dedicated hardware attribute on the Device Attributes page

Devices with Trusted Platform Module (TPM) appear on the Device Attributes page under the Dedicated hardware attribute but the unique identifier (hash) is not shown. Instead, the placeholder Present - no hash available appears.

Error possible when adding an Okta Verify account

If the "Something went wrong. Please try again" error message appears when adding an account to Okta Verify, try the following in the order shown:

  1. Make sure you entered the correct sign-in URL.
  2. If the problem persists, re-enroll the device in Okta Verify as described in Reset Okta Verify on your current or new device.
  3. (Recommended for admins only) If the problem persists, remove the app, reinstall it, and then re-enroll. Before removing the app, remove the enrollment through the user settings as described in Reset Okta Verify on your current or new device.
  4. Report the issue (right-click the app icon, and then select Report Issue). When users submit information to Okta, relevant logs are automatically attached.

Okta Verify, Windows Hello, and Remote Desktop

If a user is prompted for user verification (biometrics, Windows Hello) for Okta Verify while logged in to the machine over Remote Desktop, the authentication gets stuck at the spinning progress indicator. If the authentication policy applied to the app doesn't require Windows Hello, this issue doesn't occur.

Auto-updating Okta Verify for Windows doesn't work in a proxy-enabled environment

"Okta Auto Update Service" is a service that is installed with Okta Verify for Windows. This service checks for new versions of Okta Verify and tries to upgrade Okta Verify if a new version exists. Currently, this functionality doesn't work in a proxy-enabled environment.

For some native applications, the first user verification attempt with Windows Hello fails or is unresponsive, but the second attempt works

In some circumstances, Okta Verify fails to properly activate Windows Hello and bring it into focus. If this occurs, click the Windows Hello prompt to bring it into focus before interacting with the biometric sensor.

When a Windows device has multiple operating system (OS) user profiles and the same account is added to Okta Verify on more than one OS user profile, the most recent enrollment by the last OS user profile works, but authentications using enrollments with the same account in other OS user profiles fails

Currently, Okta allows one account enrollment on a device. The account enrollment is associated with a OS user profile. If a OS user profile enrolls on a device that contains an existing enrollment, the server overwrites the existing enrollment with the new enrollment.

macOS and Windows

Users are sometimes prompted to install Okta Verify when it's already installed

Users with Okta Verify installed on their desktop device might be prompted in error to install Okta Verify again when they try to access certain apps. This can happen if a user hasn’t enabled user verification (biometrics) in Okta Verify and the app they’re trying to access requires user verification. To remedy this, the user must do one of the following:

  • Enable user verification in Okta Verify (click the three vertical dots next to the account, click Enable Touch ID (mac) or Windows Hello (Windows), and then try to access the app again).
  • Install Okta Verify on a different device, enroll in Push and TOTP, and then use this device to access the app.

Managed devices appear as Not managed in some circumstances

Managed macOS and Windows devices appear as Not managed in Directory > Devices until the first time a user accesses a protected resource from the device using Okta Verify after the device became managed. The Okta server probes the management status of devices during authentication events and updates the status in Devices accordingly. This is expected behavior.

Enrolling Okta Verify on multiple desktop devices constraints

Follow these constraints when enrolling in Okta Verify on more than one desktop device:

  • To enroll in Okta Verify on multiple desktop devices, users must be enrolled already with another factor which can be used to sign in to the additional desktop, such as Yubikey, SMS, or Okta Verify with Push.
  • If the user's first Okta Verify enrollment is on a desktop device, their next Okta Verify enrollment must be on a mobile device. For user enrollment, see Okta Verify.

If a user tries to enroll Okta Verify on a second desktop device without following the above constraints, they’re prompted repeatedly to enroll using Okta Verify, which is not possible in this circumstance.

Access to protected resources fails if Okta Verify is not running and certain rules are set up in the authentication policy

If a user does not have Okta Verify installed or running on their device and they attempt to access an app, they are denied access and the "You don't have permissions to perform the requested action" error message appears.

Issue

The authentication policy is configured with:

  • Rule 1: Requires devices to be registered to access the app
  • Rule 2: Allow doesn't require devices to be Registered.
  • Rule 3: The Catch-All rule is set to Deny access.

This is expected behavior. Rule 1 requires devices to be registered to access the app, so Okta silently probes the device for signals. Probing fails because Okta Verify is not running. Because Rule 2 allows non-registered devices to access the app, Okta doesn't prompt the user to launch Okta Verify. If the authentication attempt doesn't match other conditions in Rule 2 such as the user's group membership or network location, the authentication attempt triggers the Catch-All Deny rule.

Solution

Change the authentication policy.

Android

Google Pixel 4 XL devices prompt for fingerprint scan, but it isn't supported by the device

On Pixel 4 XL devices, users who have not enabled biometrics on their device are prompted by the device operating system to scan their fingerprint to complete Okta Verify flows that require user verification (biometrics). Pixel 4 XL devices support face ID, but not fingerprint scan.

Number challenge option "All push challenges" not supported on Okta Verify 6.1.1 for Identity Engine-created users

If you select the option to present a number challenge with All push challenges, Okta Verify for Android version 6.1.1 crashes for users created in Identity engine. Advise these users to update to the latest version of Okta Verify.

An error occurs when adding an account in Okta Verify

If you select the Required option in Okta Verify enrollment settings, users running Okta Verify for Android version 6.2.2 or earlier will get an error when they try to add an account in Okta Verify. To avoid the error, these users should install the latest version of Okta Verify.

Setting up user verification isn't possible if the user's username is changed in Okta

Issue

In the following situation:

  1. A user has installed Okta Verify on the device.
  2. The user has added an account in Okta Verify but has not yet enabled user verification (biometrics) in Okta Verify.
  3. The admin changes the user's username in Okta.
  4. The user tries to enable user verification in Okta Verify.

Enabling user verification (biometrics) fails and the "The user signing in did not match the user on the account" error message appears.

Solution

The user must reset their Okta Verify enrollment as described in Reset Okta Verify on your current or new device.

If a user has an Okta Verify Identity Provider account, the user can’t add a Service Provider account using a sign-in URL on the same device

Issue

The user has an Okta Verify Identity Provider (IdP) account. Push Notification, This Device, and biometrics are configured as ways to sign in. The user adds a Service Provider account with a sign-in URL. The user enters a username and responds to the push notification and biometrics prompts generated by the IdP account. Instead of adding the account, Okta Verify closes.

Solution

The user can add the Service Provider account on the same device by using a QR code.

When users launch the dashboard from Okta Verify, cached data from the previous session might appear in the browser

Issue

When users access the Okta End-User Dashboard or Okta-protected apps in the mobile browser, and then launch the dashboard from a different Okta Verify account, the dashboard from the previous session might appear in the browser.

Solution

To ensure that they’re using the correct dashboard, instruct users to sign out and then sign in again.

Unable to sign in with Okta FastPass when Okta Verify is in a work and personal profile

If Okta Verify is in your work and personal profile, and you have an account with Okta FastPass and biometrics enabled for each profile, you might not always be able to sign in with Okta FastPass.

Issue

After you enter your username and select Use Okta FastPass, Okta Verify doesn’t show the “Tap to verify your identity with Okta Verify” message. If you tap Open Okta Verify, you are still not prompted to verify your identity.

Solution

Complete one of following:

  • Select a different security method, such as Enter a code or Get a push notification.

  • Make sure the Okta Verify account you use to sign in with Okta FastPass is the correct account for the profile you work in. For example:

    • Account 1 is an Okta Verify account in your personal profile.
    • Account 2 is an Okta Verify account in your work profile.

    To sign in to your app dashboard with account 2, you would open a browser in your work profile, enter the sign-in URL, and then tap Sign in with Okta FastPass.

In Incognito mode, Okta Verify doesn't launch when users click Sign in with Okta FastPass

In Incognito mode, when users click Sign in with Okta FastPass on the Sign-In Widget, Okta Verify doesn't launch. The issue is resolved when the user exits Incognito mode and then tries again.

iOS

Users are erroneously prompted to set up Okta Verify as an authenticator when they remove an Okta Verify account

Affected users should ignore the Set up required prompt by clicking Cancel on the setup screen. Their Okta Verify account is removed as expected.

Limitations in certain types of Okta Verify after reverting back to Classic Engine

If you revert your org from Identity Engine back to Classic Engine, be aware that there are limitations in the following types of Okta Verify accounts:

  • Accounts created in Identity Engine before the reversion back to Classic Engine
  • Accounts created in Classic Engine before the upgrade to Identity Engine for which the user set up This device in Ways to sign in on the Account Details screen following the reversion.
Limitations
  • The Okta Verify setting for iOS devices Require Touch ID or Face ID for Okta Verify has no effect.
  • Risk-based authentication that assesses the risk of sign in attempts and prompts Okta Verify users to satisfy a 3-number challenge has no effect

To enable these functions, users must delete and then re-enroll their accounts in Okta Verify. See Set up Okta Verify on iOS devices.

Okta FastPass doesn't launch Okta Verify

In some circumstances, when users attempt to sign in with Okta FastPass on an iPad or iOS device using Chrome or Safari, they are instructed to download Okta Verify when they already have it installed. In most cases, the issue is resolved when the user updates their device operating system to the latest version.

Device lifecycle messages do not appear for users

Device lifecycle user messages are not currently available for iOS devices that use an SSO extension profile.

In Incognito mode on Chromium browsers, Okta Verify doesn't launch when users click Sign in with Okta FastPass or when users click Select for Use Okta FastPass

In Incognito mode on Chromium browsers, when users click Sign in with Okta FastPass on the Sign-In Widget or click Select for Use Okta FastPass as their security method, Okta Verify doesn't launch. This is due to a feature in Google Chrome v75.0.3770.70 that affects all Chromium browsers (for example, Chrome, Brave, and Microsoft Edge). With this feature, links that are clicked in Incognito mode will no longer open native applications. The issue is resolved when the user exits Incognito mode on their Chromium browser.

Android and iOS

Okta Mobile is not supported in Identity Engine orgs

Okta Verify with Push enrollments migrated from Classic Engine to Identity Engine don't work if the Hardware protected constraint is enabled in the authentication policy

Issue

In the following situations:

  • A user in a Classic Engine org enrolled in Okta Verify with Push
  • The org is migrated to Identity Engine
  • For a given app, the authentication policy setting Hardware protected is selected in Possession factor constraints
  • The authentication policy allows authentication with Okta Verify with Push
  • The user tries to access the app using Push

Access to the app fails because the key associated with the user's Okta Verify Push enrollment was not stored in hardware when it was initially enrolled in the Classic Engine org.

Solution

The user can do one of the following:

  • Set up Okta FastPass in Okta Verify, if the option is available.

  • Remove the account from Okta Verify, and then re-enroll with that account.

Custom sign-in page elements might be missing in some circumstances

If your org deploys a custom Okta Sign In Page, be aware that some of your customizations may be missing or inoperable if Okta prompts users to enroll in your company's device management solution.

In some circumstances, the Okta Verify configuration in a user's Okta End-User Dashboard shows two Okta Verify enrollments instead of one

The context of this issue is a Classic Engine org without Push enabled upgraded to an Identity Engine org in which Push+TOTP are enabled by default.

Issue

In the following situation:

  1. A Classic Engine org on which Okta Verify with Push is not enabled.
  2. A user is enrolled in Okta Verify.
  3. The org is upgraded from Classic Engine to Identity Engine.
  4. The user sets up their device as an authenticator through Ways to sign on the Okta Verify Account Details screen.
  5. Now, in the Settings > Extra Verification section of the user's Okta End-User Dashboard, the user's Okta Verify configuration includes two Okta Verify enrollments instead of one, which may cause confusion.
Solution

Through Settings > Extra Verification section of the user's Okta End-User Dashboard, the user should remove the enrollment called “Okta Verify.”

In some circumstances, while setting up an enrolled device as an authenticator through Okta Verify, it's necessary to obtain a temporary passcode from the same Okta Verify instance to complete the setup

Users may have difficulty using Okta Verify on their mobile devices to set up that same device as an authenticator for passwordless authentication (that is, setting up the This device option in Ways to sign in in Okta Verify Account Details). This is because, while setting up This device in Okta Verify, the user is prompted to verify their identity by entering a temporary code generated by Okta Verify which would involve leaving the set up flow to get the temporary 6-digit code and then returning to the set up flow to enter the code before the code expires (approx. 30 seconds).

Before enabling This device as a sign-in method, users should check whether other sign-in methods are enabled. If only Authentication code is turned on, users should:

  1. Go to the Okta Verify accounts page.
  2. Tap the six-digit code to copy it.
  3. Immediately return to the Account Details screen, and then enable This device as a sign-in method.
  4. Enter the six-digit code when prompted.

Users can’t authenticate with Okta Verify when they access a Secure Web Authentication (SWA) application in their native mobile browser

When users try to access a Secure Web Authentication (SWA) application in their native mobile browser from the Okta End-User Dashboard or by using the app URL, the Okta Verify authentication doesn’t succeed. Instead, users are redirected to the app sign-in page even if the Device sign-in method and biometrics are enabled in Okta Verify.

If Intune is your MDM software, Office 365 isn't supported when you enforce Device Trust for native apps and browsers on MDM-managed iOS and Android devices

If Microsoft Intune is your mobile device management (MDM) provider and is federated to Okta, applying a Not Trusted --> Deny authentication policy to an Okta-federated Office 365 app will block users with unmanaged Android and iOS devices from enrolling their device in Intune. This occurs because your Office 365 authentication policy is applied to Intune as well. Okta is investigating this issue. In the meantime, Okta recommends that you use Microsoft Intune mobile application management (MAM) to manage access to Office 365 apps and the Okta Device Trust solution to manage access to other sensitive apps.