M1055: Do Not Mitigate
The Do Not Mitigate category highlights scenarios where attempting to mitigate a specific technique may inadvertently increase the organization's security risk or operational instability. This could happen due to the complexity of the system, the integration of critical processes, or the potential for introducing new vulnerabilities. Instead of direct mitigation, these situations may call for alternative strategies such as detection, monitoring, or response. The Do Not Mitigate category underscores the importance of assessing the trade-offs between mitigation efforts and overall system integrity. This mitigation can be implemented through the following measures:
Complex Systems Where Mitigation is Risky:
- Interpretation: In certain systems, direct mitigation could introduce new risks, especially if the system is highly interconnected or complex, such as in legacy industrial control systems (ICS). Patching or modifying these systems could result in unplanned downtime, disruptions, or even safety risks. - Use Case: In a power grid control system, attempting to patch or disable certain services related to device communications might disrupt critical operations, leading to unintended service outages.
Risk of Reducing Security Coverage:
- Interpretation: In some cases, mitigating a technique might reduce the visibility or effectiveness of other security controls, limiting an organization’s ability to detect broader attacks. - Use Case: Disabling script execution on a web server to mitigate potential PowerShell-based attacks could interfere with legitimate administrative operations that rely on scripting, while attackers may still find alternate ways to execute code.
Introduction of New Vulnerabilities:
- Interpretation: In highly sensitive or tightly controlled environments, implementing certain mitigations might create vulnerabilities in other parts of the system. For instance, disabling default security mechanisms in an attempt to resolve compatibility issues may open the system to exploitation. - Use Case: Disabling certificate validation to resolve internal communication issues in a secure environment could lead to man-in-the-middle attacks, creating a greater vulnerability than the original problem.
Negative Impact on Performance and Availability:
- Interpretation: Mitigations that involve removing or restricting system functionalities can have unintended consequences for system performance and availability. Some mitigations, while effective at blocking certain attacks, may introduce performance bottlenecks or compromise essential operations. - Use Case: Implementing high levels of encryption to mitigate data theft might result in significant performance degradation in systems handling large volumes of real-time transactions.
Analyst context for executives and security teams
“Do Not Mitigate” is a decision category, not a control to deploy. It matters when a direct fix could create more risk than the ATT&CK technique itself, such as disrupting complex or legacy industrial systems, reducing security visibility, disabling security mechanisms, or harming availability and performance. For leaders, the value is forcing an explicit risk decision: when prevention is too dangerous, the organization must prove it has monitoring, detection, response, and exception governance instead.
Executive priority
Treat this as an exception-management and resilience issue. Executives should ask whether high-risk systems have documented rationale for not applying a direct mitigation, who owns the residual risk, what compensating detection and response capabilities exist, and how the decision will be defended during audits or incident reviews. This is especially important where operational downtime, safety risk, critical process integration, or reduced visibility could outweigh the benefit of a technical restriction.
Technical view
For SOC, detection engineering, and IR teams, M1055 means coverage should be validated through compensating controls rather than assumed prevention. The relationship context ties this mitigation category to Execution Guardrails, Environmental Keying, and Mutual Exclusion, which are stealth-related behaviors on the related platforms listed for those techniques: ESXi, Linux, macOS, and Windows. Teams should validate whether they can observe suspicious execution constraints, environment-specific execution behavior, and mutex-like execution gating where applicable, while also preserving legitimate administrative and operational functions that direct mitigation might break.
Likely telemetry
- Risk acceptance and control-exception records documenting why direct mitigation is not applied
- Change-management records for complex, legacy, industrial, or tightly integrated systems
- Endpoint and workload execution telemetry on related platforms where Execution Guardrails or its sub-techniques are in scope
- Process, script, and administrative activity logs where disabling functionality could reduce operations or visibility
- Security control health and coverage evidence showing monitoring remains active when prevention is not feasible
Detection direction
- Do not interpret “Do Not Mitigate” as “ignore.” Validate that monitoring and response are explicitly mapped to the related stealth techniques: Execution Guardrails, Environmental Keying, and Mutual Exclusion.
- Tune detections to account for environment-specific execution logic and mutex-like gating without relying on a single prevention control.
- Check for blind spots created by business exceptions, such as disabled script restrictions, weakened validation, or reduced logging introduced for compatibility or availability reasons.
- Require evidence that compensating monitoring still works after any decision to avoid or roll back a mitigation.
- Use local baselines to reduce false positives, because legitimate administrative scripting, system synchronization mechanisms, and performance-sensitive configurations may resemble parts of the related behavior.
Mitigation priorities
- First, perform a documented trade-off assessment before applying controls that could destabilize critical, complex, or highly integrated systems.
- If direct mitigation is too risky, formally record the exception, affected systems, accountable owner, review date, and residual risk.
- Prioritize compensating detection, monitoring, and response coverage for the related techniques instead of leaving the behavior unmanaged.
- Preserve essential security mechanisms where possible; avoid weakening controls such as validation or visibility merely to resolve compatibility issues without risk review.
- Test changes in representative environments before production deployment, especially where availability, performance, or safety could be affected.
Analyst notes and limits
This ATT&CK object is unusual because it describes when not to apply a direct mitigation. Its practical value is governance: deciding when prevention creates unacceptable operational or security side effects and ensuring compensating measures are real, tested, and owned. The supplied relationships connect this category to stealth behaviors involving execution constraints, environmental keying, and mutual exclusion.
The official object provides no detection text, no platforms for the mitigation itself, and no vendor- or control-specific implementation guidance. Platform references come only from the related techniques. Local system criticality, safety constraints, logging coverage, and business process dependencies are required to make a defensible decision.
Do Not Mitigate
The Do Not Mitigate category highlights scenarios where attempting to mitigate a specific technique may inadvertently increase the organization's security risk or operational instability. This could happen due to the complexity of the system, the integration of critical processes, or the potential for introducing new vulnerabilities. Instead of direct mitigation, these situations may call for alternative strategies such as detection, monitoring, or response. The Do Not Mitigate category underscores the importance of assessing the trade-offs between mitigation efforts and overall system integrity. This mitigation can be implemented through the following measures:
Complex Systems Where Mitigation is Risky:
- Interpretation: In certain systems, direct mitigation could introduce new risks, especially if the system is highly interconnected or complex, such as in legacy industrial control systems (ICS). Patching or modifying these systems could result in unplanned downtime, disruptions, or even safety risks. - Use Case: In a power grid control system, attempting to patch or disable certain services related to device communications might disrupt critical operations, leading to unintended service outages.
Risk of Reducing Security Coverage:
- Interpretation: In some cases, mitigating a technique might reduce the visibility or effectiveness of other security controls, limiting an organization’s ability to detect broader attacks. - Use Case: Disabling script execution on a web server to mitigate potential PowerShell-based attacks could interfere with legitimate administrative operations that rely on scripting, while attackers may still find alternate ways to execute code.
Introduction of New Vulnerabilities:
- Interpretation: In highly sensitive or tightly controlled environments, implementing certain mitigations might create vulnerabilities in other parts of the system. For instance, disabling default security mechanisms in an attempt to resolve compatibility issues may open the system to exploitation. - Use Case: Disabling certificate validation to resolve internal communication issues in a secure environment could lead to man-in-the-middle attacks, creating a greater vulnerability than the original problem.
Negative Impact on Performance and Availability:
- Interpretation: Mitigations that involve removing or restricting system functionalities can have unintended consequences for system performance and availability. Some mitigations, while effective at blocking certain attacks, may introduce performance bottlenecks or compromise essential operations. - Use Case: Implementing high levels of encryption to mitigate data theft might result in significant performance degradation in systems handling large volumes of real-time transactions.
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 |
|---|---|---|---|
| Enterprise | T1480 | Execution Guardrails | Execution Guardrails likely should not be mitigated with preventative controls because it may protect unintended targets from being compromised. If targeted, efforts should be focused on preventing adversary tools from running earlier in the chain of activity and on identifying subsequent malicious behavior if compromised. |
| Enterprise | T1480.002 | Mutual Exclusion Sub-technique | Execution Guardrails likely should not be mitigated with preventative controls because it may protect unintended targets from being compromised. If targeted, efforts should be focused on preventing adversary tools from running earlier in the chain of activity and on identifying subsequent malicious behavior if compromised. |
| Enterprise | T1480.001 | Environmental Keying Sub-technique | Environmental Keying likely should not be mitigated with preventative controls because it may protect unintended targets from being compromised via confusion of keys by the adversary. Mitigation of this technique is also unlikely to be feasible within most contexts because there are no standard attributes from which an adversary may derive keys. If targeted, efforts should be focused on preventing adversary tools from running earlier in the chain of activity and on identifying subsequent malicious behavior if compromised. |
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 (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 29ee5c8b070e… |
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]
mitre-attack M1055Open 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.