Okta Identity Engine release notes (Preview)
Version: 2026.01.0
January 2026
Generally Available
Device assurance OS version update
The following OS versions are now supported in Device Assurance policies:
- iOS 18.7.3, 26.2
- macOS 14.8.3, 15.7.3, 26.2
UI improvements to the User profile risk tab
Columns of the table on the User profile risk tab have been reordered for better visibility, and context change events have been replaced with policy violation events.
Updated help doc links on the Recent activity page
The Recent Activity page in the End-User Settings 2.0 has updated help doc links.
Seamless Admin Console navigation
When navigating to the Admin Console from the App Switcher, Admin button, or a direct URL, your active session is now reused. This reduces redundant MFA prompts and improves the navigation experience.
Updates to first-party App Switcher
Previously, you had to be an Okta admin to use the Okta first-party App Switcher. Now, non-admin users can use the App Switcher to seamlessly navigate between Okta first-party apps like ISPM, Workflows, or the Partner Admin Portal.
Login hint evaluation for non-OIDC apps
The Security > General page of the Admin Console has been updated with a new Login hint evaluation for Non-OIDC Applications setting. This setting controls whether the Sign-In Widget evaluates login hints when provided by an app. See General Security.
New IP service categories supported
PAWXY_VPN, QUARK_VPN, GIAMPING_VPN, and ENCRYPT_SECURE_SERVERS_VPN are now supported as IP service categories in enhanced dynamic zones. See Supported IP service categories.
Custom FIDO2 AAGUID
Customers can add non-FIDO Metadata Service (MDS) security keys and other authenticators and have more granular control over them. This extends FIDO2 (WebAuthn) authenticator support to a wider range of security keys and other authenticators, which gives customers greater flexibility and control over the security in their environment.
Stay signed in text clarification
The App sign-in policy configuration page has updated text clarifying that the option to stay signed in persists across all apps. See Add an app sign-in policy rule.
New look and feel in the Access Requests email notifications
The Access Requests email notifications have a new look and feel, including updates to the text alignment, colors used, location of the Okta logo, and the addition of a gray background.
WS-Trust 1.3 support for Windows Transport
Windows Transport now supports WS-Trust 1.3 protocol. This enables Silent Activation for newer Microsoft Office clients, eliminating the need for users to manually enter their credentials.
Block words from being used in passwords
You can now use Okta Expression Language to block words from being used in passwords. This feature enhances security by allowing you to customize your password strength requirements.
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 Okta End-User Settings.
Early Access
Okta for AI agents
You can now register, secure, and govern AI agent identities directly within Okta. Designed to secure human-to-agent-to-app connections, Okta for AI agents helps you enforce least privilege access, eliminate standing privileges, and track every agent action using the System Log. It also enables you to allow AI agents to operate as an accountable part of your digital workforce while maintaining a seamless user experience. See Manage AI agents.
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 protection.
Breached credentials protection is now available for Federal customers.
Native to Web SSO
Native to Web SSO creates a seamless, unified authentication experience when a user transitions from an OIDC app (like a native or web app) to a web app (either OIDC or SAML). This feature uses standard, web-based federation protocols like SAML and OpenID Connect that help bridge the gap between two different application environments, using a single-use, one-way interclient trust SSO token. This eliminates repeating already provided sign-on assurances, and simplifies development by reducing authentication complexity. See Configure Native to Web SSO.
Policy Insights Dashboard
The Policy Insights Dashboard gives you a clear view of a policy's impact on your org. You can monitor trends in successful sign-ins, access denials, and authenticator enrollments, and also gain insight into the time users spend signing in and the prevalence of phishing-resistant authentications. The dashboard also tracks the frequency of rule matches and the percentage of successful sign-in attempts. See Use the Policy Insights Dashboard.
Bring your own telephony credentials
You can now connect your own telephony provider using a new simplified setup that doesn't require you to use a telephony inline hook. You can handle usage billing directly with your provider. Okta currently supports Twilio and Telesign. See Configure telephony providers through the Admin Console.
Release controls for Okta Verify on Windows
With the new release controls feature, admins can configure whether to allow, pause, or restrict automatic updates to Okta Verify on Windows. This provides greater flexibility for meeting enterprise change management requirements and managing version rollouts across Windows endpoints. See Configure Okta Verify release controls.
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 based on Okta Verify user verification settings.
Fixes
-
In orgs with global session policies that required a password, users couldn't authenticate with their password and a security question, even though the org's app sign-in policy allowed that combination of factors. (OKTA-1020729)
-
When users entered an invalid OTP in the Sign-in Widget too many times and clicked Back to sign in, they were redirected to the wrong page. (OKTA-1038368)
-
When an authenticator enrollment policy required Okta Verify, some users weren't prompted to enroll it in their desktop browser. (OKTA-1047509)
-
The following attributes weren't properly being gated as reserved attributes:
orgid,activationstatus,apistatus,logintype,initialreconcilecomplete,activationdate,statuschangeddate,apilastupdate,passwordexpirationguess,passwordexpirationcursor,numunlocks,changedstatus. See Review reserved attributes. (OKTA-1049339) -
In Preview orgs, admins couldn't see error messages because they were blocked by a banner. (OKTA-1053703)
-
Sometimes, if users attempted to sign in through JIT during a replication lag, a 500 error occurred. (OKTA-1055324)
-
In orgs with claims sharing enabled, admins couldn't disable the FastPass authentication method when they tried to change their app sign-in policies. (OKTA-1076241)
-
In orgs with End-User Settings 2.0 enabled, brand logos didn't display on the My Settings page. (OKTA-1082109)
-
In orgs with End-User Settings 2.0 enabled, the branding primary color didn't display on the navigation menu of the My Settings page. (OKTA-1082119)
-
In the Access Testing Tool, the column that explained which conditions matched had a title and text that were sometimes unclear for admins. (OKTA-949568)
-
The User.Session.Start event wasn't consistently recorded in the System Log when users signed in with TouchID. (OKTA-996730)
-
Admins encountered an error when they attempted to update the username for an app user. (OKTA-1047716)
-
When an admin provisioned an LDAP user with a LDAP Generalized Time attribute from Okta to LDAP, the time value was formatted incorrectly. (OKTA-1056428)
-
Some authentication attempts from computers were incorrectly identified as iOS devices, causing access denials for policies that used a
client.device eq "Computer"expression. (OKTA-1060121) -
JIT users were redirected to a SP before app assignments were completed, causing an access denied error. (OKTA-1061698)
-
In orgs with an Okta Org2Org integration, the Sign-In Widget displayed the wrong user email address if the address was changed during authentication. (OKTA-1063332)
-
Microsoft Office 365 user provisioning failed intermittently with a 429 error. This occurred when the system attempted to provision users who already existed in the Microsoft Entra recycle bin with the same onPremisesImmutableId. (OKTA-1068843)
-
Some users on unmanaged devices received an internal server error in the Sign-In Widget. This occurred when the users authenticated to orgs that had management attestation enabled but lacked a custom message for the managed device remediation. (OKTA-1079371)
-
In orgs that disabled certificate-based authentication for Office 365, Windows Autopilot was incorrectly removed from the app sign-in policy. (OKTA-1081329)
-
Active Directory imports failed with an "Incorrect result size" error when DirSync was enabled. This occurred because creating a new group in Active Directory generated duplicate entries during the import process. (OKTA-1082847)
-
When users clicked the Microsoft Teams tile on the Okta End-User Dashboard, they were directed to an error page stating that "Classic Teams is no longer available." This occurred because the destination URL was outdated following a change by Microsoft. (OKTA-1084267)
Okta Integration Network
-
Dokio (SCIM) is now available. Learn more.
-
Kuranosuke (SAML) is now available. Learn more.
-
LINE WORKS (SCIM) is now available. Learn more.
-
SciLeads Portal (OIDC) is now available. Learn more.
-
SciLeads Portal (SCIM) is now available. Learn more.
-
ShareCal (SCIM) is now available. Learn more.
-
ShareCal (SAML) was updated with a new logo.
-
Humana Military (SWA) was updated.
-
Xint (OIDC) added new IDP flow.
-
cmBuilder(OIDC) has a new Redirect URI and a new Post Logout Redirect URI Learn more.
-
Xurrent IMR (Formerly Zenduty) (SAML) has a new name and new icon.
Preview Features
UI improvements to the User profile risk tab
Columns of the table on the User profile risk tab have been reordered for better visibility, and context change events have been replaced with policy violation events.
LDAP Bidirectional Group Management
Bidirectional Group Management for Lightweight Directory Access Protocol (LDAP) allows you to manage LDAP groups from within Okta. You can add or remove users from groups based on their identity and access requirements. This ensures that changes made to user access in Okta are reflected in LDAP.
Okta can only manage group memberships for users and groups imported into Okta using the LDAP or Active Directory (AD) integration. It isn't possible to manage users and groups that weren't imported through LDAP or AD integration or are outside the organizational unit's scope for the integration using this feature.
More granular maximum clock skew options for LDAP incremental imports
More granular maximum clock skew intervals for LDAP incremental imports have been added to allow for better tuning and improved performance. You can now configure the clock skew to 1, 2, 5, or 10 minutes. This granularity helps you improve import speed by using a clock skew value closer to the actual maximum clock drive of your LDAP server. It also prevents missed updates when the server's clock temporarily moves backward, which ensures data accuracy.
Custom FIDO2 AAGUID
Customers can add non-FIDO Metadata Service (MDS) security keys and other authenticators and have more granular control over them. This extends FIDO2 (WebAuthn) authenticator support to a wider range of security keys and other authenticators, which gives customers greater flexibility and control over the security in their environment.
Associated domains
Associated domains let you build a trust relationship among your app, the referring domain, the user's credentials that are associated with that domain, and your brand in Okta. This feature makes it easier to adopt phishing-resistant authenticators, like passkeys in the FIDO2 (WebAuthn) authenticator. See Configure associated domains.
Maximum consecutive characters setting for passwords
You can now set a maximum number of consecutive repeating characters in passwords. This feature enhances security by allowing you to customize your password strength requirements.
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.
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 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.
