Okta Identity Engine release notes (Preview)

Version: 2025.05.0

May 2025

Generally Available

App permissions no longer include agent permissions

Now when you assign the Manage applications permission to an admin, the Manage agents permission isn't automatically granted. For existing admin role assignments that include the Manage applications permission, the Manage agents permission is retained in the assignment. See Role permissions.

Microsoft Office 365 Single Sign-on integration supports SHA-256

The Office 365 SSO integration (WS-Fed Auto and Manual) now uses SHA-256 for signing the authentication token.

New versions of Okta Provisioning agent and SDK

Okta Provisioning agent 2.3.0 and Okta Provisioning agent SDK 2.2.0 are now available. These releases contain bug fixes and minor improvements. See Okta Provisioning agent and SDK version history.

New look and feel in the Partner Admin Portal app

The Partner Admin Portal app pages now have a new look and feel, including redesigned side and top navigation menus.

Reasons added to System Log event

In the System Log, the Reasons field for user.risk.detect events now indicates if the detection was triggered by a DCO event.

Device assurance OS version updates

Device assurance policies now support the following OS versions

  • Android 12, 13, 14, and 15 to security patch 2025-05-01
  • iOS 18.4.1
  • macOS Sequoia 15.4.1
  • Windows 10 (10.0.17763.7136, 10.0.19044.5737, 10.0.19045.5737)
  • Windows 11 (10.0.22621.5189, 10.0.22631.5189, 10.0.26100.3775)

Removal of device support for Windows 11 21H2

Okta Verify no longer supports devices that use Windows 11 21H2. See Supported platforms for Okta Verify.

Support for additional attributes in Office 365's Universal Sync

Office 365's Universal Sync now enables users to access Kerberos resources with Windows Hello for Business. See Supported user profile attributes for Office 365 provisioning

Improved Documentation Search

The search functionality on help.okta.com has been updated with the following improvements:

  • Localized Japanese search: Supports localized searches in Japanese for all translated content.
  • Focused results: Searches take place directly in Okta help instead of rerouting users to the Okta Help Center.

These features are now available on help.okta.com to help users quickly locate relevant documentation for their specific needs.

Okta Active Directory agent, version 3.20.0

This release includes support for enhanced incremental imports from AD using DirSync. Incremental import with DirSync avoids full imports and offers delta imports with AD that significantly improves performance. Configuration and opt-in is required within Okta after an agent update. This release also includes security enhancements and bug fixes. See Okta Active Directory agent version history

New protected action

Creating API tokens is now a protected action. When you enable this feature in your org, admins are prompted for authentication when they perform create an API token, at an interval that you specify. This additional layer of security helps ensure that only authorized admins can perform key tasks in your org. See Protected actions in the Admin Console.

Universal Logout for Splunk Enterprise

Splunk Enterprise now supports Universal Logout. This enables admins to automatically sign users out of this app when Universal Logout is triggered. See Third-party apps that support Universal Logout.

Define default values for custom user attributes

You can now define default values for custom attributes in a user profile. See Add custom attributes to an Okta user profile.

Policy Recommendation Tool deprecated

The trial period of the Policy Recommendation Tool has ended and the product has been deprecated.

Authentication claims sharing between Okta orgs

Authentication claims sharing allows an admin to configure their Okta org to trust claims from third-party IdPs during SSO. Sharing claims also allows Okta to interpret the authentication context from an IdP. This helps eliminate duplicate factor challenges during user authentication and helps improve security posture. See Add a SAML Identity Provider.

Updates to the advanced search filters

The operators dropdown menu in the Advanced search section on people, groups and group membership pages shows all options and grays out the options that aren't applicable.

Track MFA abandonment in the System Log

You can now monitor abandoned MFA attempts in the System Log using the user.authentication.auth_via_mfa event. The event now has two additional statuses for the event outcome:

  • UNANSWERED: MFA prompt was abandoned, but the user eventually signed in using another authenticator.
  • ABANDONED: MFA prompt was abandoned and the user couldn't sign in.

