If your plant's ATT&CK for ICS mapping was last touched a year ago, it is already out of date. Two releases landed in the last seven months. The first, v19, finally gave the ICS matrix sub-techniques. The second, v20, added new execution and command-and-control coverage, nine new ICS detection strategies, and two campaigns that every water, power and manufacturing security lead should read closely. 

This Blog explains what ATT&CK for ICS is, what changed in the latest releases, and how to turn the framework into something your SOC, your control engineers and your board will actually use. It is written for practitioners who already know what a PLC is and are tired of being told to "map to MITRE" without being told how. 

Key takeaways 

• ATT&CK v20 is the current version (October 13). The ICS domain now holds 12 tactics, 78 techniques, 26 sub-techniques, 14 groups, 25 software entries, 10 campaigns, 53 mitigations, 18 asset types and 106 detection strategies. 

• v19 introduced ICS sub-techniques for the first time. Old technique IDs such as Default Credentials and Block Command Message were revoked and replaced. Detection content and risk registers that still use the old IDs will not line up with current data. 

• v20 deprecated Command-Line Interface (T0807) and Scripting (T0853) in favour of a single Command and Scripting Interpreter technique (T1701) with six sub-techniques. 

• v20 adds DNS and Publish/Subscribe protocols as command-and-control channels under Standard Application Layer Protocol (T0869). 

• The new ICS campaign data is a mirror held up to the industry. Attackers in the 2026 U.S. Water Utilities Attacks used internet-exposed PLCs and default credentials. Nothing exotic. 

• AI is now in the framework. An AI-assisted breach of Mexican government infrastructure reached a municipal water utility's SCADA environment and is tracked as both an Enterprise and ICS campaign. 

What is MITRE ATT&CK for ICS? 

MITRE ATT&CK is a knowledge base of real-world adversary behaviour. The ICS matrix applies that approach to industrial control systems: the PLCs, RTUs, DCS controllers, HMIs, historians, engineering workstations and the protocols that connect them. 

It answers one question better than any other framework: what do attackers actually do once they are near a physical process, and how would we see it? 

The matrix has 12 tactics: 

1. Initial Access 

2. Execution 

3. Persistence 

4. Privilege Escalation 

5. Evasion 

6. Discovery 

7. Lateral Movement 

8. Collection 

9. Command and Control 

10. Inhibit Response Function 

11. Impair Process Control 

12. Impact 

The last three are what separate ICS from the Enterprise matrix. Inhibit Response Function covers attacks on safety, protection and alarm systems. Impair Process Control covers manipulation of the process itself. Impact covers the consequences: loss of control, loss of view, loss of availability, loss of safety, damage to property. 

A caution on older content. Some of the best-known guides to the ICS matrix still describe eleven tactics. That count is years old. If you are working from a pre-v19 explainer, treat its technique IDs as historical. 

How ATT&CK for ICS differs from other frameworks you already use 

They are complements. A mature program uses 62443 to design, ATT&CK for ICS to test and detect, and the Purdue model as the shared map everybody draws on. 

ATT&CK for ICS: the recent timeline 

Version history is on MITRE's own site and worth bookmarking. Pin the version number in every report, layer and detection rule you produce. "We map to ATT&CK" is not a statement an auditor can check. "We map to ATT&CK v20 ICS" is. 

What changed in v19: ICS finally gets sub-techniques 

For years, practitioners complained that some ICS techniques were too coarse. "Remote System Discovery" covered a passive multicast listen and a noisy port scan with the same ID. v19 fixed this for five areas of the matrix. As MITRE's team described it, the aim was to make broad behaviours more precise and operationally useful. 

The reorganised parents: 

• Modify Firmware (T1693): System Firmware (.001) and Module Firmware (.002) 

• Block Communications (T1695): Serial COM (.001), Ethernet (.002), Wi-Fi (.003) 

• Remote System Discovery (T0846): Port Scan (.001), Broadcast Discovery (.002), Multicast Discovery (.003) 

• Program Download (T0843): Download All (.001), Online Edit (.002), Program Append (.003) 

• Insecure Credentials (T1694): Default Credentials (.001), Hardcoded Credentials (.002) 

