How to Identify Applications Impacted by the Okta Verify "deviceName" Property Change
Last Updated:
Overview
To improve overall security posture, Okta is updating unauthenticated response data for Okta Verify.
For the /idp/idx/identify endpoint, the Okta Verify enrollment profile clears the deviceName property during unauthenticated API requests and returns a null value. The actual value populates as expected once the user successfully verifies a factor.
For /api/v1/authn, admins are only impacted if their custom application code explicitly references the Profile object of Okta Verify factors within the unauthenticated response.
While most admins will experience no functional disruption, organizations using Direct Auth APIs or custom SDK integrations that reference Okta Verify factor data before authentication may encounter visual bugs.
A phased rollout across Production Cells is scheduled between June 15, 2026, and July 27, 2026.
This article provides instructions for identifying and testing custom applications that may be affected by this change.
NOTE: Administrators might have received communications regarding this update with the following subject lines:
-
- Okta Customer Comm Notification | Action Required: Update Custom Application Logic to Prevent Authentication Errors
- Okta Customer Comm Notification | Action Recommended: Update Custom Application Logic to Prevent UI Errors
Applies To
- Direct Auth APIs
- Application Programming Interface (API)
- Custom SDK integrations
- Okta Verify
- Okta Classic Engine
- Okta Identity Engine (OIE)
Cause
This change is being implemented proactively to prevent user enumeration. User enumeration is a method attackers use to determine whether a specific user exists in a system by analyzing the varying responses the system provides. Suppressing the device name before authentication mitigates this risk.
Solution
If the organization uses Direct Auth APIs or custom SDK integrations that reference device metadata before a user has completed authentication, follow these steps to identify and resolve potential impacts:
- Audit Codebase: Review the custom application code for any logic that references unauthenticated Okta Verify response data.
- For
/api/v1/authn, identify any custom application logic that explicitly references the Profile object of Okta Verify factors in the unauthenticated response. - For
/idp/idx/identify, identify references to the deviceName property within the Okta Verify enrollment profile object.
- For
- Remove Unauthenticated References: Modify the application logic so it does not depend on these values before authentication is complete. Ensure the custom authentication flows handle null or missing values gracefully.
- Run System Log Queries (Okta SDKs): As an Okta Admin, navigate to the System Log and run the following queries (searching at least 7 to 90 days back) to identify any SDK usage that needs to be tested. This will help to locate related App instances, Users, and Origin domains.
- For
/api/v1/authn:
debugContext.debugData.requestUri sw "/api/v1/authn" and (client.userAgent.rawUserAgent co "okta-react-native" or client.userAgent.rawUserAgent co "okta-oidc" or client.userAgent.rawUserAgent co "appauth-ios" or client.userAgent.rawUserAgent co "okta-auth" or client.userAgent.rawUserAgent co "okta-spring-security" or client.userAgent.rawUserAgent co "okta-sdk" or client.userAgent.rawUserAgent co "OktaSDK.NET" or client.userAgent.rawUserAgent co "OktaSDKJava" or client.userAgent.rawUserAgent co "okta-aspnetcore" or client.userAgent.rawUserAgent co "oidc-middleware" or client.userAgent.rawUserAgent co "okta-terraform" or debugContext.debugData.oktaUserAgentExtended co "okta-sdk" or debugContext.debugData.oktaUserAgentExtended co "okta-auth") and not (debugContext.debugData.oktaUserAgentExtended co "okta-hosted")
For/idp/idx/identify:
debugContext.debugData.requestUri sw "/idp/idx/identify" and (client.userAgent.rawUserAgent co "okta-react-native" or client.userAgent.rawUserAgent co "okta-oidc" or client.userAgent.rawUserAgent co "appauth-ios" or client.userAgent.rawUserAgent co "okta-auth" or client.userAgent.rawUserAgent co "okta-spring-security" or client.userAgent.rawUserAgent co "okta-sdk" or client.userAgent.rawUserAgent co "OktaSDK.NET" or client.userAgent.rawUserAgent co "OktaSDKJava" or client.userAgent.rawUserAgent co "okta-aspnetcore" or client.userAgent.rawUserAgent co "oidc-middleware" or client.userAgent.rawUserAgent co "okta-terraform" or debugContext.debugData.oktaUserAgentExtended co "okta-sdk" or debugContext.debugData.oktaUserAgentExtended co "okta-auth") and not (debugContext.debugData.oktaUserAgentExtended co "okta-hosted")
- For
- Manually Test Non-Okta SDKs: Okta cannot detect direct API calls or Non-Okta SDK usage (nor can Okta detect if apps overwrite user agent data/request headers). When utilizing non-standard SDKs or custom API calls, manually test and verify these custom apps.
- Validation: Verify that the custom applications function as expected and do not exhibit visual bugs in the Preview environment prior to the Production rollout.