See Track MFA abandonment in the System Log

Updated text for the Login.gov IdP

For the Login.gov IdP, the Type of Identity Verification label has been updated to Type of Service Level, and the list of possible service levels has been updated.

Authentication claims sharing between Okta orgs

Authentication claims sharing allows an admin to configure their Okta org to trust claims from IdPs during SSO. Sharing claims also allows Okta to interpret the authentication context from an IdP. This helps eliminate duplicate factor challenges during user authentication and helps improve security posture. See Add a SAML Identity Provider.

Biometric user verification in authentication policies

You can now configure authentication policies to require biometric user verification (no passcode). With this feature you ensure that users confirm their biometrics when they authenticate with Okta FastPass or Okta Verify Push. See Biometric user verification in authentication policies.

Shared signal transmitters

Okta uses CAEP to send security-related events and other data-subject signals to third-party security vendors. To enable the transmission of signals from Okta, create an SSF stream using the SSF Transmitter API. Then, configure the third-party receiver to accept signals sent as Security Event Tokens (SETs) from Okta. See Configure a shared signal transmitter.

Early Access

Advanced device posture checks

Advanced posture checks provide extended device assurance to users. It empowers admins to enforce compliance based on customized device attributes that extend beyond Okta's standard checks. Using osquery, this feature facilitates real-time security assessments across macOS devices. As a result, orgs gain enhanced visibility and control over their device fleet and ensure that only trusted devices can access sensitive resources. See Configure advanced posture checks for device assurance.

Enhanced device assurance with Android Device Trust

Android Device Trust integration for Device Assurance enhances Okta's capability to evaluate and enforce security measures on Android devices. It introduces additional security settings such as checks for Play Integrity status and Wi-Fi security. This integration strengthens device compliance while eliminating the need for Mobile Device Management (MDM), providing orgs with increased flexibility in securing their Android endpoints. See Integrate Okta with Android Device Trust.

Inline step-up flow for User Verification with Okta Verify

End users can now easily satisfy authentication policies that require higher User Verification (UV) levels, even if their current enrollment is insufficient. This feature proactively guides users through the necessary UV enablement steps. As a result, administrators can confidently implement stricter biometric UV policies to eliminate the risk of user lockouts and reduce support inquiries related to UV mismatches. See User experience according to Okta Verify user verification settings.

Breached Credentials Protection

Protect your org from the impact of credentials that have been compromised. If Okta determines that a username and password combination has been compromised after being compared to a third-party curated dataset, the protection response is customizable through password policies, including resetting the user's password, forcing a logout, or calling a delegated Workflow. See Breached credentials detection.

This feature is following a slow rollout process beginning on May 15.

Okta as an external authentication method for Microsoft Entra ID

Use Okta multifactor authentication (MFA) to satisfy Microsoft Entra ID MFA requirements. This helps users avoid double authentication and provides a seamless experience across Okta and Microsoft 365 apps. See Configure Okta as an external authentication method for Microsoft Entra ID .

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.

Custom admin roles for ITP

Through this feature, customers can use granular ITP permissions and resources to create custom roles to right-size authorization for ITP configuration and monitoring. See Configure custom admin roles for ITP.