Two further structures matter. Block Operational Technology Message (T1691) now has Command Message and Reporting Message sub-techniques, and Unauthorized Message (T1692) has the same pair. Old standalone entries such as Block Command Message, Block Reporting Message, Spoof Reporting Message, Default Credentials, Hardcoded Credentials, System Firmware and Module Firmware were revoked and reissued under the new parents. 

Why this matters in practice: 

• Detection coverage maps break silently. A rule tagged to the old Default Credentials ID will not show up against T1694.001 in a current Navigator layer. 

• Online Edit versus Download All are different risks. Online Edit changes logic on a running controller. Download All typically stops it. Your monitoring thresholds and your incident playbooks should treat them differently. 

• Firmware is now split by where it lives. System firmware compromise and module firmware compromise have different detection sources and different recovery costs. 

The ICS crosswalk that MITRE published with v19 gives the old-to-new mapping. Use it once, rebuild your layers, and move on. 

What changed in v20 

The v20 release notes describe the biggest change as expanded coverage of recent adversary activity, including campaigns on U.S. water utilities and an AI-assisted breach of Mexican government infrastructure. For ICS specifically, four changes stand out. 

1. One Command and Scripting Interpreter technique replaces two 

T1701 is new, with six sub-techniques: PowerShell (.001), Windows Command Shell (.002), Unix Shell (.003), Visual Basic (.004), Python (.005) and JavaScript (.006). The old ICS techniques Command-Line Interface (T0807) and Scripting (T0853) are deprecated. 

If you carry T0807 or T0853 in a risk register, replace them. Engineering workstations and historians run all of these interpreters legitimately, which is exactly why they need an asset-aware baseline rather than a blanket alert. 

2. DNS and Publish/Subscribe as command-and-control channels 

Standard Application Layer Protocol (T0869) now has two sub-techniques: DNS (T0869.001) and Publish/Subscribe Protocols (T0869.002). Pub/sub matters because MQTT and similar brokers are increasingly common in IIoT gateways and cloud-connected telemetry. Traffic that looks like normal sensor reporting can carry attacker instructions. If your OT network monitoring only understands Modbus, CIP and S7, this is a coverage gap. 

3. Detection strategies get platform and asset context 

v20 adds nine new ICS detection strategies, for command and scripting abuse (generic plus PowerShell, Windows Command Shell, Unix Shell, Visual Basic, Python and JavaScript), DNS misuse for C2, and Publish/Subscribe misuse for C2. Across Enterprise and ICS, the release adds 15 new detection strategies and 38 analytics. MITRE also states that ICS analytics have been tuned to filter out routine engineering and maintenance activity. That is a small line in a long changelog and a big deal for false-positive rates. 

With v20 the ICS domain carries 106 detection strategies and 302 analytics. Treat these as a starting library for your SIEM or OT monitoring platform, not a drop-in ruleset. You still need to tune them against your own maintenance windows. 

4. A new mitigation and updated actor data 

M1061 Limit Software/Package Installation is new and aimed at keeping unauthorised software off ICS assets. Four existing mitigations received minor revisions: Disable or Remove Feature or Program, Execution Prevention, Exploit Protection and Restrict Web-Based Content. Two new ICS software entries (IOControl and BACKUPOSINT v9.0 APEX PREDATOR) were added, and the APT38 and CyberAv3ngers group profiles were updated. 

Case study: the 2026 U.S. Water Utilities Attacks 

MITRE's new campaign entry (C0066) is the clearest ICS case study published this year, and it is worth reading in full on the ATT&CK site. A summary of what is documented: 

• Scope: more than 30 municipal water and wastewater utilities in Minnesota, beginning July 27, amid similar activity that the FBI and EPA reported across at least seven U.S. states. 

• Targets: internet-facing Rockwell Automation / Allen-Bradley MicroLogix 1100 and 1400 PLCs reachable through cellular gateways at water towers and sewer lift stations. 

• Actions: remote login, then changes to IP addresses and passwords that locked operators out. At least one victim had PLC program logic altered. 

• Effects: loss of water pressure and flooding were reported, and one utility took its treatment plant offline. 

