Devices known issues

Before you contact Okta Support, use the known issues information to identify the cause of the issue you experienced.

Platform

Known issue

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

When enrollment desynchronization occurs, the solution varies depending on the action that caused it.

Admin server-side causes

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

    When you deactivate a device in the OktaAdmin 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, click disable user verification (for example, Disable Windows Hello, or Disable Touch ID), and then click 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, click disable user verification (for example, Disable Windows Hello, or Disable Touch ID), and then click 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 Okta Admin 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 Okta Admin 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.

Remove accounts before deleting Okta Verify

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

Support for adding multiple Okta accounts to the same Okta Verify app instance

Users can add multiple accounts to Okta Verify as long as each account is for a single user in a separate Okta org. Users cannot add more than one Okta Verify account per Okta org.

Deactivated then reactivated users get an error when trying 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.

Suspending then reactivating a user

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

Not possible to access an app without enabling biometrics in some circumstances

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

Scenario

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 (Windows Hello) for the account at that time or later;
  3. Tries to access an Okta-protected app from either:
    • The Okta End-User Dashboard and they didn’t use Okta Verify to sign in to the dashboard (IdP-init).
    • - or -

    • 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 app sign-on 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 at the following 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.
  • -or-

  • If the user is shown a list of authenticators, Use Okta Verify on this device isn’t included because the user hasn’t enabled biometrics for their account. Without the Use Okta Verify on this device option in this case, the user can’t access the app.
The user sees this: Instead of this:
Verify it's you with an authenticator screen that appears. 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 app sign-on 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.

Polling loop if user declines to provide required biometrics during app access

When accessing an app that requires user verification (biometrics or PIN) to access, if the user clicks or taps Cancel when prompted for user verification, Okta Verify continues to prompt the user for user verification instead of redirecting to the org's home page. To remedy, the user can try the following: 

  • Close Okta Verify, reopen it, and then try to access the app again.
  • Go to Okta Verify settings and turn User Verification off then on again.
  • Remove the account from Okta Verify, and then add it back.

Remediation message for unmanaged devices might present the wrong device management solution

Given

  1. An org with 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 app sign-on policy requires devices to be managed.
  4. To help users on unmanaged devices enroll in their organization's chosen device management solution, Okta displays a remediation message Additional setup required that includes the name of the solution and a link to their enrollment site.

Limitation

In the case of multiple configurations 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 users deactivated in AD are able to enroll in Okta Verify

Given

  1. An Active Directory (AD)-sourced user, active in both AD and Okta.
  2. While the user 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.
  3. The user is deactivated in AD before they scan the QR code.
  4. The user scans the QR code and is successfully enrolled in Okta Verify after satisfying a user verification prompt.

Issue

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 app sign-on 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 app sign-on policy that requires devices to be managed, make sure to configure Device Management.

Error message is not specific

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

Error if user enters the wrong email when setting Okta Verify through email link

When setting up Okta Verify, if an end 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.

MDM remediation message is not shown in some cases

If you configured an app sign-on policy that requires devices to be managed, but did not configure Device Management (Security > Device Integrations), users on unmanaged devices are shown the message You do not have permissions to perform requested action 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 end 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 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 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 app sign-on 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.

An end user that is activated after being deactivated is able to access the Okta End-User Dashboard without first resetting their password

End user authentication requirements are based on the Okta sign-on policy and app sign-on 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.

End 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.

End 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 end 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 instances. To avoid this issue, make sure Okta FastPass is set up for all orgs before you sign in.

End 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

A user is able to sign in to an app from a deactivated device

This is expected behavior. If all rules in the app sign-on 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 end 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.

macOS

Problem 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.

Problem 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 an end 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 end 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 end 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 end user messages do not appear

Device lifecycle end 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.

Windows

No hash appears for dedicated hardware attribute on 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 end 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 (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 app sign-on 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 Office 365 apps, the first user verification attempt fails, but the second attempt works

This is a known issue. When you attempt to sign in to an Office 365 app, Okta Verify doesn't automatically launch. Click Sign in with Okta FastPass to launch Okta Verify, and then provide user verification. Your user verification attempt will fail. Click More choices, select an authentication method from the list, and then provide user verification. The second user verification attempt will work.

macOS and Windows

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

End users who already have Okta Verify installed on their desktop device may 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 avoid getting stuck in a loop, the end user must either:

  • Enable user verification in Okta Verify by clicking the three vertical dots next to the account, and then click Enable Touch ID (mac) or Windows Hello (Windows), then try to access the app again.
  • – or –

  • Install Okta Verify on a different device and enroll in Push and TOTP, 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

  • 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 end 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 sign-on policy

Given

  1. Okta Verify is not installed or not running on end-user's device.
  2. An app sign-on policy 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.
  3. User tries to access the app

Issue

Access to the app is denied with the message "You don't have permissions to perform the requested action." This is expected behavior. Rule 1 requiring devices to be registered to access the app causes Okta to silently probe 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.

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 in Account Details 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, end users must delete the accounts and re-enroll in Okta Verify. See Set up Okta Verify on iOS devices.

Okta FastPass doesn't launch Okta Verify

In some instances, when end 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 end user messages do not appear

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

Android

Google Pixel 4 XL devices prompt for fingerprint scan which 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.

Error 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

Given

  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.

Issue

Enabling User Verification fails and the message displays The user signing in did not match the user on the account.

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 right dashboard, users should sign out and 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 message “Tap to verify your identity with Okta Verify.” 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.

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 app sign-on policy

Given

  • 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 sign-on policy setting Hardware protected is selected in Possession factor constraints
  • The sign-on policy allows authentication with Okta Verify with Push
  • The user tries to access the app using Push

Issue

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 end 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 end users to enroll in your company's device management solution.

In some cases, 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.

Given

  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 in Okta Verify Account Details.

Issue

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 cases, 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 page, and then enable This device as a sign-in method.
  4. Enter the six-digit code when prompted.

End 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, either 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 app sign-on policy to an Okta-federated Office 365 app will block end users with unmanaged Android and iOS devices from enrolling their device in Intune. This occurs because your Office 365 app sign-on 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.

Related topics