Fixes

  • Users were sent to the wrong help topic when they clicked Learn more in the Change Password section of the end-user Settings page. (OKTA-801189)

  • Admins who tried to create a stream with an inaccessible URL received an Internal Server Error (HTTP 500) instead of an API Validation Error (HTTP 400). (OKTA-827169)

  • Users who signed out of the End-User Settings version 2.0 page were redirected to their sign-in page instead of their custom sign-out page. (OKTA-878856)

  • When a custom admin role had the Generate device recovery PIN permission, admins with that role couldn't create a recovery PIN for a Desktop MFA client. (OKTA-881842)

  • When accessing an Okta org2org application on macOS devices, some users were unnecessarily prompted to enroll in the Okta Verify app. (OKTA-882059)

  • When doing incremental imports using Okta Provisioning agent, users whose profiles weren't modified were removed from groups in Okta. (OKTA-884952)

  • Admins and users couldn't reset the password for staged accounts with an unverified email status. (OKTA-885853)

  • The border for the table of Active Directory instances on the Delegated Authentication page was missing. (OKTA-893589)

  • When authenticating with SMS or Google Authenticator, some users saw an incorrect error message when they entered a space in the Enter code field of the Sign-In Widget (third generation). (OKTA-897996)

  • When admins enabled the Unified Look and Feel for Okta Admin Console feature, some user interface elements didn't render correctly on Default Policy pages. (OKTA-903370)

  • When users enrolled in Okta Verify, the core.user.factor.activate System Log event wasn't recorded. (OKTA-908444)

  • Some users were asked repeatedly to approve multiple Okta FastPass user verification prompts. (OKTA-909450)

  • Users were prompted for multifactor authentication twice when they signed in to a spoke org in an Okta Org2Org scenario even though the Trust claims from this identity provider option was selected for the hub org. (OKTA-912172)

  • Some users saw a login hint in the UserHome page URL for OIDC apps even though login hints were disabled. (OKTA-919432)

  • Super admins couldn't always access Workflows with the role-based access control (RBAC) feature enable. (OKTA-920704)

  • When third-party IdP claims sharing was enabled, the redirect to the IdP happened during reauthentication even if IdP didn't provide any AMR claims. (OKTA-922086)

  • PERIMETER81_VPN was incorrectly announced as a supported IP service category in enhanced dynamic zones. (OKTA-923426)

  • When a call to activate a downstream app user failed while activating a user, the user was stuck in an activating status. (OKTA-925217)

  • The user's profile dropdown menu label displayed the user's email address instead of their first name in the Secure Partner Portal app. (OKTA-925251)

  • If a third-party SAML IdP sent the session.amr SAML attribute without the attribute schema type, Okta rejected the response when the third-party claims sharing feature was enabled. (OKTA-925864)

  • Starting with version 136, Chrome no longer returned the thirdPartyBlockingEnabled signal, and users whose Device Assurance policies relied on the signal were denied access to their resources. (OKTA-927884)

Okta Integration Network

Weekly Updates

2025.05.1: Update 1 started deployment on May 15

Generally Available

New filter and columns for Access Certifications reports

You can use the Campaign ID filter in the Past campaign details and Past campaign summary reports. You can find a campaign's ID from System Log events or from the URL for the campaign details page. Additionally, the following columns are available for use in the Admin Console.

  • Past campaign details report:

    • User email
    • Reviewer email
    • Reviewer reassigned

  • Past campaign summary report:

    • Campaign resource count

