Okta Identity Engine release notes (Production)

Version: 2024.04.0

April 2024

Generally Available

Widget, version 7.17.0

For details about this release, see the Sign-In Widget Release Notes.

For more information about the Widget, see the Okta Sign-In Widget Guide.

Okta MFA Provider for ADFS, version 1.8.0

This release includes vulnerability fixes and a .NET Framework version upgrade.

Content Security Policy for custom domains

The Content Security Policy (CSP) feature lets admins control which URLs may be linked to from customized sign-in and error pages in orgs that use custom domains. Admins add trusted URLs to Okta that link to items such as images and add these links to the code in their sign-in and error pages. This feature enhances security by enabling admins to allow only approved content to appear and prevent the introduction of potentially malicious code to these pages. See Customize the Content Security Policy (CSP) for a custom domain.

SAML Certificate expiration notification feature

This feature notifies admins through task entries in the Admin Console about expired or soon-to-expire certificates for SAML apps. This enhances security and minimizes app downtime caused by expired certificates.

Support case management for admins

Super admins can now assign the View, create, and manage Okta support cases permission and Support Cases resource to a custom admin role. This allows delegated admins to manage the support cases that they’ve opened. See About role permissions.

Okta Usage report enhancements

The Okta Usage report now attempts to download the generated CSV file immediately upon loading, and updates the email template when the report is generated. The CSV file can now contain up to five million rows. These enhancements automate the tasks of downloading and emailing the report, and provide more data to admins.

Direct Authentication

Direct Authentication offers a new set of OAuth 2.0 grants that give app developers greater control over the authentication process. When redirect authentication isn't an option, you can use direct authentication to allow client apps to authenticate users directly, without relying on HTTP redirection through a web browser. This is beneficial when there's a high degree of trust between the user and the app and when browser-based flows aren't feasible, like with mobile apps. See Configure Direct Auth grant types.

Okta Verify user verification with PIN or passcode

The Okta Verify enrollment relies on biometric verification, which presents challenges for users whose devices don’t support biometrics. To address this limitation, Okta Verify now supports user verification with PIN or password in addition to biometrics. This enhancement broadens accessibility, enabling all users to authenticate with Okta Verify and Okta FastPass, regardless of their device capabilities or personal constraints. See Configure Okta Verify options.

Granular API policy authenticator controls

The Authentication Policy API now includes three new constraints object parameters that provide precise control over what specific authenticators and methods are displayed to end users. Previously, some authenticators were mapped to the same authenticator types and methods. The parameters authenticationMethods and excludeAuthenticationMethods now identify (or exclude) the exact authenticator for both knowledge and possession constraints. The required parameter indicates whether the knowledge or possession constraints are required by the assurance. See the Policy API.

Granular controls for authentication policies

You can now disallow or allow individual authentication methods for an authentication policy. This gives admins more granular control over access to apps.

Require possession factor before password during MFA

You can now require users to verify their identity with a possession factor before a password or other knowledge factor during MFA. This helps protect your org against password guessing or spray attacks. See General Security.

New maximum number of connected AWS accounts

Admins can now connect a maximum of 1000 Amazon Web Services accounts to the AWS Account Federation app in Okta. This change helps avoid timeouts when testing API credentials on AWS.

Improved date filter display in reports

The date filter is now standardized and appears inline for the following reports: Telephony usage, Continuous access violation, Entity risk, At-risk user, and MFA events.

Improved Admin Dashboard and Administrators page

The appearance of several UI components (like buttons and dropdown menus) have been improved across the Admin Dashboard and the Administrators page.

Updated documentation links

Documentation links under the Security, Applications, and Customizations menus now redirect to the correct documentation.

End-User Dashboard and unsupported browsers

The End-User Dashboard no longer loads in unsupported browsers, including Internet Explorer 11 or Edge in Internet Explorer mode. This change enhances security by preventing access from browsers that no longer receive updates.

End-User Dashboard branding and accessibility enhancements

The End-User Dashboard now features design changes that provide a consistent brand experience across Okta's app and enhance accessibility for users.

New target added to a System Log event

