TA0110: Persistence
The adversary is trying to maintain their foothold in your ICS environment.
Persistence consists of techniques that adversaries use to maintain access to ICS systems and devices across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that allow them to secure their ongoing activity and keep their foothold on systems. This may include replacing or hijacking legitimate code, firmware, and other project files, or adding startup code and downloading programs onto devices.
Analyst context for executives and security teams
Persistence in an ICS environment matters because it is about an adversary keeping a foothold after events that should normally remove access, such as restarts, credential changes, or operational interruptions. For business leaders, the risk is not just unauthorized access; it is the possibility that recovery actions may be incomplete if altered code, firmware, project files, startup logic, or downloaded programs remain in the environment.
Executive priority
Treat ICS persistence as a resilience and recovery assurance issue. Leaders should ask whether incident response plans can prove that industrial systems and devices are returned to a trusted state, not merely that accounts were reset or hosts were rebooted. This tactic should inform budget and control priorities around configuration integrity, backup validation, change governance, and evidence needed for audit or post-incident decisions.
Technical view
MITRE provides this as an ICS tactic with no platform-specific scope and no official detection guidance. SOC, IR, and engineering teams should therefore validate local coverage against the described persistence patterns: unauthorized configuration changes, replacement or hijacking of legitimate code, firmware or project file changes, startup code, and downloaded programs on devices. Detection and response should focus on whether teams can compare current device and project state against trusted baselines and explain any change through approved engineering activity.
Likely telemetry
- ICS asset and device configuration baselines
- Firmware and project file inventories or change records
- Engineering workstation and controller change logs where available
- Startup logic or startup code records where available
- Program download or transfer records to industrial devices where available
Detection direction
- Validate whether the organization has authoritative baselines for ICS code, firmware, project files, and device configurations before relying on alerting.
- Tune monitoring around unexpected persistence-enabling changes, especially changes that survive restarts or credential resets.
- Correlate technical changes with approved maintenance windows and change records to reduce false positives from legitimate engineering work.
- Do not assume enterprise endpoint controls cover this tactic; the supplied ATT&CK object is ICS-focused and does not specify platforms.
- Because MITRE supplies no official detection text for this tactic, local engineering telemetry and configuration governance are required to define practical detection logic.
Mitigation priorities
- Prioritize trusted backups and known-good baselines for ICS configurations, firmware, code, and project files.
- Strengthen change control for engineering actions that can alter device behavior or survive restarts.
- Limit and review access capable of downloading programs, changing startup behavior, or modifying project files and firmware.
- Include persistence checks in ICS incident response playbooks before declaring recovery complete.
- Test restoration procedures to confirm they remove unauthorized persistent changes rather than only restoring connectivity or credentials.
Analyst notes and limits
This take is based on the ATT&CK ICS tactic TA0110 Persistence and its official description. The object has no supplied relationships, no platforms, and no official detection guidance, so the practical emphasis is on validation questions and evidence classes rather than specific analytics.
The supplied STIX fields do not identify specific techniques, assets, products, procedures, or detection logic. Any final control design or monitoring rule must be based on the organization’s actual ICS architecture, available engineering telemetry, and approved change processes.
Persistence
The adversary is trying to maintain their foothold in your ICS environment.
Persistence consists of techniques that adversaries use to maintain access to ICS systems and devices across restarts, changed credentials, and other interruptions that could cut off their access. Techniques used for persistence include any access, action, or configuration changes that allow them to secure their ongoing activity and keep their foothold on systems. This may include replacing or hijacking legitimate code, firmware, and other project files, or adding startup code and downloading programs onto devices.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 4b19d980d854… |
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 TA0110Open 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.