> 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/insights/remediation-actions/remediation-disable-accounts.md).

# 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            | Viewer       |
| 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 **Name** filter above the table to narrow the list by account name. Use the checkboxes to select individual 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)

### Filtering the preview by name

The **Name** filter above the preview table narrows the list to accounts with a matching name.

* Enter text in the filter search box to run a case-insensitive substring match against account names. Select one or more names to apply the filter.
* The preview table and count of total accounts reflect the current selection; the impact summary will always match the request to be submitted.
* Clear the filter to restore the full list of eligible accounts.

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

Each Disable Accounts request is logged per account in the assessment's [Remediation Log](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-log.md) tab, alongside every other remediation triggered from the query. Bulk submissions produce one row per affected account.

A row stays as audit evidence even after the account is later modified or re-enabled. See the [Remediation Log](/4yItIzMvkpAvMVFAamTf/features/insights/remediation-log.md) page for column reference, the status-and-state model, the History tab, and audit guidance.

## 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
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/insights/remediation-actions/remediation-disable-accounts.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.