Okta Identity Engine release notes (Preview)

Version: 2026.06.0

Configurable connection lifetime for OIDC-enabled LDAP Interface

The LDAP Interface now includes a configurable setting for the maximum connection lifetime when using the OpenID Connect (OIDC) flow. This allows admins to define connection validity for up to 90 days and decouples connection expiry from the global session policy.

Maximum number of IDPs in an IDP routing rule increased

The maximum number of allowed IdPs in an IdP routing rule has been increased to 100. See Configure identity provider routing rules.

Import AI agents from DataRobot

You can now import and manage AI agents built in DataRobot Agent Workforce Platform directly through DataRobot. See AI agent imports.

Suspicious login details added to entity risk detection

In Suspicious Login From An IP Flagged By FastPass detections, the reason field now populates the external_session_id of the suspicious login.

Improved network zone error messages

The error message that appears when admins try to delete a network zone that's referenced by multiple policies or rules is now easier to read.

Clear Managed Chrome Profile Browsing Data

Clear Managed Chrome Profile Browsing Data provides real-time remediation by instantly purging local session data (cookies and cache) within managed Chrome profiles upon ITP detection. By transforming the browser into a policy-enforced workspace, it ensures immediate, automated protection. See Clear managed Chrome profile browsing data.

Role-assignable push groups for Office 365

When you create a new push group for the Office 365 app integration, select the Is this role assignable checkbox to make the group role assignable in Microsoft Entra ID. This allows you to push Okta groups to Microsoft Entra ID and assign roles instead of manually creating groups in Entra ID and then linking them to Okta using push groups. See Configure Push Group.

Improved request details layout

The request details page now features an optimized layout for small screens to improve readability.

SAP SuccessFactors OAuth 2.0 with SAML Assertion

The SAP SuccessFactors app integration now supports OAuth 2.0 with SAML Assertion for enhanced API security. To ensure your provisioning and sync processes continue without interruption, you must migrate to this new authentication method before SAP Basic Authentication deletion deadline on November 20, 2026. See Configure OAuth 2.0 with SAML for SAP SuccessFactors.

New System Log events for privileged access database integrations

Two new System Log events, pam.integration.create and pam.integration.delete, are now available for Okta Privileged Access database management. This enhancement allows admins to track when database integrations are created or deleted. See System Log.

• The Send me an email button on the email verification screen of the Sign-In Widget (third generation) was truncated for Ukrainian translations. (OKTA-1016906)

• App integrations didn't populate user credentials for subdomains that used the /auth/v3/signin endpoint, preventing users from signing in to the app. (OKTA-1074055)

• In orgs that use a custom domain, users were redirected to a non-custom domain after they signed out of the My Settings page. (OKTA-1139970)

• The show/hide password icon on the Sign-In Widget (third-generation) was missing alt text. (OKTA-1156653)

• Attempts to deactivate and delete a device failed and returned a 404 Not Found: Resource not found error. (OKTA-1160266)

• The help link image on the Sign-In Widget (third generation) was missing alt text. (OKTA-1164533)

• The "OR" separator on the Sign-In Widget (third generation) couldn't be read by screen readers. (OKTA-1164534)

• Okta Expression Language expressions with array attributes didn't always behave as expected. (OKTA-1166566)

• Sign-in attempts originating from the IP exempt zone or trusted proxies were incorrectly evaluated as high risk with the reason "Anonymizing Proxy." (OKTA-1168827)

• After a multibrand-enabled org upgraded to Okta Identity Engine, custom brand redirect settings weren't migrated and the end user was incorrectly directed to the End-User Dashboard. (OKTA-1174572)

• The application.lifecycle.update System Log event didn't populate the changeDetails field when admins updated Active Directory app settings. (OKTA-1178325)

• RADIUS app sign-in policy rules were missing the Linux platform condition. (OKTA-1184034)

• Iden (API Service) has a new scope.

• Fleetclear (OIDC) is now available. Learn more.

• Dell PowerProtect Backup Services (API Service) is now available. Learn more.

• Kirin (SAML) is now available. Learn more.

Device assurance OS version update

The following OS versions are now supported in device assurance policies:

• Android 13, 14, 15, 16 security patch 2026-01-05

Spec-compliant client ID claims for AI agent tokens

Okta Expression Language profiles now include the app.clientId property during user claim evaluations for AI agent OAuth 2.0 clients. This allows developers to generate spec-compliant tokens during AI agent flows.

OAuth secure token exchange for Salesforce requests

Okta for AI Agents now uses the OAuth 2.0 secure token exchange flow when it sends requests to the Salesforce app integration, resource server, or MCP server.

Event hooks for AI agent APIs

The AI agent APIs are now event hook-eligible, enabling Workflows to be triggered based on events. See Event hooks.

Provisioning for Rapid7 InsightAppSec

Provisioning is now available for the Rapid7 InsightAppSec app integration. When you provision the app, you can enable security features like Entitlement Management. See Rapid7 InsightAppSec.

• Some UI labels and descriptions on the AI agents screens were inconsistent. (OKTA-1119360)

