M1036 Account Use Policies: ATT&CK Mitigation Guide

A valid password should not be enough to use an account from any device, at any time, from anywhere, as many times as an attacker likes. MITRE ATT&CK mitigation M1036 Account Use Policies covers the rules that govern how and when accounts can be used: lockout and throttling, logon time and location restrictions, session timeouts, account expiry and conditional access. This guide reads M1036 from the ATT&CK point of view: the 12 techniques and sub-techniques it mitigates in ATT&CK v20, how to implement it for human and service accounts, where ATT&CK's examples differ from current NIST guidance, what it cannot stop and how to measure it. It is for identity, detection and platform teams. Platform lockout settings are covered in depth in the Account Lockout and Brute-Force Protection Guide and policy design in the Conditional Access Guide, which this page links rather than repeats.

Key takeaways

Twelve techniques, one theme. In ATT&CK v20, M1036 mitigates brute force and its sub-techniques, MFA request generation, valid and cloud accounts, alternate authentication material, application-specific passwords, serverless execution and social engineering.
Context beats counting. Lockout thresholds slow password guessing, but ATT&CK's usage text leans just as heavily on conditional access: block sign-ins from non-compliant devices or outside expected networks.
Lockout can be turned against you. ATT&CK warns that too strict a policy can create a denial of service; smart or location-aware lockout and throttling reduce that risk.
Do not copy the 90-day example. ATT&CK's description gives password aging as an example, but NIST SP 800-63B-4 says verifiers shall not require periodic password changes; force a change on evidence of compromise instead.
Service accounts need use policies too. Deny interactive logon, bind credentials to expected hosts and networks, and expire what is unused; most M1036 failures in incidents involve accounts nobody was watching.

What M1036 is

ATT&CK describes M1036 as configuring and enforcing rules that govern how and when accounts can be used, to reduce the risk of brute force, credential theft and unauthorised access. Its description lists five groups of measures with example values:

ATT&CK measure	ATT&CK example	Current practice note
Account lockout	Lock after 3-5 failed attempts for about 15 minutes, or until an administrator unlocks	NIST SP 800-63B-4 sets an upper bound of 100 consecutive failed attempts and allows lower limits; Microsoft's Windows baseline guidance suggests 10 as a starting point
Logon time restrictions	Non-administrative accounts only during business hours, for example 8 AM to 6 PM	Most useful as an alert signal for service and shared accounts with predictable schedules
Inactivity timeout and session termination	Re-authenticate after 10-15 minutes of inactivity	NIST SP 800-63B-4 recommends an AAL2 inactivity timeout of no more than 1 hour and overall reauthentication within 24 hours
Password aging	Change every 90 days with password history	NIST SP 800-63B-4: verifiers shall not require periodic changes, and shall force a change on evidence of compromise; see M1027 Password Policies
Account expiration and deactivation	Expire temporary and contractor accounts; deactivate accounts unused for a set period	Overlaps with M1018 User Account Management

In the per-technique usage text, ATT&CK extends M1036 to conditional access: blocking sign-ins from non-compliant devices or from outside defined organisation IP ranges, matching MFA request locations to the user's device, restricting where application-specific passwords and access tokens can be used, and adding verification to helpdesk resets and app consents.

MITRE D3FEND describes the related defences as Account Locking (D3-AL), Authentication Event Thresholding (D3-ANET), User Geolocation Logon Pattern Analysis (D3-UGLPA) and Session Duration Analysis (D3-SDA).

Techniques M1036 mitigates in ATT&CK v20

Tactic	Technique	How M1036 helps (ATT&CK usage, paraphrased)
Credential Access	T1110 Brute Force	Lockout after a number of failures; conditional access blocking non-compliant devices and unexpected IP ranges; warning that too strict a policy causes denial of service
Credential Access	T1110.001 Password Guessing	As T1110
Credential Access	T1110.003 Password Spraying	As T1110
Credential Access	T1110.004 Credential Stuffing	As T1110
Credential Access	T1621 Multi-Factor Authentication Request Generation	Block login attempts, and the MFA prompts they trigger, from suspicious locations or where the source does not match the MFA device's location
Credential Access	T1697 Steal Application Specific Passwords	Restrict the authentication paths, clients and locations that accounts using app passwords can use
Execution	T1648 Serverless Execution	Restrict who can create serverless workflows, for example conditional access for Power Automate and limits on high-risk OAuth scopes for Google Apps Script
Lateral Movement	T1550 Use Alternate Authentication Material	Restrict use of authentication material outside expected contexts
Lateral Movement	T1550.001 Application Access Token	Restrict token use outside expected contexts, for example AWS data perimeters to prevent use outside expected networks
Stealth	T1684 Social Engineering	Add verification to helpdesk resets, approvals and app consents targeted by impersonation
Initial Access, Persistence, Privilege Escalation, Stealth	T1078 Valid Accounts	Conditional access blocking non-compliant devices and logins from outside organisation IP ranges
Initial Access, Persistence, Privilege Escalation, Stealth	T1078.004 Cloud Accounts	As T1078

