M0800: Authorization Enforcement
The device or system should restrict read, manipulate, or execute privileges to only authenticated users who require access based on approved security policies. Role-based Access Control (RBAC) schemes can help reduce the overhead of assigning permissions to the large number of devices within an ICS. For example, IEC 62351 provides examples of roles used to support common system operations within the electric power sector [1], while IEEE 1686 defines standard permissions for users of IEDs. [2]
Analyst context for executives and security teams
Authorization Enforcement is a foundational ICS control: only authenticated users with an approved need should be able to read, manipulate, or execute functions on control devices and systems. Its business value is reducing the chance that routine engineering capabilities—such as program downloads, online edits, mode changes, parameter changes, alarm changes, restarts, or remote service use—become paths to process disruption or unsafe operating conditions.
Executive priority
Treat this as an operational resilience and compliance priority, not just an IT access-control task. The ATT&CK mapping ties authorization enforcement to many high-consequence ICS behaviors, including controller program modification, firmware update mode, device shutdown/restart, alarm setting changes, and remote services. Leaders should ask whether roles and privileges for operators, engineers, maintainers, and remote users are formally approved, periodically reviewed, and aligned with IEC 62443 and NIST AC-3 evidence expectations.
Technical view
SOC, IR, and OT engineering teams should validate whether ICS devices and supporting systems enforce role-based access control for read, manipulate, and execute privileges. Priority review areas include permissions for PLC/controller program upload/download, online edit, program append, operating mode changes, parameter and alarm modifications, API-accessible functions, remote services, and firmware update mode. Because ATT&CK provides no official detection text for M0800, local validation must focus on whether privilege decisions and privileged actions are logged, attributable to authenticated users, and reviewable during incidents.
Likely telemetry
- Authentication and authorization logs from ICS devices, control applications, and supporting systems
- User, role, and permission configuration records for operators, engineers, administrators, and remote users
- Engineering workstation activity related to program upload, download, online edit, program append, and controller tasking changes
- Controller or device event logs for operating mode changes, restart/shutdown, firmware update mode, parameter changes, and alarm setting changes
- Remote service access logs for mechanisms used to administer or interact with ICS assets
Detection direction
- Confirm that privileged ICS actions are attributable to authenticated users rather than shared or unauthenticated access paths.
- Tune reviews around high-risk actions mapped by ATT&CK relationships: program modification, controller tasking changes, parameter and alarm changes, mode changes, device restart/shutdown, firmware update mode, and remote services.
- Compare device/system authorization events with approved change windows and work orders to reduce false positives from legitimate maintenance.
- Look for blind spots where legacy devices, engineering tools, APIs, or network protocol commands can perform sensitive functions without centralized authorization logging.
- Validate that read access is also governed where program upload, point/tag identification, or operating mode discovery could expose process knowledge.
Mitigation priorities
- Define approved ICS roles and least-privilege permissions for read, manipulate, and execute actions.
- Use role-based access control where supported to reduce permission-management overhead across many ICS devices.
- Restrict high-risk engineering functions—program download, online edit, program append, operating mode changes, parameter changes, alarm changes, restart/shutdown, and firmware update mode—to authenticated users with an approved operational need.
- Align authorization policy and evidence collection with the supplied control references: IEC 62443-3-3 SR 2.1, IEC 62443-4-2 CR 2.1, and NIST SP 800-53 Rev. 5 AC-3.
- Periodically review user-role assignments, especially for remote services and engineering workstations that can interact with controllers.
Analyst notes and limits
This mitigation is especially material in ICS because many dangerous outcomes can result from normal built-in device functions when used by the wrong user or outside an approved change process. Relationship context shows broad defensive relevance across controller modification, operational mode control, remote services, and process-visibility behaviors.
MITRE does not provide official detection guidance, platforms, or tactics for this mitigation. The effectiveness of this control depends on local device capabilities, engineering tool behavior, authentication design, logging availability, and the organization’s change-management process.
Authorization Enforcement
The device or system should restrict read, manipulate, or execute privileges to only authenticated users who require access based on approved security policies. Role-based Access Control (RBAC) schemes can help reduce the overhead of assigning permissions to the large number of devices within an ICS. For example, IEC 62351 provides examples of roles used to support common system operations within the electric power sector [1], while IEEE 1686 defines standard permissions for users of IEDs. [2]
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 | T0861 | Point & Tag Identification | Systems and devices should restrict access to any data with potential confidentiality concerns, including point and tag information. |
| ICS | T0843.001 | Download All Sub-technique | ll field controllers should restrict the download of programs, including online edits and program appends, to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0821 | Modify Controller Tasking | All field controllers should restrict the modification of controller tasks to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0886 | Remote Services | Provide privileges corresponding to the restriction of a GUI session to control system operations (examples include HMI read-only vs. read-write modes). Ensure local users, such as operators and engineers, are giving prioritization over remote sessions and have the authority to regain control over a remote session if needed. Prevent remote access sessions (e.g., RDP, VNC) from taking over local sessions, especially those used for ICS control, especially HMIs. |
| ICS | T0845 | Program Upload | All field controllers should restrict program uploads to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0838 | Modify Alarm Settings | Only authorized personnel should be able to change settings for alarms. |
| ICS | T0816 | Device Restart/Shutdown | All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0871 | Execution through API | All APIs used to perform execution, especially those hosted on embedded controllers (e.g., PLCs), should provide adequate authorization enforcement of user access. Minimize user's access to only required API calls. CitationMITRE June 2020 |
| ICS | T0843.003 | Program Append Sub-technique | ll field controllers should restrict the download of programs, including online edits and program appends, to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0843.002 | Online Edit Sub-technique | ll field controllers should restrict the download of programs, including online edits and program appends, to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0843 | Program Download | All field controllers should restrict the download of programs, including online edits and program appends, to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0868 | Detect Operating Mode | All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0889 | Modify Program | All field controllers should restrict the modification of programs to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. |
| ICS | T0836 | Modify Parameter | All field controllers should restrict the modification of parameter values to only certain users (e.g., engineers, field technician), preferably through implementing a role-based access mechanism. They should also restrict online edits and enable write protection for parameters. |
| ICS | T0858 | Change Operating Mode | All field controllers should restrict operating mode changes to only required authenticated users (e.g., engineers, field technicians), preferably through implementing a role-based access mechanism. Further, physical mechanisms (e.g., keys) can also be used to limit unauthorized operating mode changes. |
| ICS | T0800 | Activate Firmware Update Mode | Restrict configurations changes and firmware updating abilities to only authorized individuals. |
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 | e15d0157714f… |
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]
International Electrotechnical Commission July 2020
International Electrotechnical Commission 2020, July 17 IEC 62351 - Power systems management and associated information exchange - Data and communications security Retrieved. 2020/09/17
Open source URL -
[2]
Institute of Electrical and Electronics Engineers January 2014
Institute of Electrical and Electronics Engineers 2014, January 1686-2013 - IEEE Standard for Intelligent Electronic Devices Cyber Security Capabilities Retrieved. 2020/09/17
Open source URL -
[3]
mitre-attack M0800Open 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.