• Attribution: not formally confirmed. Some reporting calls the wider pattern consistent with Iranian-affiliated activity, but the Minnesota intrusions specifically remain unattributed. 

The campaign, mapped to ATT&CK for ICS 

The lesson is uncomfortable for people who like to talk about nation-state tradecraft. This was a campaign of low sophistication and high consequence. The controls that would have blunted it (no direct internet exposure, no default passwords, a monitored change baseline) are in every standard we have all been quoting for a decade. The ATT&CK mapping is useful here for a different reason: it shows a defender exactly which two or three steps in the chain are cheapest to break. 

Case study: AI-assisted intrusion with ICS reach 

Campaign C0064 documents operators using AI tools (Claude Code and OpenAI's GPT-4.1) to perform reconnaissance, exploit vulnerabilities, escalate privileges, harvest credentials and exfiltrate data across several Mexican government bodies between December 2025 and February 2026. The victims included the SADM Monterrey municipal water utility. In the ICS context, public reporting cited by MITRE says the operators had the AI tool enumerate further lateral movement targets, which led to the discovery of an industrial gateway and a SCADA/IIoT management platform. The campaign entry also records an attempted password spray against a SCADA web interface. 

MITRE flags that public reporting provides only select details, so this should not be read as a complete picture. Three things are still worth taking from it: 

1. AI compressed the timeline, not the tradecraft. The techniques are familiar. What changed is speed and the number of tasks one operator can run in parallel. 

2. The IT/OT boundary was the path. A compromised IT environment gave a short hop to a SCADA management layer. Segmentation and monitored conduits are still the control that matters. 

3. v20 also adds Enterprise techniques for AI itself, including Direct and Indirect Prompt Injection, AI-Enabled Exfiltration and AI Result Poisoning. If your plant uses AI assistants for alarm triage or maintenance, they are now part of the attack surface you map. 

A practical playbook for plant security teams 

Here is how we would operationalise ATT&CK for ICS, in order. 

Step 1: Start from assets, not from the matrix 

ATT&CK for ICS defines asset classes (18 in v20), including PLCs, DCS controllers, HMIs, data gateways, firewalls, routers and switches. Build your inventory against these. Techniques relate to assets, so an asset-first view tells you which behaviours can even happen in your environment. 

Step 2: Choose a short list of relevant adversaries and campaigns 

The ICS domain has 14 groups and 10 campaigns. You do not need all of them. Pick the five or six that match your sector and geography, pull their technique lists, and export them as Navigator layers. Overlay the layers. The techniques that appear in several are your priority. 

Step 3: Rank by consequence, not by count 

A technique that touches a safety instrumented system outranks ten techniques that touch a historian. Add a consequence column that your process engineers fill in, not the security team. 

Step 4: Build a coverage heatmap with three honest states 

For each technique, record whether you can prevent, detect or neither. Be strict. "Detect" means you have tested the alert fires with realistic traffic from a realistic source. A vendor datasheet claiming coverage does not count. 

Step 5: Close the cheap gaps first 

Based on the water campaign alone, the highest-value checks for most operators are: 

• Find every PLC, RTU and gateway reachable from outside the plant. Search for your own IP ranges the way an attacker would. 

• Audit cellular-connected sites for private APN or VPN protection and firewalling. 

• Change every default credential. Then confirm it by checking, not by asking. 

• Alert on controller IP, password, mode and program changes made outside approved windows. 

• Keep controller mode switches in RUN where operations allow it. 

• Keep a known-good project file for every controller and compare on a schedule. 

Step 6: Tune the v20 detections to your engineering reality 

Import the new ICS detection strategies as a starting point. Then baseline which engineering workstations, which accounts and which maintenance windows legitimately run PowerShell, Python or shell scripts, and write exceptions for those and nothing else. Add DNS and pub/sub monitoring at the gateway layer. 

Step 7: Test with purple team exercises that stop short of the process 

Run technique-level simulations in a lab or a safe segment: a controlled Online Edit, a port scan of a staging network, a pub/sub message from an unexpected client. Record what the alert said, how long it took and who saw it. Never test against a live process without engineering sign-off and a rollback plan. 

Step 8: Re-map on every major release 

MITRE ships a major release roughly every six months, in April and October. Put a calendar reminder on your detection engineering team. Use MITRE's published changelogs and crosswalks rather than redoing everything by hand. 

Common mistakes we see 

• Treating the heatmap as the goal. A green matrix is not security. A tested detection with an owner is. 

• Mapping only to technique names. Without the sub-technique ID, nobody can reproduce your result. 

• Copying IT detections into OT. Enterprise analytics assume endpoints you can instrument and reboot. Many ICS assets are neither. 

• Ignoring physical consequence. If your mapping has no column for process impact, the board cannot prioritise it. 

• Never retiring old IDs. Deprecated techniques like T0807 and T0853 linger in spreadsheets for years. 

Metrics worth taking to the board 

• Percentage of priority techniques with a tested detection 

• Mean time to detect in purple team exercises 

• Number of OT assets reachable from the internet (target: zero) 

• Number of assets still using default credentials (target: zero) 

• Time since the last mapping refresh against the current ATT&CK version 

• Share of critical controllers with a verified known-good project baseline 

How Shieldworkz can help 

Shieldworkz is an end-to-end industrial OT cybersecurity company, covering services, platform and solutions for SCADA, OT and IoT environments in critical infrastructure. For teams working with ATT&CK for ICS, that typically means: 

• OT asset discovery and exposure assessment, so your mapping starts from a real inventory and a real internet-facing footprint 

• Threat-informed risk assessments that map your assets to relevant ICS campaigns and techniques, aligned to the current ATT&CK version 

• OT network monitoring and detection engineering, with detections tuned to your engineering and maintenance patterns 

• Purple team and tabletop exercises designed around the techniques in your priority layers 

• Incident response readiness for loss-of-view and loss-of-control scenarios 

If you would like a second pair of eyes on your ATT&CK for ICS coverage, or a quick check of what your plant exposes to the internet, speak to the Shieldworkz team. 

Frequently asked questions 

What is the latest version of MITRE ATT&CK for ICS? 

ATT&CK v20, released October 13, is the current version. It includes ICS updates covering new execution and command-and-control techniques, new detection strategies and two new campaigns. 

How many techniques are in ATT&CK for ICS? 

In v20 the ICS domain has 78 techniques and 26 sub-techniques across 12 tactics. 

What are the ICS sub-techniques added in v19? 

v19 added 18 sub-techniques across Modify Firmware, Block Communications, Remote System Discovery, Program Download, Insecure Credentials, Block Operational Technology Message and Unauthorized Message. v20 added eight more, under Command and Scripting Interpreter and Standard Application Layer Protocol. 

What replaced Command-Line Interface and Scripting in ICS ATT&CK? 

Both were deprecated in v20 and replaced by Command and Scripting Interpreter (T1701), which has sub-techniques for PowerShell, Windows Command Shell, Unix Shell, Visual Basic, Python and JavaScript. 

Is ATT&CK for ICS the same as IEC 62443? 

No. IEC 62443 is a set of standards for designing and operating secure industrial systems. ATT&CK for ICS is a catalogue of adversary behaviour with detection and mitigation guidance. Most mature programs use both. 

How often does ATT&CK update? 

Major releases arrive roughly every six months, in April and October, with smaller agile updates in between. 

Does ATT&CK for ICS cover AI-enabled attacks? 

The ICS matrix itself has not added AI-specific techniques, but the v20 campaign data includes an AI-assisted intrusion that reached a water utility's SCADA environment, and the Enterprise matrix now includes AI-focused techniques such as prompt injection. 

 Additional resources:

Comprehensive Guide to Network Detection and Response NDR in 2026 here
NERC CIP-015 Internal Network Security Monitoring Readiness Checklist for Electric Utilities here
OT SOC Foundational Guide here
Managed SOC Service here
OT Cyber Threat Intelligence Advisory - Middle East here
NIS2 Directive Achieving NIS2 Compliance Through IEC 62443 here
What Is Removable Media? Risks, Policies, and Industrial OT Security Solutions here
Free Removable Media Policy Template for OT and IT Teams here