A new target was added to the user.authentication.auth_via_mfa System Log event. The target shows the type of MFA app that was used to authenticate.

Authentication context System Log event

The new AuthenticationContext System Log event shows who accessed the configuration secrets for ADFS, Windows Credential Provider (RDP), Epic Hyperspace, and Epic Hyperdrive apps.

New DSSO user impersonation System Log event

A System Log event is now logged when a user attempts Desktop Single Sign-On (DSSO) authentication using a profile source that wasn't the highest priority.

Additional CrowdStrike signals

Okta Verify collects additional trust signals from CrowdStrike. You can view these signals in the System Log. When you configure authentication policy rules, you can use the CrowdStrike signals in Expression Language conditions. See EDR signals for custom expressions.

Early Access

Identity Threat Protection with Okta AI

Identity Threat Protection with Okta AI is a powerful risk assessment and response solution that provides post-authentication security to your org. By continuously analyzing risk signals that are native to Okta, risk signals from integrated security partner vendors, and your policy conditions, it safeguards orgs against identity attacks that occur during and outside of a user’s session. When Identity Threat Protection discovers a risk, it can immediately end the user’s sessions, prompt an MFA challenge, or invoke a workflow to restore your org’s security posture. Using intuitive dashboard widgets and reports, you can easily monitor security threats as they happen. See Identity Threat Protection with Okta AI.


  • Users couldn't enroll multiple Smart Cards as security methods from the End User Settings page. (OKTA-581807)

  • When end users enrolled the email authenticator, the Sign-in Widget displayed their email incorrectly. (OKTA-625907)

  • Some Microsoft Windows 365 Enterprise license names weren't displayed correctly on the Edit Assignment page. (OKTA-679276)

  • Admins could delete active network zones. (OKTA-691904)

  • No GovSlack attributes appeared for new app instances. (OKTA-693162)

  • Google Workspace default user schema attributes weren't imported into Okta. (OKTA-697236)

  • On the Configure SAML 2.0 IdP screen, the Account matching with IdP Username section appeared when Factor Only was selected for IdP Usage. (OKTA-698614)

  • When an end user enrolled in Okta Verify from an OIDC app, they received the email notification from noreply@okta.com instead of the custom email domain. (OKTA-701658)

  • When an admin enabled a self-service Early Access feature and an error occurred, a success message appeared. (OKTA-701707)

  • Users received a Bad Request error when they canceled Okta FastPass during authentication. (OKTA-706541)

  • App admins could initiate the refresh app data process for apps to which they didn't have permission. (OKTA-711670)

  • Users were unable to enroll in an authenticator with the inline enrollment prompt when the authentication policy did not contain constraints for the corresponding factor class. (OKTA-715402)

Okta Integration Network

  • Alohi (SAML) is now available. Learn more.
  • Alohi (SCIM) is now available. Learn more.
  • Better Stack (SAML) has a new logo.
  • Candor (OIDC) is now available. Learn more.
  • FAX.PLUS (SAML) has a new logo, description, and display name.
  • Humi (OIDC) is now available. Learn more.
  • Jurnee (SCIM) is now available. Learn more.
  • UMA (OIDC) is now available. Learn more.

Version: 2024.03.0

March 2024

Generally Available

Widget, version 7.16.1

For details about this release, see the Sign-In Widget Release Notes.

For more information about the Widget, see the Okta Sign-In Widget Guide.

Okta LDAP agent, version 5.20.0

This version of the agent includes the following:

  • Fixed an LDAP query used by the agent for retrieving group memberships using range attributes.

  • The Okta LDAP Agent service now automatically starts on boot for Red Hat and CentOS platforms.

  • Fixed an issue where some customers experienced slower than expected queries during LDAP authentication.

  • Security enhancements.

See Okta LDAP Agent version history.

Okta Hyperdrive agent, version 1.4.0

This version includes bug fixes and an upgrade of the .NET Framework to version 4.8. See Okta Hyperdrive agent version history.

Okta Hyperspace agent, version 1.4.0

This version includes bug fixes and an upgrade of the .NET Framework to version 4.8. See Okta Hyperspace Agent Version History.

