> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/verify-remediations.md).

# Verify Remediations

Access Reviews help organizations identify and remediate inappropriate entitlements. The **Verify Remediations** feature automatically reconciles row decisions against live access data on completed and expired reviews:

* **Bidirectional auto-validation** — the validation job runs in both directions, marking Rejected rows as Fixed when access is removed, and reverting Fixed rows back to Rejected if access reappears.
* **Admin override** — administrators can manually switch a row's decision between Fixed and Rejected to correct rows that were incorrectly marked.

## How it works

Once a review is completed or expired and Verify Remediations is enabled, Veza runs a background validation cycle every 2 hours against the live Access Graph. The job checks both signed-off Rejected rows and previously Fixed rows:

| Direction        | Trigger                                            | Result                          | Note recorded                                         |
| ---------------- | -------------------------------------------------- | ------------------------------- | ----------------------------------------------------- |
| Rejected → Fixed | Rejected access is no longer detected in the graph | Row is marked **Fixed**         | *"Rejected access no longer detected by Veza"*        |
| Fixed → Rejected | Previously fixed access reappears in the graph     | Row is reverted to **Rejected** | *"Previously rejected access detected again by Veza"* |

Both checks run as a single cycle, and all action log entries are recorded as performed by the System. For example, for a review of Okta Users to Okta Groups:

1. A reviewer rejects an Okta user's access to a particular Okta group.
2. The decision is signed off.
3. Once the review has been completed or reaches its due date, Veza periodically queries the Access Graph to check if the rejected Okta User → Okta Group access relationship still exists.
4. If the access is no longer present, Veza marks the rejected row as **Fixed** with the note above.
5. If that access later reappears (for example, due to a data upload that temporarily removed the edge), Veza reverts the row from **Fixed** back to **Rejected**.

This provides an auditable record of both successful and incomplete remediations without requiring manual follow-up.

> **Note:** The **Verify Remediations** feature is agnostic to the method of access revocation. Access can be removed automatically using Veza's [auto-revocation](/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/auto-revocation.md) capabilities, programmatically removed, or manually removed using out-of-band means. Once the rejected access is no longer detected in the Access Graph, the corresponding row in the access review is marked as **Fixed**.

Automated datasource extractions, CSV file uploads, and data pushes for OAA-based integrations should continue at regular intervals post-review completion to ensure Verify Remediations remains effective.

**The feature is disabled by default.** To use it, enable it in **Access Reviews** > **Settings** or within a review configuration.

### Sign-off requirements

A sign-off must occur on the rejected row before Veza will check that row against the Access Graph. The verification only processes rows that have been **both Rejected and Signed Off** by a reviewer.

Sign-off can occur in two ways:

* **Manually:** A reviewer explicitly signs off on their rejected decisions using the sign-off action in the Reviewer Interface, or uses the **Reject & Sign-Off** combined action.
* **Automatically:** Rows that are auto-rejected by system events (such as review auto-expiration or auto-advance at due date) are signed off automatically.

### Validation timing and duration

