Devices known issues and workarounds

This issue occurs when an org has multiple device management configurations for the same platform and each configuration integrates with a different solution. For example, if one of your Windows device management configurations integrates with Microsoft Intune and another with Workspace ONE.

When a user on an unmanaged device tries to access an app that is associated with one of the configurations and the authentication policy requires a managed device, Okta displays an Additional setup required remediation message. The message includes the name of the solution and a link to their enrollment site.

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

When an Active Directory (AD)-sourced user prepares to set up Okta Verify from the Settings page on the Okta End-User Dashboard, the enrollment QR code is displayed. If the user is deactivated in AD before they scan the QR code, they could still scan the QR code and enroll in Okta Verify. A QR code generated before a user is deactivated in AD remains valid until they time out.

Even if the user is able to enroll into Okta Verify successfully, they can't access any Okta-protected apps.

To resolve this issue, delete unwanted Okta Verify enrollments from the Admin Console.

If you're using Okta FastPass to sign in to a multi-org environment and Okta FastPass isn't set up for all orgs, the Okta FastPass enrollment prompt might not appear.

To avoid this issue, make sure Okta FastPass is set up for all orgs.

To resolve this issue, delete the user enrollment from Okta.

Okta isn't able to probe for device context, so users are denied access when they authenticate with a username and password. This issue occurs 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.

Use the following steps to work around this issue:

1. Enable Okta FastPass.

2. In step 5, select the Show the "Sign in with Okta FastPass" button checkbox.

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

If a user doesn't have an Okta Verify account, enrollment is automatically triggered when they enter their org URL (for example, http://exampleorg.okta.com) in a browser.

However, if the user enters their admin portal URL (for example, http://exampleorg-admin.okta.com), the browser redirects the user to their org URL, but the enrollment isn't automatically triggered.

To avoid this issue, use the org URL instead of the URL for the admin portal.

Sign in with Okta FastPass isn't supported in WebView on native Android apps.

If the Okta Verify app isn't running in the background, Okta can't probe for device context and the user may be denied access, depending on the app sign-on policy.

Share these workarounds with your users:

• Launch the Android Okta Verify app before logging in to the app.

• Enable notifications for Okta Verify in the device's settings app.

• Ensure the App battery usage for Okta Verify isn't set to Restricted within the device's settings app.

• Add Okta Verify to the list of apps that never turn off or go to sleep in the background. If you can't add Okta Verify to the Never sleeping apps list, or if you already did and the issue persists, disable the parent setting Put unused apps to sleep.

• Ensure that Okta Verify is installed only in the work profile. If users also install the app in the personal profile, device probing fails, and the device doesn't appear as managed.

On Android 12, you can't enable biometrics if Okta Verify is installed on your work profile.

To work around this issue, skip the biometrics enablement step if you can.

Phishing-resistant factor restraints don't work on unmanaged devices if iCloud Private Relay is enabled. If unmanaged iOS devices are specified in the authentication policy and you want to require phishing-resistant factor restraints, then users must disable iCloud Private Relay before authenticating.

Share these workarounds with your users:

• Disable iCloud Private Relay before authenticating. Re-enable it after authentication is complete.

• See the knowledge base article for more workarounds.

When attempting to activate their account in Okta Verify for iOS, new users without a configured password receive an Authenticator operation is not allowed error message. This prevents the completion of the enrollment process.

To work around this issue, the user (or an admin) can set a password factor before enrolling the device in Okta Verify. Alternatively, the user can enroll in Okta Verify using a non-iOS device and then add the account to their iOS device.

Okta Verify single sign-on (SSO) fails when a user tries to access a Google Drive File Stream app that is protected by a policy permitting passwordless access.

To resolve this issue, click Sign in with your browser instead to access the app.

This is a known issue for macOS Big Sur and earlier. Apple has fixed the issue for macOS Monterey.

To resolve this issue, the user must restart Okta Verify.

Device lifecycle messages aren't available on macOS devices that use an SSO extension profile.

This only affects Safari users with macOS Big Sur and earlier.