• For a specific Active Directory integration, scheduled and manual incremental imports failed intermittently in Preview environments. This issue occurred after admins resumed a previously halted import block. (OKTA-1135003)

• During Group Push operations, Okta unexpectedly provisioned a non-Active Directory user into a target Active Directory group. (OKTA-1147204)

• During an Okta Verify enrollment, a broken mobile setup link was incorrectly displayed. (OKTA-1158811)

• After a successful YubiKey inline enrollment, the interface displayed a blank page, forcing users to manually close the page to proceed with authentication. (OKTA-1163272)

• When admins edited a custom admin role that included delegated flow Workflows permissions, Okta incorrectly prompted them to repeat step-up authentication. This issue blocked the changes and displayed a protected-action message. (OKTA-1169760)

• During Group Push operations, updates sometimes failed with an error message when the system processed group memberships. This issue caused synchronization to fail intermittently for specific push groups. (OKTA-1181698)

• Group Push operations to Jamf Pro sometimes failed. (OKTA-1183535)

• IP addresses weren't populated in the user.risk.detect System Log event when a breached credential was detected. (OKTA-1184255)

• Some users saw a Bad Request error when they tried to sign in with Okta FastPass. (OKTA-1185557)

• For some orgs using Okta for AI Agents, the OAuth 2.0 authorization flow failed when downstream identity provider client IDs contained a plus character. (OKTA-1191356)

• CodeSignal (SAML) is now available. Learn more.

• CodeSignal (SCIM) is now available. Learn more.

• Dell Power Protect Backup Services powered by Druva has the okta.deviceAssurance.manage and okta.behaviors.manage scopes.

• Kirin (SAML) is now available. Learn more.

• Mabyduck (OIDC) is now available. Learn more.

• Mabyduck now supports Universal Logout.

• Ocozzio Marketing Center (SAML) is now available. Learn more.

• Ocozzio Marketing Center (SCIM) is now available. Learn more.

• Risotto (SAML) is now available. Learn more.

• StackAdapt (SCIM) is now available. Learn more.

• X (Twitter) (SWA) was updated.

Admin OIDC App Phase Two Tranch One

When the Admin OIDC App Phase Two Tranch One feature is enabled, the Okta Admin Console automatically initiates the OIDC sign-in flow on page load, and admins are briefly redirected to the authentication page before the requested page appears.

Unique client authorization settings required for OIN apps

When you enter client authorization details for an app integration, an error now appears if another integration already uses those details.

New protocol runtime for Amazon Bedrock AgentCore AI agents

You can now import both standard HTTP and agent-to-agent protocol runtimes from the Amazon Bedrock AgentCore platform.

MCP servers active by default

Newly created MCP servers are now in an active state by default. See Add MCP servers.

AI agent admin role

Super admins can now delegate AI agent management tasks using the new AI agent admin role. Admins with this role can perform tasks like registering AI agents, assigning owners, and configuring resource connections. See Manage Okta for AI Agents admin roles.

Date range filter for AI agents

The AI Agents page now provides a date range filter so admins can filter AI agents by when they were created or updated.

• Users received an error when they used Okta Verify push as the authentication method to sign in to Microsoft 365 native desktop apps. (OKTA-1098991)

• ITP couldn't successfully complete continuous policy evaluation when device IDP conditions were part of the policies. (OKTA-1123312)

• In the Sign-In Widget (third generation), the password history requirement wasn't displayed when users reset their password. (OKTA-1142182)

• Users who matched a group rule weren't automatically added to the target group. (OKTA-1152179)

• The hyperlink icon on the Recent Activity page of My Settings was missing alt text. (OKTA-1164465)

• When users signed in with Google authenticator on a mobile device, they couldn't copy the code for Okta Verify Time-based One-Time-Password (TOTP). This required them to switch between apps to enter the code. (OKTA-1169544)

• Sometimes accessing an Active Directory domain resulted in a 500 error. (OKTA-1194967)

• The Agent down notification label in the Admin Console was unclear. (OKTA-1195857)

• The Resource Server tab was visible for app integrations that don't support OAuth 2.0 secure token exchanges. (OKTA-1197690)

• When the display language was set to French, some text in the Partner Admin Portal wasn't translated. (OKTA-1198325)

• Sometimes approval tasks in access requests for Okta admin roles weren't assigned to groups and remained unassigned, causing delays in request resolution. (OKTA-1198387)

• When an Okta service account was removed from Okta Privileged Access, Okta suspended the associated managed users and blocked admins from performing manual lifecycle operations on those users. (OKTA-1199623)

• Docupilot (SCIM) is now available. Learn more.

• Dokio (SAML) is now available. Learn more.

• Dokio (SCIM) is now available. Learn more.

• Factor Labs (SCIM) is now available. Learn more.

• Granola (SAML) is now available. Learn more.

• IBM OS/400 on AS/400 (IBM i on Power Systems) by Aquera (SCIM) is now available. Learn more.

• Rapid7 Insightappsec (SAML) is now available. Learn more.

• Splunk Add-on for Okta Identity Cloud (API Service) has a new integration guide.

