Overview

This article covers prerequisites, deployment configuration, and troubleshooting steps for DBSSO registration failures and repeated multi-factor authentication (MFA) prompts.

Applies To

• Okta Identity Engine (OIE)
• Okta Device Access (ODA)
• Desktop MFA for Windows
• Device-Bound Single Sign-On (DBSSO)

Solution

Prerequisites and Environment Requirements

Before deploying or troubleshooting DBSSO, confirm the following requirements are met across all target endpoints.

Client Version Requirements

• Windows: Okta Verify 6.6.2 or later.

NOTE: Okta Verify versions 6.9 and later introduce an updated DBSSO registration process.

Windows Registry Configuration

The following deployment parameters must be pushed to Windows endpoints via a mobile device management (MDM) solution or Group Policy Object (GPO).

Additional Prerequisites

• Device Access Certificate: Install the certificate in the Local Computer Store. The certificate must contain Object Identifier (OID): 1.3.6.1.4.1.51150.13.1.
• User Enrollment: The target user must be enrolled in Okta FastPass on the same device.
• Username Alignment: The Okta username must match the Active Directory (AD) User Principal Name (UPN) or the Microsoft Entra ID UPN. For more information, see Windows Desktop MFA Users Unable to Login with FIDO2 Security Keys or Okta Verify Push/TOTP When UseDirectAuth Is Enabled.
• Password Synchronization: For Okta environments where direct authentication (delAuth) is not in use, the device password and the Okta password must match.
• Initial Online Login: The user must have signed in to the device using a Desktop MFA online factor — for example, an Okta Verify Push — to process the registration and seed the initial secure device session.

How to Troubleshoot DBSSO When Authenticated Users Are Repeatedly Prompted for MFA

When a user completes authentication but continues to receive MFA prompts in browsers, the root cause falls into one of two categories: the DBSSO session was never created, or the session was created but the authentication policy requirements are not satisfied.

Cause A: The DBSSO Session Is Not Created

The hardware-bound session record never initiates after the user completes authentication.

Step 1: Validate Baseline Prerequisites and Re-trigger Registration

Verify all items in the Prerequisites and Environment Requirements section are fully deployed, then restart the appropriate service to re-trigger registration. DBSSO registration triggers only during a service startup.

1. Verify all prerequisites in the Prerequisites and Environment Requirements section are completely deployed.
2. Restart the appropriate service based on the installed Okta Verify version:
   • Okta Verify 6.9 and later: Restart the Okta Authenticator Service.
   • Okta Verify earlier than 6.9: Restart the Okta Identity Service.

Step 2: Review Windows Event Viewer Logs

Open the Windows Event Viewer and trace the registration endpoint requests to determine the DBSSO registration status. Look for messages that detail the registration outcome.

• If logs show Device registration status: False, the device failed to register. Verify prerequisites again and restart the service.
• If logs contain the following error, a known limitation with Desktop MFA may be the cause. If Okta Verify is reinstalled on the device without first deleting the device entry from the Okta Admin Console, or without installing new certificate, device registration failures may occur.

DeviceRegistrationManager.ExecuteDeviceRegistrationAsync: Registration attempt 1 failed: Registration request failed with Forbidden. Error Id: oaerLslpexuRpWhzNpbxF9HYw, Error Code: E0000006, Error Summary: You do not have permission to perform the requested action, retrying in 60 seconds

NOTE: Deleting device from Okta admin console should be last option. Please refrain from recommending this workaround to customers until the root cause has been fully investigated. If an issue requires device deletion to resolve, escalate the case for further verification.

Step 3: Check the Okta System Log

If the Event Viewer indicates Device registration status: True, search the Okta System Log for the targeted user and filter for the event type user.device_session.start.

• If user.device_session.start is present: The DBSSO session was successfully created. Proceed to Cause B to evaluate authentication policies.
• If user.device_session.start is absent: Session creation failed on the endpoint during the Windows login flow. Review the following potential causes:
  • Offline Login Limitations: DBSSO is an online-only feature. If the user unlocks their workstation while offline, a valid cloud-backed device session cannot be initialized. Ensure the machine has an active network connection, then have the user sign in using an online MFA method such as an Okta Verify Push, Time-based One-Time Password (TOTP), or FIDO2. A new device session generates with every successful online Desktop MFA login.
  • Okta FastPass Status: Open the Okta Verify desktop application on the endpoint and confirm that Okta FastPass is fully configured, active, and bound to that specific user profile.

Cause B: The Authentication Policy Requirements Are Not Satisfied

The device session successfully initializes, but the user continues to receive authentication challenges inside application sessions.

Step 1: Verify Authentication Policy Rules

Confirm that the application authentication policy rules are configured with the correct expressions to recognize Okta-joined devices. Configure the authentication policy rules to filter for and recognize Okta-joined devices using the correct expression formatting as described in the Okta DBSSO Configuration Guide.

Step 2: Check Factor Assurance Alignment

Okta evaluates the exact authentication factor used at machine login against the targeted web application's sign-on policy. If an application requires a high-assurance factor such as phishing-resistant FastPass, but the user unlocked their Windows desktop using a standard Okta Verify Push or a one-time password (OTP), Okta prompts the user in the browser for the missing higher-assurance factor.

Adjust the targeted application sign-in policies to align with and accept the specific desktop authentication methods deployed across the workstation fleet.

Log and Event Reference

Successful Client-Side Execution Traces in Windows Event Viewer

During a healthy registration lifecycle, the following sequence appears in the Event Viewer logs. Navigate to Application and Services Logs > Okta Authentication Service Logs to locate these entries.

// Phase 1: Initiate registration
DeviceRegistrar.RegisterDeviceAsync: Starting device registration process.

// Phase 2: API call to register the device
OktaWebRequest.SendMessageAsync: Sending POST-message to https://<tenant>.okta.com/idp/v2/device/register with token OktaAccessToken

// Phase 3: Device Registration successful
DeviceRegistrar.RegisterDeviceAsync: Device registration v2 completed successfully.

Okta Device Access Client Session Creation Logs

Source: Okta Device Access (ODA) Local Logs

Path:c:\windows\system32\config\systemprofile\appdata\local\okta device access\logs

2026-06-08 16:35:11.192 +05:30 [INF] [DeviceSessionManager::GetOrCreateDeviceSession] No existing device session found for user EXAMPL_USER. Creating new session.
2026-06-08 16:35:11.192 +05:30 [INF] [DeviceSessionManager::GetOrCreateDeviceSession] Created new device session with handle 80cb1617-04ac-47aa-a03d-d4aaeb69244d.
2026-06-08 16:35:11.195 +05:30 [INF] [DeviceInstanceClient.SendRequestAsync] Requesting device session JWT via IPC.
2026-06-08 16:35:11.739 +05:30 [INF] [DeviceInstanceClient.SendRequestAsync] device session JWT retrieved.

Related References

• Windows Desktop MFA Users Unable to Login with FIDO2 Security Keys or Okta Verify Push/TOTP When UseDirectAuth Is Enabled
• Okta DBSSO Configuration Guide