M0936: Account Use Policies
Configure features related to account use like login attempt lockouts, specific login times, etc.
Analyst context for executives and security teams
Account Use Policies is an ICS ATT&CK mitigation focused on configuring account-use controls such as login attempt lockouts and allowed login times. Its business value is reducing the chance that stolen, default, or externally used credentials become an easy path into control-system environments, especially where remote access services are used for administration or vendor connectivity.
Executive priority
Prioritize this as an identity and remote-access resilience control for ICS environments. Leaders should ask whether critical operational accounts, remote service access, and vendor or administrative logins have enforceable use limits that can be shown as audit evidence. The strongest business case is reducing exposure from Valid Accounts and External Remote Services without relying only on post-compromise detection.
Technical view
For SOC, IAM, OT, and IR teams, validate whether account policies are actually enforced on systems and remote access paths relevant to ICS administration. The relationship context points to two key risk areas: external remote services such as VPN, Citrix, or other access gateways, and valid or default credentials used to bypass access controls. Because ATT&CK provides no detection text for this mitigation, teams should treat this as a control-validation item rather than a detection rule by itself.
Likely telemetry
- Authentication success and failure logs
- Account lockout events
- Remote access gateway authentication logs
- VPN, Citrix, or similar external remote service logs where present
- Account policy configuration evidence
Detection direction
- Confirm that failed-login, lockout, and remote-service authentication events are collected from systems that control access to ICS resources.
- Review whether alerting distinguishes normal operational login failures from repeated attempts against privileged, vendor, service, or remote-access accounts.
- Look for blind spots where external remote services authenticate users but logs are not forwarded to the SOC or are not correlated with ICS asset access.
- Because no official ATT&CK detection guidance is provided, use local baselines, access policy evidence, and incident history to define meaningful thresholds.
Mitigation priorities
- Inventory accounts used for ICS administration, remote access, vendor support, service functions, and privileged operations.
- Configure account-use controls such as login attempt lockouts and specific allowed login times where operationally appropriate.
- Apply these policies first to externally reachable remote access paths and accounts with access to control-system resources.
- Review default or shared account exposure in the context of Valid Accounts risk.
- Maintain evidence of account policy settings for compliance mappings noted by ATT&CK, including IEC 62443 SR/CR 1.11 and NIST SP 800-53 IA-5.
Analyst notes and limits
This mitigation is most decision-relevant when tied to remote access governance and credential-risk reduction in ICS. It should be assessed jointly by OT operations, IAM, remote access owners, and SOC/IR teams because overly aggressive lockout settings can affect operational availability, while weak policies can leave remote services and valid accounts exposed.
The supplied ATT&CK object does not specify platforms, tactics, or official detection guidance. It also does not identify particular products, adversaries, or active exploitation. Local architecture, operational constraints, and authentication logging determine how this mitigation should be implemented and measured.
Account Use Policies
Configure features related to account use like login attempt lockouts, specific login times, etc.
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 |
|---|---|---|---|
| ICS | T0822 | External Remote Services | Configure features related to account use like login attempt lockouts, specific login times, and password strength requirements as examples. Consider these features as they relate to assets which may impact safety and availability. CitationKeith Stouffer May 2015 |
| ICS | T0859 | Valid Accounts | Configure features related to account use like login attempt lockouts, specific login times, and password strength requirements as examples. Consider these features as they relate to assets which may impact safety and availability. CitationKeith Stouffer May 2015 |
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.0 | Current bundle | 5ca7f8edcc6d… |
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 M0936Open 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.