Okta AD agent, version 3.17.0

This version includes fixes for signing executable and DLL files that come with the Active Directory agent. See Okta Active Directory agent version history.

Enhanced Disaster Recovery

This feature enables commercial customers in the North America region (excluding Compliance cells) to recover faster in the event of a disaster or regional outage. See Overview of enhanced disaster recovery.

Admin sessions bound to Autonomous System Number (ASN)

When an admin signs in to Okta, their session is now associated with the ASN they are logging in from. If the ASN changes during the session, the admin is signed out of Okta, and an event appears in the System Log.

Admin sessions bound to IP address

The Security General Organization Security page has a new IP binding for admin console setting that's enabled by default. This setting associates all of the admin sessions in your org with the device IP address. If the IP address changes during the session, the admin is signed out of Okta, and an event appears in the System Log. This setting can be disabled, but Okta recommends keeping it enabled as a security best practice. See General Security.

Verify Zoom users with Okta

Zoom users can now attest and verify a user’s identity between two independent parties using Okta-signed tokens.

Permission conditions for profile attributes

You can now apply conditions to the View users and their details and Edit users' profile attributes custom admin role permissions. Permission conditions help you limit the scope of a role by including or excluding admins' access to individual profile attributes. This gives you more granular control over your custom admin roles and helps meet your org’s unique security needs. See Permission conditions.

Enhanced security of Okta Verify enrollments

The Higher security methods option on the authenticator configuration page ensures that users enroll in Okta Verify in a phishing-resistant manner. With this option, users can't enroll with QR code, email, or SMS link. See Configure Okta Verify options.

Stay signed in

Today, Keep me signed in allows the user to select whether their multifactor authenticators from previous sessions should be remembered. However, the option to select Keep me signed in was only available on the sign-in screen.

To enable Stay signed in for integrated authentication flows, admins can now configure their sign-in experience such that the option to Stay signed in is provided either before the user signs in to Okta or before and after the user completes multifactor authentication. If a user selects Stay signed in, they won't be challenged for MFA the next time they sign in. In addition, users will now be able to sign out of all active Okta sessions from the Okta End-User Dashboard. See Stay signed in.

Granular permissions to manage directories

This feature enables you to assign permissions to view and manage directories as part of a customized admin role. Admins without universal application administrator permissions can handle directory-specific tasks.

Improved password reset process for Active Directory-sourced users

The password reset process sends password update and verification requests to the same Active Directory agent to avoid replication delay.

Device Context using Limited Access in Okta Identity Engine

You can now pass device context using Limited Access in Okta Identity Engine. See Pass Device Context using Limited Access in Okta Identity Engine

Unknown devices detection using fingerprint

Admins can now configure how unknown devices are treated based on the presence of a device fingerprint.

See Block suspicious sign-in attempts from unknown devices.

New requirement for email customizations

To prevent phishing attacks, Okta now requires orgs to have a custom domain to send customized emails. All customized emails currently sent from the Okta domain are disabled, and orgs that use the Okta domain can send default email templates only. This feature is currently enabled by default for new orgs only.

Enhanced System Log Event

The policy.evaluate_sign_on System Log event now shows the assurance policy factor requirement and a list of the available authentication factors for the sign-on event.

Cornerstone OnDemand now uses OAuth for authentication

Cornerstone OnDemand replaced the previous authentication method with OAuth authentication to improve security for provisioning. Create a new Cornerstone OnDemand app instance and configure it to use Oauth credentials. See Configure provisioning for Cornerstone OnDemand.

Styling change for Brands pages

The CustomizationsBrands section of the Admin Console now uses Odyssey UI components. There's no change to functionality, but some of the styling is different.

AAL values for Login.gov IdP

The Login.gov IdP configuration has been updated to include all allowed AAL values. See Create an Identity Provider in Okta.

New System Log information for password policy changes

System Log entries for password policy changes now display the policy settings before and after the update was made.

Improved System Log map view

The System Log map view now includes a reset button and left and right bounds on the zoom function.

New System Log information for MFA enrollment policy changes

System Log entries for MFA enrollment policy changes now display the policy settings before and after the update was made.

