D3-AL Account Locking: Disabling Compromised Accounts and Proving Access Is Gone

Disabling a compromised account is the fastest eviction step a responder has, and it is also the step most often assumed to work when it has only half worked. MITRE D3FEND names this countermeasure Account Locking (D3-AL) and defines it as "The process of temporarily disabling user accounts on a system or domain." It sits under the Evict tactic as a child of Credential Eviction (D3-CE), next to Authentication Cache Invalidation and Credential Revocation. This card covers what D3-AL changes, which ATT&CK techniques D3FEND relates it to, how it is implemented in directories, cloud identity providers and Linux hosts, and how to prove that the attacker's access is actually gone. It is written for incident responders, identity administrators and SOC leads. Note the scope: D3-AL is the deliberate disabling of an account, not the automatic lockout after failed passwords, which is covered in the Account Lockout and Brute-Force Protection Guide.

Key takeaways

• Disabling stops new sign-ins, not existing sessions. Tokens, Kerberos tickets and application sessions issued before the disable keep working until they expire or are revoked, so D3-AL needs its sibling eviction techniques to be complete.
• D3FEND links it to account abuse. D3FEND relates D3-AL through the User Account artefact to Valid Accounts (T1078), Create Account (T1136), Account Manipulation (T1098) and Account Discovery (T1087); all of these relations are inferred.
• Each account store needs its own action. Active Directory, a cloud identity provider, local accounts on servers and SaaS applications each hold their own enabled flag, and disabling one does not disable the others unless provisioning is wired.
• Locking a password is not locking an account. On Linux, passwd -l leaves SSH key logins working; the account needs an expiry date as well.
• Proof is part of the control. A disable event in the log, a failed test sign-in and a search for activity after the disable time are the evidence that eviction worked.

D3-AL at a glance

How it works

D3FEND's description is about policy: management servers with enterprise account policies can enable and disable accounts by rule, and the rules can cover time periods (weekends, plant shutdowns, leave), user types or groups, or individual users. That gives two uses for the same mechanism.

• Reactive eviction: an account is disabled because it is known or suspected to be compromised, during incident containment. This is the use most responders mean.
• Preventive locking: accounts are kept disabled when they are not needed, for example contractor accounts outside a contract window, a plant engineering account during shutdown, or a privileged account enabled only for a change window. An account that is disabled when the attacker finds its password cannot be used as a valid account.

D3FEND lists three considerations: local account caches versus centralised account management, single sign-on, and role-based versus attribute-based systems. In practice these are the three reasons a disable fails to evict. A host can still accept a cached logon, an SSO session can keep an application open after the directory account is disabled, and an attribute-based policy may grant access by group or claim regardless of the account flag in a downstream system.

D3FEND cites two patents as references. The Forescout patent on account monitoring describes watching account state, and the Oracle patent describes notifying a directory service of authentication events processed outside it, which is the same gap in another form: authentication that happens away from the central store does not see the central disable unless something tells it.

ATT&CK techniques D3FEND relates to D3-AL

Relationship type: inferred only. D3FEND derives every row below through the shared User Account artefact (D3-AL disables User Account; these ATT&CK techniques act on a User Account) and labels the mappings "inferred, experimental" (D3FEND 1.6.0, checked November 2026). IDs were checked against ATT&CK v20. D3FEND groups some rows under several tactics; they are listed once here.

Treat the table as a guide to where disabling helps, not as a coverage claim. Deeper treatment of the attacker side is in the MITRE ATT&CK T1078 Valid Accounts Guide, the MITRE ATT&CK T1136 Create Account Guide, the MITRE ATT&CK T1098 Account Manipulation Guide and MITRE ATT&CK T1531 Account Access Removal.

Where it is implemented

Every platform below offers an account disable; the practical differences are what else must be done for the disable to evict. Platforms are listed alphabetically by account store type.

D3FEND also names RADIUS, LDAP directories and JumpCloud as account stores. The same rule applies to each: find the enabled flag, find what was issued before it changed, and close both. For SaaS applications with their own local accounts, provisioning (SCIM) carries the disable downstream; Microsoft documents its app provisioning cycle as typically 20 to 40 minutes, which is a window to plan for in an incident.

Where identity fits

Service accounts and other non-human identities are where D3-AL gets hard. Disabling a compromised service account stops the attacker and the production workload together, so responders hesitate and the account stays live. Plan for it before the incident: know which workloads each service account supports, keep a documented replacement path (a new account or a managed identity), and prefer workload identities with short-lived credentials so eviction is a session revocation, not an outage. Microsoft's event 4725 guidance makes the same point from the other side: monitor disable events on service accounts that should never be disabled, because an unexpected disable may be an attacker using T1531. See the Workload Identity Compromise Response Playbook.