Fixes

  • Some System Log entries showed the wrong user agent operating system version for risk scoring and new device detection events. (OKTA-792841)

  • Some Active Directory Single Sign-On (ADSSO) users were required to provide their username in the Sign-In Widget before they were routed to ADSSO. (OKTA-814881)

  • The Application Usage report didn't include successful RADIUS authentications. (OKTA-815504)

  • Some users didn't receive emails from Okta. (OKTA-826144)

  • When users edited an authorization server on the Security > API page, the value of the Type column on the Claims tab incorrectly wrapped to a second line. (OKTA-863707)

  • Some users weren't prompted for multifactor authentication after the Keep me signed in period expired. (OKTA-871178)

  • Admins didn't receive the correct notifications when they had both role and admin email notifications selected. (OKTA-876846)

  • Some ADSSO functionality didn't work as expected. (OKTA-880273)

  • When users edited an authorization server on the Security > API page, some user interface elements had the wrong background color. (OKTA-893509)

  • Some user interface elements on the API Token page had the wrong background color. (OKTA-893608)

  • Some users saw an extra line at the bottom of the Identity Providers page. (OKTA-893613)

  • Some user interface elements in the Access Testing Tool didn't render correctly when the Unified UI for the Admin App feature was enabled. (OKTA-904105)

  • Some user interface elements in the entity risk policy didn't render correctly when the Unified UI for the Admin App feature was enabled. (OKTA-904369)

  • Some user interface elements had incorrect spacing on the Okta API Scopes tab of app pages. (OKTA-905018)

  • Email notifications for the super admin role weren't applied consistently when all admin email notification settings were selected for the role. (OKTA-906587)

  • Agents in an error state were properly displayed on the Agent Monitors page for their respective directory integration but weren't displayed on the Admin Dashboard. (OKTA-910056)

  • Some users received an error message when they tried to sign in after their account was unlocked. (OKTA-913228)

  • Some users were prompted for multifactor authentication despite having previously selected Stay signed in. (OKTA-914076)

  • On the Add resource dialog, the Show more button didn't display all the resources that were already included in the resource set. (OKTA-921890)

  • Starting with version 136, Chrome no longer returned the thirdPartyBlockingEnabled signal, and users whose Device Assurance policies relied on the signal were denied access to their org. (OKTA-927884)

  • After signing in to Okta on a mobile device (either Android or iOS), opening the menu resulted in the screen flickering. (OKTA-933477)

  • Some users were unable to authenticate using Microsoft Entra ID External Authentication Methods. (OKTA-936300)

  • Updating an LDAP-sourced user profile sometimes resulted in an error. (OKTA-939330)

Okta Integration Network

  • Attribute Dashboard (OIDC) now supports IdP-initiated SSO flows.
  • DX (SAML) is now available. Learn more.
  • Embrace (SAML) is now available. Learn more.
  • Merkle (OIDC) is now available. Learn more.
  • SAP Concur by Aquera is now available. Learn more.
  • SAP S/4HANA by Aquera (SCIM) is now available. Learn more.

2025.05.2: Update 2 started deployment on May 21

Fixes

  • The online help link on the Brands page didn't link to the correct page. (OKTA-654709)

  • Some users saw an error message when editing the Embedded widget sign-in support settings on the Settings > Account page. (OKTA-881712)

  • LDAP agents were displayed as operational after registration, even if they hadn't successfully connected to Okta. (OKTA-886963)

  • Some users were prompted to enroll in additional authenticators after they enrolled in the FIDO2 (WebAuthn) authenticator. (OKTA-888797)

  • Some user interface elements in pages under the Customizations menu didn't render correctly when the Unified UI for the Admin App feature was enabled. (OKTA-893521)

  • The border on the Delegated Authentication page for LDAP used squared corners instead of rounded corners. (OKTA-893569)

  • When some users requested a new account activation email, an error message appeared after they clicked Request activation email. (OKTA-919395)

  • Some user interface elements on app pages weren't rendered correctly. (OKTA-932378)

  • Some pages didn't load correctly when the Unified look and feel for Okta Admin Console feature was enabled. (OKTA-938750)

Okta Integration Network

  • CyberDefenders (OIDC) is now available. Learn more.
  • Google Cloud Workforce Identity Federation (OIDC) is now available. Learn more.
  • Pro-Vigil (SAML) is now available. Learn more.

2025.05.3: Update 3 started deployment on May 29

Generally Available

RingCentral uses new default phone number logic

The RingCentral app integration's logic for detecting and populating phone numbers has been updated to work with both DirectNumber and IntegrationNumber entries.

