# Disable Accounts

The **Disable Accounts** action disables user accounts in the source identity provider directly from a query result. Use this when a query surfaces risky user accounts, such as dormant accounts or accounts associated with departed employees, and you want to act immediately without leaving Veza.

{% hint style="warning" %}
**This is a bulk, immediate action. Read this before proceeding.**

* Service accounts, admin accounts, and break-glass accounts are not filtered out. Review query results for privileged identities before executing.
* There is no approval step after initiating remediation. Any admin with access to this feature can execute it immediately.
* The action affects every selected account. A misconfigured query can result in unintended accounts being disabled.
* Veza does not provide an undo action. To re-enable a disabled account, you must do so manually in the identity provider.
* Query results reflect data from the last extraction. If extraction is stale, the results may not match the current state of your environment.
  {% endhint %}

{% hint style="info" %}
**Early Access**: This feature is not enabled by default. Contact Veza support to enable it for your organization.

Behavior and configuration options may change before general availability. Before using this feature at scale, test it against a small, controlled query that returns a known set of accounts.
{% endhint %}

## Enabling write access

Veza integrations use read-only service account credentials by default. Before you can use Disable Accounts, you must grant the Veza service account write permissions and enable the integration for write actions. This is a one-time setup per integration.

1. Follow the guide for your integration to add the required write permissions to the Veza service account:
   * [Okta: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta/provisioning.md)
   * [Azure AD: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure/provisioning.md)
   * [Active Directory: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory/provisioning.md)
2. In Veza, go to **Integrations**, open the integration configuration, and check the **Enable usage for Provisioning** checkbox.

   ![The Edit Integration panel showing the Enable usage for Provisioning checkbox](/files/CH6LjOL7HxbbLUpax9EP)
3. Click **Save Configuration**.
4. To verify: reopen the integration configuration and confirm the **Enable usage for Provisioning** checkbox is checked.

## Before you begin

Before enabling or using this action on a production query, complete the following steps:

1. Run the query and review every account in the results. Confirm all returned accounts are safe to disable.
2. Check when the integration last ran a successful extraction. Stale extraction data means stale query results.
3. Identify whether the query could surface service accounts, shared accounts, or privileged identities. Add filters to exclude them if needed.
4. Confirm your team has a process to re-enable accounts in the identity provider if any accounts need to be restored.

## Prerequisites

