M0927: Password Policies
Set and enforce secure password policies for accounts.
Analyst context for executives and security teams
Password Policies is an ICS ATT&CK mitigation focused on setting and enforcing secure passwords for accounts. Its business value is highest where remote access, vendor access, shared operational accounts, or device-default credentials could let an intruder enter or move through control system environments using legitimate logins rather than malware.
Executive priority
Treat this as a foundational identity and operational resilience control for ICS. Leaders should ask whether password rules are consistently enforced across remote service gateways, operator workstations, engineering systems, and control system devices, and whether exceptions are documented for equipment that cannot support modern password controls. The mapped relationships make this especially relevant to remote access risk, valid-account abuse, default credentials, and scenarios where adversaries change credentials to block operator or responder access. The listed IEC 62443 and NIST IA-5 mappings also make password policy evidence useful for compliance readiness.
Technical view
SOC, IR, IAM, and OT security teams should validate that password policy requirements are actually applied to the account types and access paths implicated by the related techniques: External Remote Services, Valid Accounts, Remote Services, Change Credential, and Default Credentials. Because ATT&CK provides no detection text and no platform scope for this mitigation, local architecture determines the validation plan. Prioritize accounts used for VPN/Citrix-like remote access, RDP/SMB/SSH-like internal remote services, device management interfaces, vendor/supplier accounts, and any default or built-in credentials on control system devices.
Likely telemetry
- Authentication logs for remote access services and gateways
- Account creation, password change, and password reset records
- Directory or identity provider password policy configuration and audit logs
- Control system device management and configuration logs where available
- Remote service login records for administrative protocols such as RDP, SMB, SSH, or equivalent local services
Detection direction
- Do not treat password policy existence as detection coverage; ATT&CK provides no official detection guidance for this mitigation.
- Validate whether failed logon spikes, repeated account lockouts, unusual password changes, and successful remote logons are collected and reviewable for ICS-relevant accounts.
- Tune monitoring around legitimate operations and vendor maintenance windows to reduce false positives while still preserving evidence of abnormal credential use.
- Correlate password-change events with remote access activity, especially where credential changes could prevent operator or responder access.
- Maintain visibility into default and built-in accounts; the major blind spot is assuming policy applies to embedded or vendor-managed devices when it may not.
Mitigation priorities
- Define minimum password requirements and enforcement scope for ICS user, service, administrative, vendor, and device accounts.
- Remove or change default credentials where the device or vendor process permits it, and document exceptions where credentials cannot be changed.
- Apply policy controls first to externally reachable remote services and administrative remote access paths, then extend to internal remote services and device management interfaces.
- Establish controlled processes for password rotation, emergency access, and credential recovery so policy enforcement does not create operational lockout risk.
- Keep audit-ready evidence mapped to the supplied control references: IEC 62443-3-3 SR 1.5, IEC 62443-4-2 CR 1.5, and NIST SP 800-53 Rev. 5 IA-5.
Analyst notes and limits
This mitigation is simple but material in ICS because several related techniques depend on legitimate credentials rather than exploit activity. The decision point for defenders is not whether a written password policy exists, but whether it is enforceable across remote access, valid accounts, remote services, default credentials, and device-management paths.
The ATT&CK object provides only a brief mitigation description, no official detection text, no specified platforms, and no tactics. Recommendations therefore remain control-validation oriented and require local asset inventory, identity architecture, and OT device capability evidence.
Password Policies
Set and enforce secure password policies for accounts.
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 | T1694.001 | Default Credentials Sub-technique | Review vendor documents and security alerts for potentially unknown or overlooked default credentials within existing devices. |
| ICS | T0886 | Remote Services | Enforce strong password requirements to prevent password brute force methods for lateral movement. |
| ICS | T0892 | Change Credential | Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment.CitationCISA June 2013 |
| ICS | T0822 | External Remote Services | Set and enforce secure password policies for accounts. |
| ICS | T0859 | Valid Accounts | Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. CitationCISA June 2013 |
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 | 30c02a0a4e39… |
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 M0927Open 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.