On this page
Okta Identity Engine API release notes (2026)
Subscribe to RSS
March
Monthly release 2026.03.0
| Change | Expected in Preview Orgs |
|---|---|
| Self-Service for Enhanced Disaster Recovery is self-service EA in Preview | March 4, 2026 |
| Submit API service integrations | March 4, 2026 |
| Admin Console Home page | March 4, 2026 |
| New Directories Integration endpoints to view extended Active Directory group attributes is GA in Preview | March 4, 2026 |
| Grace period for device assurance is GA in Production is GA in Production | October 9, 2024 |
| Dynamic OS version compliance for device assurance is GA in Production | February 7, 2024 |
| Enable custom admin permissions for inline and event hooks is GA in Preview | December 10, 2025 |
| Developer documentation updates in 2026.03.0 | March 4, 2026 |
| Bug fixed in 2026.03.0 | March 4, 2026 |
Self-Service for Enhanced Disaster Recovery is self-service EA in Preview
When unexpected infrastructure-related outages occur, orgs need an immediate and reliable way to maintain business continuity. Okta's Standard Disaster Recovery, implemented by Okta's operations teams, provides failover and failback with a recovery time objective of one hour.
Okta's Enhanced Disaster Recovery (Enhanced DR) gives admins the option to manage their org's recovery. This feature empowers admins by providing direct, self-service tools and APIs to manage, test, and automate the failover and restoration processes for their impacted orgs.
With Enhanced DR, admins gain active control to initiate a failover and restore for impacted orgs directly from the Okta Disaster Recovery Admin portal or through APIs. Additionally, teams can validate their system's resilience by safely testing these failover and restoration capabilities at their convenience. Finally, Enhanced DR enables orgs to automate failover processes by using real-time monitoring to invoke failover APIs, significantly minimizing downtime during an actual event. See Manage org recovery with Okta Enhanced Disaster Recovery.
Submit API service integrations
Independent Software Vendors (ISVs) can now use the OIN Wizard to submit API service integrations to the Okta Integration Network (OIN). Previously, ISVs provided metadata in the OIN Manager. With this update, ISVs can create and configure API service apps directly within the OIN Wizard The OIN Wizard currently supports only client secret authentication for API service integrations. ISVs can also generate credentials and perform end-to-end testing independently. These improvements streamline the app submission process and ensure a faster, more secure review. See Submit an integration with the OIN Wizard.
Admin Console Home page
The new Admin Console Home page for IFT orgs provides a faster way to start and manage your app submissions. Instead of navigating through the previous Applications > Your OIN Integrations path, you can now initiate submissions directly from the Home page. This guided experience helps you select integration types, understand requirements through a new Quick Start guide, and track your submission in real time from build to publication. It also includes a Coming Soon section to preview and register for upcoming integrations, making the entire process more centralized and efficient.
New Directories Integration endpoints to view extended Active Directory group attributes is GA in Preview
New API endpoints have been added to the Directories Integration (POST /api/v1/directories/{appInstanceId}/group/{groupId}/query and GET /api/v1/directories/{appInstanceId}/group/{groupId}/query/{resultId}), which allows for the real-time retrieval of any standard or custom attribute from Active Directory (AD) groups. You can now programmatically access attributes, like cost centers and department codes, without waiting for a full directory sync. This feature allows you to accelerate automation by using live AD group metadata, while simultaneously eliminating manual data management by creating a single, reliable bridge between your on-premises directory details and your cloud ecosystem. See Directories Integrations API (opens new window).
Grace period for device assurance is GA in Production
Occasionally, users’ devices might fall out of compliance with security policies due to temporary conditions such as missed software updates or unapproved network connections. Without a grace period, they would be immediately blocked from accessing critical resources, which disrupts productivity and causes frustration. The grace period for device assurance feature allows you to define a temporary window during which non-compliant devices can still access resources. This gives users time to remediate issues without being locked out, balancing productivity with security standards.
See Device Assurance Policies API (opens new window) and the Add a device assurance policy guide (opens new window).
Dynamic OS version compliance for device assurance is GA in Production
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 Dynamic OS version compliance (opens new window) and Device Assurance Policies API (opens new window).
Enable custom admin permissions for inline and event hooks is GA in preview
The inline hook and event hook framework now supports read and write permissions for custom admin roles. This enhancement gives fine-grained access to manage inline and event hooks that previously required the super admin role. See Hooks admin roles.
Developer documentation updates in 2026.03.0
Okta's API reference pages (opens new window) are undergoing a migration, which started on February 24. While the look and feel may vary across pages during this time, all technical documentation remains accurate and up to date.
You can no longer submit API service integrations through the OIN Manager, so the instructions have been removed from the OIN Manager guide. To submit an API service integration, use the OIN Wizard.
The new Plan your self-service registration doc explains the self-service registration (SSR) flow, how it works, its default state, and three different ways to customize and configure it.
A new guide is available for Okta Enhanced Disaster Recovery, a feature that gives admins direct control over business continuity. Learn how to:
- Initiate failover and restoration (failback) using the self-service portal or APIs.
- Validate system resilience by safely testing recovery capabilities.
- Automate failover processes to minimize downtime during an outage.
See Manage org recovery with Okta Enhanced Disaster Recovery.
The new Enable and configure a sign-up form guide explains how to configure a Self-Service Registration flow to securely automate how you onboard new users. You learn how to build policies that go beyond a simple sign-up form by defining required user information, automating group assignments, and enforcing security measures like email verification and authenticator enrollment.
The new Add a sign-up form to your web app journey helps you implement a sign-up form for your web app, reducing onboarding friction and accelerating user acquisition.
The new Sign users up with an Okta-hosted sign-up form guide illustrates how to implement a Self-Service Registration flow on page using the Okta-hosted Sign-In Widget. It also covers how to customize an out-of-the-box experience for your app using the Okta Auth JavaScript SDK.
The new Sign users up with a self-hosted sign-up form guide illustrates how to implement a self-hosted sign-up experience using the Okta Auth JavaScript SDK and the Okta embedded Sign-In Widget.
Bug fixed in 2026.03.0
Bot detection events were logged for standard Admin/Management API calls when the Sign-In Widget wasn’t involved. (OKTA-1113990)
February
Weekly release 2026.02.3
| Change | Expected in Preview Orgs |
|---|---|
| Bug fixed in 2026.02.3 | February 25, 2026 |
Bug fixed in 2026.02.3
An incorrect error occurred when a user made a request to the /primary-authenticate endpoint with a challenge_hint value that was a valid OAuth 2.0 grant type, but not a valid value for the /primary-authenticate endpoint. (OKTA-1116277)
Weekly release 2026.02.2
| Change | Expected in Preview Orgs |
|---|---|
| Bug fixed in 2026.02.2 | February 19, 2026 |
Bug fixed in 2026.02.2
In orgs with Device claims support for Okta-to-Okta Claims Sharing enabled, claims weren't sent in the SAML assertion if device signals weren't collected in the IdP org. (OKTA-1112627)
Weekly release 2026.02.1
| Change | Expected in Preview Orgs |
|---|---|
| Bug fixed in 2026.02.1 | February 11, 2026 |
Bug fixed in 2026.02.1
SMS and Call factor rate limits were sometimes incorrectly reported by the direct authentication APIs. (OKTA-1107880)
Monthly release 2026.02.0
| Change | Expected in Preview Orgs |
|---|---|
| Linux as a platform condition is GA in Preview | February 4, 2026 |
| Skip counts for authenticator enrollment grace periods is self-service EA in Preview | February 4, 2026 |
| Dynamic OS version compliance for device assurance is GA in Preview | February 4, 2024 |
| Grace period for device assurance is GA in Preview | October 9, 2024 |
| Lightweight Directory Access Protocol Bidirectional Group Management is GA in Production | December 5, 2025 |
| Detection settings in session protection is GA in Preview | February 4, 2026 |
| Passkeys Rebrand is self-service EA in Preview | February 4, 2026 |
| Custom FIDO2 AAGUID is GA in Production | July 16, 2025 |
| OAuth 2.0 support for custom email providers is self-service EA in Preview | February 4, 2026 |
| Okta as a fallback IdP is self-service EA in Preview | January 28, 2026 |
| Developer documentation updates in 2026.02.0 | February 4, 2026 |
| Bugs fixed in 2026.02.0 |
Linux as a platform condition is GA in Preview
Okta now supports LINUX as a device platform condition in the following policy types and policy rules:
- App sign-in policies (
ACCESS_POLICYrules) - Okta account management policy rules (Rules for the Okta account management
ACCESS_POLICY) - Identity provider routing rules (
IDP_DISCOVERYrules)
See the Policies API (opens new window).
Skip counts for authenticator enrollment grace periods is EA
This feature allows admins to define a number of skips that end users can defer enrollment into an authenticator, as well as customizations to the prompt when end users see the grace period. See Grace periods and type (opens new window).
Dynamic OS version compliance for device assurance is GA in Preview
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 Dynamic OS version compliance (opens new window) and Device Assurance Policies API (opens new window).
Grace period for device assurance is GA in Preview
Occasionally, users’ devices might fall out of compliance with security policies due to temporary conditions such as missed software updates or unapproved network connections. Without a grace period, they would be immediately blocked from accessing critical resources, which disrupts productivity and causes frustration. The grace period for device assurance feature allows you to define a temporary window during which non-compliant devices can still access resources. This gives users time to remediate issues without being locked out, balancing productivity with security standards.
See Device Assurance Policies API (opens new window) and the Add a device assurance policy guide (opens new window).
Lightweight directory access protocol bidirectional group management is GA in Production
The Bidirectional Group Management API (opens new window) has been expanded to allow you to manage Lightweight Directory Access Protocol (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.
Detection settings in session protection is GA in Preview
Tailor ITP to your org’s security priorities to gain control and balance security with a seamless user experience. With new detection settings, you can define which session context changes trigger policy re-evaluations, helping you focus only on what truly matters. See Session protection (opens new window).
Passkeys rebrand is self-service EA in Preview
The FIDO2 (WebAuthn) authenticator is being rebranded to Passkeys (FIDO2 WebAuthn). The FIDO2 (WebAuthn) authenticator is being rebranded to Passkeys (FIDO2 WebAuthn) and Okta is introducing enhanced administrative controls and a streamlined user experience. This update centralizes passkey management through a consolidated settings page, allows for customized authenticator naming, and introduces a dedicated Sign in with a passkey button within the Sign-In Widget. These enhancements simplify the authentication journey and provide users with a more intuitive sign-in process with the Sign in with a passkey button.
For more information about the new settings and updates, see Configure the FIDO2 (WebAuthn) authenticator (opens new window) and settings (opens new window).
Custom FIDO2 AAGUID is GA in Production
You can now use the Authenticators API (opens new window) to create, view, and update custom Authenticator Attestation Global Unique Identifiers (AAGUIDs).
Admins 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 admins greater flexibility and control over the security in their environment.
OAuth 2.0 support for custom email providers is self-service EA in Preview
You can now configure custom email providers with OAuth 2.0 authentication. You can choose between two OAuth 2.0 client configurations to fetch access tokens and use those access tokens to authenticate with your email provider’s SMTP server. See Custom email providers with OAuth 2.0 to understand the new OAuth 2.0 methods.
- See Use your own email provider (opens new window) to configure them in the Admin Console.
- See the Email Providers API (opens new window) to configure them with APIs.
Okta as a fallback IdP is self-service EA in Preview
This feature redirects users to Okta to authenticate if the primary identity provider can't establish their identity. This can happen because of explicit rejections, like invalid credentials and MFA failures, or if an existing user session can't be silently verified, such as during a prompt=none OIDC request or IsPassive=true SAML request. See the Policies API (opens new window).
Developer documentation updates in 2026.02.0
- All references to deprecated API Postman collections are now removed from Home | Okta Developer (opens new window) and replaced with references to the Okta Public API Collections (opens new window) workspace.
- The new Add a sign-in form to your mobile app (opens new window) journey helps you build a secure and complete sign-in experience for your mobile app, giving your users seamless access while protecting their data.
- The new Universal Directory concept provides a comprehensive overview of Okta’s Universal Directory (UD). UD is the centralized data layer that serves as the foundation for the entire Okta platform. This new doc replaces the previous User Profiles concept and goes into more depth on its components and advantages.
- The Okta developer portal search results now include the API references.
- The new Set up AI agent token exchange guide explains how to configure token exchange for AI agents. This feature enables you to securely request and use credentials such as Identity Assertion JWTs (ID-JAGs), secrets, or service accounts to access resources on behalf of authenticated users.
- The /token (opens new window) endpoint now supports token exchange flows for AI agents through the standard OAuth 2.0 Token Exchange grant type.
- The Okta Model Context Protocol (MCP) server is a secure protocol abstraction layer that enables AI agents/Large Language Models (LLMs) to interact with an Okta org. MCP clients can now communicate with the Okta scoped management APIs in natural language. This simplifies building context-aware AI workflows while ensuring strict access control and least-privilege security. To learn more and start your implementation, see the Okta MCP server concept and guide. Also, MCP now has its own dedicated Release Notes section. In the future, refer to this page for all MCP server announcements.
Bugs fixed in 2026.02.0
- When users requested metadata for a non-existent identity provider, the system attempted to trigger an undefined error code. This caused a secondary exception in the Splunk logs. (OKTA-504955)
- When no-cache, no-store headers from
/oauth2/<authorizationServerId>/v1/keyswere returned, it caused an unnecessarily high number of requests to/oauth2/<authorizationServerId>/v1/keys. (OKTA-1099636)
January
Weekly release 2026.01.2
| Change | Expected in Preview Orgs |
|---|---|
| Bugs fixed in 2026.01.2 | January 28, 2026 |
Bugs fixed in 2026.01.2
POST requests to the
/device-assurancesendpoint and PUT requests to the/device-assurances/{deviceAssuranceId}endpoint forANDROIDorIOSplatforms permitted the inclusion of the Windows-specificthirdPartySignalProviders.dtcobject. (OKTA-1045564)Upon activation (
POST /users/{id}/lifecycle/activate?sendEmail=true), some users were enrolled in duplicate email authenticators for the same address. (OKTA-1046873)When you call the List all Groups API (
/api/v1/groups(opens new window)) with theexpand=statsquery parameter, the response returned inaccurate data for the_embedded.stats.hasAdminPrivilegesfield for groups with assigned custom roles. (OKTA-1094903)The link to the API reference for Native to Web SSO on the Features page was broken. (OKTA-1094965)
Weekly release 2026.01.1
| Change | Expected in Preview Orgs |
|---|---|
| Bug fixed in 2026.01.1 | January 14, 2026 |
Bug fixed in 2026.01.1
When an admin sent a GET request to the /idp/myaccount/password/complexity-requirements endpoint, the response body contained HTML-escaped characters. (OKTA-1080153)
Monthly release 2026.01.0
| Change | Expected in Preview Orgs |
|---|---|
| Native to Web SSO is self-service EA in Preview | January 7, 2026 |
| Bring your own telephony credentials is self-service EA in Preview | January 7, 2026 |
| Client update policy is EA in Preview | January 7, 2026 |
| Encryption of ID tokens and access tokens is GA in Production | August 7, 2025 |
| Unified claims generation for custom apps is GA in Production | July 30, 2025 |
| Custom FIDO2 AAGUID is GA in Preview | July 16, 2025 |
| Improvements to the global session policy MFA requirements is GA in Production | December 10, 2025 |
| Additional Anything-as-a-Source API endpoints is GA in Production | December 10, 2025 |
| Anything-as-a-Source for groups and group memberships API is GA in Production | December 10, 2025 |
| Okta account management policy protection for password expiry flows is GA in Production | July 2, 2025 |
| New password complexity property is GA in Preview | June 4, 2025 |
| Developer documentation updates in 2026.01.0 | January 7, 2026 |
| Bugs fixed in 2026.01.0 | January 7, 2026 |
Native to Web SSO is self-service EA in Preview
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.
Bring your own telephony credentials is self-service EA in Preview
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.
To configure your own telephony credentials, you can use the Custom Telephony Provider API (opens new window) or you can use the Admin Console (opens new window).
Client update policy is EA in Preview
The Policies API now supports the CLIENT_POLICY type, enabling you to enforce or defer app updates across different device platforms. This lets you programmatically align app versions with internal change management processes. See the Policies API (opens new window) and Release controls policy (opens new window).
Encryption of ID tokens and access tokens is GA in Production
You can now encrypt OIDC ID tokens for Okta-protected custom app integrations using JSON Web Encryption. You can also now encrypt access tokens minted by a custom authorization server. See Key management.
Unified claims generation for custom apps is GA in Production
Unified claims generation is a new streamlined interface for managing claims (OIDC) and attribute statements (SAML) for Okta-protected custom app integrations. In addition to group and user profile claims, the following new claim types are available: entitlements (required OIG), device.profile, session.id, and session.amr. See Okta Expression Language in Identity Engine.
Custom FIDO2 AAGUID is GA in Preview
You can now use the Authenticators API (opens new window) to create, view, and update custom Authenticator Attestation Global Unique Identifiers (AAGUIDs).
Admins 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 admins greater flexibility and control over the security in their environment.
Improvements to the global session policy MFA requirements is GA in Production
The Policy API now correctly enforces MFA requirements for every sign-in attempt when New Device is included as a behavior and MFA is required in a global session policy. See the Policy API (opens new window).
Additional Anything-as-a-Source API endpoints is GA in Production
Anything-as-a-Source (XaaS) capabilities allow customers to use a custom identity source with Okta. With XaaS, customers can source entities such as users into Okta Universal Directory by connecting a custom HR app or a custom database. This release offers Anything-as-a-Source APIs for both individual operations and bulk operations on groups, group memberships, and users. Okta now enables creating and updating users, creating and updating groups, and managing group memberships into Okta Universal Directory from any identity source using the Identity Source APIs. See Identity Sources (opens new window).
Anything-as-a-Source for groups and group memberships API is GA in Production
Anything-as-a-Source (XaaS) capabilities allow customers to use a custom identity source with Okta. With XaaS, customers can source entities such as users into Okta Universal Directory by connecting a custom HR app or a custom database. This release offers XaaS capabilities with groups and group memberships, allowing customers to start sourcing groups with XaaS. Okta now enables creating and updating users, creating and updating groups, and managing group memberships into Okta Universal Directory from any identity source using the Identity Source APIs. See Identity Sources (opens new window).
Okta account management policy protection for password expiry flows is GA in Production
This feature improves the security posture of customer orgs by protecting the password expiry flow with the Okta account management policy. Password expiry flows now require the assurance defined in an org's Okta account management policy.
You can now use the metadata component in an Expression Language condition for an Okta account management policy. You can only use metadata in an expression that’s related to password expiry. See Enable password expiry (opens new window)
New password complexity property is GA in Preview
You can now use the oelStatement property to block words from being used in passwords. This feature enhances security by allowing you to customize your password strength requirements. See the Policy API (opens new window).
Developer documentation updates in 2026.01.0
- The new Express Configuration customer configuration guide template is available to help Express Configuration partners create accurate configuration guides for their customers. This resource provides standardized instructions for setting up apps that use Express Configuration, covering functionalities such as SSO, Universal Logout, and SCIM provisioning.
- The rate limits documentation has been revised and updated on the References tab. New updates include detailed explanations on rate limit buckets, as well as more information on how to increase your rate limits. See the Rate Limits overview.
- The Okta API release notes now provide an RSS feed for each API release note category: Classic Engine, Identity Engine, Identity Governance, Privileged Access, Access Gateway, and Aerial. Click the RSS icon to subscribe.
Bugs fixed in 2026.01.0
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 (opens new window). (OKTA-1049339)An error sometimes occurred when an admin attempted to update the username for an app user. (OKTA-1047716)
