D3-ULA Unlock Account: Recovering Safely and Verifying the Restore

An account lockout stops a password guessing run, but every lockout has to end, and the moment of unlocking is when a defender can either restore a legitimate user or hand an attacker a fresh set of attempts. MITRE D3FEND names this step Unlock Account (D3-ULA) and defines it as "Restoring a user account's access to resources by unlocking a locked User Account." It sits under the Restore tactic as the only child of Restore User Account Access (D3-RUAA), which itself sits under Restore Access (D3-RA). This card covers when to unlock automatically and when to unlock by hand, how the main identity platforms do it, how to tell a benign lockout from an attack before unlocking, and how to prove the restore worked. It is written for identity operations teams, service desk leads and incident responders. Lockout policy design itself is covered in the Account Lockout and Brute-Force Protection Guide and the opposite countermeasure in D3-AL Account Locking; this page does not repeat them.

Key takeaways

• Unlock is a recovery action, not a reset. Unlocking clears the lockout state; the password and the factors stay the same. If the lockout came from an attacker who may already know the password, unlocking alone restores the attacker's access too.
• Find the cause before you unlock. On Windows, event 4740 names the caller computer that produced the bad attempts. A stale credential on a phone or a mapped drive, a password spray and a single attacker on a known password all look identical to the user, but need different responses.
• Automatic unlock limits denial of service. Microsoft's guidance notes that a lockout duration of 0, where only an administrator can unlock, lets an attacker keep an account locked indefinitely. Timed unlock plus throttling is the usual balance.
• The unlock path is an attack surface. A help desk that unlocks or resets on a phone call can be talked into restoring access for an impersonator, so caller verification is part of this control.
• Every unlock should leave a record. Windows logs 4767, cloud identity providers write audit events, and those records are what you review to spot unlocks of privileged or dormant accounts.

D3-ULA at a glance

How it works

D3FEND gives D3-ULA a one-line definition and no further how-it-works text, so the practical detail comes from the platforms that implement it. Three unlock modes exist.

• Timed unlock: the lockout expires on its own. In Active Directory the Group Policy setting Account lockout duration (Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy) takes 1 to 99,999 minutes, and Microsoft's recommended value is about 15 minutes. Microsoft Entra smart lockout locks for 60 seconds by default and lengthens the lock after each further failed attempt.
• Self-service unlock: the user proves identity through a separate recovery path. In Entra, choosing "I forgot my password" in self-service password reset sets the remaining lockout to zero; choosing "I know my password" leaves the timer running.
• Administrator unlock: a person or a workflow clears the lock. This is the only path when the AD lockout duration is 0, and the path most often used by service desks.

Because the credential is unchanged, the safety of an unlock depends entirely on the reason for the lockout. That is why the steps below start with diagnosis.

ATT&CK techniques D3FEND relates to D3-ULA

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-ULA. The rows below are relationships D3FEND infers because D3-ULA restores a User Account and these techniques use, create, modify or discover a User Account or one of its sub-types (domain, local, cloud, default). D3FEND labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.

Read the table as a list of situations in which an unlock needs care, not as attacks that unlocking defeats. Lockouts themselves are usually caused by MITRE ATT&CK T1110 Brute Force Guide activity such as password spraying, and deliberate lockouts by an attacker are covered in MITRE ATT&CK T1531 Account Access Removal.

Where it is implemented

Platforms are listed alphabetically; the order is not a ranking.

Availability: Entra custom lockout threshold and duration need Microsoft Entra ID P1 or higher, per Microsoft's documentation as of November 2026.

Hybrid lockout settings

Where Entra uses pass-through authentication against Active Directory, Microsoft's guidance is to keep the Entra lockout threshold lower than the AD threshold (AD at least two to three times higher) and the Entra duration longer than the AD duration, so cloud lockout triggers first and on-premises accounts are not locked by internet-facing attempts. Entra counts duration in seconds and AD in minutes, which is a frequent source of mismatched settings.

Implementation steps

