---
{
  "title": "Account Access Removal",
  "summary": "Account access removal disrupts legitimate users by changing, deleting, or restricting their identities.",
  "topic": "grc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    3
  ],
  "aliases": [
    "T1531"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1531: Account Access Removal",
      "url": "https://attack.mitre.org/techniques/T1531"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Account access removal disrupts legitimate users by changing, deleting, or restricting their identities. This can impede response or directly harm availability.


## An investigation example

A suspicious administrator changes recovery settings and locks several operational accounts during an incident.

## Evidence to examine

Review identity changes, actor privileges, affected roles, recovery dependencies, and approval records.

## A common analytical pitfall

A locked account can result from normal policy enforcement; determine the cause and intent through evidence.

## Response considerations

Protect independent administrative recovery paths and restore legitimate access through verified identity and change procedures.


## Identity disruption can block legitimate recovery

Unauthorized changes to accounts can prevent staff from performing normal work or responding to an incident. Removal may involve disabling identities, changing credentials, altering roles, or restricting access. The specific mechanism determines which recovery options remain available. A password reset alone may not restore a deleted role assignment or an inaccessible identity tenant.

Account changes also occur legitimately during offboarding, maintenance, and security containment. Compare the event with approvals, expected workflow, responsible identity, and affected population. A widespread change affecting administrators has a different operational consequence from one planned account disablement, but both need accurate context.

## A fictional administrator lockout

An academy's operations team discovers that several administrator accounts have lost access. Audit records show role changes made through an unfamiliar session. The incident team preserves identity events, validates an authorized emergency access route, and coordinates recovery without sharing uncontrolled credentials through ordinary chat.

After access returns, investigate how the modifying identity obtained its authority and whether other account settings changed. Review recovery methods, application permissions, and relevant sessions as appropriate. Restoring visible roles is only one part of rebuilding confidence in the identity environment. Test emergency access arrangements in advance under controlled conditions rather than discovering their weaknesses during an actual lockout.

## Map a trustworthy fallback

For a fictional cloud service, identify the normal administrator route, an approved emergency route, its custodian, and the records retained when it is used. Ask which dependencies could make both routes fail together. Document one improvement that reduces that shared dependency. Do not disable real administrator accounts to test the idea; use a dedicated lab or a paper rehearsal.

Emergency access should remain exceptional and auditable. After use, review the action, restore the intended custody arrangements, and verify that temporary permissions have been removed. Otherwise, the fallback introduced to recover legitimate control may leave a new long-lived concentration of authority.

## Related concepts

- [[business-continuity]]
- [[disaster-recovery]]
- [[incident-response]]
- [[system-shutdown-reboot]]
- [[command-and-scripting-interpreter]]
- [[data-destruction]]
- [[defacement]]