IP binding for Admin Console setting

The SecurityGeneralOrganization Security page has a new IP binding for Admin Console setting. When you enable this setting, all of the admin sessions in your org are associated with the system IP address that they signed-in from. If the IP address changes during the session, the admin is signed out of Okta, and an event appears in the System Log. See General Security.

Additional operator for date filter

The date filter is now standardized across all reports and includes the in range operator.

Early Access

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 User settings.

Enforce Number Challenge for Desktop MFA

You can now enforce number challenge on all push notifications for Desktop MFA, regardless of the authentication policy. See Configure Desktop MFA policies

Realms for Workforce

Realms allows you to unlock greater flexibility in managing and delegating management of your distinct user populations within a single Okta org. See Manage realms.

Trusted App filters

Trusted App filters allow orgs to block applications from invoking Okta FastPass in Windows, and in Google Chrome and Firefox browsers for macOS. See Trusted app filters .

Google Workspace 1-click federation

Admins can set up SSO to Google Workspace using a simplified integration experience that saves time and reduces the risk of errors.


  • Sometimes group membership changes in a downstream app weren't reflected upon source app assignment in Okta. (OKTA-647132)

  • When users clicked the X in the upper-right corner of the Edit User Assignment page, the page wasn't restored to the default User Assignment view. (OKTA-651313)

  • The MFA Usage report sometimes displayed L10N_ERROR instead of the MFA factor. (OKTA-658326)

  • Office 365 user licenses were randomly removed. (OKTA-665130)

  • During Okta Verify enrollment, the Scan the QR code option was incorrectly displayed for the requests coming from a mobile device. (OKTA-671029)

  • Users in certain geolocations couldn’t sign in to Okta, even when the org’s policies didn’t block the location. (OKTA-671528)

  • Importing large group membership data failed for orgs using ranged queries. (OKTA-672521)

  • The Jira On-Premises app authenticator didn't include a relay state parameter. (OKTA-673058)

  • Password age validation incorrectly appeared on the new user registration window. (OKTA-673824)

  • The Display application icon in the Okta Mobile app option was incorrectly available for the Application visibility property in the Application Integration Wizard (AIW). (OKTA-674235)

  • During self-service registration, users didn't receive the verification email when enrolling Okta Verify with Push. (OKTA-677750)

  • On the Tasks page, the user search didn't return any results for deactivated users. (OKTA-677822)

  • AD users created through JIT couldn't reset their password even if it was set to change after they first signed in. (OKTA-679679)

  • Google licenses were missing from the Universal Directory profile. (OKTA-684513)

  • During LDAP authentication, orgs with large customer databases experienced slower-than-expected queries. (OKTA-686417)

  • Some links on the Admin Dashboard to Okta Documentation didn't work. (OKTA-693031)

  • Users were prompted to enter a password twice when signing in. (OKTA-699026)

  • Read-only admins could modify the IP restrictions of other users' tokens. (OKTA-700117)

  • Some text was truncated on the Recent Activity page. (OKTA-700858)

  • The locale attribute from the user profile wasn't correctly populated to the telephony inline hook. (OKTA-700928)

  • Admins couldn't enroll or reset FIDO2 authenticators for staged users. (OKTA-701467)

  • An inline hook secured by an OAuth 2.0 token that had no expiry value returned an HTTP 400 Bad Request error. (OKTA-702184)

  • The Cornerstone REST API rate limit wasn't honored. (OKTA-702729)

Okta Integration Network

  • Acronis Cyber Cloud (SCIM) has a new authorize endpoint, display name, SAML attribute, and icon.
  • Dashworks (OIDC) has a new integration guide. Learn more.
  • Dashworks (SCIM) has a new integration guide. Learn more.
  • Modal (SAML) is now available. Learn more.
  • NexHealth (SAML) has a new description and an additional SAML attribute.
  • Onyxia (SAML) is now available. Learn more.
  • Paved (OIDC) is now available. Learn more.
  • Reftab Discovery (API service) is now available. Learn more.
  • Resonance by spiderSilk (SAML) is now available. Learn more.
  • Semana (SAML) is now available. Learn more.
  • SpotDraft (SAML) is now available. Learn more.
  • Vansec (SCIM) is now available. Learn more.