Fixes

  • Users who successfully authenticated with AMR claims were still prompted to stay signed in. (OKTA-914125)

  • Users with '+' in their email address couldn't reset their passwords from email templates. (OKTA-914601)

  • When an admin changed a user attribute in Okta, the profile in Zendesk reverted back to the default language of the Zendesk account. (OKTA-916240)

  • In the System Log, 'policy.evaluate_sign_on' events with a DENY outcome displayed a 'PolicyRuleFactorMode'. (OKTA-922161)

  • Some users incorrectly received an Invalid Phone Number error when they enrolled an SMS factor. (OKTA-923373)

  • When an admin configured the Salesforce.com connector with the Customer Portal user type and then ran an import, no users were fetched. (OKTA-931016)

  • When using an Org2Org integration between a Classic hub org and an OIE spoke org, some users were prompted for MFA in the spoke org even though Trust claims from this identity provider was enabled and they had already authenticated in the hub org. (OKTA-931086)

  • After signing in to Okta on a mobile device (either Android or iOS), opening the menu resulted in the screen flickering. (OKTA-933477)

  • When users performed Org2Org SSO with an existing IdP session, FactorVerifiedByIdp was missing from the System Log entry. (OKTA-935626)

  • When third-party IdP claims sharing was enabled, some claims were missing from the System Log. (OKTA-936530)

  • Some UI elements rendered incorrectly on the Security Methods section of the Settings page on the End-User Dashboard. (OKTA-937390)

  • Some pages didn't load correctly when the Unified look and feel for Okta Admin Console feature was enabled. (OKTA-938750)

  • Updating an LDAP-sourced user profile sometimes resulted in an error. (OKTA-939330)

  • When the Enforce MFA for admin-only Identity Governance apps feature was enabled, the authentication policy settings were hidden from the the Application pages. (OKTA-939580)

  • When third-party claims sharing was enabled, users couldn't sign in using their IdP because of an authentication loop. (OKTA-939862)

  • Search functionality didn't work in the AAGUID list table. (OKTA-940240)

Okta Integration Network

  • Conviva (SCIM) is now available. Learn more.
  • Paylocity (Demo)(SCIM & SAML) is now available. Learn more.
  • SELR.ai (OIDC) is now available. Learn more.
  • Wirespeed (API service) is now available. Learn more.

Preview Features

Domain restrictions on Realms

You can now limit users to a specific domain in Realms, which adds an extra layer of oversight for realm and partner admins and enforces boundaries between user populations. See Manage realms.

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.

Granular configuration for Keep Me Signed In

Admins can now configure the post-authentication prompt for Keep Me Signed In (KMSI) at a granular level in authentication policies. This allows admins to selectively enable post-authentication KMSI on a per-user, per-group, or per-app basis. When enabled, this feature exposes a frequency setting that lets admins control how often the post-authentication prompt is presented to users. See Keep me signed in. The post-authentication prompt text (title, subtitle, accept button, and reject button) is now customizable through the Brands management API. See Configure Keep me signed in (KMSI) and Brands API.

Automatic renewal of Okta Certificate Authorities

Okta Certificate Authorities (CAs) used for management attestation expire every five years. Without proactive renewal, expired CAs lead to disruptions in authentication and hinder compliance requirements. To mitigate this risk, the Okta CA Renewal Service automatically renews CAs 1.5 years before expiration, ensuring uninterrupted authentication and compliance. By managing CA renewals proactively, this service prevents downtime, reduces manual intervention, and guarantees that management attestation remains seamless and uninterrupted. See Okta Certificate Authority Renewal and Activation Guide

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

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

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.

Content security policy enforcement on end-user pages

Content security policy is now enforced for end-user pages on orgs with custom domains on non-customizable pages. Content Security Policy headers provide an additional layer of security that helps to detect attacks such as cross-site scripting and data injection by ensuring browsers know what kind of actions the webpage can execute. We already had a policy enforced in our admin pages from last year and in report-only mode for end-user pages. We plan that future iterations of our Content Security Policy enforcement for end-user pages will become stricter than this first release.

This feature will be gradually made available to all orgs.

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:

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.

Email failure events in the System Log

Admins can now view email delivery failure events in the System Log. This helps admins better monitor the email event activity in their org. See System Log.

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 application's assurance policy. After the assurance requirements are met, the user is signed directly in to the application.

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 application 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 application, 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 application.

Choose additional filters for Office 365 sign-on policy

Filters have been added to enable admins to distinguish between web browsers and Modern Authentication clients when creating an app sign-on policy.

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 applications 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 complete sign-in to applications that run on such devices.