M0813: Software Process and Device Authentication

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.

Additional 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.

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Official MITRE ATT&CK definition

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.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

Filter related techniques22 rows

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 AppendSub-technique	Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.
ICS	T1692.001	Command MessageSub-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 FirmwareSub-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 AllSub-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 EditSub-technique	Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.
ICS	T1692.002	Reporting MessageSub-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 FirmwareSub-technique	Authenticate connections from software and devices to prevent unauthorized systems from accessing protected management functions.

Relationship explorer

All related ATT&CK context

Change history

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.

ATT&CK release: 19.1
Object version: 1.2
Created: Jun 6, 2019, 21:16 UTC (UTC+00:00)
Modified: May 12, 2026, 15:12 UTC (UTC+00:00)
Raw hash: 0b2f0c787d05cb6f...

Imported snapshots across ATT&CK releases(1)

Release	Bundle imported	Object version	Modified	Status	Raw hash
19.1	Jul 14, 2026, 09:14 UTC (UTC+00:00)	1.2	May 12, 2026, 15:12 UTC (UTC+00:00)	Current bundle	`0b2f0c787d05…`

Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

[1]
mitre-attackM0813
Open source URL

Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use