• Supabase (SAML) is now available. Learn more.

• Taktile (SCIM) is now available. Learn more.

• Taktile has a new configuration guide.

Bot protection

Bot protection enables orgs to automatically identify and mitigate bot traffic by configuring remediation actions within the Identity Threat Protection (ITP) landing page. See Bot protection.

DirSync group imports for Active Directory

For Active Directory (AD) integrations, the Provisioning tab now provides an Enable imports with AD using DirSync checkbox. When you enable the checkbox, admins can perform incremental group imports using DirSync. See Configure Active Directory import and account settings.

Workday supports incremental imports

Workday now has the ability to run immediate, incremental imports. Incremental imports are much faster than full imports. However, they don't detect when users only have changes to custom attributes, so you must periodically run a full import to capture these changes. See Incremental imports.

Same-device enrollment for Okta FastPass

On orgs with Okta FastPass, the Okta Verify enrollment process has been streamlined:

• Users can initiate and complete enrollment on the device they're currently using. Previously, two different devices were required to set up an account.
• Users no longer need to enter their org URL during enrollment.
• The enrollment flow has fewer steps. This feature is supported on Android, iOS, and macOS devices.

Prevent new single-factor access to the Admin Console

This feature prevents admins from configuring any new single-factor access to the Admin Console. This feature is currently available to new orgs only.

Application Entitlement Policy

Admins can now override attribute mapping when assigning apps to individuals or groups. You can also revert attributes to their default mappings. See Override application attribute mapping. This feature will be gradually made available to all orgs.

Direct End-User Settings access

Users may now access their Settings page through a direct URL in addition to the End-User Dashboard. This feature provides convenience and security for users, gives admins greater flexibility when working with End-User Dashboard access control scenarios, and includes accessibility and UX improvements. See End-User Settings.

End-user setting for nicknaming factors

End users can now nickname their phone, WebAuthn, and Okta Verify factors. If they have enrolled multiple instances of a factor, giving nicknames helps them identify the factors quickly (for example, "My personal cellphone" or "My office MacBook TouchID"). See the end-user documentation. This is a self-service feature.

Descriptive System Log events

When Okta identifies a security threat, the resulting security.threat.detected System Log entry now provides a descriptive reason for the event. See System Log.

New flexible LDAP

A new LDAP schema allows flexibility by moving email to the custom schema and making first name, last name, username, and UID optional. This avoids error scenarios when an LDAP schema doesn't include specific attributes.

ThreatInsight coverage on core Okta API endpoints

Okta ThreatInsight coverage is now available for core Okta API endpoints:

• OpenID Connect and OAuth 2.0
• Okta Management
• MyAccount API

Based on heuristics and machine learning models, Okta ThreatInsight maintains an evolving list of IP addresses that consistently show malicious activity across Okta's customer base. Requests from these bad IP addresses can be blocked or elevated for further analysis when Okta ThreatInsight is enabled for an Okta org. Previously, Okta ThreatInsight coverage only applied to Okta authentication endpoints (including enrollment and recovery endpoints). With this release, enhanced attack patterns are detected for authentication endpoints and limited attack patterns are also detected for non-authentication endpoints. There are no changes to the existing Okta ThreatInsight configuration. You can still enable Okta ThreatInsight with log and block mode, log mode, and exempt network zones. A new Negative IP Reputation reason is available for high security.threat.detected events. See System Log events for Okta ThreatInsight.

SSO apps dashboard widget

The new SSO apps widget displays the number of user sign-in events across each of your org's apps over a selected period of time. You can use it to see which apps are used most frequently and to easily monitor the authentication activity across your org.

Improvements to the self-service unlock process

Earlier versions of the self-service unlock (SSU) flow created unnecessary friction in the end user experience. The newly enhanced SSU feature introduces a seamless magic link experience in emails sent out to unlock accounts. Users no longer need to provide consent when using the same browser. In addition, after successfully unlocking their account, clicking the email magic link counts towards the app's assurance policy. After the assurance requirements are met, the user is signed directly in to the app.

Improvements to the self-service registration experience

Earlier versions of the self-service registration (SSR) flow used a complicated array of templates to send activation emails to end users. The simplified SSR flow reduces this to only two email templates with customized welcome messages. If your app requires immediate verification of the end user's email address, Okta uses the Registration - Activation template. This template includes a magic link for a smoother sign-in experience. If email verification isn't immediately required to sign in to the app, Okta uses the Registration - Email Verification template. This template includes a link for end users to complete email verification at any time after they successfully sign in to the app.

Device Authorization grant type

Advancements in internet technology have seen an explosion of smart devices and the Internet of Things. Consumers need to sign in to apps that run on these devices, but the devices either lack support for a web browser or have limited ability for input, such as smart TVs, car consoles, and thermostats. As a result, users resort to insecure authentication solutions that are error prone and time consuming.

The Device Authorization grant feature is an OAuth 2.0 grant type that allows users to sign in to input-constrained devices and also to devices that lack web browsers. This feature enables users to use a secondary device, such as a laptop or mobile phone, to sign in to apps that run on such devices.