M1036: Account Use Policies
Account Use Policies help mitigate unauthorized access by configuring and enforcing rules that govern how and when accounts can be used. These policies include enforcing account lockout mechanisms, restricting login times, and setting inactivity timeouts. Proper configuration of these policies reduces the risk of brute-force attacks, credential theft, and unauthorized access by limiting the opportunities for malicious actors to exploit accounts. This mitigation can be implemented through the following measures:
Account Lockout Policies:
- Implementation: Configure account lockout settings so that after a defined number of failed login attempts (e.g., 3-5 attempts), the account is locked for a specific time period (e.g., 15 minutes) or requires an administrator to unlock it. - Use Case: This prevents brute-force attacks by limiting how many incorrect password attempts can be made before the account is temporarily disabled, reducing the likelihood of an attacker successfully guessing a password.
Login Time Restrictions:
- Implementation: Set up login time policies to restrict when users or groups can log into systems. For example, only allowing login during standard business hours (e.g., 8 AM to 6 PM) for non-administrative accounts. - Use Case: This prevents unauthorized access outside of approved working hours, where login attempts might be more suspicious or harder to monitor. For example, if an account that is only supposed to be active during the day logs in at 2 AM, it should raise an alert or be blocked.
Inactivity Timeout and Session Termination:
- Implementation: Enforce session timeouts after a period of inactivity (e.g., 10-15 minutes) and require users to re-authenticate if they wish to resume the session. - Use Case: This policy prevents attackers from hijacking active sessions left unattended. For example, if an employee walks away from their computer without locking it, an attacker with physical access to the system would be unable to exploit the session.
Password Aging Policies:
- Implementation: Enforce password aging rules, requiring users to change their passwords after a defined period (e.g., 90 days) and ensure passwords are not reused by maintaining a password history. - Use Case: This limits the risk of compromised passwords being used indefinitely. Regular password changes make it more difficult for attackers to reuse stolen credentials.
Account Expiration and Deactivation:
- Implementation: Configure user accounts, especially for temporary or contract workers, to automatically expire after a set date or event. Accounts that remain unused for a specific period should be deactivated automatically. - Use Case: This prevents dormant accounts from becoming an attack vector. For example, an attacker can exploit unused accounts if they are not properly monitored or deactivated.
**Tools for Implementation**:
- Group Policy Objects (GPOs) in Windows: To enforce account lockout thresholds, login time restrictions, session timeouts, and password policies. - Identity and Access Management (IAM) solutions: For centralized management of user accounts, session policies, and automated deactivation of accounts. - Security Information and Event Management (SIEM) platforms: To monitor and alert on unusual login activity, such as failed logins or out-of-hours access attempts. - Multi-Factor Authentication (MFA) Tools: To further enforce secure login attempts, preventing brute-force or credential stuffing attacks.
Analyst context for executives and security teams
Account Use Policies are the guardrails that limit how long accounts, passwords, and sessions remain useful to an attacker. For leaders, this matters because many ATT&CK behaviors tied to this mitigation involve valid accounts, brute force attempts, cloud accounts, tokens, and MFA request abuse—areas where adversaries can look like normal users unless policy and monitoring are disciplined.
Executive priority
Treat this as an identity risk and resilience control, not just a password setting. Executives should ask whether account lockout, login time restrictions, inactivity timeouts, password aging/history, and account expiration are consistently enforced across workforce, administrator, temporary, cloud, and service accounts where applicable. The business decision is balancing access continuity against reducing opportunities for credential theft, password spraying, credential stuffing, dormant account abuse, and unauthorized off-hours access.
Technical view
SOC, IAM, cloud, and IR teams should validate where these policies are actually enforced: Windows Group Policy where used, centralized IAM, identity providers, SIEM monitoring, MFA tooling, and cloud/SaaS account controls where relevant. Relationship context ties this mitigation to Valid Accounts, Cloud Accounts, Brute Force, Password Guessing, Password Spraying, Credential Stuffing, Use Alternate Authentication Material, Application Access Tokens, MFA Request Generation, Serverless Execution, and Social Engineering. Because ATT&CK provides no official detection for M1036, detection engineering should focus on evidence that policies are functioning and on exceptions where valid account use appears inconsistent with expected time, session, failure, or lifecycle rules.
Likely telemetry
- Authentication success and failure events
- Account lockout and unlock events
- Out-of-hours login attempts and blocked logins
- Session timeout, session termination, and re-authentication events
- Password change, password age, and password history enforcement evidence
Detection direction
- Confirm that failed-login thresholds generate observable lockout events and alerts without creating unacceptable operational disruption.
- Tune for password spraying patterns that may avoid per-account lockout by using few attempts across many accounts.
- Correlate successful logins after repeated failures, out-of-hours access, or access from accounts expected to be inactive or expired.
- Separate normal service, administrator, support, and workforce account behavior to reduce false positives and expose unsafe exceptions.
- Monitor repeated MFA request generation as a credential-access signal when MFA is used.
Mitigation priorities
- Start with high-risk identities: administrators, remote access users, cloud accounts, temporary workers, contractors, and dormant accounts.
- Enforce account lockout policies with thresholds and lockout durations appropriate to business operations.
- Apply login time restrictions where roles have predictable access windows, and alert or block access outside those windows when appropriate.
- Enforce inactivity timeouts and session termination to reduce unattended session exposure.
- Use password aging/history controls where required by policy and supported by the environment.
Analyst notes and limits
This object is a mitigation, so the main value is governance, control validation, and telemetry assurance. Its relationship set is identity-heavy and cloud-relevant, especially for Valid Accounts, Cloud Accounts, brute force variants, token abuse, and MFA request generation. The most important local question is not whether a policy exists on paper, but whether it is consistently enforced, logged, exception-managed, and tested across account types.
ATT&CK does not provide an official detection section, tactics, or platforms for this mitigation object. Platform relevance is inferred only from related techniques and should be validated against the organization’s actual identity, cloud, SaaS, and endpoint architecture. This take does not imply active exploitation, attribution, or guaranteed detection coverage.
Account Use Policies
Account Use Policies help mitigate unauthorized access by configuring and enforcing rules that govern how and when accounts can be used. These policies include enforcing account lockout mechanisms, restricting login times, and setting inactivity timeouts. Proper configuration of these policies reduces the risk of brute-force attacks, credential theft, and unauthorized access by limiting the opportunities for malicious actors to exploit accounts. This mitigation can be implemented through the following measures:
Account Lockout Policies:
- Implementation: Configure account lockout settings so that after a defined number of failed login attempts (e.g., 3-5 attempts), the account is locked for a specific time period (e.g., 15 minutes) or requires an administrator to unlock it. - Use Case: This prevents brute-force attacks by limiting how many incorrect password attempts can be made before the account is temporarily disabled, reducing the likelihood of an attacker successfully guessing a password.
Login Time Restrictions:
- Implementation: Set up login time policies to restrict when users or groups can log into systems. For example, only allowing login during standard business hours (e.g., 8 AM to 6 PM) for non-administrative accounts. - Use Case: This prevents unauthorized access outside of approved working hours, where login attempts might be more suspicious or harder to monitor. For example, if an account that is only supposed to be active during the day logs in at 2 AM, it should raise an alert or be blocked.
Inactivity Timeout and Session Termination:
- Implementation: Enforce session timeouts after a period of inactivity (e.g., 10-15 minutes) and require users to re-authenticate if they wish to resume the session. - Use Case: This policy prevents attackers from hijacking active sessions left unattended. For example, if an employee walks away from their computer without locking it, an attacker with physical access to the system would be unable to exploit the session.
Password Aging Policies:
- Implementation: Enforce password aging rules, requiring users to change their passwords after a defined period (e.g., 90 days) and ensure passwords are not reused by maintaining a password history. - Use Case: This limits the risk of compromised passwords being used indefinitely. Regular password changes make it more difficult for attackers to reuse stolen credentials.
Account Expiration and Deactivation:
- Implementation: Configure user accounts, especially for temporary or contract workers, to automatically expire after a set date or event. Accounts that remain unused for a specific period should be deactivated automatically. - Use Case: This prevents dormant accounts from becoming an attack vector. For example, an attacker can exploit unused accounts if they are not properly monitored or deactivated.
**Tools for Implementation**:
- Group Policy Objects (GPOs) in Windows: To enforce account lockout thresholds, login time restrictions, session timeouts, and password policies. - Identity and Access Management (IAM) solutions: For centralized management of user accounts, session policies, and automated deactivation of accounts. - Security Information and Event Management (SIEM) platforms: To monitor and alert on unusual login activity, such as failed logins or out-of-hours access attempts. - Multi-Factor Authentication (MFA) Tools: To further enforce secure login attempts, preventing brute-force or credential stuffing attacks.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1648 | Serverless Execution | Where possible, consider restricting access to and use of serverless functions. For examples, conditional access policies can be applied to users attempting to create workflows in Microsoft Power Automate. Google Apps Scripts that use OAuth can be limited by restricting access to high-risk OAuth scopes.CitationMicrosoft Developer Support Power Apps Conditional AccessCitationGoogle Workspace Apps Script Restrict OAuth Scopes |
| Enterprise | T1550.001 | Application Access Token Sub-technique | Where possible, consider restricting the use of access tokens outside of expected contexts. For example, in AWS environments, consider using data perimeters to prevent credential use outside of an expected network.CitationAWS Data Perimeters |
| Enterprise | T1684 | Social Engineering | Adds verification for helpdesk resets, approvals, and app consents commonly targeted by impersonation.CitationSE SentinelOne 2CitationSE - Hackers Target Workday |
| Enterprise | T1110.004 | Credential Stuffing Sub-technique | Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. Too strict a policy may create a denial of service condition and render environments un-usable, with all accounts used in the brute force being locked-out. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies Consider blocking risky authentication requests, such as those originating from anonymizing services/proxies.CitationOkta Block Anonymizing Services |
| Enterprise | T1550 | Use Alternate Authentication Material | Where possible, consider restricting the use of authentication material outside of expected contexts. |
| Enterprise | T1110.001 | Password Guessing Sub-technique | Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. Too strict a policy may create a denial of service condition and render environments un-usable, with all accounts used in the brute force being locked-out. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies Consider blocking risky authentication requests, such as those originating from anonymizing services/proxies.CitationOkta Block Anonymizing Services |
| Enterprise | T1621 | Multi-Factor Authentication Request Generation | Enable account restrictions to prevent login attempts, and the subsequent 2FA/MFA service requests, from being initiated from suspicious locations or when the source of the login attempts do not match the location of the 2FA/MFA smart device. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies |
| Enterprise | T1078.004 | Cloud Accounts Sub-technique | Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies |
| Enterprise | T1110 | Brute Force | Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. Too strict a policy may create a denial of service condition and render environments un-usable, with all accounts used in the brute force being locked-out. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies Consider blocking risky authentication requests, such as those originating from anonymizing services/proxies.CitationOkta Block Anonymizing Services |
| Enterprise | T1110.003 | Password Spraying Sub-technique | Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. Too strict a policy may create a denial of service condition and render environments un-usable, with all accounts used in the brute force being locked-out. Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies Consider blocking risky authentication requests, such as those originating from anonymizing services/proxies.CitationOkta Block Anonymizing Services |
| Enterprise | T1078 | Valid Accounts | Use conditional access policies to block logins from non-compliant devices or from outside defined organization IP ranges.CitationMicrosoft Common Conditional Access Policies |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 05d9edb983f5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M1036Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.