Weekly Updates

Version: 2024.02.0

February 2024

Generally Available

Widget, version 7.15.1

For details about this release, see the Sign-In Widget Release Notes.

For more information about the Widget, see the Okta Sign-In Widget Guide.

Okta LDAP agent, version 5.19.1

This version of the agent fixes the expiring signature error that prevented agents from auto-updating to the newest LDAP agent version. See Okta LDAP Agent version history.

Okta Active Directory agent, version 3.16.1

This version of the agent fixes an expiring signature error that prevented agents from auto-updating to the newest Active Directory agent version. See Okta Active Directory agent version history.

Okta MFA Credential Provider for Windows, version 1.4.2

This version includes bug fixes and security enhancements. See Okta MFA Credential Provider for Windows Version History.

Assign admin roles to an app

Orgs can now assign admin roles to their custom API Service Integrations. Apps with assigned admin roles are constrained to the permissions and resources that are included in the role assignment. This helps ensure that apps only have access to the resources that are needed to perform their tasks, and improves orgs' overall security. See Work with the admin component.

Seamless ISV experience

Okta now provides a seamless ISV experience to optimize the Okta Integration Network (OIN) submission experience for SAML and OIDC integrations. This new experience enables independent software vendors (ISVs) to build and manually test their integration metadata before submission. This reduces the time needed for the OIN team to review and validate that the integration functions as intended, which shortens the time to publish in the OIN.

This experience also incorporates communication processes in Salesforce, enabling improved collaboration internally within Okta teams and externally with ISVs. See Publish an OIN integration overview and Submit an SSO integration with the OIN Wizard guide.

Email or password no longer required in authenticator enrollment policy

Currently, the authenticator enrollment policy requires either email or password, even when you’ve enabled another authenticator for authentication. Now you can set email or password as optional or disabled in the policy, and instead require stronger authenticators like Okta Verify, Okta FastPass, and FIDO2 (WebAuthn) for authentication. With this change, passwordless users who initially signed in with an email now receive the activation email. See Create an authenticator enrollment policy.

Force authentication

Orgs now support force authentication for WS-Fed SSO requests. Users must re-authenticate WS-Fed authentication requests that include Wfresh=0.

DPoP support for Okta management API

You can now use OAuth 2.0 Demonstrating Proof-of-Possession (DPoP) access tokens to access Okta management APIs. See Configure OAuth 2.0 Demonstrating Proof-of-Possession.

MFA Activity report

The new MFA Activity report provides insight into the MFA trends in your org. It helps you understand which authentication methods were used to access Okta and Okta-protected apps. The report also provides information about the characteristics of authenticators, helping you measure how phishing resistant your org is. See MFA Activity report.

LDAP real-time synchronization

With real-time synchronization, user profiles, groups, and group memberships can now be updated when LDAP-sourced users sign in to Okta, or when they refresh their People page. Admins no longer need to perform full or incremental imports of user attributes, and user profiles, groups, and group memberships are always up to date. Real-time synchronization also reduces the burden on system resources because user attributes are imported and updated individually and not in large groups. See Manage your LDAP integration. This feature is being re-released.

Reports field update

The operator field of the Reports Edit Filters dialog shows the selected item in the dropdown menu.

Dynamic user schema discovery now available

Dynamic user schema discovery is now available for SCIM app integrations that support user entitlements and Identity Governance.

OIN connector support for Entitlement Management

The PagerDuty and Zendesk connectors have been updated to support Entitlement Management. See Provisioning-enabled apps.

App integration tile now available for Okta Workflows

Users who are assigned to the Okta Workflows app integration now have a dedicated tile on their End-User Dashboard to launch the Okta Workflows Console. See Workflows Console.

API setting now an Admin Console option

The Use Persistent Name ID (Higher Security) checkbox allows more secure account linking. This setting allows Okta to determine the associated user account by matching the Name ID with the External ID. When no match is found, Okta uses the IdP username value for account matching.

New action items for self-service upgrades

