Okta Identity Governance release notes

Security access reviews is generally available in Production environments

Security access reviews are a new, security-focused type of user access review that can be automatically triggered by events. These reviews provide a unified view of a user's access, and contextual information about their access history including an AI-generated access summary, allowing you to investigate and take immediate remediation actions like revoking access. You also have the option to enable or disable the AI summary from the Governance AI tab of the Settings page. See Security access reviews.

Access Requests for AD Groups is generally available in Production environments

You can now manage access requests for Active Directory (AD)-sourced groups directly from Okta. This allows you to use AD groups when configuring access request conditions and enables users to request membership directly from their Okta dashboard. When a request is approved, the requester's access is granted in AD. It's also removed when it expires (if it's time-bound). Additionally, if you select a resource owner as a task assignee in an approval sequence, the AD-sourced group's manager is assigned to the task. This feature eliminates the need for duplicate Okta groups or custom workflows and supports creating a strong security posture with time-bound access. See Access governance for AD groups.

Escalate tasks is generally available in Production environments

Access request admins and request assignees can escalate stalled tasks within a request to the task assignee's manager. Requesters can also escalate tasks within their access requests if you've enabled the Allow requesters to escalate tasks toggle on the Settings page. This helps expedite request resolution, prevents bottlenecks, improves productivity, and helps reduce the use of risky workarounds. Task escalation is a secure, auditable, and automated process that helps you adopt time-based access request models by supporting both efficient operations and strong security postures. See Manage tasks and Allow requesters to escalate tasks.

Changes to the Campaign Summary report

If predefined user scope is selected for a resource campaign, then depending on the selection, the User scope column of the Campaign Summary report now shows either Users with no recent activity or Users with SOD conflicts.

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.

Changes to the group owner functionality in approval sequences

For approval sequences, you can now select the Resource Owner option if you want to assign the task to the group owner of the group specified in the Access level of the access request condition. Any existing approval sequences that had tasks assigned to a combination of Group owner and The group being requested have been automatically updated to Resource owner. You can continue to use the Group owner option to assign tasks to group owners of other groups (not specified in the access level of the access request condition). Additionally, the following approval sequence templates have been renamed:

• Justification + Group Owner Approval is now Justification + Resource Owner Approval

• Manager, Group Member & Owner Approvals is now Manager, Group Member & Resource Owner Approvals

See Configure an approval sequence.

Certify service accounts

You can now create resource campaigns to review and certify access for both SaaS application and Okta service accounts. This feature extends your governance strategy to non-human identities, ensuring you maintain visibility and control over critical service account access. See Certify service accounts.

This is an Early Access release. See Enable self-service features.

Governance for Workflows

You can now use Okta Identity Governance to manage access to Workflows roles. This helps you ensure that access to Workflows is granted consistently and in compliance with your company's requirements. See Governance for Workflows.

This is an Early Access release. See Enable self-service features.

Access Requests for AD Groups is generally available in Preview environments

You can now manage access requests for Active Directory (AD)-sourced groups directly from Okta. This allows you to use AD groups when configuring access request conditions and enables users to request membership directly from their Okta dashboard. When a request is approved, the requester's access is granted in AD. It's also removed when it expires (if it's time-bound). Additionally, if you select a resource owner as a task assignee in an approval sequence, the AD-sourced group's manager is assigned to the task. This feature eliminates the need for duplicate Okta groups or custom workflows and supports creating a strong security posture with time-bound access. See Access governance for AD groups.

This feature is generally available in Preview environments but it's an Early Access release for Production environments.

Escalate tasks is generally available in Preview environments

Access request admins and request assignees can escalate stalled tasks within a request to the task assignee's manager. Requesters can also escalate tasks within their access requests if you've enabled the Allow requesters to escalate tasks toggle on the Settings page. This helps expedite request resolution, prevents bottlenecks, improves productivity, and helps reduce the use of risky workarounds. Task escalation is a secure, auditable, and automated process that helps you adopt time-based access request models by supporting both efficient operations and strong security postures. See Manage tasks and Allow requesters to escalate tasks.

This feature is generally available in Preview environments but it's an Early Access release for Production environments.

Resource labels is generally available in Production environments

Define labels for resources across Okta to enable better visibility, filtering, and automation within Access Certifications when scoping and maintaining campaigns. See Resource labels.

Delegated flow updates

Delegated flows now include a Caller input field. This allows you to pass more information to a flow that was called from another Okta product. For example, the requestID from Access Requests is now passed to the delegated flow. See Build a delegated flow.

Changes to access request approval by email

When you approve or deny requests from email, you now have five seconds after you click Approve or Deny to cancel your decision if you made a mistake. After that, your decision will be automatically applied.

Changes to preview user functionality

On the User page of the campaign wizard, Preview user is now called Preview expression scope. When you preview a user, Okta only validates the user against the Okta Expression Language expression that you specified. A user who matches the expression but isn't assigned to a resource in the campaign won't be included in the campaign.

Security access reviews is generally available in Preview environments

A security access review is a new, security-focused user access review that can be automatically triggered by events. These reviews provide a unified view of a user's access and contextual information about their access history including an AI-generated access summary. This allows you to investigate and take immediate remediation actions like revoking access. You also have the option to enable or disable the AI summary from the Governance AI tab of the Settings page. See Security access reviews.

Changes to security access reviews are generally available in Preview environments

• For resources that require manual remediation, reviewers can now select Revoke access or Restore access. When a reviewer selects these, Okta records this action in the review history for an admin to take manual remediation action on. Okta also fires an access.review.action System Log event. See Review access.

• You can now update the reviewer and end date of a security access review after it launches. See Manage Security Access Reviews .

Entitlement history is generally available in Preview environments

Admins can now access a user's entitlement history. This feature improves auditing and compliance tasks and enhances visibility for troubleshooting access issues. See View user entitlements.

Resource owners is generally available in Production environments

Assign owners to groups, apps, entitlements, and entitlement bundles. This feature allows you to automatically route access request steps and access certification campaign reviews to the correct stakeholder, improving the efficiency and accuracy of your governance processes. It also helps ensure that the right stakeholder is always involved in access decisions without requiring manual updates to your configurations.

• Access Requests: When configuring approval sequences in access request conditions, you can now assign approvals, tasks, or questions directly to resource owners. Configure an approval sequence.

• Access Certifications: When creating certification campaigns, you can now select the Resource Owner as the designated reviewer. See Certification campaign reviews.

See Resource owners.

Enhanced security for Okta Access Requests web app is generally available in Production environments

The Okta Access Requests web app now performs policy evaluations before granting new access tokens.

Export Okta Identity Governance reports in PDF format is generally available in Production environments

You can now export Okta Identity Governance reports to PDF. When exporting, you can also select specific columns to include in the report.

Universal Logout for Okta Access Requests web app

The Okta Access Requests web app now supports Universal Logout. This enables admins to automatically sign users out of this app when Universal Logout is triggered.

Enhanced security for Okta Access Requests web app is generally available in Preview environments

The Okta Access Requests web app now performs policy evaluations before granting new access tokens.

• When editing a request type or interacting with a request managed by request types, long text labels for dropdown menus and fields weren't rendered correctly and were missing their hover tooltips. (OKTA-993083)

• Users with access request and app admin roles could see the Access Request tab on app profile page for various apps even if the app admin role was scoped to a specific app. (OKTA-1030035)

• The Access Requests tab appeared on the app's profile page for API service apps. (OKTA-1035925)

• The Resource access changes - Campaign launch to campaign complete report included details of users who weren't included in the campaign's user scope. (OKTA-1038132)

• The Access Request - V2 APIs didn't support the client credentials authentication flow. (OKTA-1044065)

• The History section in the Review details panel didn't display the reviewer's decision if the campaign creator information was missing for recurring campaigns with multilevel reviews. (OKTA-1046833)

• The client credential flow for API service apps didn't work for some governance API requests. (OKTA-926552)

• Admins couldn't export Past Access Requests reports to PDF. (OKTA-997865)

Export Okta Identity Governance reports in PDF format is generally available in Preview environments

You can now export Okta Identity Governance reports to PDF. When exporting, you can also select specific columns to include in the report.

Entitlement history is generally available in Preview environments

Admins can now access a user's entitlement history. This feature improves auditing and compliance tasks and enhances visibility for troubleshooting access issues. See View user entitlements.

Resource owners is generally available in Preview environments

Assign owners to groups, apps, entitlements, and entitlement bundles. This feature allows you to automatically route access request steps and access certification campaign reviews to the correct stakeholder, improving the efficiency and accuracy of your governance processes. It also helps ensure that the right stakeholder is always involved in access decisions without requiring manual updates to your configurations.

• Access Requests

  When configuring approval sequences in access request conditions, you can now assign approvals, tasks, or questions directly to resource owners. Configure an approval sequence.

• Access Certifications

  When creating certification campaigns, you can now select the Resource Owner as the designated reviewer. See Certification campaign reviews.

See Resource owners.

Resource labels is generally available in Preview environments

Define labels for resources across Okta to enable better visibility, filtering, and automation within Access Certifications when you scope and maintain campaigns. See Resource labels.

Auditor reporting package is generally available on Production environments

Use this feature to automatically generate access certification campaign reports, which are tailored to meet auditor requirements. These reports make preparing for compliance audits faster and easier by reducing the time and manual effort required for assembling and exporting campaign and user access data. See Auditor reporting package.

Governance delegates is generally available in Production environments

You can set delegates for users or allow users to specify another user as a delegate to complete governance tasks for them. Governance tasks include access certification campaign review items and access request approvals, questions, and other tasks. After a delegate is specified, all future governance tasks (access request approvals and access certification reviews) are assigned to the delegate instead of the original approver or reviewer. This helps ensure that governance processes don't stall when approvers are unavailable or tasks need to be rerouted to a different stakeholder for a long period. It also reduces the time spent in reassigning requests and reviews manually. See Governance delegates.

New System Log event

The governance.settings.update System Log event is fired when super admins update the delegate settings to allow or block users from assigning their own delegate.

Changes to access request notifications

To ensure conversations are displayed consistently across platforms, messages sent within an access request from the web app now automatically appear for the message sender in the corresponding Slack or Microsoft Teams chat. This reduces confusion for the message sender around the messages associated that are with a request.

Changes to the Past Access Requests (Conditions) report

The Request subject column has been removed from the Past Access Requests (Conditions) report.

• Sometimes the Request access button wasn't available after you enabled the Unified Requester Experience feature if the org didn't have any access request conditions configured. (OKTA-1032205)

• Admins who were recently assigned the app and access request admin roles couldn't see the Access Requests tab on the app instance page. (OKTA-1020342)

• Pending review emails were composed for all reviewers, regardless of whether they had any pending reviews. This issue resulted in the delivery of emails that contained no review items. (OKTA-1020491)

• Sometimes campaigns failed to launch. (OKTA-1020732)

• After being assigned to Salesforce and assigned an entitlement bundle through a workflow in Okta, some users weren't pushed and synced, and therefore weren't visible in Salesforce. (OKTA-1021934)

• The entitlement description field wasn't imported into Okta through SCIM 2.0. (OKTA-935291)

Removed delegate self-approval for Access Requests

Delegates can no longer approve requests made on their behalf, ensuring proper separation of duties.

• Access Certification email notifications for a changed campaign end date incorrectly displayed Pending reviews in the subject line. (OKTA-1007068)

• User status in Okta Identity Governance wasn't correctly populated in an Access Certifications campaign for deactivated users. (OKTA-991451)

• Admins who were recently assigned the app and access request admin roles couldn't see the Access Requests tab on the app instance page. (OKTA-1020342)

Release 2025.09.0

Features and Enhancements

Changes to Access Certifications UI

The Campaigns tab on the Access Certification page has been renamed Certification campaigns. The + Create campaign button has been relocated to the Certification campaigns tab.

This is an Early Access release. See Enable self-service features.

Changes to Access Certifications limits

The following limits have been updated for resource campaigns:

• Maximum number of resources included in a campaign has been increased from 50 to 250.

• Maximum number of apps reviewing entitlements has been increased from 10 to 20.

For user campaigns, the maximum number of excluded resources has been increased from 50 to 100. You can exclude a maximum of 100 apps or groups, or a combination of both.

Changes to resource campaigns UI

When you select apps to include in a resource campaign, the search results for apps that have entitlements available are now suffixed with Entitlements in parenthesis.

Governance delegates

You can set delegates for users or allow users to specify another user as a delegate to complete governance tasks for them. Governance tasks include access certification campaign review items and access request approvals, questions, and other tasks. After a delegate is specified, all future governance tasks (access request approvals and access certification reviews) are assigned to the delegate instead of the original approver or reviewer. This helps ensure that governance processes don't stall when approvers are unavailable or tasks need to be rerouted to a different stakeholder for a long period. It also reduces the time spent in reassigning requests and reviews manually. See Governance delegates.

Group owner role is now Resource owner

The Group owner role has been renamed Resource owner.

Improved user experience for Access Requests

The access request details page and email notifications have been improved for better visibility on approvers' tasks and requesters' responses. If you integrated Slack with Access Requests, similar changes have been made to the access request message that approvers receive. Also, the request assignee has been removed from Slack and email notifications and the email notification sender's name and address have been changed. The sender's new name is Okta Access Requests and the new email address is noreply@at.okta.com. See Redesigned Approver Experience for Access Requests.

Security Access Reviews

Security Access Reviews are a new, security-focused type of user access review that can be automatically triggered by events. These reviews provide a unified view of a user's access, and contextual information about their access history including an AI-generated access summary, allowing you to investigate and take immediate remediation actions like revoking access. See Security access reviews.

UI improvements for resource catalog tiles

The resource catalog tiles for request types and resource collections now include descriptions. For tiles with longer descriptions, you can hover over the text to view the full description in a tooltip.

Governance delegates

Super admins and users can assign another user as a delegate to complete governance tasks for them. Governance tasks include access certification campaign review items and access request approvals, questions, and other tasks. After a delegate is specified, all future governance tasks (access request approvals and access certification reviews) are assigned to the delegate instead of the original approver or reviewer. This helps ensure that governance processes don't stall when approvers are unavailable or tasks need to be rerouted to a different stakeholder for a long period. It also reduces the time spent in reassigning requests and reviews manually. See Governance delegates.

This is an Early Access release. See Enable self-service features.

Unified requester experience

Use this feature to create a consistent and unified experience for initiating requests in End-User Dashboard, Slack, and Microsoft Teams regardless of whether the request is managed by conditions or request types. This gives you the flexibility to use either or both methods together to manage resource access without altering the requester experience.

• Request types now appear as tiles in the End-User Dashboard's resource catalog alongside other resources. Your settings for a request type's audience continue to govern which users can view the request type on their dashboard and request access.

• In Slack and Microsoft Teams, users can now request access to resources that are governed by access request conditions, and the user experience for requesting resources that are managed by request types has also been changed.

Additionally, in the Okta Access Requests app, the Access requests page has been renamed to Resource catalog. Clicking it redirects requesters to the resource catalog on the End-User Dashboard. The Request types section in the web app is only visible to admins and team members who own the request type. See Create requests.

This is an Early Access release. See Enable self-service features.

Export Okta Identity Governance reports in PDF format

You can now export Okta Identity Governance reports to PDF. When exporting, you can also select specific columns to include in the report.

This is an Early Access release. See Enable self-service features.

Changes to request assignees for request types are available in Production environments

When a task or question in a request type is assigned to a group to complete, the user who originally submitted the request is now automatically excluded from the assignment, even if they are a member of that group. This prevents the requester from taking an action on their own request in a request management capacity.

For Access Certification campaigns, the Employee number checkbox is now available in the Contextual Information section of the Settings page. See Customizable reviewer context.

Okta Access Requests Resource Catalog app has been renamed

The Okta Access Requests Resource Catalog app has been renamed Okta Identity Governance. This app is automatically assigned to all users and no app management is required. Users may see the new name when they click Request access on the End-User Dashboard. This change doesn't impact the existing Okta Access Certification Reviews and Okta Access Requests apps that campaign reviewers and request approvers use.

Changes to access requests managed by request types are available in Production

If an access request is managed by request types, you can't use it to assign groups that grant Okta admin roles. You can't add groups that grant Okta admin roles to a list. Okta also invalidates request types that assign these groups when you create or edit the request type. Users get an error if they request a group that grants the Okta admin role. See Access Requests for admin roles.

Changes to Okta apps are available in Preview

You can no longer view or assign the following apps to users:

• Okta Access Certifications

• Okta Access Requests Admin

• Okta Entitlement Management

Additionally, the sign-on policies for these apps will default to the existing sign-on policy that you use for the Okta Admin Console.

Changes to access requests managed by request types are now available in Preview environments

If an access request is managed by request types, you can't use it to assign groups that grant Okta admin roles. You can't add groups that grant Okta admin roles to a list. Okta also invalidates request types that assign these groups when you create or edit the request type. Users get an error if they request a group that grants the Okta admin role. See Access Requests for admin roles.

Changes to request assignees for request types are now available on Preview environments

When a task or question in a request type is assigned to a group to complete, the user who originally submitted the request is now automatically excluded from the assignment, even if they are a member of that group. This prevents the requester from taking an action on their own request in a request management capacity.

Separation of duties is generally available in Production environments

Use Separation of duties (SOD) rules to define which combinations of entitlements create conflicts of interest in an org. Divide tasks and responsibilities using these rules so that the same user in an org doesn't have control over all aspects of a critical process. You can configure SOD rules to help reduce the risk of error, fraud, or unauthorized actions. With SOD rules, you can adopt a two-pronged approach to manage conflicting entitlement assignments – preventative and remediative.

• Use Access Requests to specify whether users are allowed (or allowed with custom settings) or blocked from requesting access that can cause an SOD rule conflict. You can also run the Past Access Requests (Conditions) report to view access requests that have an SOD rule conflict using the Conflict name column.

• Use Access Certifications to review and remediate existing user access if they have an SOD rule conflict by running a resource campaign.

In addition, SOD conflict information is also available when you run any of the Separation of duties, Past campaign details, or Past Access Requests (Conditions) reports.

See Resource collections, Configure settings for access requests, and Create resource campaigns.

User-friendly group display name and description is generally available in Production environments

Use the endUserDisplayName and endUserDisplayDescription group profile attributes to set a display name and description for an Okta group. After you set these, they are visible to requesters and approvers and provide context when they request or approve access. Okta automatically updates the group's display name and description (if available) on the End-User Dashboard twice daily. To make changes visible immediately on the End-User Dashboard, update a condition for an app that's assigned to the group. See Update group profile attributes .

Fixes

• Okta didn't refresh the End-User Dashboard twice a day to remove app tiles for deleted or deactivated apps that had active access request conditions. (OKTA-896199)

New look and feel in Access Requests is generally available in Production environments

The Access Requests console and Okta Access Requests web app now have a new look and feel, including redesigned side and top navigation menus and the addition of a gray background. Additionally, Dark mode is no longer available in the Access Requests.

Fixes

• For groups that were used in access request conditions for admin role bundles, the maximum number of users allowed in a group was 100 instead of 200. (OKTA-859014)

Release 2025.02.0

Features and Enhancements

Release notes retention policy

Okta maintains release notes online for a period of 12 months following a release.

Contact Okta Support to request archived documentation for releases outside this window.