Access reviews in Okta Identity Governance are your automated way to ensure the right people have access to the right things, and that this access is regularly re-validated.

Let’s see it in action. Imagine a new employee, Alice, joins the marketing team.

{
  "eventType": "user.session.login.success",
  "actor": {
    "id": "00ub0o51lhpj85j0a653",
    "type": "User",
    "alternateId": "alice.smith@example.com",
    "displayName": "Alice Smith"
  },
  "target": [
    {
      "id": "app789",
      "type": "AppInstance",
      "displayName": "Marketing Content Platform"
    }
  ],
  "published": "2023-10-27T10:00:00.000Z",
  "outcome": {
    "result": "SUCCESS"
  }
}

This event shows Alice successfully logged into the "Marketing Content Platform." Okta Identity Governance, configured with an access review policy, will now automatically:

  1. Identify Alice’s role: Based on her HR data or Okta group membership, it’s determined she’s in the "Marketing" department.
  2. Trigger an access review: A policy might state that all members of the "Marketing" group need their access to the "Marketing Content Platform" reviewed quarterly.
  3. Assign a reviewer: This could be Alice’s manager, or a designated security admin.
  4. Generate a review task: The reviewer gets a notification to approve or revoke Alice’s access.

The core problem Okta Identity Governance solves with access reviews is the sprawl of unnecessary privileges. Over time, as employees change roles, leave departments, or are onboarded without proper access provisioning, the attack surface grows. Manual reviews are tedious, error-prone, and often don’t happen with the required frequency.

Internally, Okta Identity Governance leverages its understanding of user lifecycle events, group memberships, application assignments, and policy definitions to automate this process. When a user is assigned an application or joins a group, the system can flag this assignment for future review based on predefined policies. These policies define:

  • What to review: Specific applications, groups, or even custom resources.
  • Who reviews: Managers, resource owners, or dedicated administrators.
  • How often: Quarterly, annually, or upon specific lifecycle events (like role changes).
  • What happens on non-review: Auto-revoke, escalate, or re-assign.

The exact levers you control are within the Okta Admin Console, under "Identity Governance" > "Access Reviews." Here, you define your "Review Policies." For instance, a policy might look like this:

  • Name: "Marketing App Quarterly Review"
  • Scope: All users assigned to app789 (Marketing Content Platform) who are members of the Marketing Okta Group.
  • Reviewer: User’s Manager (resolved via Okta’s profile hierarchy).
  • Frequency: Every 90 days.
  • Action on no response: Auto-revoke access after 14 days of no reviewer action.
  • Notification: Send email reminders to the reviewer 7 days before and 1 day before the review due date.

The system doesn’t just passively wait. It actively monitors for changes that might trigger a review or require immediate attention. For instance, if Alice is moved from the "Marketing" group to the "Sales" group, an existing access review policy might immediately re-assign her access review for the "Marketing Content Platform" to her new manager, or even revoke it if the policy dictates that sales personnel shouldn’t have access to marketing tools.

A common point of confusion is how Okta Identity Governance handles "resource owners." When you configure a review policy, you can often specify a "Resource Owner" as the reviewer. This owner is typically an attribute on the application or group itself, which Okta resolves. If this attribute is empty or points to an invalid user, the review might fall back to a default administrator or even stall. Ensuring that your applications and groups have accurate and active "owner" attributes is crucial for smooth automated reviews, preventing those reviews from getting stuck in limbo waiting for an unassigned or invalid owner.

Once access reviews are established, the next logical step is to integrate them with workflows for access requests and lifecycle management.

Want structured learning?

Take the full Okta course →