The OIE Upgrade Hub displays actions items if orgs have non-writable attributes in their self-service registration policy or a factor enrollment policy set to Do Not Enroll. See Self-service upgrade action items.

New System Log event

There's a new system.mfa.preregister.initiate System Log event. The event appears for event hooks and represents MFA preregistration flow initiation. Currently, it's only available for pre-registered YubiKey enrollments.

UI enhancements to Authenticator Enrollment tab

The Authenticator Enrollment tab has been updated to include information about how the enrollment works.

Super admin role now required to update direct authentication grants

Super admin permissions are now required to enable or change direct authentication grants for clients.

Early Access Features

Protected actions in the Admin Console

The protected actions feature provides an additional layer of security to your org. It prompts admins for authentication when they perform critical tasks in the Admin Console and helps ensure that only authorized admins can perform these tasks. Super admins can configure the authentication interval for their org. SeeProtected actions in the Admin Console.

Detect and block requests from anonymizing proxies

Orgs can now detect and block web requests that come from anonymizers. This helps improve the overall security of your org.

Network zone allowlists for SSWS API tokens

Admins can now specify a network zone allowlist for each static (SSWS) API token. These allowlists define the IP addresses or network ranges from where Okta API requests using SSWS API tokens can be made. This restricts attackers and malware from stealing SSWS tokens and replaying them outside of the specified IP range to gain unauthorized access.

Custom languages for email templates

Admins can now customize Okta-generated emails in any BCP47-formatted language. Previously, customizations were limited to 27 Okta-supported languages. This feature allows admins to configure additional locales using Okta’s Brands API. When a new locale is configured, it's available as a new language selection within the Email Templates Editor. See Customized Email Notifications.

Dynamic OS version compliance for device assurance

You can configure OS version compliance by using device assurance. However, you have to manually update the policies every time a new OS version or patch is released. With Dynamic OS version compliance, Okta updates device assurance policies with the latest OS versions and patches, eliminating the need for manual updates. With this feature you can ensure OS version compliance in your org without tracking OS releases. See Add a device assurance policy.

Prevent new single-factor access to the Admin Console

This feature prevents admins from configuring any new single-factor access to the Admin Console. There's no impact to any existing rules that allow single-factor access.


  • OKTA-649640

    Password rules weren't correctly translated in French.

  • OKTA-664368

    Assistive technologies couldn't read the Which option do you want to try? label on the Sign-In Widget.

  • OKTA-668324

    Email notifications that were sent when a password was reset by Okta Support didn't include Support information.

  • OKTA-668665

    The re-authentication frequency labels on the Authentication Policies page weren't clear.

  • OKTA-669735

    When an admin was removed from a group that was imported from an app, their user profile still displayed the admin assignments that were granted through the group’s membership.

  • OKTA-678416

    Some special characters and symbols were displayed incorrectly in the Sign-In Widget (3rd generation).

  • OKTA-678489

    Voice call to some destinations didn't work when a 7 digit phone number with a 3 digit extension was entered.

  • OKTA-680179

    The Sign-In Widget displayed the wrong error message to users whose activation token was invalid when they attempted to register with Okta.

  • OKTA-680483

    The self-service registration form accepted invalid input for the first and last name fields.

  • OKTA-680795

    Admins couldn't access the Access Testing Tool in some preview orgs.

  • OKTA-681083

    Voice calls for MFA challenges were not completely translated in Vietnamese when the user's locale was set to Vietnam.

  • OKTA-682202

    If an admin’s role had a conditioned permission, they couldn’t assign apps to users.

  • OKTA-689632

    The IssuerDN PIV IDP matching attribute was referencing the wrong value in the certificate.

  • OKTA-690143

    Unicode characters deemed illegal for HTTP headers were being accepted.

  • OKTA-691492

    Continuous Access terminated sessions even though users were able to authenticate.

Okta Integration Network

App updates

  • The Elba SSO app integration has new redirect URIs.
  • The Ermetic app integration has been rebranded as Tenable Cloud Security.
  • The Ermetic JIT app integration has been rebranded as Tenable Cloud Security JIT.

New Okta Verified app integrations

Weekly Updates