* Write access must be configured for the target integration. See [Enabling write access](#enabling-write-access) above.
* An administrator must enable the action on each query before it appears in the **Remediate** dropdown.
* The query's source entity type must be one of: **Azure AD User**, **Active Directory User**, or **Okta User**.

### Role requirements

Different controls in this feature are available to different roles:

| Action                              | Minimum role |
| ----------------------------------- | ------------ |
| View the Remediate dropdown         | Viewer       |
| Execute the Disable Accounts action | Admin        |
| View the Remediation Log            | Admin        |
| Enable the action on a query        | Admin        |

Viewers can see the Remediate dropdown but cannot execute actions. The Disable Accounts action is only available to Admins.

The Disable Accounts option only appears in the dropdown after an Admin has enabled it on the query. If provisioning is not enabled for the integration, the option is grayed out for all users.

## Enabling the action on a query

Before Disable Accounts appears in the **Remediate** dropdown for a query, an administrator must enable it. On the query details page, open the **Remediate** dropdown and select **Enable Option to Disable Accounts** at the bottom of the menu.

![The Remediate dropdown showing the Enable Option to Disable Accounts item at the bottom of the menu](/files/3Qoel20Vt3ewCI3g8BIx)

This setting is per-query. Each query that should support Disable Accounts must be configured separately. Once enabled, the option appears under the **Automatic** group for all users with the Admin role.

## How to access

On the query details page, click the **Remediate** dropdown and select **Disable Accounts** under the **Automatic** group.

![The Remediate dropdown on a query details page, showing Disable Accounts under the Automatic group](/files/jlMrMiyAVoUquK3kDNVn)

The option is grayed out if the query has not been configured for this action or if Provisioning is not enabled for the integration.

## Workflow

Selecting **Disable Accounts** opens a full-screen page with three sections:

1. **Safety Conditions**: This section displays checks that must pass before execution. The action is blocked if any condition fails. Additional safety conditions may be added in future releases.
2. **Preview**: This section lists the accounts from the query results that are eligible for disablement. Use the checkboxes to select the accounts to disable.
3. **Summary**: Use this section to add notes (required) documenting the reason for the action.

![The Preview Action page showing an impact summary and the Accounts to be Processed table, with checkboxes to select which accounts to disable](/files/dTXAabWbQEkxLdKJTv9A)

Click **Execute** to submit the request. Veza disables the selected accounts and creates an auditable access request record. After execution, you are redirected to the **Remediation Log** tab, where you can monitor the status of the request.

{% hint style="info" %}
The Disable Accounts action performs a simple account disable only. Advanced deprovisioning options such as removing group memberships, moving the account to a different OU, or syncing attributes are not configurable in this flow. For full deprovisioning control, use a [Lifecycle Management workflow](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md) instead.
{% endhint %}

## Remediation Log

The Remediation Log tab shows all Disable Accounts requests submitted for the query. Each row includes the affected entity, who executed the action, any notes added, the current state, and timestamps for when the request was submitted and completed.

![The Remediation Log tab showing Disable Accounts requests, with a toast notification confirming the action was triggered](/files/fW4M3q1RBkF5WL1HmSIS)

Click **View details** on any row to open the request detail view.

The summary card at the top of the detail view shows:

| Field                | Description                                                                                                 |
| -------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Requested At**     | When the request was submitted.                                                                             |
| **Created By**       | The Veza user who triggered the disable action.                                                             |
| **Remediation Type** | Always "Disable Accounts" for this flow.                                                                    |
| **Status**           | The current state of the request. See the status table below for plain-language descriptions of each value. |
| **Completed At**     | When the request reached a terminal state (Completed, Errored, Rejected, or Canceled).                      |
| **Note**             | The reason entered by the user before execution.                                                            |
| **Error Message**    | Shown only when the status is Errored. Describes what went wrong during execution.                          |

Below the summary card, the **History** tab shows every state transition the request went through from submission to completion.

The Remediation Log is scoped to the query. There is no corresponding entry in the platform Events page (**Administration** > **Events**).

### Interpreting request status

Each request moves through a series of states as it is processed. The following statuses may appear in the Remediation Log and the detail view:

| Status            | Meaning                                                                      |
| ----------------- | ---------------------------------------------------------------------------- |
| **Initial**       | The request was received and is being routed for execution.                  |
| **Plan Selected** | The disable operation is executing.                                          |
| **Completed**     | The account was successfully disabled.                                       |
| **Errored**       | The disable operation failed. Open the detail view to see the error message. |
| **Canceled**      | The request was canceled before execution. The account was not changed.      |

### Interpreting the History tab

The History tab in the detail view records every state change for the request, including who or what triggered it and when. Each row shows:

* **Created At** — when the transition occurred.
* **Created By** — the user or system that triggered the transition. Entries showing **Veza** as the actor are automated transitions made by the system, not by a person.
* **Action** — the operation that caused the state change (for example, "Revoke Access" when the disable operation runs).
* **Message** — additional context about the transition, such as an error description.
* **Current State / Previous State** — the state before and after the transition.

The audit record is created when you click **Execute** and is retained even if the account is later modified or re-enabled.

## Supported integrations

The following integrations support disabling accounts. Write access must be configured for the Veza service account as described in [Enabling write access](#enabling-write-access):

* Okta
* Active Directory
* Azure AD

## See also

* [Remediation actions](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions.md)
* [Okta: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta/provisioning.md)
* [Azure AD: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/azure/provisioning.md)
* [Active Directory: Enabling provisioning](/4yItIzMvkpAvMVFAamTf/integrations/integrations/active-directory/provisioning.md)
* [Lifecycle Management](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management.md)


---

# Agent Instructions: 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:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/features/insights/remediation-actions/remediation-disable-accounts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.