{ "version": "2026-08-04", "licence": "CC BY 4.0 for the original commentary; see attribution for ATT&CK content", "attribution": "© 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation.", "attackVersion": "ATT&CK for ICS v19 (April 2026)", "note": "MITRE ATT&CK for ICS techniques re-cut for asset owners: placed on the Purdue model, expressed as operational consequences, and mapped to IEC 62443 foundational requirements. This is a curated asset-owner subset, not a mirror of the full matrix; see attack.mitre.org for the canonical and complete set. ATT&CK technique IDs and names are used as references under MITRE's Terms of Use. IEC 62443 is copyrighted: FR numbers and short names are identifiers and no requirement text is reproduced.", "lastReviewed": "2026-08-04", "sources": [ { "label": "MITRE ATT&CK for ICS matrix", "url": "https://attack.mitre.org/matrices/ics/" }, { "label": "MITRE ATT&CK Terms of Use", "url": "https://attack.mitre.org/resources/terms-of-use/" } ], "zones": [ { "id": "l5-4", "level": "5 / 4", "name": "Enterprise and business network", "what": "Corporate IT: email, ERP, the domain, the things a phishing email lands in.", "stakes": "Not OT, and the origin of most OT incidents anyway. Almost every published ICS intrusion began here and moved down, which is why an OT programme that starts at the firewall has already conceded the entry point." }, { "id": "l35", "level": "3.5", "name": "Industrial DMZ", "what": "The brokered boundary: historian replicas, jump hosts, patch and antivirus relays, remote access brokers.", "stakes": "The single most consequential zone in the model, because it is where the two networks are permitted to touch. It is also where 'temporary' exceptions accumulate and are never removed." }, { "id": "l3", "level": "3", "name": "Site operations", "what": "Historians, engineering workstations, domain services for the plant, patch management.", "stakes": "The engineering workstation is the crown jewel: it holds the project files and the ability to push logic to controllers. Compromise here is compromise of everything beneath it." }, { "id": "l2", "level": "2", "name": "Supervisory control", "what": "HMIs, SCADA servers, alarm and operator displays.", "stakes": "Where loss of view happens. An operator who cannot trust the screen is operating blind, and blind operation is where good crews make reasonable decisions that turn out to be wrong." }, { "id": "l1", "level": "1", "name": "Basic control", "what": "PLCs, RTUs, DCS controllers, IEDs.", "stakes": "Where loss of control happens. Logic changes here move physical things, and many of these devices authenticate nothing and log almost nothing." }, { "id": "l0", "level": "0", "name": "Process", "what": "Sensors, actuators, valves, drives, the physical process itself.", "stakes": "Where consequence becomes physical and irreversible. Nothing at this level can be patched, restored from backup, or rolled back." }, { "id": "safety", "level": "SIS", "name": "Safety instrumented systems", "what": "The independent protective layer that brings the process to a safe state.", "stakes": "The last line, and the reason TRISIS mattered so much: it was the first malware written specifically to reach the safety layer. Compromise here removes the protection everything else assumes is there." } ], "consequences": [ { "id": "loss-of-view", "label": "Loss of view", "meaning": "Operators can no longer see the process. The plant may still be running correctly; nobody can confirm it." }, { "id": "manipulation-of-view", "label": "Manipulation of view", "meaning": "Worse than losing the screen: the screen lies. Operators act confidently on false information, which is what made Stuxnet effective." }, { "id": "loss-of-control", "label": "Loss of control", "meaning": "Commands no longer reach the process. The plant continues doing whatever it was last told to do." }, { "id": "manipulation-of-control", "label": "Manipulation of control", "meaning": "The process is driven by someone else. This is the one that breaks equipment and hurts people." }, { "id": "loss-of-safety", "label": "Loss of safety", "meaning": "The protective layer is degraded or disabled. Often invisible until the day it was needed." }, { "id": "loss-of-availability", "label": "Loss of availability", "meaning": "The process stops. In OT this is frequently the *best* available outcome, and a legitimate response to the others." }, { "id": "theft-of-information", "label": "Theft of information", "meaning": "Process designs, recipes, logic and layouts taken. Rarely the endgame on its own; usually reconnaissance for something later." } ], "foundationalRequirements": [ { "id": "FR1", "name": "Identification and authentication control" }, { "id": "FR2", "name": "Use control" }, { "id": "FR3", "name": "System integrity" }, { "id": "FR4", "name": "Data confidentiality" }, { "id": "FR5", "name": "Restricted data flow" }, { "id": "FR6", "name": "Timely response to events" }, { "id": "FR7", "name": "Resource availability" } ], "tactics": [ { "id": "initial-access", "label": "Initial Access" }, { "id": "execution", "label": "Execution" }, { "id": "persistence", "label": "Persistence" }, { "id": "privilege-escalation", "label": "Privilege Escalation" }, { "id": "evasion", "label": "Evasion" }, { "id": "discovery", "label": "Discovery" }, { "id": "lateral-movement", "label": "Lateral Movement" }, { "id": "collection", "label": "Collection" }, { "id": "command-and-control", "label": "Command and Control" }, { "id": "inhibit-response", "label": "Inhibit Response Function" }, { "id": "impair-process-control", "label": "Impair Process Control" }, { "id": "impact", "label": "Impact" } ], "techniques": [ { "id": "T0886", "name": "Remote Services", "tactic": "initial-access", "zones": [ "l35", "l3" ], "consequences": [ "theft-of-information" ], "what": "Entry through the remote access path that exists so vendors and on-call engineers can work without driving to site. It is rarely undocumented; it is usually documented, approved, and far broader than anyone intends.", "defence": "Broker every session through the DMZ with per-session approval and recording, and make access time-bound by default so it expires rather than being revoked. Vendor accounts should be disabled between visits, not left standing.", "defenceStrength": "strong", "frs": [ "FR1", "FR2", "FR5" ] }, { "id": "T0865", "name": "Spearphishing Attachment", "tactic": "initial-access", "zones": [ "l5-4" ], "consequences": [ "theft-of-information" ], "what": "Mail to a corporate user, which is not OT at all. It matters because the enterprise network is where nearly every published OT intrusion began before moving down.", "defence": "This is an IT control protecting an OT outcome. The OT-specific part is ensuring the path from a compromised corporate mailbox to a controller is not short, which is a segmentation question rather than a mail question.", "defenceStrength": "partial", "frs": [ "FR5" ] }, { "id": "T0847", "name": "Replication Through Removable Media", "tactic": "initial-access", "zones": [ "l3", "l2" ], "consequences": [ "theft-of-information" ], "what": "USB into an engineering workstation. Still current, because air-gapped plants move files somehow and the somehow is usually a memory stick in an engineer's pocket.", "defence": "A sanctioned transfer path with a scanning kiosk, and port control on engineering workstations. An air gap without a sanctioned way across it does not remove the transfer, it just removes your visibility of it.", "defenceStrength": "partial", "frs": [ "FR2", "FR3" ] }, { "id": "T0862", "name": "Supply Chain Compromise", "tactic": "initial-access", "zones": [ "l3", "l2", "l1" ], "consequences": [ "manipulation-of-control", "theft-of-information" ], "what": "Compromise arriving inside legitimate vendor software, firmware or an integrator's laptop. The integrator's laptop is the one people forget, and it connects to everything.", "defence": "Contractual security requirements on integrators, verification of firmware and project files before they are loaded, and treating integrator equipment as untrusted on arrival rather than on suspicion.", "defenceStrength": "partial", "frs": [ "FR3" ] }, { "id": "T0871", "name": "Execution through API", "tactic": "execution", "zones": [ "l2", "l1" ], "consequences": [ "manipulation-of-control" ], "what": "Using the controller's own documented programming interface to run code. Nothing is exploited; the device is asked to do what it was designed to do, by someone who should not be asking.", "defence": "Physical key switches in RUN rather than REMOTE where the process allows, controller access restricted by network position, and alerting on programming-mode changes. There is often no authentication to strengthen, which is why position and monitoring carry the load.", "defenceStrength": "partial", "frs": [ "FR1", "FR2", "FR6" ] }, { "id": "T0823", "name": "Graphical User Interface", "tactic": "execution", "zones": [ "l2" ], "consequences": [ "manipulation-of-control", "manipulation-of-view" ], "what": "Driving the HMI as an operator would, through stolen credentials or a hijacked session. Indistinguishable from legitimate use in most logs.", "defence": "Individual accounts rather than a shared operator login, session timeouts that suit a control room, and alerting on logins outside shift patterns or from unexpected stations.", "defenceStrength": "partial", "frs": [ "FR1", "FR2", "FR6" ] }, { "id": "T0853", "name": "Scripting", "tactic": "execution", "zones": [ "l3", "l2" ], "consequences": [ "manipulation-of-control" ], "what": "Scripting engines on engineering workstations and historians, used to automate the attack the way engineers use them to automate work.", "defence": "Application allowlisting on fixed-function OT hosts, which suits them far better than IT: an engineering workstation's software set barely changes, so allowlisting is realistic where it would be unmanageable on a laptop.", "defenceStrength": "strong", "frs": [ "FR2", "FR3" ] }, { "id": "T0889", "name": "Modify Program", "tactic": "persistence", "zones": [ "l1" ], "consequences": [ "manipulation-of-control" ], "what": "Changing controller logic so the attacker's behaviour survives reboots, restores and staff changes, because the logic is now simply what the plant does.", "defence": "Offline golden copies of controller logic with periodic comparison against what is actually running. Most sites cannot answer 'has this logic changed?' without a manual comparison, and that is the gap.", "defenceStrength": "strong", "frs": [ "FR3", "FR6" ] }, { "id": "T1693", "name": "Modify Firmware", "tactic": "persistence", "zones": [ "l1", "l0" ], "consequences": [ "manipulation-of-control", "loss-of-safety" ], "what": "Persistence below the logic layer, in device firmware, where reimaging the workstation and reloading the program changes nothing.", "defence": "Signed firmware where the vendor supports it, and firmware version attestation as part of routine checks. On older devices there is frequently no integrity mechanism at all, and the honest answer is replacement or compensating monitoring.", "defenceStrength": "weak", "frs": [ "FR3" ] }, { "id": "T0890", "name": "Exploitation for Privilege Escalation", "tactic": "privilege-escalation", "zones": [ "l3", "l2" ], "consequences": [ "manipulation-of-control" ], "what": "Standard escalation on the Windows hosts that run OT applications, which are often years behind on patches for entirely legitimate availability reasons.", "defence": "Where patching is genuinely constrained by vendor validation, compensating controls carry it: least privilege, allowlisting, and segmentation that limits what an escalated account can reach.", "defenceStrength": "partial", "frs": [ "FR1", "FR2" ] }, { "id": "T0858", "name": "Change Operating Mode", "tactic": "evasion", "zones": [ "l1" ], "consequences": [ "manipulation-of-control", "loss-of-view" ], "what": "Putting a controller into program or remote mode to permit changes, then returning it, so the window is brief and easily missed.", "defence": "Alert on every mode change as a security event rather than an engineering one. Mode changes are rare, expected, and trivially baselined, which makes them one of the highest-signal detections available in OT.", "defenceStrength": "strong", "frs": [ "FR6" ] }, { "id": "T0872", "name": "Indicator Removal on Host", "tactic": "evasion", "zones": [ "l3", "l2" ], "consequences": [ "loss-of-view" ], "what": "Clearing logs and artefacts on OT hosts, which is easy when logs are stored locally and never leave the device.", "defence": "Forward logs off the host as they are written. Local-only logging on an engineering workstation is a record the attacker controls.", "defenceStrength": "strong", "frs": [ "FR3", "FR6" ] }, { "id": "T0842", "name": "Network Sniffing", "tactic": "discovery", "zones": [ "l2", "l1" ], "consequences": [ "theft-of-information" ], "what": "Passive listening on control networks, which is unusually productive because most industrial protocols carry no encryption and announce a great deal about the process.", "defence": "Segmentation limits what can be heard from any one position. Encryption is rarely available on legacy protocols, so this is a design and monitoring problem rather than a cryptographic one.", "defenceStrength": "partial", "frs": [ "FR4", "FR5" ] }, { "id": "T0846", "name": "Remote System Discovery", "tactic": "discovery", "zones": [ "l3", "l2", "l1" ], "consequences": [ "theft-of-information" ], "what": "Enumerating controllers and their roles, often using the same discovery functions engineering tools use.", "defence": "Passive network monitoring built for industrial protocols. Active scanning of OT is itself a risk: fragile devices have been knocked over by ordinary IT scanners, so this is one place where the IT playbook does real harm.", "defenceStrength": "partial", "frs": [ "FR5", "FR6" ] }, { "id": "T0867", "name": "Lateral Tool Transfer", "tactic": "lateral-movement", "zones": [ "l35", "l3", "l2" ], "consequences": [ "theft-of-information" ], "what": "Moving tooling deeper into the plant, usually through the paths built for legitimate file movement between levels.", "defence": "Conduits that permit specific protocols between specific endpoints rather than general connectivity, and file transfer that is brokered and inspected rather than direct.", "defenceStrength": "strong", "frs": [ "FR5" ] }, { "id": "T1694", "name": "Insecure Credentials", "tactic": "lateral-movement", "zones": [ "l2", "l1" ], "consequences": [ "manipulation-of-control" ], "what": "Documented default credentials on controllers, HMIs and network gear, published in manuals anyone can download.", "defence": "Change them where the device permits it. Where it does not, and that is common on older equipment, the control is network position: the device must be unreachable from anywhere an attacker realistically stands.", "defenceStrength": "partial", "frs": [ "FR1", "FR5" ] }, { "id": "T0801", "name": "Monitor Process State", "tactic": "collection", "zones": [ "l2", "l1" ], "consequences": [ "theft-of-information" ], "what": "Watching the process to learn its normal behaviour, which is the prerequisite for changing it convincingly rather than obviously.", "defence": "Little can be done about observation once an attacker is positioned, which is the argument for detecting the position rather than the watching.", "defenceStrength": "weak", "frs": [ "FR4", "FR5" ] }, { "id": "T0811", "name": "Data from Information Repositories", "tactic": "collection", "zones": [ "l3" ], "consequences": [ "theft-of-information" ], "what": "Historians, engineering document stores and project file repositories: the fastest route to understanding a plant without standing in it.", "defence": "Access control on project repositories, and treating process design documents as sensitive rather than as engineering convenience.", "defenceStrength": "partial", "frs": [ "FR2", "FR4" ] }, { "id": "T0869", "name": "Standard Application Layer Protocol", "tactic": "command-and-control", "zones": [ "l35", "l3" ], "consequences": [ "theft-of-information" ], "what": "Command and control over protocols already permitted outbound, so nothing new has to be opened.", "defence": "OT networks should have almost no legitimate outbound internet traffic, which makes egress filtering unusually effective here. Default-deny outbound from control zones is achievable in OT in a way it never is in IT.", "defenceStrength": "strong", "frs": [ "FR5", "FR6" ] }, { "id": "T0878", "name": "Alarm Suppression", "tactic": "inhibit-response", "zones": [ "l2", "l1" ], "consequences": [ "loss-of-view", "loss-of-safety" ], "what": "Stopping alarms reaching operators, so the process degrades with nobody told. Frequently paired with a manipulation technique rather than used alone.", "defence": "Monitor for alarm system health as a control in its own right. A quiet alarm system is ambiguous evidence: it means either nothing is wrong or the alarms have stopped, and those need distinguishing.", "defenceStrength": "strong", "frs": [ "FR6", "FR7" ] }, { "id": "T0881", "name": "Service Stop", "tactic": "inhibit-response", "zones": [ "l3", "l2" ], "consequences": [ "loss-of-view", "loss-of-control" ], "what": "Stopping the services that provide visibility and control, a common precursor to ransomware deployment in OT-adjacent environments.", "defence": "Service monitoring with alerting, and recovery procedures rehearsed against the actual systems rather than documented against them.", "defenceStrength": "strong", "frs": [ "FR6", "FR7" ] }, { "id": "T0838", "name": "Modify Alarm Settings", "tactic": "inhibit-response", "zones": [ "l2", "l1" ], "consequences": [ "loss-of-safety" ], "what": "Widening alarm thresholds so genuinely abnormal conditions read as normal. Quieter than suppression and considerably harder to notice.", "defence": "Baseline alarm configuration and compare periodically. Threshold drift also happens innocently through operational tuning, so the comparison finds real problems either way.", "defenceStrength": "partial", "frs": [ "FR3", "FR6" ] }, { "id": "T0836", "name": "Modify Parameter", "tactic": "impair-process-control", "zones": [ "l1", "l0" ], "consequences": [ "manipulation-of-control", "loss-of-safety" ], "what": "Changing setpoints and tuning within ranges the system accepts, so the process moves somewhere harmful without anything rejecting the instruction.", "defence": "Range limits enforced in the controller rather than the HMI, and change detection on parameters. Limits enforced only at the screen are advisory.", "defenceStrength": "partial", "frs": [ "FR3" ] }, { "id": "T1692", "name": "Unauthorized Message", "tactic": "impair-process-control", "zones": [ "l1", "l0" ], "consequences": [ "manipulation-of-control" ], "what": "Well-formed protocol commands from an unauthorised source. Most industrial protocols authenticate nothing, so a valid message is obeyed regardless of origin.", "defence": "Network position does the work that authentication cannot. Where the protocol has a secure variant and the devices support it, use it; on most installed equipment they do not.", "defenceStrength": "partial", "frs": [ "FR1", "FR5" ] }, { "id": "T0828", "name": "Loss of Productivity and Revenue", "tactic": "impact", "zones": [ "l3", "l2", "l1" ], "consequences": [ "loss-of-availability" ], "what": "Production stops, whether deliberately or because the operator shut down on losing confidence. The second is far more common and is usually the right call.", "defence": "Recovery capability, rehearsed. The question that decides the outcome is how quickly you can return to safe production, not whether you can prevent every stop.", "defenceStrength": "strong", "frs": [ "FR7" ] }, { "id": "T0880", "name": "Loss of Safety", "tactic": "impact", "zones": [ "safety" ], "consequences": [ "loss-of-safety" ], "what": "The protective layer no longer protects. TRISIS is the reference case: malware written specifically to reach a safety instrumented system.", "defence": "Keep safety systems genuinely independent of the control network, and treat any convergence proposal as the significant risk decision it is. Convenience is the usual reason they are connected.", "defenceStrength": "strong", "frs": [ "FR5", "FR7" ] }, { "id": "T0826", "name": "Loss of Availability", "tactic": "impact", "zones": [ "l2", "l1", "l0" ], "consequences": [ "loss-of-availability" ], "what": "The process cannot run. In OT this is often the least bad outcome available and a legitimate protective response.", "defence": "Decide in advance who may stop the process on security grounds and on what evidence. Sites that have not decided lose hours to the argument at the worst possible moment.", "defenceStrength": "strong", "frs": [ "FR7" ] } ] }