MITRE ATT&CK v18.0 became active on October 28, 2025, and represents the largest restructuring of the detection model since the framework's inception. The traditional Detections section attached to each technique — historically organized by Data Sources like "Process: Process Creation" — has been replaced by Detection Strategies and Analytics. The change is not cosmetic. v18 directly couples detection guidance to specific log fields, queries, and false-positive considerations, making the framework usable as a detection-engineering source of truth rather than a coarse mapping artifact. For SOC teams, threat-intel consumers, and detection engineers, the upgrade demands a methodical re-baseline of internal ATT&CK mappings.
What changed structurally in v18?
Each technique now exposes one or more Detection Strategies. A Detection Strategy is a named approach to identifying the technique — for example, "Detect via parent-child process anomalies." Each Detection Strategy contains one or more Analytics, which are concrete pseudo-query expressions over specific log fields, with notes on false positives, prerequisites, and tuning. The previous "Data Source: Process: Process Creation" line item still exists, but as a property referenced by an Analytic rather than as the primary detection container. The new model retains backward references — anyone who had mapped internal SIEM rules to the old Data Source list can still trace the mapping — but the new structure makes the leap from "we cover T1055 Process Injection" to "we have implemented Analytics 1, 2, and 4 of Detection Strategy DS-T1055-002" auditable.
Why did MITRE make this change?
Two reasons stated in the v18 release notes. First, the community had been bolting detection content (Sigma rules, Splunk queries, KQL) on top of ATT&CK in inconsistent ways, and MITRE wanted to formalize a structure that vendors and SOCs could converge on. Second, the data-source-centric model conflated "what telemetry exists" with "how to detect a behavior" — many techniques have multiple viable detection paths against the same data source, and many require correlating across sources. Detection Strategies cleanly separate the detection idea from the data-source dependency, which improves how teams reason about coverage.
| ATT&CK pre-v18 | ATT&CK v18+ | | --- | --- | | Detections (free-text) | Detection Strategies (named, with IDs) | | Data Sources (top-level field) | Data Components consumed by Analytics | | Mitigations (unchanged) | Mitigations (unchanged) | | Detection coverage hard to measure | Coverage measurable per Strategy and Analytic |
What does an Analytic look like in practice?
Each Analytic includes a name, narrative, pseudo-code or SPL-like query, mapped Data Components, and false-positive notes. Below is a stylized example for T1059.001 PowerShell:
Detection Strategy: DS-T1059.001-001 "Suspicious PowerShell Encoded Command"
Analytic A1: PowerShell process with -EncodedCommand parameter and parent ≠ user shell
Data Components:
- process: process_creation (parent_process_name, process_command_line)
Logic:
process.parent_process_name NOT IN ("explorer.exe", "code.exe", "WindowsTerminal.exe")
AND process.command_line MATCHES "(?i)powershell.*-enc(odedcommand)?"
False positives:
- legitimate IT automation invoked from svchost or wmic
- vendor management agents (sccmexec.exe, ccmexec.exe)
Prerequisites: command-line auditing enabled (Sysmon Event ID 1 or 4688)
How do v18 changes affect existing ATT&CK mappings?
Existing mappings against techniques and sub-techniques continue to work — technique IDs (T-numbers) are stable. What needs to be re-baselined is detection coverage reporting. If your team's quarterly metric was "we cover 412 ATT&CK Data Sources," that metric quietly degrades in v18 because Data Sources have moved structurally. Re-baseline as "we have implemented Analytics for N Detection Strategies across M techniques." Several detection vendors (including Sigma's community, Microsoft Sentinel, and Splunk's ESCU project) have begun mapping content to the new Detection Strategy IDs, so consumers can adopt the new vocabulary without rewriting rules.
How should detection-engineering teams operationalize v18?
Four operational changes follow from the v18 model. First, detection-coverage dashboards should switch from "Data Source coverage" to "Detection Strategy implementation rate per technique," because the former metric became misleading the moment the underlying ATT&CK structure changed. Second, detection-rule metadata should reference both technique IDs and Detection Strategy IDs, so that downstream coverage reports can join SIEM content to the framework without ambiguity. Third, internal documentation that previously listed "Data Source: Process: Process Creation" should be updated to list the Analytics those rules implement; the Sigma project's mapping work is a useful template. Fourth, detection-engineering peer review should include "what false positives did MITRE call out for this Analytic?" — the framework now publishes that information, and detection engineers ignoring it duplicate work that the community has already done. For organizations measuring SOC maturity, v18's structure makes it possible to argue not just "we cover technique T1059" but "we implement four of the five published Detection Strategies for T1059, with documented FP-tuning evidence." That is the kind of statement that holds up in a regulatory or contractual assurance conversation.
What is coming in v19 in April 2026?
MITRE's published roadmap calls v19 for April 2026. The largest preview item is a split of the Defense Evasion tactic into Stealth and Defense Impairment, the addition of Sub-Techniques to ICS ATT&CK, and the start of Detection Strategies in Mobile ATT&CK. The Defense Evasion split is a non-trivial change: a meaningful number of mapped techniques will move tactic, which affects how detection coverage by tactic is reported. Plan for the same kind of re-baseline exercise in April 2026 as v18 prompted in October 2025.
How do v17 ESXi techniques fit into v18 coverage?
The v17 release in April 2025 introduced ESXi as a first-class platform in the Enterprise matrix, with new techniques like "ESXi Administration Control" and "Hypervisor CLI." v18 continues to evolve the ESXi coverage and applies the Detection Strategies and Analytics model uniformly across the new platform. For organizations running VMware ESXi at scale, the v17/v18 combination provides the first comprehensive ATT&CK-aligned detection roadmap for hypervisor-layer threats — historically a weak point in SOC coverage because the underlying telemetry is harder to collect than endpoint telemetry. Several SIEM vendors have begun shipping ESXi-focused detection content aligned to the new techniques in late 2025, and organizations targeting ESXi hardening have a clearer measurement framework than they did before April 2025.
How does v18 affect threat-intelligence consumption?
Threat-intel feeds and vendor reports have used ATT&CK technique IDs as the lingua franca for years. v18 does not break that — technique IDs remain stable — but it adds expressive power for intel producers willing to use it. A threat-intel report can now reference specific Detection Strategies and Analytics in addition to techniques, which is useful when describing how an observed campaign should be hunted. Intel feeds that historically said "this actor uses T1059.001" can now say "this actor uses T1059.001 with the encoded-command pattern matched by Detection Strategy DS-T1059.001-001, which Analytic A1 detects with documented false positives X, Y, Z." That is a meaningfully more actionable intelligence product for SOCs that have implemented the strategies. Intel-consumer tooling (TIP platforms, threat-intel-aware SIEMs) is rapidly updating to handle the additional metadata, with the major commercial TIPs supporting Detection Strategy and Analytic IDs as of late 2025. For SOCs evaluating intel-feed quality, the question to ask vendors in 2026 is whether their reports use the v18 vocabulary or remain on the older Data Source-centric model.
How Safeguard Helps
Safeguard's supply-chain detection content was re-mapped to ATT&CK v18 within two weeks of the October 2025 release. Findings that correspond to supply-chain attack behaviors — malicious package install, build-system tampering, signed-release bypass, dependency-confusion exploitation — surface with their v18 technique IDs, Detection Strategy IDs, and the specific Analytics that triggered. For SOC integration, Safeguard emits webhook payloads using v18 vocabulary so that downstream SIEMs and SOAR platforms route consistently with the rest of your detection content. Griffin AI explains the detection logic for any finding by referencing the underlying ATT&CK v18 Detection Strategy, with FP-rate notes pulled from the framework. As v19 ships in April 2026 with the Defense Evasion split, Safeguard's content will re-baseline automatically and existing customer dashboards will not break — the technique IDs you depended on stay stable, and the tactic-level reporting updates with a release note explaining what moved.