MITRE released ATT&CK v19 on 28 April 2026, and the biggest change in this release is structural. Defense Evasion, which was the most heavily used tactic in the MITRE ATT&CK framework, it is gone. It has been split into two new tactics in v19. Stealth keeps the old tactic ID TA0005. Defense Impairment is the new tactic, with the ID TA0112. This is an Enterprise matrix only change. The Mobile and ICS matrices still have Defense Evasion, with the same set of techniques. If you work only in Mobile or ICS detection content, this post may not apply to you yet. If you work in Enterprise, this change affects everyone who writes detections, runs purple teams, builds adversary emulation scenarios, or ships any product that maps to Enterprise ATT&CK. The new changes are not huge, but it is not optional either. The deeper your product or service stack is relied on ATT&CK, the more there is to do.
Figure 1 - MITRE ATT&CK Updates April 2026.
I am also writing this as my own reference for the v19 transition. A place I can come back to when I forget which T1562 sub-technique became which new ID, or which techniques moved out of the old Defense Evasion entirely. The release notes are the primary sources for the actual data. But honestly, neither of them is something you read end-to-end. Hopefully this post serves a similar purpose for others working through the migration.
And it is not just us. Every security product vendor that ships ATT&CK mappings has the same problem. EDR coverage matrices, SIEM detection rules, SOAR playbooks, BAS libraries, threat intel data, GRC controls, vendor marketing slides that claim Defense Evasion coverage. All of these have been built on top of TA0005 for years. The v19 release does not respect any of that prior work. The next two to three quarters across the industry will be a mix of patching, remapping, and validation. The teams that treated ATT&CK as a working framework will get through this faster than the ones who used it as a slide decks.
Before going any further, here is the simple version of what these two tactics actually mean. Skip this section if you already know.
The adversary is doing things on your network, but they look like normal activity. Your security tools (EDR, SIEM, antivirus) are all running and working normally and they can see what is happening. The problem is that the activity does not look suspicious to the products. Think of an intruder walking through your office building dressed as a maintenance worker. The CCTV cameras are recording every step. The security guards see the figure on the monitors. But nothing looks out of place, so no alarms. The defenses work perfectly but he intruder just does not trigger them. Examples: using PowerShell to download a file (because IT admins do this every day), running rundll32.exe to load a malicious DLL (because Windows runs rundll32.exe thousands of times a day), or naming the malicious binary svchost.exe so it blends in.
Figure 2 - Here is a cool mockup of a thief hiding from a security guard. Just being stealth in a silly manner.
The attacker takes direct action to disable, degrade, or compromise the security tools entirely or partially. Your EDR gets killed or removed, your event log gets cleared. This time the intruder cuts the CCTV cables on the way in. The cameras do not have to be fooled. They are just not recording anything. There is no footage to review, no alarm to fire. The defenses are not being tricked. They are not there to trigger. Examples: using a vulnerable signed driver to terminate the EDR agent from the kernel (BYOVD), stopping the Windows Event Log service, clearing security logs after the attack.
Figure 3 - Here is another mockup of the thief simply impairing the security guard. In this case making him fall and in-capable of doing his job, using a silly banana peel as a weapon. ;)
Stealth and Defense Impairment are two different problems, and they need two different defensive responses. Stealth needs analytics, behavioural baselines, and correlation. Defense Impairment needs proper telemetry monitoring, agent heartbeat checks, and alerts for when your security tools go silent. ATT&CK v19 separates them so that detection plans can be measured and fine-tuned against the right problem.
Figure 4 - The Enterprise tactic row before and after. Fourteen tactics in v18 became fifteen in v19. Defense Evasion (TA0005) was the only tactic that changed. Stealth inherited its ID, and Defense Impairment (TA0112) was added as a net-new tactic. Sources: MITRE ATT&CK Enterprise Matrix and MITRE ATT&CK Updates April 2026.
Defense Evasion had grown into the framework's dumping ground. Over 40 techniques covered everything from obfuscating a PowerShell payload to physically terminating an EDR agent at the kernel. The breadth was always the problem. A good friend of mine, Cat Self of MITRE explained at ATT&CKcon 6.0, the tactic violated ATT&CK's own definition of a tactic, which is an adversary's goal. Hiding your activity is not a discrete goal, it is something attackers attempt throughout the entire kill chain, alongside initial access, persistence, lateral movement, and everything else. Breaking the defense tooling is its own intent. MITRE's Defense Evasion Split preview blog from March, authored by Allison Henao and Alice Koeninger, walks through this rationale in detail and is the canonical reference for understanding the design intent.
MITRE's March preview blog called the new tactic Impair Defenses, and many secondary sources still use that name. By the April release, MITRE had finalised it as Defense Impairment. Both names refer to the same tactic with the same ID (TA0112). This post uses Defense Impairment throughout, matching the official v19 release.
Once you separate hiding from breaking, the rest of the split makes immediate sense, and the operational consequences run a lot deeper than the one-line summary suggests. The behaviour looks different on the wire. The detection program that catches each is different. The triage response is different. The investment profile to build coverage is different. The kind of SOC that handles one well is often weak at the other, because the two require different models, different log pipelines, and different alerting thresholds.
Figure 5 - The full Defense Evasion split, technique-level. The old tactic deprecated, Stealth and Defense Impairment as the two replacements, the T1562 merge into T1685, the reissued sub-techniques, and the techniques that left Defense Evasion entirely. Sources: MITRE Defense Evasion split crosswalk and the MITRE Defense Evasion Split preview blog.
Stealth covers techniques where the adversary reduces visibility by blending in with legitimate behaviour. The defining characteristic is that defensive systems are still working. The EDR is running and the agent is sending heartbeats. The adversary just operates in ways that look indistinguishable from normal activity. Living-off-the-land binaries belong here, so T1218 System Binary Proxy Execution is squarely a Stealth technique. So is T1036 Masquerading, where malicious files or processes are disguised as legitimate system components. T1027 Obfuscated Files or Information, T1055 Process Injection, T1070 Indicator Removal, and T1480 Execution Guardrails all land in Stealth. The old T1211 Exploitation for Defense Evasion has been renamed to Exploitation for Stealth and retains its ID.
The defensive response to Stealth is analytic. The tools can see these behaviours, the problem is distinguishing the benign from the malicious. rundll32.exe and msiexec.exe show up in your telemetry every single day for legitimate reasons. Catching the malicious instances requires behavioural baselining, anomaly detection, and forensic correlation across multiple events. The detection engineering investment is in the analytic layer, not the collection layer.
Defense Impairment covers techniques where the adversary actively degrades, disables, or undermines the trustworthiness of security controls and monitoring mechanisms. The attacker here is not hiding from your sensors, they are killing them. This is where BYOVD attacks live. Bringing a vulnerable signed driver into the environment and using it to terminate the EDR agent from the kernel is the textbook Defense Impairment behaviour. So is stopping the Windows Event Log service, modifying or disabling Defender, flushing iptables rules on Linux, tampering with audit pipelines, or installing a rogue root certificate to subvert TLS inspection. T1553.004 Install Root Certificate, T1222 File and Directory Permissions Modification, and the brand new T1687 Exploitation for Defense Impairment all map to TA0112.
Figure 6 - Two Tactics
Stealth detection looks for suspicious signals. Defense Impairment detection looks for the absence of expected ones. As MITRE's own Defense Evasion Split blog put it, this is the difference between needing better behavioural analytics and needing better tamper protection. It is a different telemetry problem and a different alerting model, and it is the reason MITRE split the tactic in the first place.
The single most disruptive technique-level change in v19 sits inside Defense Impairment. T1562 Impair Defenses has been promoted to a tactic in spirit, and the old technique tree has been restructured. T1562, T1562.001 Disable or Modify Tools, and T1562.006 Indicator Blocking have been merged into a single new parent technique, T1685 Disable or Modify Tools. The remaining T1562 sub-techniques have been revoked and reissued under brand new IDs inside Defense Impairment. If your detection rules reference any T1562 sub-technique by ID, those references are now stale and you have to consult MITRE's crosswalk to find the replacements.
Figure 7 - T1562 restructure
Most other technique IDs survive the v19 release unchanged. Only the tactic association moves for the majority of techniques, which is far less disruptive than a mass ID migration would have been. A handful of techniques have left the old Defense Evasion space entirely.
Two further restructure details are worth flagging because they will surface in detection content remaps. The old standalone technique Spoof Security Alerting has been revoked and folded into T1685.003 Modify or Spoof Tool UI. This is the technique where an adversary, after disabling the EDR agent, modifies its UI to keep showing a green "all clear" status to the user and to the help desk. If your detection content referenced the old Spoof Security Alerting technique directly, that reference now needs the new ID. Separately, a much wider pattern affects roughly sixty Defense-Evasion-era techniques that received major version bumps in v19 because their tactic mapping moved. T1218 System Binary Proxy Execution went v3.2 to v4.0. T1027 Obfuscated Files went v1.7 to v2.0. T1036 Masquerading went v1.8 to v2.0. T1055 Process Injection went v1.4 to v2.0. T1070 Indicator Removal went v2.4 to v3.0. T1574 Hijack Execution Flow went v1.3 to v2.0. If you maintain STIX bundles, Navigator layers, or version-pinned mappings, expect a wave of object-version diffs even where the technique IDs are unchanged.
The split is the biggest change in v19 but it is not the only one. A handful of other things landed in the same release that will end up affecting detection content, emulation plans, and CTI mappings.
T1684 Social Engineering is now a parent technique inside Stealth. It has two sub-techniques, T1684.001 Impersonation and T1684.002 Email Spoofing.
The standalone Impersonation and Email Spoofing techniques that used to exist have been revoked and folded under the new parent. The change is structural rather than substantive. Adversaries combine impersonation across email, voice, helpdesk and collaboration platforms, and treating each channel as its own technique was always artificial. MITRE has also published DET0899 Detect Social Engineering as a dedicated detection strategy. It targets the cross channel adversary pattern that holds these techniques together. A suspicious interaction followed by an unusual user authorized action like a password reset, an OAuth consent grant, a financial approval or a credential submission.
Three new techniques for, how adversaries are using AI in 2025 - 2026, formally entering the framework for the first time.
T1682 Query Public AI Services covers adversaries using ChatGPT, Claude, Gemini, and similar services to draft phishing content, generate exploit code, automate reconnaissance, or accelerate any other offensive workflow.
T1683 Generate Content covers AI generated artefacts used in operations, with sub-techniques T1683.001 Written Content (synthetic emails, ransom notes, pretext narratives) and T1683.002 Audio-Visual Content (deepfake voice for vishing, synthetic video for BEC, fabricated screenshots).
T1027.018 Obfuscated Files or Information: Invisible Unicode covers hiding payloads or prompt injection content inside Unicode characters that render as empty space but contain instructions to LLMs or evade text based detection. MITRE has published five new Detection Strategies alongside these techniques. DET0916 Generate Content, DET0917 Written Content, DET0918 Audio-Visual Content, DET0919 Query Public AI Services, and DET0920 Invisible Unicode. Detection logic for AI-enabled techniques is genuinely new territory and the official strategies are the right starting point if you are building this coverage for the first time.
The Industrial Control Systems matrix gains sub-techniques in v19, a meaningful step for OT/ICS coverage that previously had a flatter taxonomy than Enterprise. Several ICS techniques arrive with sub-technique decomposition.
T1693 Modify Firmware (with .001 System firmware and .002 Module firmware), T1694 Insecure Credentials (.001 Default credentials, .002 Hardcoded credentials), T1691 Block Operational Technology Message (.001 Command Message, .002 Reporting Message), T1692 Unauthorized Message (same sub-technique pattern), and T1695 Block Communications (.001 Serial COM, .002 Ethernet, .003 Wi-Fi).
If you build OT or critical-infrastructure detection content, treat this as a v18 to v19 schema migration for the ICS domain on alignment with the Enterprise Defense Evasion updates.
Several v19 CTI additions are there, which are operationally relevant for adversary emulation, reporting, and threat modelling.
C0062 Anthropic AI-Orchestrated Campaign is the first formally documented LLM-orchestrated campaign in the framework. Attributed to GTG-1002 (PRC-aligned), it used Claude Code for offensive automation across multiple intrusion stages.
S9035 LAMEHUG (APT28 attributed) is the first malware family to query an LLM in live operations.
C0063 2025 Poland Wiper Attacks is a cross domain wiper campaign hitting NATO energy infrastructure, notable for being one of the first wiper campaigns to span both Enterprise and ICS domains. Two further campaigns landed in v19 that are worth tracking.
C0060 Operation AkaiRyū (a MirrorFace espionage campaign against European diplomatic targets) and C0061 Operation Digital Eye (a long-running PRC-aligned intrusion set targeting IT service providers in southern Europe).
New groups G1054 MirrorFace and G1055 VOID MANTICORE arrive in v19.
Existing groups including G0069 MuddyWater (v6.0 to v7.0 major update), G1017 Volt Typhoon, G0007 APT28, and G0129 Mustang Panda all received updates.
If you maintain adversary emulation libraries, check whether your existing scenarios still align with the updated group profiles.
Two existing Detection Strategies are formally deprecated alongside the split.
DET0317 Detection Strategy for Impair Defenses Across Platforms and DET0239 Detection Strategy for Impair Defenses Indicator Blocking. They are replaced by the new DET0900 Detection of Defense Impairment and adjacent strategies.
If your detection pipeline references DET0317 or DET0239 directly, for example in coverage reporting, vendor scorecards, or compliance attestations, remap those references during the same time as the technique ID remap.
"The attacker disabled Windows Defender before running the payload" and "the attacker proxied execution through rundll32 executable" no longer share the same bucket, which means coverage maps, heat maps, and board level posture reports become more honest.
A SOC that previously claimed eighty percent Defense Evasion coverage could have been measuring almost anything. With Stealth and Defense Impairment scored separately, the conversation becomes specific.
Where are we strong, where are we weak, and what does each gap actually require to close.
The second win is detection engineering. Stealth coverage and Defense Impairment coverage need different work, and treating them as one problem has historically produced poor coverage. The split forces detection engineers to confront the absence of telemetry question for the first time in a structured way. Most organisations cannot reliably detect when their own EDR stops reporting, and Defense Impairment as a first class tactic puts that gap on the agenda where it has always belonged.
Every detection mapped to TA0005 inherits a very narrow scope overnight. Rules will still fire but coverage claims based on the old tactic are now misleading and reports lose historical continuity. An year based coverage trend report referencing Defense Evasion becomes apples to oranges from April onward.
The T1562 rule packs are the worst of it. This is not just renaming, it is a merge and a reissue, so find and replace will not cut it.
Detection engineers need to read the crosswalk, locate every rule that touches T1562 or one of its sub-techniques, and rewrite the tactic and technique references against the new IDs. OR you can extensively use the AI systems to help you with that.
There is also a roadmap problem. MITRE has been explicit that v19 is phase one. Updated technique descriptions, further scope realignments, and additional deprecations are coming in later releases. The April work is the structural foundation, not the finished article. Anyone hoping this is a one time exercise should plan otherwise.
Again, half finished migrations are worse than no migration at all. Detection rules with stale technique IDs will still match events, but they will quietly stop appearing in coverage reports that filter by the new tactic.
A blind spot you used to have visibility into is worse than a blind spot you knew about.
So who actually does the work? The split is a taxonomy change, but the work it triggers is operational, and that work is not spread evenly. Different audiences inherit different problems on different timelines. Below is a walkthrough in roughly the order each audience feels the change.
Anyone shipping MITRE ATT&CK mappings has work to do and the amount of work tracks how cosmetically the vendor was using the framework in the first place. EDR and XDR vendors need to re tag every detection rule and re-render every coverage matrix.
The marketing diagrams that boasted full row Defense Evasion coverage age badly the moment v19 ships, and any customer with serious due diligence is going to ask about Defense Impairment specifically.
SIEM rules maintainers have the same problem at scale. Sigma, Splunk, Elastic detection rules and Sentinel rule library all need updated tactic references and new rules covering TA0112. The Sigma project's specification keys off tactic strings, so community rule updates have been moving since the v19 preview blog landed.
OpenCTI, MISP, and ThreatConnect all need their MITRE connectors updated, and the OpenCTI project already has an open issue against its connector for v19 tactic ordering. SOAR vendors with playbooks that branch on tactic IDs need new branches for TA0112, otherwise Defense Impairment alerts will fall through to default handling. Breach and attack simulation platforms have the most visible remap, because their entire value proposition is mapping to ATT&CK. AttackIQ, SafeBreach, Cymulate, and Picus have all published v19 alignment commitments.
The largest population affected and the one with the most day one operational change.
The mechanical work breaks into three pieces.
The first is remapping the existing rules. Every SIEM rule, dashboard, or coverage report that references TA0005 keeps firing after the v19 release, but against a narrower set of behaviours than before.
Every rule that references T1562 or its sub-techniques needs reworking against the crosswalk, because both parent technique and sub-technique IDs have changed underneath the rule.
The second piece is adding new Defense Impairment coverage. This is the gap the split exposed by design and it is the bigger investment of the three.
The third piece is the analyst facing change. The triage flow that treated all TA0005 alerts as one category now needs to differentiate between Stealth alerts (hunting prompt, confirm intent before action) and Defense Impairment alerts (containment prompt, treat host as suspect regardless of proven intent). This is intuitive once explained but needs a deliberate briefing before it sticks in workflows.
Adversary emulation tooling needs re-tagging across the board. Atomic Red Team tests mapped to T1562.x need new tactic and technique labels. MITRE Caldera plugins and ability files reference tactic IDs that have shifted. Custom emulation tooling with hardcoded tactic strings needs the same treatment. Engagement scoping language needs to change.
A statement of work that asks the red team to "demonstrate Defense Evasion coverage gaps" is now ambiguous, because the client may mean Stealth, Defense Impairment or both and the answer affects which tooling, which techniques and which detection assumptions are in scope.
Reporting templates need rework. TIBER, CBEST, GBEST, and equivalent regulatory red team frameworks all reference ATT&CK in their output formats. Internal team reports that listed observed tactics by name need updating before the next engagement report goes out.
Leadership inherits three conversations in the next ninety days. The first is reporting accuracy. Coverage percentages presented to the board last quarter that referenced "Defense Evasion" are now inaccurate against the v19 taxonomy. The second is the absence of telemetry gap. Most enterprises cannot reliably detect when their own EDR stops reporting, and Defense Impairment now has its own line on every coverage dashboard. The third is metrics and KPIs. Anything related to "Defense Evasion coverage" in SOC scorecards, MDR SLAs, or vendor evaluations needs replacing with two separate metrics. Compliance and regulatory standards reference ATT&CK indirectly through crosswalks, and those crosswalks will take three to six months to propagate through audit cycles.
The order of things matters. Done in the wrong sequence the remap creates a half migrated state that produces silent gaps, so it is worth being deliberate about how the work progress. The steps below combine what MITRE's own guidance published as operational playbooks ordered the way a working detection engineering team would actually sequence the project.
Pull MITRE's official crosswalk. The v19 release ships with both a JSON and CSV crosswalk that map every revoked or relocated object to its replacement, and an human readable detailed changelog alongside a machine-readable JSON changelog. The CSV is the fastest way to filter by change type (Revoked, Merged into new technique, Became new sub-technique) and prioritise the rules that need most work.
Figure 8 - MITRE's official crosswalk csv - https://attack.mitre.org/docs/subtechniques/de-split-crosswalk.csv
Inventory every reference. Search your defense stack for TA0005, defense evasion, T1562 and its sub-technique IDs, and T1211 Exploitation for Defense Evasion. SIEM rule metadata, SOAR playbooks, detection engineering documentation, purple team plans, threat models, BAS scenario tags, GRC control references, board reports, and customer facing artefacts all count.
Remap by intent, not by string match. For each detection, ask the operational question. Does this rule fire because the attacker is hiding inside legitimate activity or because the attacker is breaking my sensors? Stealth or Defense Impairment falls straight out of that question and the answer is usually obvious.
Build out new Defense Impairment coverage. Start with the basics that most environments do not have. EDR agent heartbeat monitoring with alerting on missed beacons, log volume baselines per source with alerts on sudden drops, Windows Event ID 1102 for cleared logs, auditd configuration changes on Linux, and driver loads of known vulnerable signed drivers cross referenced against the LOLDrivers project.
Use MITRE's official Detection Strategies as your starting point. The Detection Strategies framework launched in mid-2025 and expanded substantially in v19. Enterprise ATT&CK v19 now ships with six hundred and ninety-seven Detection Strategies, each providing platform-specific, vendor-agnostic analytics, log sources, and tunable parameters for a given technique.
Always validate do not just remap. Remapping a broken detection from one bucket to two buckets does not make it work. Run the procedures against the remapped rules and confirm they work. The remap effort is a free excuse to do the validation work that probably should have happened a year ago.
Update SOAR playbook routing and SOC analyst facing material. Playbooks that branch on tactic ID need a new branch for TA0112. A playbook that treats all former Defense Evasion alerts identically is missing the point of the split.
Refresh purple team and adversary emulation plans and exercises. If your organization runs CBEST, TIBER, GBEST, or in house red team engagements, the reporting templates need updating now not at the end of the quarter. Atomic Red Team test mappings, MITRE Caldera plugins, BAS exercise scenarios, and emulation plan documentation all carry the old tactic and technique IDs.
Brief leadership before they ask. Tactic counts in your last board deck are stale. Coverage percentages are changed by now. Get ahead of the "why did our Defense Evasion coverage drop from eighty two percent to fifty eight percent" question before it gets asked, because once it is asked the answer sounds defensive.
The work above is what BreachSimRange focuses on. We build breach simulation scenarios, security control validation exercises, and adversary emulation plans mapped to ATT&CK, and we have been remapping our own range content against v19 since the preview blog landed in March. If your organization is working through the same remap and wants a hand, get in touch.
No adversary changed their behaviour on 28 April. Mustang Panda did not file an amended TTP report. UNC1069 is still phishing maintainers and BYOVD is still the answer to "how do I make this EDR be quiet". What changed is how we name and organize our response to all of this. That is more useful than it sounds because bad taxonomy produces bad detection priorities and bad coverage claims, but it is not a silver bullet either. The split exposes a Defense Impairment coverage gap that was always present. ATT&CK v19 just made it impossible to ignore.
The path MITRE recommends through this change is concrete and it lines up with what I would recommend anyway. The crosswalk is the single source of truth. Not vendor remap guides, not blog posts including this one. Do not just rename TA0005 references, that gets you nowhere, because Stealth and Defense Impairment ask for different defensive responses. Rethink each detection by adversary intent.
Anyway, that is my brain dump on v19 and the Defense Evasion split. I will keep updating this post as more sources land and as our own remap work uncovers new things.
If you find any of this useful, or if I have got something wrong, please reach out. I would love to hear how other teams are handling the migration.