Depending on the configured trigger, the validation job starts either when the review reaches its due date or when all rows are completed. The job runs every 2 hours and continues checking both Rejected and Fixed rows until the configured maximum validation duration is reached (default is 30 days). The maximum duration can only be adjusted via the [API](#configure-via-the-api) — it cannot be changed from the UI.

## Admin Override

Administrators can manually switch the decision on individual rows of completed or expired reviews between **Fixed** and **Rejected**. Notes can also be updated at the same time.

**Requirements:**

* Administrator-level permissions on Access Reviews
* Review must be in Completed or Expired state
* Verify Remediations must be enabled on the configuration

**What can be changed:**

* Decision (Fixed ↔ Rejected)
* Notes

**What cannot be changed on a completed or expired review:**

* Reviewer assignment
* Sign-off state
* Predefined question responses

The override works through the existing row update controls in the review — there is no separate admin UI. For users without administrator permissions, these controls remain locked on completed or expired reviews.

## Configuring Verify Remediations

The Access Reviews section in the Veza administrative console provides a simple on/off toggle for enabling Verify Remediations, either globally or per-Review Configuration. When enabled, the following defaults are applied automatically:

| Setting                     | Default                            |
| --------------------------- | ---------------------------------- |
| Trigger                     | On review completion or expiration |
| Maximum validation duration | Up to 30 days                      |

For full trigger options and custom durations, use the [API](#configure-via-the-api).

### Global Settings

To enable Verify Remediations for all Review Configurations that do not have their own override:

1. Go to **Access Reviews** → **Settings**.
2. On the **Reviews** tab, scroll down to the **Verify Remediations** card.
3. Toggle **Mark verified remediations as fixed** on.

### Review Configuration

To enable Verify Remediations for a specific review configuration:

1. Go to **Access Reviews** → **Configurations**.
2. Click the configuration name, then click **Edit**.
3. In the configuration wizard, scroll to or click **Verify Remediations** in the right-side step navigation.
4. Toggle **Mark verified remediations as fixed** on.

Settings configured at the review configuration level override the global setting for that configuration.

## Configure via the API

Administrators can configure all options for Verify Remediations via API, including the trigger condition, the validation duration, and the behavior when validation succeeds. Settings can apply globally or to a specific review configuration.

The toggle in the administrative interface enables Verify Remediations with fixed defaults: validation triggers on review completion and runs for up to 30 days. To use any of the following, configure the feature via API:

* **Trigger on due date** — start validation as soon as a review reaches its due date, without waiting for completion or expiration
* **Custom validation windows** — set a duration other than the default 30 days
* **Per-configuration overrides** — enable globally but disable for a specific configuration, or use different settings per configuration

### Required permissions

| Operation       | Roles                                                                                                                                             |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| Update settings | `admin`, `operator`, `access_reviews_admin`                                                                                                       |
| Read settings   | `admin`, `operator`, `access_reviews_admin`, `access_reviewer`, `viewer`, `reassigner`, `watcher`, `access_reviews_monitor`, `nhi_security_admin` |

### Update settings

```
PUT /api/private/workflows/access/global_settings/remediation_validation_behavior
```

**Request body**

```json
{
  "workflow_id": "optional-review-config-id",
  "value": {
    "behavior": "ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_MARK_AS_FIXED",
    "trigger": "ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_COMPLETION",
    "max_validation_duration_days": 30
  }
}
```

**Fields**

| Field                                | Type    | Required | Description                                                                                                                                                                                           |
| ------------------------------------ | ------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `workflow_id`                        | string  | No       | If provided, applies settings only to this review configuration. If omitted, applies globally to all configurations that do not have their own settings.                                              |
| `value.behavior`                     | string  | Yes      | Controls what happens when validation runs. See [Behavior values](#behavior-values).                                                                                                                  |
| `value.trigger`                      | string  | Yes      | Determines when the validation job starts. See [Trigger values](#trigger-values).                                                                                                                     |
| `value.max_validation_duration_days` | integer | Yes      | How many days the job continues attempting to validate before giving up. Must be greater than 0. Once all signed-off rejected rows are validated, the job stops immediately regardless of this value. |

#### Behavior values

| Value                                                  | Description                                                                                                                                                                                                  |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_DISABLED`      | Validation does not run.                                                                                                                                                                                     |
| `ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_MARK_AS_FIXED` | Bidirectional validation: rejected rows are marked **Fixed** when access is no longer detected, and Fixed rows are reverted to **Rejected** if access reappears. All changes are recorded in the action log. |

#### Trigger values

| Value                                                 | Description                                                                                                                                                                                                                                                    |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_COMPLETION` | The validation job starts when a review enters the **Completed** or **Expired** state. Note: a review that is past its due date is not the same as an expired review. For a review to expire, it must have a due date and review expirations must be enabled.  |
| `ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_DUE_DATE`   | The validation job starts as soon as the review reaches its due date, regardless of whether review expiration is enabled. If the review has no due date, this behaves identically to `ON_COMPLETION` and the job will not start until the review is completed. |

### Get current settings

```
GET /api/private/workflows/access/global_settings/remediation_validation_behavior
```

**Query parameters**

| Parameter     | Type   | Required | Description                                                                                               |
| ------------- | ------ | -------- | --------------------------------------------------------------------------------------------------------- |
| `workflow_id` | string | No       | If provided, returns the settings for this review configuration. If omitted, returns the global settings. |

**Response**

```json
{
  "value": {
    "behavior": "ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_MARK_AS_FIXED",
    "trigger": "ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_COMPLETION",
    "max_validation_duration_days": 30
  }
}
```

### Example: Enable with on-due-date trigger and 14-day window

Enables Verify Remediations globally. Validation starts as soon as a review reaches its due date, and the job will continue checking for up to 14 days.

```
PUT /api/private/workflows/access/global_settings/remediation_validation_behavior
```

```json
{
  "value": {
    "behavior": "ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_MARK_AS_FIXED",
    "trigger": "ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_DUE_DATE",
    "max_validation_duration_days": 14
  }
}
```

### Example: Disable for a specific review configuration

Disables Verify Remediations for a single review configuration, overriding the global setting for that configuration. Replace the `workflow_id` value with the ID of the target configuration.

```
PUT /api/private/workflows/access/global_settings/remediation_validation_behavior
```

```json
{
  "workflow_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "value": {
    "behavior": "ACCESS_REMEDIATION_VALIDATION_BEHAVIOR_DISABLED",
    "trigger": "ACCESS_REMEDIATION_VALIDATION_TRIGGER_ON_COMPLETION",
    "max_validation_duration_days": 30
  }
}
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/access-reviews/configuration/verify-remediations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.