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]
Security context for executives and security teams
M0800: Authorization Enforcement describes 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 (Citation: International Electrotechnical Commission July 2020), while IEEE 1686 defines stand...
Executive priority
M0800: Authorization Enforcement is an official MITRE ATT&CK mitigation. Glexia treats it as defensive behavior context for prioritizing monitoring, control validation, and response planning without using the object by itself as an attribution claim.
Technical view
Security teams should validate M0800: Authorization Enforcement by reviewing the official ATT&CK relationships, mapped tactics (the mapped ATT&CK tactic context), supported platforms (the platforms named in the official object), and available local telemetry before making detection or mitigation decisions.
Likely telemetry
- Official ATT&CK relationships and object metadata
Detection direction
- Validate whether M0800: Authorization Enforcement appears in your detection coverage and tabletop scenarios.
- Use the object to align executive risk language with SOC, incident response, and detection engineering work.
- Do not treat ATT&CK relationship context as attribution without corroborating evidence.
Mitigation priorities
- Map the object to existing controls and identify missing telemetry or response ownership.
- Prioritize mitigations that reduce exposure on the listed platforms and tactics.
- Review adjacent ATT&CK relationships before changing policy, detections, or reporting language.
Additional notes and limits
Baseline Glexia take generated from the official MITRE ATT&CK STIX object, source hash, tactics, platforms, and detection fields. It is safe to replace with a richer model-generated take for the same source hash later.
This baseline take is source-grounded and schema-validated, but it does not include environment-specific telemetry, incident evidence, or threat-intelligence corroboration.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
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 AllSub-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 AppendSub-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 EditSub-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(2)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.2 | 1.2 | Current bundle | e15d0157714f… | ||
| 19.1 | 1.2 | Older 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-attackM0800Open 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.