1. Set the default to timed unlock. Use a non-zero lockout duration for standard accounts so a spray cannot keep the workforce locked out, and rely on throttling for protection. NIST SP 800-63B-4 section 3.2.2 caps consecutive failures at no more than 100 per authenticator and suggests increasing wait periods and risk-based checks to reduce legitimate lockouts.
2. Define which accounts need manual review. Privileged accounts, break-glass accounts and service accounts should not simply time out and resume after repeated lockouts. Alert on every 4740 for those accounts, as Microsoft recommends for high-value accounts, and route unlocks through an approval.
3. Diagnose before an administrator unlock. Read the Caller Computer Name in 4740 (or the source IP and client in the cloud sign-in log). If it is the user's own device, look for a stale credential. If it is unknown, outside the domain or one of many accounts locked in the same window, treat it as an attack.
4. Choose unlock or reset. Unlock when the cause is a benign stale credential. Reset the password and review factors when the source is unknown, the account shows MITRE ATT&CK T1078 Valid Accounts Guide signs such as successful sign-ins from new locations, or the password may have leaked.
5. Verify the caller. Service desk unlocks follow the same identity checks as resets: a call-back to a number on record, manager confirmation or a verified self-service path, never knowledge an attacker could find publicly. See the Account Recovery and Help Desk Security Guide.
6. Fix the cause. Remove the stale credential from the device, scheduled task, mapped drive or service configuration, otherwise the account locks again within minutes.
7. Handle mass lockouts as an incident. When many accounts lock at once, contain the source first (block the IP range, disable the exposed endpoint), then unlock in bulk with timed expiry or a scripted unlock, and force resets for any account with a successful sign-in from the attack source.

Where identity fits for service accounts

A locked service account usually means a password was changed in the directory but not in every application, task or connection string that uses it. Unlocking without updating those consumers just restarts the lock cycle, and an outage team under pressure may be tempted to disable lockout for the account instead. Fixing the credential at the source, or moving the workload to a managed identity, is the durable answer. The D3-LAM Local Account Monitoring and D3-DAM Domain Account Monitoring cards cover the monitoring side.

How to verify it works

• Restore test: after an unlock, confirm the user signs in successfully once and the next 4740 for that account does not arrive within the following hour. A repeat lockout means the cause was not fixed.
• Log pairing: every 4767 should match a ticket or an approved workflow. Microsoft recommends monitoring all 4767 events for local accounts; a 4767 with no ticket is a finding.
• Subject check: Microsoft notes that 4740 is normally raised by SYSTEM; report any where the Subject is another account.
• Exercise the path: in a test run, ask the service desk to unlock a test account for a caller who cannot pass verification. The call should be refused and logged.

Limits, bypasses and failure patterns

• Unlocking an attacker: if the lockout came from attempts that included the right password, unlocking restores that access. Reset instead.
• Social engineering the unlock path: attackers who phone the help desk as an employee aim for exactly this kind of restore. In the MGM Resorts Breach 2023 attackers reported that a call to the IT help desk impersonating an employee gave them their way in.
• Manual-only unlock as a denial-of-service lever: a lockout duration of 0 lets anyone who can submit bad passwords keep an account locked until an administrator acts.
• Hybrid mismatch: cloud and directory lockout thresholds set the wrong way round lock on-premises accounts from internet attempts.
• Clearing the symptom: unlocking a service account repeatedly while the stale password remains in a scheduled task.
• No record: unlocks done by a privileged script that does not write to the ticketing system leave no trail beyond 4767, which few teams review.

Framework mapping

Related countermeasures

• Account Locking (D3-AL): the Evict-side action this technique reverses.
• Authentication Event Thresholding (D3-ANET): detects the failure patterns that cause lockouts. See D3-ANET Authentication Event Thresholding.
• Restore User Account Access (D3-RUAA): the parent technique, which also covers re-enabling disabled accounts.
• Multi-factor Authentication (D3-MFA): reduces the damage when an unlock goes to the wrong person. See D3-MFA Multi-factor Authentication.

Practitioner checklist

• Use a non-zero lockout duration for standard accounts.
• Collect 4740 and 4767 from domain controllers, servers and workstations.
• Read the caller computer or source IP before every administrator unlock.
• Reset rather than unlock when the lockout source is unknown or the account shows suspicious sign-ins.
• Apply the same caller verification to unlocks as to password resets.
• Route privileged, break-glass and service account unlocks through approval.
• In hybrid tenants, keep cloud lockout threshold lower and duration longer than on-premises.
• Match every unlock record to a ticket or workflow and review the exceptions.
• Treat many simultaneous lockouts as an incident and contain before restoring.

Standards and references

• MITRE D3FEND: Unlock Account (D3-ULA)
• NIST: SP 800-63B-4 Authentication and Authenticator Management
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft Learn: Event 4740, a user account was locked out
• Microsoft Learn: Event 4767, a user account was unlocked
• Microsoft Learn: Account lockout duration
• Microsoft Learn: Microsoft Entra smart lockout
• Okta Developer: Unlock a user
• Linux manual page: faillock(8)

Related NHI Mgmt Group resources: Account Lockout and Brute-Force Protection Guide · MFA Lockout and Recovery Troubleshooting Guide · Help Desk Identity Verification Policy Template · Active Directory Security Monitoring and Event IDs Guide · MITRE D3FEND Guide