M0932: Multi-factor Authentication
Use two or more pieces of evidence to authenticate to a system; such as username and password in addition to a token from a physical smart card or token generator. Within industrial control environments assets such as low-level controllers, workstations, and HMIs have real-time operational control and safety requirements which may restrict the use of multi-factor.
Analyst context for executives and security teams
Multi-factor Authentication is a high-value ICS control because stolen or default credentials can otherwise become a direct path into remote access services and operational systems. In control environments, MFA is not just an identity improvement; it is a resilience decision that must be balanced against real-time operational and safety constraints on controllers, workstations, and HMIs.
Executive priority
Prioritize MFA where compromise would create the highest business and operational risk: external remote services, vendor or administrator access, and accounts with access to control system resources. Leaders should ask where MFA is enforced, where it is technically or operationally restricted, and what compensating evidence exists for audit alignment with IEC 62443 SR/CR 1.7 and NIST SP 800-53 IA-2.
Technical view
ATT&CK lists this mitigation for External Remote Services, Network Sniffing, and Valid Accounts in ICS. SOC, IR, and identity teams should validate that remote service gateways such as VPN or Citrix-style access paths require MFA, that privileged and service account usage is reviewed, and that MFA gaps around HMIs, workstations, and lower-level control assets are documented with operational justification. No official ATT&CK detection guidance is provided for this mitigation, so coverage must be proven through local authentication, remote access, and MFA control evidence.
Likely telemetry
- Remote access gateway authentication logs
- MFA enrollment, challenge, approval, denial, and bypass records
- Identity provider and directory authentication logs
- Privileged account and service account usage records
- VPN, Citrix, or other external remote service connection logs
Detection direction
- Validate that successful external remote service logins include MFA evidence, not only password authentication.
- Monitor for accounts accessing ICS resources without MFA where MFA is expected or required.
- Review MFA bypass, exception, recovery, and enrollment changes as high-risk identity events.
- Correlate remote access activity with privileged or service account use to identify credential misuse risk.
- Treat network sniffing context conservatively: MFA does not stop traffic capture, but it can reduce the value of captured reusable credentials.
Mitigation priorities
- Start with MFA enforcement on external remote services used to reach ICS networks or resources.
- Prioritize privileged users, vendor access, and accounts tied to control system administration.
- Identify default, shared, and service accounts and determine where MFA is feasible versus where account redesign or compensating controls are needed.
- Document operational and safety constraints for low-level controllers, workstations, and HMIs before enforcing MFA directly on those assets.
- Maintain exception records, periodic access reviews, and compliance evidence for the referenced IEC 62443 and NIST identity control mappings.
Analyst notes and limits
This is a mitigation object, not a technique. Its main decision value is identity assurance for ICS access paths, especially remote services and valid account abuse. The relationship to Network Sniffing should be interpreted as reducing credential reuse risk rather than preventing packet capture itself.
ATT&CK provides no platform list, tactics, aliases, or official detection text for this object. Local architecture, remote access design, asset criticality, and operational safety requirements are required to decide where MFA can be enforced and where compensating controls are necessary.
Multi-factor Authentication
Use two or more pieces of evidence to authenticate to a system; such as username and password in addition to a token from a physical smart card or token generator. Within industrial control environments assets such as low-level controllers, workstations, and HMIs have real-time operational control and safety requirements which may restrict the use of multi-factor.
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 | T0842 | Network Sniffing | Use multi-factor authentication wherever possible. |
| ICS | T0859 | Valid Accounts | Integrating multi-factor authentication (MFA) as part of organizational policy can greatly reduce the risk of an adversary gaining access to valid credentials that may be used for additional tactics such as initial access, lateral movement, and collecting information. MFA can also be used to restrict access to cloud resources and APIs. |
| ICS | T0822 | External Remote Services | Use strong multi-factor authentication for remote service accounts to mitigate an adversary's ability to leverage stolen credentials. Be aware of multi-factor authentication interception techniques for some implementations. |
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 | 6c5ba54517e1… |
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 M0932Open 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.