M0813: Software Process and Device Authentication
Require the authentication of devices and software processes where appropriate. Devices that connect remotely to other systems should require strong authentication to prevent spoofing of communications. Furthermore, software processes should also require authentication when accessing APIs.
Analyst context for executives and security teams
Software Process and Device Authentication is an ICS mitigation focused on making sure devices and software processes prove who they are before they connect, communicate remotely, or access APIs. For leaders, the value is reducing the chance that a spoofed device, rogue master, unauthorized message, or unauthenticated engineering action can affect industrial operations.
Executive priority
Prioritize this where remote device connectivity, controller APIs, engineering workstations, wireless access, firmware update functions, or program upload/download workflows could affect safety, uptime, or process integrity. It also supports compliance evidence mapped by ATT&CK to IEC 62443 SR/CR 1.2 and NIST SP 800-53 IA-3, but local proof is required: asset inventories, authentication requirements, exceptions, and logs showing enforcement.
Technical view
SOC, OT engineering, and IR teams should validate where ICS devices and software processes authenticate before remote communication or API access. Relationship context makes this especially relevant to firmware update mode, controller restart/shutdown, program download/upload, operating mode changes, rogue master activity, wireless compromise, unauthorized command/reporting messages, and firmware modification. ATT&CK does not provide detection guidance for M0813, so teams should test whether authentication failures, successful privileged sessions, API calls, engineering software actions, and device-to-device communication events are observable and attributable to approved assets/processes.
Likely telemetry
- Device authentication success and failure logs for remote connections
- API access logs for software processes interacting with controllers or ICS services
- Engineering workstation and vendor programming software activity logs
- PLC/controller events for program upload, download, append, online edit, mode change, restart/shutdown, and firmware update mode
- Network traffic or protocol metadata showing device-to-device and master/outstation communications
Detection direction
- Confirm logs can distinguish authenticated approved devices/processes from unauthenticated, unknown, or spoofed sources.
- Tune for authentication failures followed by successful access, especially around controller API calls, remote services, engineering software use, firmware update workflows, and program transfer actions.
- Correlate device/process authentication with change-control windows to reduce false positives from legitimate maintenance.
- Look for communication patterns inconsistent with expected masters, outstations, engineering workstations, or approved remote services.
- Treat missing authentication telemetry as a coverage gap; ATT&CK provides no official detection text for this mitigation.
Mitigation priorities
- Inventory devices, software processes, APIs, remote services, and wireless paths that can communicate with ICS assets.
- Require strong authentication for remote device communications and software process access to APIs where appropriate, as stated by ATT&CK.
- Prioritize enforcement around functions tied to high-consequence relationships: firmware updates, program download/upload, operating mode changes, restart/shutdown, alarm changes, and command/reporting messages.
- Remove or formally document exceptions where legacy systems cannot support authentication, and compensate with segmentation, restricted access paths, and monitoring.
- Maintain audit evidence aligned to IEC 62443-3-3 SR 1.2, IEC 62443-4-2 CR 1.2, and NIST SP 800-53 IA-3 mappings supplied by ATT&CK.
Analyst notes and limits
This is a mitigation object, not a technique. Its decision value is in governance and validation: can the organization prove that only authenticated devices and authenticated software processes can perform sensitive ICS communication and API actions? Relationship context shows broad relevance across unauthorized messaging, rogue master behavior, program transfer, operating mode, remote services, wireless access, and firmware-related activity.
ATT&CK lists no platforms, tactics, or official detection guidance for M0813. The supplied data does not specify products, protocols, authentication mechanisms, or deployment patterns. Local architecture, device capability, vendor documentation, and engineering change processes are required to determine feasible enforcement and monitoring.
Software Process and Device Authentication
Require the authentication of devices and software processes where appropriate. Devices that connect remotely to other systems should require strong authentication to prevent spoofing of communications. Furthermore, software processes should also require authentication when accessing APIs.
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 | T0843 | Program Download | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0845 | Program Upload | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0848 | Rogue Master | Devices should authenticate all messages between master and outstation assets. |
| ICS | T0868 | Detect Operating Mode | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0843.003 | Program Append Sub-technique | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T1692.001 | Command Message Sub-technique | Devices should authenticate all messages between master and outstation assets. |
| ICS | T0860 | Wireless Compromise | Ensure wireless networks require the authentication of all devices, and that all wireless devices also authenticate network infrastructure devices (i.e., mutual authentication). For defense-in-depth purposes, utilize VPNs or ensure that application-layer protocols also authenticate the system or device. Use protocols that provide strong authentication (e.g., IEEE 802.1X), and enforce basic protections, such as MAC filtering, when stronger cryptographic techniques are not available. |
| ICS | T0886 | Remote Services | All communication sessions to remote services should be authenticated to prevent unauthorized access. |
| ICS | T0838 | Modify Alarm Settings | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0830 | Adversary-in-the-Middle | To protect against AiTM, authentication mechanisms should not send credentials across the network in plaintext and should also implement mechanisms to prevent replay attacks (such as nonces or timestamps). Challenge-response based authentication techniques that do not directly send credentials over the network provide better protection from AiTM. |
| ICS | T0800 | Activate Firmware Update Mode | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0858 | Change Operating Mode | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T1693.001 | System Firmware Sub-technique | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0861 | Point & Tag Identification | Devices should authenticate all messages between master and outstation assets. |
| ICS | T1692 | Unauthorized Message | Devices should authenticate all messages between master and outstation assets. |
| ICS | T1693 | Modify Firmware | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0843.001 | Download All Sub-technique | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T0806 | Brute Force I/O | Devices should authenticate all messages between master and outstation assets. |
| ICS | T0843.002 | Online Edit Sub-technique | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T1692.002 | Reporting Message Sub-technique | Devices should authenticate all messages between master and outstation assets. |
| ICS | T0816 | Device Restart/Shutdown | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
| ICS | T1693.002 | Module Firmware Sub-technique | Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions. |
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.2 | Current bundle | 0b2f0c787d05… |
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 M0813Open 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.