Implementation steps

1. Map every store for each identity. For each privileged user and service account, record where it exists: directory, identity provider, cloud IAM, local server accounts, SaaS local accounts. Eviction later depends on this list.
2. Prepare scripted actions. Write and test the disable, session revocation and token revocation actions for each store, with the admin roles they need. Microsoft documents that disabling admin accounts in Entra ID needs Privileged Authentication Administrator, so make sure responders hold or can obtain that role.
3. Turn on the evidence. Enable the Audit User Account Management subcategory so 4725 is logged on domain controllers, member servers and workstations, and forward identity provider audit logs to the SIEM.
4. Agree the service account rule. Decide in advance who may disable a production service account during an incident, and what the business impact process is.
5. Disable in the right order. During an incident: disable the account in every store, revoke sessions and refresh tokens, reset the password (twice for Active Directory), then remove attacker-added roles, delegations and keys. Record the exact time of each step.
6. Use preventive locking where it fits. Keep seasonal, contractor and privileged accounts disabled outside their approved windows, and alert on any enable (event 4722 in Windows) outside a change ticket.
7. Roll back safely. Re-enable only after credentials are reset, attacker persistence is removed and the owner confirms; log the re-enable with its ticket.

How to verify it works

• Disable evidence: confirm a 4725 event (or the identity provider equivalent) exists for every store in the map, with the expected administrator as the subject.
• Negative sign-in test: from an approved test path, attempt a sign-in with a test account disabled by the same procedure and confirm it fails at each store.
• Post-disable activity search: search sign-in logs, cloud API logs and server logs for any activity by the account after the recorded disable time. Activity in the following hour points to a live token, ticket or session.
• Exercise: include full account eviction in tabletop and technical exercises and time it end to end.

Limits, bypasses and failure patterns

• Disabling one store only: the directory account is disabled, but a local administrator account with the same password, or a SaaS local account, still works.
• Trusting the disable without revocation: refresh tokens and sessions keep the attacker in. The Global Token Revocation Guide covers the revocation side.
• Locking the password, not the account: passwd -l on Linux and password resets elsewhere leave key-based and token-based access open.
• Leaving attacker grants in place: roles, mail delegations and extra keys added under T1098 survive the disable and return to use on re-enable, or are used by another account.
• Disabling an account that is not the one in use: if the attacker has moved to a service account or created a new account, disabling the first victim is not eviction. Scope the compromise first; see D3-CCSA Credential Compromise Scope Analysis.
• Tipping off the attacker too early: disabling one account while the attacker holds others can prompt them to use the rest. Coordinate eviction of all known footholds at one time.

Framework mapping

Related countermeasures

• Authentication Cache Invalidation (D3-ANCI): removes cached credentials and tokens that let a disabled account keep working.
• Credential Revocation (D3-CR): the other Credential Eviction child, for tokens and keys. Password Rotation (D3-PR), a Credential Hardening technique in D3FEND, covers shared secrets.
• Authentication Event Thresholding (D3-ANET): D3FEND lists Account Locking as one of its possible actions, which is where automatic lockout meets this technique.
• Session Termination (D3-ST): ends sessions that the disable leaves running. The wider picture is in the MITRE D3FEND Guide.

Practitioner checklist

• Keep a store map for every privileged and service account.
• Script and test disable plus revoke actions for each store before an incident.
• Log 4725 and 4722 and identity provider disable and enable events centrally.
• On Linux, disable with an expiry date and review SSH keys, not only passwd -l.
• Revoke sessions and refresh tokens in the same step as the disable.
• Remove attacker-added roles, delegations and keys before any re-enable.
• Search for activity after the disable time and record the result as eviction evidence.
• Alert on unexpected disables of service accounts as possible T1531.
• Keep seasonal and privileged accounts disabled outside approved windows.

Standards and references

• MITRE D3FEND: Account Locking (D3-AL)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-2, IR-4)
• Microsoft Learn: Revoke user access in an emergency in Microsoft Entra ID
• Microsoft Learn: Event 4725, a user account was disabled
• Microsoft Learn: Maximum lifetime for user ticket
• AWS: Revoke IAM role temporary security credentials
• Linux man-pages: passwd(1)

Related NHI Mgmt Group resources: Identity Incident Response Playbook · M1018 User Account Management · Employee Offboarding Security Guide · Global Token Revocation Guide · MITRE D3FEND Guide