The priority order for most organisations is T1110 and its sub-techniques (internet-facing sign-in pages see them constantly), then T1078 and T1078.004 (stolen but valid credentials, where lockout does nothing and context is the only control), then T1550.001 and T1697 (token and app password reuse).

Implementation priorities

Inventory sign-in surfaces. List every place a password or token is accepted: identity provider, on-premises directory, VPN and remote access portals, legacy protocols that use app passwords, and application-local logins. Policies applied only at the identity provider leave the rest open.
Set lockout and throttling per layer. In Windows the settings live under Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy; Microsoft's documentation notes the default threshold is 0 (never lock) and that the built-in Administrator account is excluded. Microsoft Entra smart lockout is on for all tenants, locks after 10 failures by default in public cloud tenants, keeps separate counters for familiar and unfamiliar locations, and ignores repeats of the last three bad passwords. In hybrid pass-through setups Microsoft says the Entra threshold should be lower than the AD DS threshold and the Entra duration longer, so cloud lockout triggers before on-premises accounts lock.
Add context conditions. Block or step up sign-ins from non-compliant devices and unexpected networks for all users, and block legacy authentication paths that cannot enforce them. See the Conditional Access Guide.
Set session limits. Apply inactivity and maximum session lifetimes by risk tier; stricter on administrative portals and remote sessions.
Expire and disable automatically. Set end dates on contractor and temporary accounts at creation, and disable accounts after a defined period without sign-in. See the Orphaned and Dormant Accounts guide.
Harden recovery paths. Require verification for helpdesk password and MFA resets and for high-risk app consent (T1684).

Testing and rollback

Report-only first: run new conditional access policies in report-only mode where the platform supports it, and review which sign-ins would have been blocked.
Exclude and protect break-glass accounts: keep emergency access accounts out of location and device conditions, with strong authenticators and alerting on any use.
Lockout drills: test that a lockout storm against many accounts does not stop operations, and that self-service unlock works.
Rollback: change one policy at a time with a named owner, so a disruptive rule can be switched back to report-only quickly.

Lockout or context: choosing the right control

Control	Stops	Does not stop	Best used for
Hard lockout (fixed threshold)	Online guessing against one account	Spraying below threshold, stuffing with correct passwords, offline cracking	On-premises directories and systems without risk signals
Smart or location-aware lockout, throttling	Guessing while reducing lockout denial of service	Valid stolen credentials	Cloud identity providers and internet-facing logins
Device and network conditions	Valid credentials used from unmanaged devices or unexpected networks	Attackers on a compliant device or inside the network	T1078, T1078.004, T1621
Token and credential use restrictions	Replay of stolen tokens and keys from elsewhere	Abuse from the expected network	T1550.001, T1697, service principals and API keys
Logon hours and session limits	Out-of-hours misuse, unattended sessions	Attacks during permitted windows	Shared, kiosk and service accounts with fixed schedules

Small organisations: rely on the identity provider's built-in lockout, require MFA, block legacy authentication and set a device or country condition for administrators. Large organisations: add tiered conditional access, workload identity conditions, automated account expiry from HR data and SIEM correlation of lockouts across layers.

Service accounts and other non-human identities

M1036 is usually written for people, but service accounts break the assumptions behind it: they rarely trigger MFA, cannot answer a prompt, and often have passwords that never change. NHI Mgmt Group recommends these account use rules for non-human identities:

Deny interactive logon. Assign Windows user rights such as "Deny log on locally" and "Deny log on through Remote Desktop Services" to service accounts, and alert when they log on interactively; see How to detect interactive logons by service accounts.
Bind to expected hosts and networks. Restrict which workstations an account may log on to, and use network conditions on cloud credentials. ATT&CK's T1550.001 usage points to AWS data perimeters, which AWS describes as guardrails ensuring only trusted identities access trusted resources from expected networks; see the AWS Resource Control Policies and Data Perimeter Guide.
Prefer managed credentials. Group managed service accounts remove static passwords that lockout and aging rules were meant to protect; see the Group Managed Service Accounts (gMSA) Guide.
Do not exclude them silently. Service accounts excluded from conditional access are a common blind spot; see How to Find Accounts Excluded From MFA and Conditional Access.
Watch lockouts on service accounts. A locked service account usually means either a stale password on a host or someone guessing; both need investigation, and lockout of a critical service account is a denial of service risk to plan for.

What M1036 does not stop

Correct credentials on the first try. Credential stuffing with a reused password never trips a lockout. In the 23andMe breach, more than 18,000 accounts were accessed with credentials leaked elsewhere, MFA was optional, and a day with over a million login attempts did not trigger an effective response. MFA (M1032 Multi-factor Authentication) and volume-based detection are the controls.
Accounts outside the policy. The Colonial Pipeline attack began with a legacy VPN profile that was no longer used but never disabled, and had no MFA. Expiry and deactivation only work for accounts the policy can see.
Offline password attacks. Microsoft notes lockout does not counter offline attacks on captured hashes.
Attackers inside the expected context. Location and device conditions do not help once the attacker operates from a compliant device or trusted network; session and behaviour analytics are needed.

Detection and measurement

Log: failed and successful sign-ins at every layer (Windows Security events 4625 failed logon and 4740 account locked out, identity provider sign-in logs, VPN and remote access logs), conditional access results, and service account logon types.
Alert on: many accounts failing from one source (spraying), lockouts across many accounts in a short window, sign-ins from dormant accounts, MFA prompts denied repeatedly, service accounts with interactive logons, and tokens used from unexpected networks.

Metric	What good looks like
Share of sign-in surfaces with lockout or throttling enforced	100%, including VPN and legacy endpoints
Accounts excluded from conditional access, by type	Only documented break-glass and reviewed exceptions
Enabled accounts with no sign-in in 90 days	Trending to zero
Temporary and contractor accounts without an end date	Zero
Service accounts permitted interactive logon	Zero outside documented exceptions
Mean time to detect a password spray in authorised tests	Minutes, not days

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	AC-7 Unsuccessful Logon Attempts	Lockout and throttling
NIST SP 800-53 Rev. 5	AC-11 Device Lock; AC-12 Session Termination	Inactivity and session limits
NIST SP 800-53 Rev. 5	AC-2(3) Disable Accounts; AC-2(11) Usage Conditions; AC-2(12) Account Monitoring for Atypical Usage	Expiry, time and location conditions, monitoring
NIST SP 800-63B-4	Rate limiting; password verifiers; reauthentication	Upper bound on failed attempts, no periodic changes, session timeouts
NIST CSF 2.0	PR.AA-05	Access permissions defined, enforced and reviewed
MITRE D3FEND	D3-AL, D3-ANET, D3-UGLPA, D3-SDA	Locking, thresholding, geolocation and session analysis
Related ATT&CK mitigations	M1018, M1026, M1027, M1032, M1035	Account lifecycle, privileged accounts, passwords, MFA, network reachability

Common failure patterns

Lockout only at the identity provider. VPN portals, legacy protocols and application-local logins have no throttling.
Thresholds that lock everyone out. A threshold of 3 on an internet-facing directory lets anyone with a user list lock out the organisation, which ATT&CK itself warns about.
Periodic forced resets kept from old policy. Users choose predictable variants, while compromised passwords are not reset when they leak.
Dormant remote access accounts. Unused VPN and contractor accounts never expire, as in the Colonial Pipeline case.
Blanket exclusions for service accounts. Whole service account groups are excluded from conditional access and never reviewed.

Practitioner checklist

List every sign-in surface and confirm lockout or throttling on each.
Align hybrid lockout so the cloud threshold is lower and its duration longer than on-premises.
Block legacy authentication and restrict app password use to approved clients and locations.
Apply device and network conditions to all users, strictest for administrators.
Set inactivity and maximum session lifetimes by tier.
Set end dates on temporary accounts and auto-disable accounts unused for a defined period.
Deny interactive logon for service accounts and bind them to expected hosts and networks.
Replace periodic password expiry with compromise-driven resets.
Alert on spraying patterns, mass lockouts and dormant account sign-ins.

M1036 Account Use Policies: Limiting When, Where and How Accounts Sign In